TTPs de Scattered Spider que tu EDR probablemente ignora.

Scattered Spider — también catalogado como UNC3944 — sigue siendo, dos años después de sus operaciones más mediáticas, uno de los grupos más eficientes contra organizaciones occidentales. No por sofisticación técnica, sino por la asimetría que han descubierto: la mayoría de defensas asumen malware, y ellos casi no usan. Su superpoder es el helpdesk, la identidad y el clic con permisos.

Esto es lo que vemos vivo en clientes este trimestre, y la consulta que recomendamos para cada técnica.

1 · MFA bombing acompañado de llamada al usuario

El cliente recibe una avalancha de pushes de Microsoft Authenticator. Mientras eso pasa, el atacante llama al usuario haciéndose pasar por IT y le pide que «acepte el push para validar el sistema». La técnica funciona porque el usuario, harto de las notificaciones, quiere que paren.

La detección no está en el endpoint. Está en Azure AD:

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType in ("50074", "50076", "500121")  // MFA fallidos
| summarize attempts = count() by UserPrincipalName, bin(TimeGenerated, 5m)
| where attempts > 10
| join kind=inner (
    SigninLogs
    | where ResultType == "0"
    | where AuthenticationDetails contains "MFA"
) on UserPrincipalName

Si una cuenta tiene 10+ MFA fallidos en 5 minutos y a continuación un MFA exitoso desde una IP nueva, asume MFA fatigue hasta que se demuestre lo contrario.

2 · Ingeniería social al helpdesk para reseteo de MFA

Llamada al helpdesk haciéndose pasar por un ejecutivo. Presión: «estoy fuera del país, necesito reseteo de MFA ya». Si el helpdesk no tiene un proceso de verificación fuerte (videocall + factor secundario), la cuenta cae.

La señal en logs es muy específica: un reseteo de MFA seguido en minutos de un alta de método de autenticación nuevo (típicamente un Authenticator en un dispositivo nuevo) y un login exitoso desde IP atípica. La consulta:

AuditLogs
| where OperationName in ("Reset user authentication method", "Update authentication method", "User registered security info")
| where TimeGenerated > ago(24h)
| join kind=inner (
    SigninLogs
    | where ResultType == "0"
    | extend ip = tostring(IPAddress)
) on $left.TargetResources_0_userPrincipalName == $right.UserPrincipalName
| where datetime_diff('minute', TimeGenerated1, TimeGenerated) < 30

3 · Persistencia vía aplicaciones OAuth maliciosas

Una vez dentro, en lugar de instalar nada, registran o consientan a una aplicación que pida permisos sobre Mail.Read, Files.Read.All o User.Read.All. La aplicación queda persistente incluso si la contraseña cambia. Es OAuth como puerta trasera.

La fuente es AuditLogs con OperationName == "Consent to application", filtrando por consentimientos a aplicaciones que no estén en tu inventario aprobado. Tener una whitelist activa es lo que separa "ruido" de "alerta".

4 · Login desde RMM legítimo (TeamViewer, AnyDesk, ScreenConnect)

Convencen a un usuario, casi siempre por teléfono, para que instale "una herramienta de soporte" — TeamViewer, AnyDesk, ScreenConnect. Una herramienta legítima, firmada, con reputación. Tu EDR no marca nada porque no hay nada malicioso que marcar.

La detección que mejor funciona es el inventario: cualquier instalación de software RMM en un endpoint corporativo que no esté en la lista aprobada por IT debería disparar una alerta de severidad alta. Es trivial implementarlo:

DeviceEvents
| where ActionType == "ProcessCreated"
| where InitiatingProcessFileName in (
    "TeamViewer.exe", "TeamViewer_Service.exe",
    "AnyDesk.exe", "ScreenConnect.WindowsClient.exe",
    "ScreenConnect.ClientService.exe", "ConnectWiseControl.exe",
    "Splashtop.exe", "AeroAdmin.exe"
)
| join kind=leftanti (
    AssetInventory
    | where ApprovedRMM == true
) on DeviceName

5 · Abuso de Azure AD Connect Sync

Si consiguen DA en el on-prem, vuelan al sync agent y vuelcan credenciales sincronizadas. La operación deja huella en eventos 1644 (Active Directory) y en logs del propio Azure AD Connect, pero hay que buscarla: por defecto no es ruidosa.

La detección útil aquí no es una sola consulta sino una baseline de quién accede al servidor de Azure AD Connect. Cualquier sesión interactiva nueva en ese host debería ser alerta crítica. Sin excepciones.

Por qué tu EDR no las pilla

Las cinco técnicas comparten la misma razón: no hay binario malicioso en ninguna de ellas. Son acciones humanas con software legítimo y sesiones legítimas. El EDR está optimizado para malware, y aquí no hay malware. La detección útil es la que vive en logs de identidad (Azure AD), logs de aplicaciones (AuditLogs O365) y logs de inventario (asset management). Si tu programa de detección está concentrado al 80 % en endpoints y al 20 % en cloud/identidad, vas a ser una víctima fácil contra Scattered Spider y todos los actores que han copiado su manual.