Inicio de sesión sospechoso en Google Workspace y la 2SV
Investigar un inicio de sesión sospechoso en Google Workspace: is_suspicious, ASN de hosting, países nuevos, viaje imposible, fallos en ráfaga y 2SV.
En resumen. En el registro de inicios de sesión (User log), compruebe cuatro señales para la cuenta sospechosa: la marca de Google (suspicious_login, is_suspicious=true, avisos de cuenta desactivada), un inicio de sesión correcto desde un ASN de hosting, un país nuevo o un viaje imposible, y ráfagas de fallos. Después revise qué cambió la sesión en la cuenta: 2sv_disable, recovery_email_edit, recovery_phone_edit. Un inicio de sesión correcto desde un VPS justo después de que el usuario pulsara un enlace es la huella del phishing adversary-in-the-middle.
El inicio de sesión es donde empieza la cronología de un compromiso de Workspace, y a menudo donde están sus únicos indicadores de red claros. Este artículo explica qué guarda el registro de inicios de sesión, cómo leerlo y dónde están las trampas.
Qué guarda el registro de inicios de sesión
Los eventos de inicio de sesión (y de cuenta de usuario) están documentados en el apéndice Login audit activity events de Google. Los que importan ante una toma de control:
| Evento | Significado |
|---|---|
login_success, login_failure | Resultado del inicio de sesión, con login_type, login_challenge_method, is_suspicious |
login_challenge, login_verification | Desafío de 2SV o de riesgo presentado / superado |
suspicious_login, suspicious_login_less_secure_app, suspicious_programmatic_login | El motor de riesgo de Google bloqueó o marcó el intento |
user_signed_out_due_to_suspicious_session_cookie | Google detectó una cookie de sesión sospechosa y cerró la sesión del usuario |
account_disabled_password_leak, account_disabled_hijacked, gov_attack_warning | Avisos de cuenta |
risky_sensitive_action_allowed / _blocked | Acción sensible tras un inicio de sesión de riesgo |
2sv_disable, 2sv_enroll, titanium_unenroll, passkey_removed | Cambios de 2SV y de Protección Avanzada |
recovery_email_edit, recovery_phone_edit, password_edit | Cambios de recuperación y de contraseña |
Cada registro lleva también la dirección IP. En la API Reports lleva además networkInfo, con el ASN de la IP y un código de región. Esos datos de red son los que hacen posibles las tres comprobaciones siguientes.
Señal 1: Google ya lo marcó
Empiece por la evidencia más barata. El motor de riesgo de Google decide cuándo un inicio de sesión está «fuera del patrón habitual» (acerca de las alertas de inicio de sesión sospechoso). Un login_success con is_suspicious = true significa que el intento pasó igualmente. user_signed_out_due_to_suspicious_session_cookie es especialmente interesante en casos AiTM: la sesión fue robada y Google lo notó.
Estas marcas no son exhaustivas. Muchos inicios de sesión AiTM no se marcan, porque la víctima superó realmente el desafío.
Señal 2: una red de hosting
Los kits AiTM (proxies inversos al estilo de Evilginx) se sitúan entre la víctima y Google. La víctima escribe la contraseña y aprueba la solicitud en la página retransmitida. Google ve llegar el inicio de sesión desde el servidor del proxy, normalmente un VPS en DigitalOcean, OVH, Hetzner, Vultr, AWS o similares. MITRE lo recoge como T1557 Adversary-in-the-Middle, que lleva a T1078.004 Cloud Accounts.
El analizador compara el ASN de cada inicio de sesión correcto (también SAML) con una lista revisada de proveedores de hosting y marca las coincidencias con gravedad alta. Antes de escalar, descarte su propia infraestructura: concentradores de VPN corporativa, escritorios virtuales en la nube y proxies de seguridad salen todos por estas redes.
Señal 3: la geografía
- País nuevo. Tras un historial de al menos tres inicios de sesión desde países conocidos, un éxito desde un país nunca visto para ese usuario. Por sí solo es de gravedad media: la gente viaja.
- Viaje imposible. Dos inicios de sesión correctos desde países a más de 500 km a una velocidad implícita superior a 900 km/h. Una de las dos sesiones no es el usuario, o hay una VPN de por medio.
Ambas dependen de un código de región por evento. La API Reports lo proporciona. Muchas exportaciones CSV de la consola, no. Sin él, estas comprobaciones no pueden ejecutarse. Véase limitaciones de los registros de auditoría.
Señal 4: ráfagas de fallos
Diez o más eventos login_failure en diez minutos contra una cuenta apuntan a adivinación o pulverización de contraseñas (T1110). Por sí solo es un hallazgo de gravedad media. Se vuelve importante cuando le sigue un éxito desde la misma IP.
Después: ¿qué cambió la sesión?
Tras el inicio de sesión, el atacante hace duradero su acceso:
2sv_disable(otitanium_unenrollpara la Protección Avanzada) facilita el siguiente inicio de sesión. MITRE: T1556.006 Multi-Factor Authentication. Un administrador puede hacer lo mismo desde el registro de Admin (TURN_OFF_2_STEP_VERIFICATION,UNENROLL_USER_FROM_STRONG_AUTH).recovery_email_edit/recovery_phone_editpermiten al atacante recuperar la cuenta después de que usted restablezca la contraseña. Compruebe siempre los nuevos valores con el usuario.
El analizador marca ambas familias y, si siguen a un inicio de sesión de riesgo en la misma cuenta, eleva a crítica la cadena «inicio de sesión de riesgo → cambio de seguridad».
Por qué la 2SV no lo impidió y qué funciona
Los códigos SMS, los de aplicaciones autenticadoras y las solicitudes en el teléfono son todos retransmisibles: la víctima los completa en el proxy del atacante. Los métodos resistentes al phishing (llaves de seguridad y llaves de acceso FIDO2/WebAuthn) están ligados al origen real y no funcionan a través de un proxy. La hoja informativa de CISA sobre MFA resistente al phishing explica la diferencia. Google permite a los administradores exigir llaves de seguridad por unidad organizativa o grupo. Empiece por finanzas y administradores. Véase también verificación en dos pasos.
Respuesta
- Restablezca las cookies de inicio de sesión del usuario para matar la sesión robada.
- Revise qué vino después: autorizaciones OAuth, reenvío, filtros. Véase la guía de investigación.
- Restablezca la contraseña después de eliminar la persistencia, y restaure la 2SV y las opciones de recuperación.
- Pivote sobre las IP del atacante en la pestaña Entidades del analizador para encontrar otras cuentas afectadas.
Siguiente en la serie: reglas de reenvío de Gmail creadas por atacantes. Si su Workspace inicia sesión a través de Okta, el lado del proveedor de identidad del mismo inicio de sesión se trata en oktaforensics.com.
FAQ
¿Por qué entró el atacante pese a la verificación en dos pasos?
Los kits de phishing adversary-in-the-middle sirven la página real de inicio de sesión de Google a través de un proxy. La víctima escribe la contraseña y aprueba la solicitud o teclea el código, y el kit se queda con la sesión resultante. Solo los métodos resistentes al phishing, como las llaves de seguridad y las llaves de acceso, están ligados al sitio real y lo resisten.
¿Un inicio de sesión desde un VPS o un proveedor cloud es siempre malicioso?
No. Las VPN corporativas, las pasarelas web seguras y algunos servicios de escritorio remoto salen por redes cloud. Compare primero la IP con su propia infraestructura. Para un usuario normal sin esa configuración, un inicio de sesión correcto desde un proveedor de hosting es una señal fuerte de toma de control.