La pregunta que nos hacen los CISOs cada vez con más frecuencia es: «¿cómo bloqueo la exfiltración a la nube?». Es la pregunta equivocada. La pregunta correcta es: «¿cómo veo la exfiltración cuando va por mi propia nube?» Porque eso es lo que está pasando.
Cuando un atacante consigue una sesión de Microsoft 365 — vía phishing de OAuth, AiTM, robo de cookies o cualquiera de las cinco rutas más usadas en 2026 — no necesita exfiltrar nada por tu firewall. La exfiltración ya está sucediendo dentro de Microsoft, entre productos de Microsoft, con tráfico que tu DLP de red etiqueta como "tráfico corporativo legítimo".
El problema: el egress es invisible cuando el destino es Microsoft
El esquema tradicional de DLP asume que el dato sale por una IP que no es la tuya. Si el dato sale a onedrive.com, graph.microsoft.com o sharepoint.com — todos en rangos de Microsoft, todos en certificados válidos, todos esperados — tu DLP de red lo deja pasar y no debería hacer otra cosa.
El movimiento del atacante moderno consiste en usar tu propio tenant como cinta transportadora: copiar SharePoint a su OneDrive comprometido, sincronizar carpetas a un equipo no monitorizado, exportar buzones a PST con APIs nativas, mover datos sensibles a sitios SharePoint creados al vuelo, etc. Todo dentro de Microsoft. Todo con un token OAuth válido. Todo invisible para el firewall.
Dónde se ven, entonces
Hay dos fuentes de telemetría que la mayoría de equipos infrautilizan: Microsoft 365 Unified Audit Log (UAL) y Azure AD Sign-in Logs. Si tu SIEM ingiere ambos, ya tienes el 80 % de lo que necesitas. Si no, el primer paso es activarlo: en E5 ya viene, en E3 hay que activarlo y retenerlo.
Las operaciones que más nos interesan en UAL para exfiltración:
FileDownloaded,FileSyncDownloadedFull· descarga puntual o sincronización completa.FileAccessed,FilePreviewed· acceso a fichero (útil para ver qué tocó antes de descargar).SharingSet,SharingInvitationCreated· compartir hacia fuera.Add-MailboxPermission,New-InboxRule· clásicos del compromiso de buzón.Consent to application· concesión de OAuth a una aplicación nueva.
La consulta que nos cierra el 70 % de los casos
El patrón más común que vemos: una cuenta legítima descarga un volumen anómalo de ficheros, desde una IP nueva, en una franja horaria atípica, después de haberle dado consentimiento a una aplicación de terceros que nadie del equipo IT recuerda haber aprobado.
OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation in ("FileDownloaded", "FileSyncDownloadedFull")
| summarize fileCount = count(),
uniquePaths = dcount(SourceFileName),
uniqueIPs = dcount(ClientIP)
by UserId, bin(TimeGenerated, 1h)
| where fileCount > 200 and uniqueIPs > 1
| join kind=inner (
AuditLogs
| where OperationName == "Consent to application"
| where TimeGenerated > ago(7d)
) on $left.UserId == $right.InitiatedBy_userPrincipalName
| project TimeGenerated, UserId, fileCount, uniquePaths, uniqueIPs, ClientIPEs deliberadamente conservadora: solo enseña cuentas que han descargado más de 200 ficheros en una hora y que han concedido OAuth a alguna app en los últimos 7 días. Falsos positivos: muy bajos. Falsos negativos: existen, pero el verdadero positivo cuando salta es casi siempre real.
El detalle que casi nadie mira
El indicador más fuerte que hemos encontrado para diferenciar uso legítimo de exfiltración no es el volumen. Es la primera carpeta que se tocó. Un usuario legítimo abre el documento que necesita; un atacante navega primero a /Finanzas, /Legal, /RRHH o /Tecnología antes de descargar. Si correlacionas FilePreviewed con FileDownloaded y el primer ítem accedido pertenece a un site sensible al que ese usuario no entra habitualmente, casi siempre tienes algo.
Qué hacer cuando salta
Lo que no funciona: deshabilitar la cuenta. El atacante ya tiene el token y lo seguirá usando hasta que expire o se revoque explícitamente. Lo que sí funciona, en este orden:
Revoke-AzureADUserAllRefreshTokensobre la cuenta. Esto invalida sesiones activas.- Reset de credenciales y reset de MFA tokens.
- Auditoría de
OAuth2PermissionGrants— buscar apps recién consentidas y revocarlas. - Buscar retro-actividad: ¿qué descargó en las últimas 72 horas? ¿qué buzones cambió permisos? ¿creó alguna InboxRule?
El egress dejó de ser el cuello de botella interesante hace cinco años. Si tu detección de exfiltración solo mira tráfico saliente, estás mirando el sitio equivocado. La fuga de datos moderna pasa por una API legítima, con un token legítimo, hacia el mismo sitio donde guardas todo lo demás. Mira ahí.