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 de lógica y estrategias de ajuste para las Detecciones Curadas nativas de Google SecOps (Chronicle).
Si bien Google Threat Intelligence (GTIG) ofrece una cobertura conceptual excepcional de amenazas (como el seguimiento de las campañas 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. En entornos empresariales reales, esto provoca con frecuencia una fatiga masiva de alertas.
Este proyecto analiza por qué las reglas nativas se rompen 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 mediante Principales de Servicio comprometidos (técnicas muy 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 desajustes lógicos sistémicos entre el objetivo declarado y la implementación YARA-L, probablemente debido a la reutilización de código en todo el paquete de reglas. Las reglas no logran distinguir adecuadamente entre Principales de Servicio automatizados y la actividad humana estándar, lo que genera alertas que se activan ante el comportamiento normal de los empleados.
A pesar de que la descripción de la regla establece explícitamente: "Detecta un Principal de Servicio con un único ID de sesión de O365...", 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 por completo el objetivo declarado de la regla, agregando inicios de sesión humanos no relacionados en una ventana de 3 horas simplemente porque utilizan la misma aplicación.
Las reglas rastrean patrones de comportamiento anómalos (cambios de IP, ASN o User-Agents) vinculados a un ClientAppId específico. Si bien Google incluye una expresión regular de exclusión para varias aplicaciones nativas de Microsoft, omitieron inexplicablemente el cliente móvil humano más ubicuo: la Aplicación Móvil de Microsoft Outlook (27922004-5251-4030-b22d-91ecd9a37ea4).
Multiple ASNs y Multiple IPs. Diferentes 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 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 sobre 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 necesariamente tienes que deshabilitar las reglas ni escribir código personalizado. Simplemente puedes crear una Exclusión directamente en la interfaz del SIEM de Google SecOps. Solo agrega una exclusión dirigida al ClientAppId de Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) y a tus aplicaciones de respaldo autorizadas (por ejemplo, Keepit). Esto detiene de inmediato la inundación de falsos positivos mientras mantiene activas las reglas curadas de Google.
Opción 2: Implementar Reglas Personalizadas (Solución Arquitectónica)
Si deseas corregir por completo los fallos subyacentes de la lógica de agrupación (como el desajuste de $application_id), debes deshabilitar las Detecciones Curadas e implementar Reglas Personalizadas. Las correcciones implican:
27922004-...).match para agregar adecuadamente 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
(
$e.network.http.user_agent = /AppId/ nocase or $e.additional.fields["ClientAppId"] = /./
)
// EXCLUSIONS: Added Outlook Mobile + Standard Google Exclusions
$e.additional.fields["ClientAppId"] != /^(27922004-5251-4030-b22d-91ecd9a37ea4|bea75f7a-2505-46e8-9bf6-d3f7da9c9da7|b52893c8-bc2e-47fc-918b-77022b299bbc|...)$/ nocase
match:
// Group by both App AND Session to isolate the specific token lifecycle
$application_id,$session_id over 3h
outcome:
$vendor_name = "Microsoft"
$product_name = "Office 365"
$source_ua_dc = count_distinct($e.network.http.user_agent)
$client_app_id = array_distinct($e.additional.fields["ClientAppId"])
condition:
// Triggers if the SAME session rotates 2+ User Agents
$e and $source_ua_dc >= 2
}
(Misma lógica, pero en las exclusiones asegúrate de incluir en la lista blanca tus soluciones de respaldo autorizadas como Keepit (a7cd46df...) junto con Outlook Mobile).
(A diferencia de la regla de User Agents, Google en realidad logró agrupar por $session_id correctamente en esta. Sin embargo, aún carece de la exclusión de Outlook Mobile. Sigue la misma lógica de exclusión anterior, manteniendo la condición en $source_asn_dc >= 2).
(Misma lógica. Asegúrate de agregar aplicaciones de respaldo autorizadas como Keepit (a7cd46df...) a la expresión regular de exclusión al final del bloque events).
Regla: Anomalous Auth Attempts Total by Principal Hostname and Target User ID
(Nota: UEBA significa "User and Entity Behavior Analytics" (Analítica de Comportamiento de Usuarios y Entidades). Estas reglas no utilizan firmas estáticas, sino que se basan en algoritmos matemáticos para establecer una línea base del comportamiento "normal" y alertar sobre desviaciones estadísticas).
Esta regla UEBA intenta detectar picos de autenticación anómalos calculando el promedio histórico y las desviaciones estándar durante 30 días.
$num_stddevs_away = max(2) al comienzo del bloque outcome. Sin embargo, en el cálculo de $historical_threshold, el desarrollador de Google codificó el valor 2 en lugar de usar la variable. Este error de programación impide que los analistas puedan anular fácilmente la sensibilidad mediante la interfaz o variables heredadas, sin tener que clonar y reescribir completamente la lógica YARA-L.Las pruebas en entornos reales muestran que simplemente modificar los umbrales estadísticos (por ejemplo, aumentar $num_stddevs_away a 3 o 4, reducir $coefficient_of_variation_threshold de 0.1 a 0.05, o incrementar $observation_threshold a 15) es insuficiente: reduce los conteos de 710 a 111 alertas semanales, lo que sigue siendo excesivamente ruidoso para un equipo de analistas.
Broad para "Failed Authentications by Device" y depende estrictamente del canal de alertas Precise. Esta mitigación estructural es la única forma efectiva de detener la inundación de alertas.2 codificado dentro de $historical_threshold para que coincida con tu variable personalizada $num_stddevs_away, y aplica coeficientes de línea base más estrictos.Descargo de responsabilidad: Estos ajustes se basan en experiencia real de respuesta a incidentes e ingeniería de SIEM. Siempre prueba las reglas YARA-L en tu entorno específico antes de implementarlas en producción.