Phishing con PWA que simula Google Security: riesgos para MFA por SMS y controles prioritarios en empresas

Una campaña reciente muestra cómo un sitio falso puede convertir el navegador en un proxy para atacantes, capturar OTP y exfiltrar datos sin explotar vulnerabilidades. Qué cambia para equipos SysAdmin, DevOps y Seguridad.

Durante años, muchos equipos de infraestructura asumieron que el principal riesgo en phishing era la captura de contraseña. La campaña documentada esta semana por BleepingComputer y Malwarebytes obliga a actualizar ese modelo mental: los atacantes ya no necesitan solamente una clave, sino que están usando Progressive Web Apps (PWA), permisos del navegador y componentes móviles para construir un canal de control persistente sobre el dispositivo de la víctima.

En términos operativos, el caso no es un “nuevo CVE” que se resuelve con un parche. Es un abuso de funciones legítimas del navegador y del sistema operativo, potenciado por ingeniería social. Para entornos corporativos, eso desplaza la prioridad desde el parcheo tradicional hacia políticas de identidad, hardening del navegador, telemetría de permisos y controles de salida.

Qué se observó en la campaña y por qué importa

El flujo reportado es simple y efectivo: un sitio que se presenta como chequeo de seguridad de Google guía al usuario por pasos para instalar una PWA, habilitar notificaciones y conceder permisos sensibles. A partir de ahí, el actor obtiene capacidades de vigilancia y ejecución remota sin desplegar malware clásico en escritorio.

• Captura de OTP y datos de sesión: según el análisis de Malwarebytes, el kit intenta extraer códigos de un solo uso y otros datos transitorios cuando la app web está activa.
• Canal persistente vía Service Worker: aun cerrando la pestaña, el worker puede seguir recibiendo notificaciones y tareas, dependiendo de permisos y soporte del navegador.
• Proxy desde la máquina víctima: el componente de relay permite enrutar solicitudes a través del navegador comprometido, lo que complica controles basados solo en IP.
• Reconocimiento interno: se describe escaneo de red local desde el contexto del navegador para identificar hosts accesibles.

La consecuencia práctica para SOC y equipos de plataforma es clara: un incidente de “phishing de credenciales” puede evolucionar rápidamente a living-off-the-browser, con exposición de datos, abuso de sesiones y pivot interno.

El punto débil: OTP por SMS como factor de alta fricción y baja resistencia

El incidente también reabre una discusión conocida: el uso extensivo de OTP por SMS como segundo factor en procesos críticos. La documentación de MDN sobre WebOTP recuerda que la API está diseñada para mejorar experiencia de usuario, pero también subraya que SMS no es el mecanismo más robusto frente a phishing y secuestro de canal.

NIST, en SP 800-63B, refuerza la dirección estratégica: para niveles de aseguramiento superiores, las organizaciones deben ofrecer métodos resistentes a phishing. Esto no significa apagar SMS de forma inmediata en toda la empresa, pero sí definir un plan de reducción por riesgo y criticidad de activo.

Implicancias para SysAdmin/DevOps/SecOps

Desde operación, hay cuatro impactos directos que conviene priorizar esta semana:

1) Identidad y autenticación

• Migrar cuentas privilegiadas y de administración a mecanismos resistentes a phishing (passkeys/FIDO2 o llaves físicas donde aplique).
• Restringir OTP por SMS a casos de contingencia, con monitoreo de uso anómalo.
• Revisar políticas de reautenticación en paneles de infraestructura (VPN, IAM, CI/CD, cloud consoles).

2) Hardening del navegador corporativo

• Gestionar por política la instalación de PWA en endpoints administrados.
• Limitar permisos de notificaciones, portapapeles y geolocalización para dominios no aprobados.
• Bloquear o auditar dominios recientemente registrados con señuelos de marca.

3) Detección y respuesta

• Incorporar eventos de permisos del navegador al pipeline de detección (EDR + logs de navegador cuando estén disponibles).
• Hunt de sesiones sospechosas: múltiples desafíos MFA, cambios rápidos de IP/UA y accesos fuera de patrón horario.
• Playbook específico para “compromiso vía PWA”: revocación de sesiones, limpieza de service workers, revisión de extensiones/apps instaladas.

4) Red y egress control

• Aplicar controles de salida para reducir tunelización HTTP/WebSocket no autorizada.
• Segmentar recursos internos para minimizar impacto de un navegador comprometido dentro de la red de usuario.
• Correlacionar tráfico a C2 con telemetría de identidad para acelerar contención.

Plan de acción recomendado (72 horas)

1. Comunicación interna breve: recordar que Google no exige instalar apps desde pop-ups para “checks de seguridad”.
2. Revisión de MFA: inventario de aplicaciones críticas que aún dependen de SMS OTP y priorización de migración.
3. Políticas de navegador: validación de baseline MDM/Intune/Workspace One para PWA y permisos sensibles.
4. Threat hunting puntual: búsqueda de actividad relacionada con dominios de señuelo y picos de prompts MFA.
5. Simulación controlada: ejercicio interno de respuesta para phishing con abuso de navegador (sin payload real).

El aprendizaje de fondo es operativo: en 2026, parte del malware ya no “rompe” el navegador; lo usa como plataforma. Por eso, la defensa efectiva combina identidad fuerte, políticas de cliente, telemetría y disciplina de respuesta, no solo antivirus o parcheo.

Fuentes

• BleepingComputer: campaña con PWA falsa de Google Security (02 Mar 2026)
• Malwarebytes: análisis técnico del toolkit y cadena de infección
• MDN: WebOTP API y consideraciones de seguridad de SMS OTP
• NIST SP 800-63B: lineamientos de autenticación y resistencia a phishing
• Google Account Help: 2-Step Verification, passkeys y métodos recomendados