Uber breach por Lapsus$: MFA fatigue contra contractor y cómo defender tu empresa
Hace seis días, el 15 de septiembre, el grupo Lapsus$ comprometió a Uber mediante una técnica que ya se está volviendo manual de procedimiento para actores de amenaza modernos: ingeniería social contra un contractor externo, MFA fatigue para vencer la autenticación multifactor, y luego escalada lateral encadenada hasta llegar a G-Suite, Slack, AWS, OneLogin y el repositorio de scripts internos. El atacante (de 18 años según los reportes públicos) publicó capturas en el propio Slack interno de Uber para anunciar lo que había logrado. Es el segundo incidente mayor del grupo en 2022 después de NVIDIA, Samsung, Microsoft y Okta.
Para CISOs e IT managers en México, este caso es lectura obligada porque expone vectores que están operando contra empresas locales hoy mismo, no en escenarios hipotéticos. En este artículo desempacamos la anatomía del ataque, los controles que sí protegen y el plan defensivo razonable para empresas medianas.
Anatomía del ataque, paso a paso
La cadena que reconstruyeron analistas en los días posteriores al incidente sigue una secuencia conocida.
Paso uno: identificar a un contractor externo. Uber tiene relaciones con cientos de contractors EXT con accesos a sistemas internos. El atacante eligió uno cuyas credenciales probablemente ya estaban circulando en mercados de credenciales robadas (típicamente vendidas en foros por entre 5 y 20 dólares por cuenta).
Paso dos: intentar autenticarse repetidamente. Con usuario y contraseña en mano, el atacante intentó autenticarse contra Uber. La autenticación requería MFA, así que el contractor empezó a recibir push notifications en su dispositivo solicitando aprobar el inicio de sesión.
Paso tres: MFA fatigue. El atacante mantuvo intentos durante un periodo prolongado, generando push notifications continuas. Esta técnica explota fatiga psicológica: tarde o temprano, el usuario aprueba "para que se detenga" o porque asume que es un glitch del sistema.
Paso cuatro: ingeniería social vía WhatsApp. Para acelerar la aprobación, el atacante contactó al contractor por WhatsApp haciéndose pasar por staff de TI de Uber, le explicó que necesitaba aprobar el push para resolver un problema, y consiguió la cooperación.
Paso cinco: persistencia inicial. Una vez con sesión válida, el atacante exploró el ambiente accesible al contractor: conexión a la VPN corporativa.
Paso seis: descubrimiento de credenciales privilegiadas. El atacante encontró un script de PowerShell en un share de red interno que contenía credenciales hardcodeadas con privilegios elevados, incluyendo a la consola de administración de PAM (privileged access management).
Paso siete: escalada masiva. Con esas credenciales, el atacante accedió a OneLogin (proveedor de SSO), a G-Suite, a Slack, a AWS, y a otros sistemas críticos. Publicó evidencias en el Slack interno de Uber.
Lo que falló (y los patrones repetidos)
El caso es ilustrativo porque concentra cuatro fallas que vemos repetidamente en empresas mexicanas medianas.
MFA basado en push notification es vulnerable a fatigue. Los push approvals tipo "aprobar/rechazar" son cómodos pero psicológicamente débiles. Bajo presión sostenida, la gente cede. El propio Uber tenía MFA, no es que no lo tuviera; el problema es el tipo de MFA.
Contractors con accesos no diferenciados de empleados. El contractor podía acceder a la red interna y desde ahí a recursos amplios. La segmentación de accesos para externos suele ser más laxa de lo que debería.
Credenciales hardcodeadas en scripts y shares de red. Esto es el "muerto en el clóset" de muchas empresas. PowerShell scripts con passwords, archivos .ps1 o .bat con credenciales en variables, hojas Excel en SharePoint con accesos. Un atacante con cualquier acceso al ambiente las encuentra rápido.
Falta de detección de anomalías en escalada lateral. Acceso desde dispositivo nuevo, en horario inusual, con comportamiento de exploración: todas señales que un SOC moderno debería detectar. La detección reactiva ya no alcanza.
Controles que sí protegen
La defensa contra este patrón existe y es relativamente clara. No es trivial implementarla pero las piezas son conocidas.
MFA resistente a phishing. FIDO2/WebAuthn con llaves de hardware (YubiKey o equivalente) elimina el vector de phishing y de fatigue. El usuario tiene que tocar físicamente la llave conectada al dispositivo correcto; no hay forma de que un atacante remoto la engañe. El costo por usuario es de 25-50 USD por llave; para empresa mediana, inversión menor frente al alternativo.
Number matching en push notifications. Si por costo o usabilidad no se puede mover todo a FIDO2, el siguiente nivel es MFA con number matching: la app muestra un número que el usuario debe escribir en el sistema que está autenticando, no solo aprobar. Reduce dramáticamente el éxito de fatigue.
Política de máximo de intentos MFA. Bloqueo temporal después de N intentos fallidos en ventana de tiempo. Detiene fatigue antes de que llegue al usuario.
Just-in-time access para contractors. Accesos otorgados por solicitud explícita, con duración limitada y aprobación de manager. Reduce drásticamente el blast radius si una credencial de contractor se compromete.
Eliminación sistemática de credenciales en código y shares. Auditorías periódicas con herramientas tipo gitleaks, trufflehog o equivalentes. Política de no-secrets-in-code aplicada en CI con bloqueo de commits. Migración a vaults reales (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).
Detección de comportamiento anómalo. UEBA o equivalente en tu SIEM, configurado para alertar en patrones como nuevo dispositivo, geolocalización inesperada, escalada de privilegios, descarga inusual de recursos.
Plan de respuesta a incidente probado. No solo escrito, sino simulado en ejercicio anual. El equipo debe saber qué hacer en las primeras dos horas sin tener que improvisar.
Plan defensivo para empresa mediana mexicana
Para una empresa con 100 a 1,000 empleados que quiera revisar exposición frente a este patrón, el plan a 90 días se ve así.
Días 1-30: diagnóstico. Inventario de proveedores y contractors con acceso a sistemas internos. Inventario de tipos de MFA configurados (push, SMS, TOTP, FIDO). Búsqueda activa de credenciales hardcodeadas en repos y en shares de red. Revisión de qué accesos tiene cada cuenta de contractor.
Días 31-60: cierre de las brechas más urgentes. Migración de cuentas privilegiadas a MFA con number matching o FIDO2. Rotación de credenciales encontradas en código. Revisión y reducción de accesos de contractors. Activación de bloqueo por intentos múltiples MFA.
Días 61-90: refuerzo y detección. Despliegue de detección de anomalías en SIEM. Capacitación de equipo de TI y de usuarios sobre MFA fatigue. Simulacro de incidente con escenario tipo Uber. Documentación de plan de respuesta actualizado.
Lo que también va a doler en los próximos meses
El éxito de Lapsus$ no es accidente. Es señal de que un perfil nuevo de atacante (jóvenes con habilidad técnica moderada pero excelentes en ingeniería social, motivados por reputación más que por dinero) está operando con éxito contra objetivos grandes. Espera más casos similares. Empresas medianas mexicanas no son inmunes; al contrario, son objetivo atractivo porque suelen tener controles más débiles que las multinacionales.
Cierre
El breach a Uber es un caso de estudio que conviene tener fresco en el equipo de seguridad. La técnica es replicable, los controles defensivos existen y la diferencia entre quien aguanta y quien no se reduce a cuatro o cinco prácticas concretas: MFA resistente a phishing, accesos diferenciados para contractors, eliminación de credenciales hardcodeadas y detección de anomalías. No es glamoroso, pero la seguridad bien hecha rara vez lo es.
¿Tu MFA aguanta fatigue? Hagamos test. En ALCA acompañamos a equipos de seguridad mexicanos a evaluar postura defensiva contra técnicas modernas de ingeniería social y a implementar controles que efectivamente protegen. Agenda 30 minutos con nuestro equipo.
