all3xj/fixing-google-secops-detectionsAjuste e refatoração das Curated Detections do Google Chronicle para eliminar a fadiga de alertas e corrigir lacunas/bugs de lógica.
Este repositório documenta falhas de design arquitetural, discrepâncias de lógica e estratégias de ajuste para as Detecções Curadas (Curated Detections) nativas do Google SecOps (Chronicle).
Embora o Google Threat Intelligence (GTIG) forneça uma cobertura conceitual excepcional de ameaças (como o rastreamento das campanhas APT29/BRICKSTORM), as implementações YARA-L brutas das regras curadas às vezes sofrem de descuidos de implementação, como contradições na lógica de agrupamento e variáveis de limiar fixas (hardcoded). Em ambientes empresariais do mundo real, isso frequentemente leva a uma fadiga massiva de alertas.
Este projeto analisa por que as regras nativas quebram ou inundam o SOC e compartilha Regras Personalizadas otimizadas e correções para resolver esses problemas.
A Google lançou um pacote de regras para detectar exfiltração de e-mail em massa do Microsoft 365 Exchange Online por Service Principals comprometidos (técnicas amplamente usadas pelo APT29/Midnight Blizzard).
As regras curadas afetadas são:
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 pacote de regras contém incompatibilidades lógicas sistêmicas entre o objetivo declarado e a implementação YARA-L, provavelmente devido à reutilização de código no pacote de regras. As regras não conseguem distinguir adequadamente entre Service Principals automatizados e atividade humana padrão, resultando em alertas que disparam diante do comportamento normal de funcionários.
Apesar da descrição da regra afirmar explicitamente: "Detecta um Service Principal com um único ID de sessão O365...", a seção match do YARA-L da regra "Multiple User Agents" agrupa por $application_id em vez do ID de sessão ($session_id). Isso contradiz completamente o objetivo declarado da regra, agregando logins humanos não relacionados em uma janela de 3 horas simplesmente porque usam o mesmo aplicativo.
As regras rastreiam padrões comportamentais anômalos (mudanças de IPs, ASNs ou User-Agents) vinculados a um ClientAppId específico. Embora a Google inclua uma regex de exclusão para vários aplicativos nativos da Microsoft, ela omitiu inexplicavelmente o cliente móvel humano mais onipresente: o Microsoft Outlook Mobile App (27922004-5251-4030-b22d-91ecd9a37ea4).
Multiple ASNs e Multiple IPs. Funcionários diferentes usando iOS e Android para verificar a mesma caixa de correio departamental disparam o alerta Multiple User Agents.Para identificar contas de serviço de backend, a lógica da Google depende desta condição:
$e.principal.user.userid != $e.target.user.userid
[email protected]). Esse defeito de design gera ruído massivo no tráfego humano operacional padrão.Para corrigir esses defeitos de design, você tem duas opções, dependendo das suas necessidades operacionais:
Opção 1: Exclusões Nativas do SIEM (Solução Rápida)
Você não precisa necessariamente desabilitar as regras nem escrever código personalizado. Você pode simplesmente criar uma Exclusão diretamente na interface do SIEM do Google SecOps. Basta adicionar uma exclusão direcionada ao ClientAppId do Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) e aos seus aplicativos de backup autorizados (por exemplo, Keepit). Isso interrompe imediatamente a enxurrada de falsos positivos enquanto mantém as regras curadas da Google ativas.
Opção 2: Implantar Regras Personalizadas (Correção Arquitetural)
Se você quiser corrigir completamente as falhas subjacentes da lógica de agrupamento (como a incompatibilidade do $application_id), é necessário desabilitar as Detecções Curadas e implantar Regras Personalizadas. As correções envolvem:
27922004-...) na lista de permissões.match para agregar adequadamente por sessão.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
}
(Mesma lógica, mas nas exclusões certifique-se de incluir na lista de permissões suas soluções de backup autorizadas, como Keepit (a7cd46df...), juntamente com o Outlook Mobile.)
(Diferentemente da regra de User Agents, a Google conseguiu agrupar corretamente por $session_id nesta. No entanto, ela ainda não possui a exclusão do Outlook Mobile. Siga a mesma lógica de exclusão acima, mantendo a condição em $source_asn_dc >= 2.)
(Mesma lógica. Certifique-se de anexar aplicativos de backup autorizados, como Keepit (a7cd46df...), à regex de exclusão no final do bloco events.)
Regra: Anomalous Auth Attempts Total by Principal Hostname and Target User ID
(Nota: UEBA significa "User and Entity Behavior Analytics" (Análise do Comportamento de Usuários e Entidades). Essas regras não usam assinaturas estáticas, mas dependem de algoritmos matemáticos para estabelecer uma linha de base do comportamento "normal" e alertar sobre desvios estatísticos.)
Esta regra UEBA tenta detectar picos anômalos de autenticação calculando a média histórica e os desvios padrão ao longo de 30 dias.
$num_stddevs_away = max(2) no início do bloco de resultado (outcome). No entanto, no cálculo de $historical_threshold, o desenvolvedor da Google fixou o valor 2 no código (hardcoded) em vez de usar a variável. Esse erro de programação impede que os analistas sobrescrevam facilmente a sensibilidade pela interface ou por variáveis herdadas, sem clonar e reescrever completamente a lógica YARA-L.Testes no mundo real mostram que simplesmente ajustar os limiares estatísticos (por exemplo, elevar $num_stddevs_away para 3 ou 4, reduzir $coefficient_of_variation_threshold de 0.1 para 0.05, ou aumentar $observation_threshold para 15) é insuficiente: isso reduz os totais de 710 para 111 alertas semanais, o que permanece excessivamente ruidoso para uma equipe de analistas.
Broad para "Failed Authentications by Device" e dependa estritamente do canal de alertas Precise. Essa mitigação estrutural é a única maneira eficaz de interromper a enxurrada de alertas.2 fixo (hardcoded) dentro de $historical_threshold para corresponder à sua variável personalizada $num_stddevs_away e aplique coeficientes de linha de base mais rigorosos.Aviso Legal: Estes ajustes são baseados em experiência real de resposta a incidentes e engenharia de SIEM. Sempre teste as regras YARA-L no seu ambiente específico antes de implantá-las em produção.