Tres investigaciones publicadas la primera semana de agosto apuntan al mismo lugar: la capa donde el usuario prueba quién es y donde recibe lo que le mandan. Passkeys, casilla de correo y la red por la que se conecta cuando viaja.
Ninguna requiere romper criptografía. Todas aprovechan que el eslabón débil está en la interfaz, no en el algoritmo.
Pass-ta-key: tres formas de abusar de las passkeys sincronizadas
Unit 42, de Palo Alto Networks, documentó el 3 de agosto tres ataques contra las passkeys sincronizadas en Google Password Manager. Afectan a equipos Windows con TPM que usan Chrome.
La precondición es importante y conviene decirla de entrada: el malware ya tiene que estar corriendo en la máquina. Esto no es un ataque remoto contra las passkeys en general, es una escalada desde un equipo ya comprometido.
Dicho eso, lo que se logra desde ahí es serio:
- Pass-ta-key: el malware se hace pasar por un dispositivo de confianza y obtiene una respuesta de autenticación válida, sin privilegios de administrador y sin interacción del usuario.
- Silver Pass-ta-key: el atacante registra su propia clave de verificación de usuario contra el autenticador en la nube de Google, lo que le abre las cuentas que validan esa verificación.
- Golden Pass-ta-key: forzando un re-registro, extrae de la memoria la clave maestra que cifra todas las passkeys sincronizadas.
Las recomendaciones de los investigadores apuntan al diseño: validar de verdad la verificación de usuario, endurecer el flujo de re-registro y evitar que la clave maestra quede accesible en la memoria del navegador.
Cuando el CSS de un mail se escapa del mail
Gareth Heyes, de PortSwigger, presentó en Black Hat USA una investigación que parte de una premisa que suena inofensiva: los clientes de webmail permiten algo de HTML y CSS dentro del cuerpo del mensaje.
El hallazgo es que ese contenido puede escapar del límite del mensaje e interferir con la interfaz del webmail que lo está mostrando.
Hay dos caminos: abusar del HTML y CSS que sí están permitidos, o explotar la discrepancia entre lo que el sanitizador aprueba y lo que el navegador termina ejecutando.
El ejemplo más claro es Outlook sobre Firefox. Elementos label permitidos disparan controles que están fuera del mensaje, y JavaScript convierte atributos personalizados ya sanitizados en nodos del DOM con CSS no permitido. Con eso se logra disfrazar un elemento select como un campo de contraseña.
El estado por cliente al momento de la publicación:
- Outlook: la captura de contraseñas seguía funcionando.
- Gmail: el bypass vía
image-set()seguía funcionando. - Yahoo y AOL Mail: vulnerables, con robo de tokens de login demostrado.
- Fastmail: dos fallas de CSS corregidas.
- Proton Mail: el bypass del proxy dejó de funcionar.
La parte que más va a dar que hablar es la que cruza con los asistentes de IA. En Gmail con Claude Cowork, instrucciones inyectadas lograron que el asistente recuperara un token de Slack y lo dejara escrito en un borrador HTML.
Es decir: el asistente que lee tu correo por vos también lee las instrucciones ocultas que alguien te mandó por correo.
CaptiveCrunch: el Wi-Fi del hotel como puerta al Microsoft 365
Microsoft vinculó una campaña global contra redes Wi-Fi de hoteles y centros de conferencias con Midnight Blizzard (APT29), concretamente con el subgrupo Storm-2945. Está activa al menos desde mayo de 2026.
La secuencia es prolija:
- Comprometen la infraestructura compartida de la red Wi-Fi del hotel.
- Modifican la configuración de DNS para interceptar las conexiones.
- Redirigen a portales falsos de Microsoft 365.
- Entregan malware mediante «actualizaciones» falsas con prompts de tipo ClickFix.
El malware es a medida. CornFlake es un troyano escrito en Go con acceso remoto, registro de teclas, vigilancia de micrófono y cámara y robo de tokens de sesión de Microsoft 365. ChocoShell es una herramienta en PowerShell que extrae credenciales de los navegadores y tokens de Azure AD.
Las recomendaciones de Microsoft son las que uno esperaría pero que casi nadie aplica en viaje: usar conexión celular propia en vez del Wi-Fi del lugar, MFA con passkeys, y desconfiar por completo de cualquier actualización ofrecida desde un portal cautivo.
Y el dominio que nadie creía real
Como nota al pie del mismo problema, dos investigadores compraron dominios baratos como noreply.net y noreply.us y montaron casillas catch-all.
Desde fines de 2024, solo el dominio más grande acumuló unos 400.000 correos (cerca de 700 por día), provenientes de más de 6.200 dominios raíz y 14.000 direcciones remitentes.
Adentro había partes de siniestros, altas de cuentas en plataformas escolares, órdenes de servicio y credenciales de prueba. Empresas configurando notificaciones automáticas hacia una dirección que asumían inexistente, o reescribiendo las casillas de empleados que se fueron hacia ese dominio.
Los investigadores lo trataron como un honeypot accidental, presentaron los hallazgos en DEF CON y vienen notificando en privado a las organizaciones afectadas.
El factor que falta no es un factor más
Lo que conecta a los cuatro casos es que el control existía y estaba bien elegido. Las passkeys son mejores que las contraseñas, el sanitizador de HTML está puesto, la MFA está habilitada y el dominio de notificaciones parecía un placeholder inofensivo.
Lo que falla es el borde: dónde termina el contenido del atacante y dónde empieza tu interfaz, tu proceso o tu configuración.
¿Sabés a qué dirección van las notificaciones automáticas de tus sistemas? Te leemos en los comentarios.
Fuentes
- BleepingComputer — New Pass-ta-key attacks let malware hijack Google-synced passkeys
- The Hacker News — New CSS attacks can break webmail defenses
- BleepingComputer — Hotel Wi-Fi attacks use custom malware to breach Microsoft 365 accounts
- PC Perspective — Did you realize noreply.us and noreply.net are real domains?
