Google SecOps (Chronicle) Detecções Curadas: Análise de Falhas e Ajustes

Este repositório documenta falhas de design arquitetural, discrepâncias de lógica e estratégias de ajuste para Detecções Curadas nativas do Google SecOps (Chronicle).

Embora o Google Threat Intelligence (GTIG) forneça uma cobertura conceitual de ameaças excepcional (como o rastreamento de campanhas APT29/BRICKSTORM), implementações YARA-L brutas de regras curadas às vezes sofrem de descuidos de implementação, como contradições na lógica de agrupamento e variáveis de limiar codificadas diretamente. 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 patches para resolver esses problemas.

Rastreamento Upstream e Feedback ao Fornecedor

• Status: Lacunas de lógica e feedback de telemetria de regras foram reconhecidos pela equipe de Detection Engineering / Produto do Google, iniciando uma frente de trabalho de revisão do ciclo de vida de regras interna ao Google.

---

📑 Índice

1. Falha de Alertas do O365 Suite para BRICKSTORM / APT29
   • Falha 1: Contradição na Lógica de Agrupamento
   • Falha 2: Descuido com Cliente Público do Outlook Mobile
   • Falha 3: Colisão de Caixa de Correio Compartilhada
   • Soluções YARA-L Otimizadas
2. O365 Teams: Tentativa de Personificação Externa
   • Falha 1: Inversão entre Adversário e Alvo
   • Falha 2: Chave de Agrupamento de Correspondência Errónea
   • Solução YARA-L Otimizada
3. UEBA: Total de Tentativas de Autenticação Anómalas
   • Falha de Codificação Direta e Fadiga de Alertas
   • Recomendações de Ajuste

---

1. Falha de Alertas do O365 Suite para BRICKSTORM / APT29

O Google lançou um conjunto de regras para detectar exfiltração em massa de e-mail do Microsoft 365 Exchange Online por Service Principals comprometidos (técnicas amplamente utilizadas por APT29/Midnight Blizzard).

As regras curadas afetadas são:

• O365 Mailbox Access by Service Principal with Multiple User Agents
• O365 Multiple Mailboxes Accessed by Service Principal
• O365 Mailbox Access by Service Principal from Multiple ASNs
• O365 Multiple Mailboxes Accessed via Microsoft Graph API

❌ Falhas Centrais na Lógica do Google

Este conjunto 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 entre o pacote de regras. As regras não conseguem distinguir adequadamente entre Service Principals automatizados e atividade humana padrão, resultando em alertas que são acionados por comportamento normal de funcionários.

Falha 1: Contradição na Lógica de Agrupamento

Apesar da descrição da regra afirmar explicitamente: "Detects a Service Principal with a single O365 session ID...", a secçã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.

• Impacto: Sessões de funcionários não relacionadas que compartilham o mesmo App ID empresarial e o mesmo e-mail compartilhado são mescladas em todo o tenant ao longo de uma janela de 3 horas. Isso aciona falsos positivos sempre que dois utilizadores distintos se autenticam via user agents diferentes (por exemplo, iPhone vs. Android) sob a mesma aplicação, falhando em isolar o sequestro individual de tokens.

Falha 2: Descuido com Cliente Público do Outlook Mobile

As regras rastreiam padrões comportamentais anômalos (mudança de IPs, ASNs ou User-Agents) vinculados a um ClientAppId específico. Embora o Google inclua uma regex de exclusão para vários aplicativos nativos da Microsoft, eles omitiram inexplicavelmente o cliente móvel humano mais onipresente: o Microsoft Outlook Mobile App (27922004-5251-4030-b22d-91ecd9a37ea4).

• Impacto: Sem filtrar esse Public Client, funcionários legítimos que leem caixas de correio compartilhadas em seus smartphones e que alternam entre redes (por exemplo, mudando de Wi-Fi para 4G) acionam inerentemente os alertas de Multiple ASNs. Funcionários diferentes usando iOS e Android para verificar a mesma caixa de correio departamental acionam o alerta de Multiple User Agents.

Falha 3: Colisão de Caixa de Correio Compartilhada

Para identificar contas de serviço de backend, a lógica do Google depende desta condição: $e.principal.user.userid != $e.target.user.userid

• Impacto: Esta condição simplesmente verifica se o ID do ator é diferente do proprietário da caixa de correio de destino. Embora seja verdadeiro para entidades de serviço automatizadas, também é um comportamento padrão para funcionários humanos acessando caixas de correio compartilhadas ou departamentais (por exemplo, um operador abrindo [email protected]). Essa falha de design gera um ruído massivo no tráfego operacional humano padrão.

---

✅ Soluções YARA-L Ajustadas para Regras do O365

Para corrigir essas falhas de design, você tem duas opções, dependendo das suas necessidades operacionais:

Opção 1: Exclusões Nativas do SIEM (Correção Rápida) Você não precisa necessariamente desativar as regras ou escrever código personalizado. Você pode simplesmente criar uma Exclusão diretamente na interface do Google SecOps SIEM. 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, mantendo as regras curadas do 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 de $application_id), você deve desativar as Detecções Curadas e implantar Regras Personalizadas. As correções envolvem:

1. Colocar explicitamente o Outlook Mobile (27922004-...) na lista de permissões.
2. Colocar na lista de permissões os Aplicativos de Backup Empresariais autorizados conhecidos (por exemplo, Keepit).
3. Corrigir as seções match para agregar adequadamente por sessão.

Regra Ajustada 1: Multiple User Agents

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"] = /./
    )