all3xj/fixing-google-secops-detectionsAjuste y refactorización de las detecciones curadas de Google Chronicle para eliminar la fatiga de alertas y corregir brechas/errores de lógica.
Este repositorio documenta fallos de diseño arquitectónico, discrepancias lógicas y estrategias de ajuste para las Detecciones Curadas nativas de Google SecOps (Chronicle).
Si bien Google Threat Intelligence (GTIG) proporciona una cobertura conceptual de amenazas excepcional (como el seguimiento de campañas de APT29/BRICKSTORM), las implementaciones YARA-L sin procesar de las reglas curadas a veces adolecen de descuidos de implementación, como contradicciones en la lógica de agrupación y variables de umbral codificadas de forma rígida. En entornos empresariales del mundo real, esto con frecuencia provoca una fatiga masiva de alertas.
Este proyecto analiza por qué las reglas nativas fallan o inundan el SOC, y comparte Reglas Personalizadas optimizadas y parches para resolver estos problemas.
Google publicó un conjunto de reglas para detectar la exfiltración masiva de correo electrónico desde Microsoft 365 Exchange Online por parte de Service Principals comprometidos (técnicas ampliamente utilizadas por APT29/Midnight Blizzard).
Las reglas curadas afectadas son:
O365 Mailbox Access by Service Principal with Multiple User AgentsO365 Multiple Mailboxes Accessed by Service PrincipalO365 Mailbox Access by Service Principal from Multiple ASNsO365 Multiple Mailboxes Accessed via Microsoft Graph APIEste conjunto de reglas contiene discrepancias lógicas sistémicas entre el objetivo declarado y la implementación en YARA-L, probablemente debido a la reutilización de código entre el paquete de reglas. Las reglas no logran distinguir adecuadamente entre Service Principals automatizados y la actividad humana estándar, lo que resulta en alertas que se activan ante el comportamiento normal de los empleados.
A pesar de que la descripción de la regla establece explícitamente: "Detects a Service Principal with a single O365 session ID...", la sección match de YARA-L de la regla "Multiple User Agents" agrupa por $application_id en lugar del ID de sesión ($session_id). Esto contradice completamente el objetivo declarado de la regla.
Las reglas rastrean patrones de comportamiento anómalos (cambios de IP, ASN o User-Agent) vinculados a un ClientAppId específico. Si bien Google incluye una regex de exclusión para varias aplicaciones nativas de Microsoft, omitió inexplicablemente el cliente móvil humano más omnipresente: la aplicación móvil de Microsoft Outlook (27922004-5251-4030-b22d-91ecd9a37ea4).
Multiple ASNs. Distintos empleados que usan iOS y Android para consultar el mismo buzón departamental activan la alerta de Multiple User Agents.Para identificar cuentas de servicio de backend, la lógica de Google se basa en esta condición:
$e.principal.user.userid != $e.target.user.userid
[email protected]). Este fallo de diseño genera un ruido masivo en el tráfico operativo humano estándar.Para corregir estos fallos de diseño, tienes dos opciones según tus necesidades operativas:
Opción 1: Exclusiones nativas del SIEM (solución rápida)
No es necesario deshabilitar las reglas ni escribir código personalizado. Basta con crear una Exclusión directamente en la interfaz de Google SecOps SIEM. Solo tienes que añadir una exclusión dirigida al ClientAppId de Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) y a tus aplicaciones de copia de seguridad autorizadas (por ejemplo, Keepit). Esto detiene de inmediato la avalancha de falsos positivos mientras mantiene activas las reglas curadas de Google.
Opción 2: Desplegar reglas personalizadas (solución arquitectónica)
Si quieres corregir por completo los fallos subyacentes de la lógica de agrupación (como la discrepancia de $application_id), debes deshabilitar las Detecciones Curadas y desplegar Reglas Personalizadas. Las correcciones implican:
27922004-...).match para agregar correctamente por sesión.rule custom_ttp_o365_mailbox_access_by_service_principal_with_multiple_uas {
meta:
rule_name = "[CUSTOM] O365 Mailbox Access by Service Principal with Multiple User Agents"
description = "Detects a Service Principal with a single O365 session ID accessing O365 mailboxes with multiple user agents. Tuned to fix grouping logic and exclude Outlook Mobile (Public Client) human traffic."
severity = "Low"
tactic = "TA0009"
technique = "T1114.002"
events:
$e.metadata.log_type = "OFFICE_365"
$e.metadata.product_event_type = "MailItemsAccessed" nocase
$e.target.application = "Exchange"
$e.security_result.detection_fields["RecordType"] = /^(2|50)$/
// Extract actual Session ID and App ID
$session_id =$e.network.session_id
$application_id =$e.additional.fields["ClientAppId"]
$e.principal.user.userid !=$e.target.user.userid