# T1564.008 - Email Hiding Rules
> [!abstract] Resumo Técnico
> Adversários criam regras de email maliciosas na caixa de entrada da vítima comprometida para ocultar automaticamente respostas a ataques BEC, alertas de segurança e comúnicações de C2 por email. Esta é uma subtécnica de [[t1564-hide-artifacts|T1564 - Hide Artifacts]], crítica para sustentação de fraudes financeiras corporativas.
## Técnica Pai
Esta é uma sub-técnica de [[t1564-hide-artifacts|T1564 - T1564 - Hide Artifacts]].
## Descrição
O Email Hiding Rules (Regras de Ocultação de Email) é uma técnica de evasão utilizada após o comprometimento de uma conta de email corporativo. O adversário cria regras de caixa de entrada automáticas que movem, deletam ou marcam como lidas certas mensagens antes que o usuário legítimo as vejá - eliminando evidências de atividade maliciosa e prolongando o tempo de permanência.
A técnica é um elemento central em ataques de **BEC (Business Email Compromise)** - fraude de email corporativo que causa bilhões de dólares em prejuízo globalmente a cada ano. No Brasil, o BEC é uma das modalidades de crime financeiro com maior crescimento, afetando principalmente tesourarias corporativas, compras e setores de RH.
O poder desta técnica está na sua **invisibilidade operacional**: ao contrário de outras formas de evasão que exigem execução de código ou modificação de configurações de sistema, a criação de regras de email é uma função **nativa e esperada** em qualquer cliente de email. Ferramentas de segurança raramente monitoram a criação de regras de inbox com a mesma aténção dedicada a execução de processos.
Esta técnica é subtécnica de [[t1564-hide-artifacts|T1564 - Hide Artifacts]] e frequentemente combinada com [[t1534-internal-spearphishing|T1534 - Internal Spearphishing]] - o adversário usa a conta comprometida para enviar phishing interno e oculta as respostas com regras de email.
## Como Funciona
### Microsoft Exchange / Outlook - New-InboxRule
Em ambientes Microsoft 365 e Exchange on-premises, adversários com credenciais válidas (obtidas via phishing, credential stuffing ou [[t1110-brute-force|T1110 - Brute Force]]) podem criar regras programaticamente via PowerShell:
```powershell
New-InboxRule -Name "Security Alerts" `
-SubjectContainsWords "suspicious","malware","phish","hack","alert","compromise" `
-DeleteMessage $true
```
Esta única linha de comando, executada com as credenciais da vítima, passa a deletar silenciosamente todos os emails com termos relacionados a segurança antes que o usuário os vejá.
Variantes comuns para BEC:
```powershell
# Mover respostas de transferência para pasta oculta
New-InboxRule -Name "Faturas" `
-From "
[email protected]" `
-MoveToFolder "RSS Subscriptions"
# Marcar como lidos e mover sem notificação
New-InboxRule -Name "Updates" `
-SubjectContainsWords "transferência","aprovação","urgente" `
-MarkAsRead $true `
-MoveToFolder "Deleted Items"
```
### Outlook Client - Interface Gráfica
Adversários com sessão remota ativa (RDP, VNC, ou acesso via ferramentas de RAT) podem criar regras diretamente na interface gráfica do Outlook sem deixar rastros em logs de PowerShell. Esta abordagem é menos detectável pois usa o fluxo normal de uso do aplicativo.
### Microsoft Graph API / EWS (Exchange Web Services)
Com um token OAuth válido (obtido via [[t1528-steal-application-access-token|T1528 - Steal Application Access Token]] ou através de aplicativo OAuth malicioso registrado via [[t1550-003-pass-the-token|T1550.003]]), adversários podem criar regras via API REST sem necessidade de acesso ao cliente de email:
```
POST https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messageRules
Authorization: Bearer [TOKEN]
Content-Type: application/json
{
"displayName": "Newsletter Cleanup",
"sequence": 1,
"isEnabled": true,
"conditions": {
"subjectContains": ["unsubscribe", "security", "alert", "suspicious"]
},
"actions": {
"delete": true
}
}
```
### Transport Rules (Escopo Organizacional)
Em cenários de comprometimento de contas administrativas do Exchange ou Microsoft 365, adversários podem criar **Transport Rules** que operam em nível organizacional, não apenas na caixa de entrada de um usuário. Estas regras processam **todos os emails da organização** que correspondam às condições definidas - um impacto dramaticamente maior:
```powershell
New-TransportRule -Name "Compliance Filter" `
-SubjectContainsWords "incident","breach","compromised","forensics" `
-DeleteMessage $true
```
Este vetor foi utilizado pelo [[g1015-scattered-spider|Scattered Spider]] em intrusões a empresas de telecomúnicações para suprimir alertas internos de segurança enviados para toda a organização.
### Google Workspace (Gmail)
Em ambientes Google, regras equivalentes são criadas via Gmail Filters. Adversários com acesso à conta podem usar a API do Google Workspace ou a interface web para criar filtros que arquivam, deletam ou marcam automaticamente mensagens por critérios de palavras-chave, remetente ou assunto.
## Attack Flow
```mermaid
graph TB
A([Adversário]) --> B[Comprometimento de Credenciais]
B --> B1["Phishing de Credenciais<br/>T1566"]
B --> B2["Credential Stuffing<br/>T1110"]
B --> B3["Token OAuth Roubado<br/>T1528"]
B --> B4["Acesso via RAT<br/>pós-intrusão"]
B1 --> C{Acesso à Caixa de Email}
B2 --> C
B3 --> C
B4 --> C
C --> D[Criação de Regras de Ocultação]
D --> D1["PowerShell<br/>New-InboxRule"]
D --> D2["Outlook GUI<br/>sem log de PS"]
D --> D3["Graph API<br/>via token OAuth"]
D --> D4["Transport Rule<br/>nível organizacional"]
D1 --> E{Objetivo da Regra}
D2 --> E
D3 --> E
D4 --> E
E --> E1["Deletar alertas<br/>de segurança"]
E --> E2["Ocultar respostas<br/>a phishing interno"]
E --> E3["Esconder aprovações<br/>de BEC/fraude"]
E --> E4["Suprimir notificações<br/>de MFA e login"]
E1 --> F[Adversário opera sem<br/>detecção por email]
E2 --> G["T1534 - Internal<br/>Spearphishing habilitado"]
E3 --> H[Fraude Financeira BEC]
E4 --> F
F --> I([Persistência longa<br/>no ambiente])
G --> J([Campanhas de phishing<br/>interno em larga escala])
H --> K([Transferências fraudulentas<br/>bilhões em perdas globais])
style A fill:#c0392b,color:#fff
style D fill:#e67e22,color:#fff
style H fill:#8e44ad,color:#fff
style K fill:#c0392b,color:#fff
style I fill:#2c3e50,color:#fff
```
## Exemplos de Uso
### Scattered Spider (UNC3944 / 0ktapus)
O [[g1015-scattered-spider|Scattered Spider]] é um grupo de crime financeiro anglófono (composto majoritariamente por jovens adultos) que realiza ataques de engenharia social sofisticados contra grandes corporações. O grupo é conhecido por seus ataques a empresas de telecomúnicações (MGM Resorts, Caesars Entertainment, Reddit) e usa Email Hiding Rules de forma sistemática:
1. Compromete conta de helpdesk via vishing (engenharia social por telefone) para resetar MFA
2. Acessa o email corporativo do usuário comprometido
3. Cria regras de inbox para deletar emails contendo palavras como "suspicious activity", "new device", "login from new location"
4. Usa a conta para [[t1534-internal-spearphishing|phishing interno]] (T1534), enviando emails de autoridade interna solicitando transferências ou redefinições de acesso
5. Regras ocultam as respostas - a vítima do phishing responde, mas o usuário original nunca vê
O grupo foi responsável por perdas estimadas em mais de US$ 1 bilhão em 2023-2024 combinando esta técnica com SIM swapping e vishing.
### FIN4 (APT Financeiramente Motivado)
O [[g0085-fin4|FIN4]] é um grupo de ameaça único: em vez de roubar dinheiro diretamente, o grupo roubaInformações privilegiadas de mercado para **negociação de ações** com base em informações não-públicas. O grupo comprometia contas de email de executivos C-suite, banqueiros de investimento e consultores de M&A.
Após comprometer contas de email via phishing ultra-direcionado (spear-phishing com contexto muito específico da organização alvo), o FIN4 criava regras de email para:
- Ocultar alertas de IT Security sobre "suspicious login"
- Esconder comúnicações internas sobre aquisições, fusões ou resultados financeiros ainda não públicos
- Manter acesso prolongado a caixas de email sem que os usuários percebessem
O grupo foi ativo entre 2013-2016, comprometendo mais de 100 organizações incluindo empresas farmacêuticas e firmas de M&A de Wall Street.
### Grupos de BEC com Foco no Brasil
Grupos de BEC operando no Brasil frequentemente criam regras de email após comprometer contas corporativas via phishing em PT-BR. O padrão documentado em incidentes brasileiros:
1. Phishing com tema fiscal (boleto, nota fiscal, DARF) compromete credenciais de funcionário financeiro
2. Adversário loga na conta M365 ou Gmail corporativo
3. Cria regra que move emails do CFO, CEO ou fornecedores para pasta "RSS Feeds" ou "Lixeira"
4. Inicia troca de emails com o fornecedor pedindo mudança de dados bancários para boleto ou PIX
5. Fornecedor responde confirmando - adversário intercepta e redireciona pagamento
O custo médio de um ataque BEC bem-sucedido no Brasil supera R$ 500 mil, segundo dados do CERT.br e da Polícia Federal.
## Detecção
> [!tip] Prioridade de Detecção
> Criação de regras de inbox fora do horário comercial ou por usuários que raramente criam regras é um sinal de alta fidelidade. O volume de criação de regras por usuário é normalmente zero ou muito baixo - qualquer criação deve ser investigada em contexto.
### Regra Sigma - Criação de Regra de Inbox via PowerShell
```yaml
title: Criação Suspeita de Regra de Inbox via PowerShell Exchange
id: 09182736-4556-7890-1234-56789abcdef0
status: experimental
description: >
Detecta uso dos cmdlets New-InboxRule ou Set-InboxRule via PowerShell
para criar ou modificar regras de email, especialmente com ações de
deleção ou movimentação para pastas ocultas. Indicativo de T1564.008
e BEC pós-comprometimento de credenciais.
references:
- https://attack.mitre.org/techniques/T1564/008/
author: RunkIntel
daté: 2026-03-25
tags:
- attack.defense_evasion
- attack.t1564.008
logsource:
product: windows
category: process_creation
detection:
selection:
CommandLine|contains:
- 'New-InboxRule'
- 'Set-InboxRule'
CommandLine|contains:
- 'DeleteMessage'
- 'MoveToFolder'
- 'MarkAsRead'
condition: selection
falsepositives:
- Scripts de administração legítimos de Exchange (documentar automações existentes)
- Criação de regras por help desk com consentimento do usuário
level: high
```
### Regra Sigma - Criação de Regra via Microsoft Graph API (M365 Unified Audit Log)
```yaml
title: Criação de Regra de Email via Microsoft Graph / EWS
id: 1a2b3c4d-5e6f-7890-abcd-ef1234567901
status: experimental
description: >
Detecta criação ou modificação de regras de inbox no Microsoft 365
via Graph API ou Exchange Web Services, especialmente de IPs não-corporativos
ou fora do horário de trabalho esperado. Alta relevância para BEC.
references:
- https://attack.mitre.org/techniques/T1564/008/
author: RunkIntel
daté: 2026-03-25
tags:
- attack.defense_evasion
- attack.t1564.008
logsource:
product: m365
service: exchange
detection:
selection:
Operation:
- 'New-InboxRule'
- 'Set-InboxRule'
- 'UpdateInboxRules'
filter_legitimate_hours:
# Horário fora do padrão: antes das 7h ou depois das 22h
ResultStatus: 'Success'
condition: selection
falsepositives:
- Administradores configurando regras durante manutenção fora do horário
- Migração de Exchange (processo de importação de regras)
level: medium
```
### Regra Sigma - Transport Rule com Ação de Deleção
```yaml
title: Transport Rule Criada com Ação de Deleção no Exchange
id: 2b3c4d5e-6f70-8901-bcde-f01234567912
status: experimental
description: >
Detecta criação de transport rules com ação de deletar mensagens.
Transport rules com DeleteMessage afetam toda a organização - altíssimo
impacto e quase nunca legítimas em ambientes normais.
references:
- https://attack.mitre.org/techniques/T1564/008/
author: RunkIntel
daté: 2026-03-25
tags:
- attack.defense_evasion
- attack.t1564.008
- attack.impact
logsource:
product: m365
service: exchange
detection:
selection:
Operation: 'New-TransportRule'
Parameters|contains: 'DeleteMessage'
condition: selection
falsepositives:
- Regras de compliance legítimas de deleção (ex: LGPD, retenção de dados)
level: critical
```
## Mitigação
| ID | Mitigação | Descrição Aplicada |
|---|-----------|-------------------|
| [[m1047-audit\|M1047]] | Audit | Habilitar auditoria de criação e modificação de regras de inbox no Microsoft 365 via Unified Audit Log. Configurar alertas para `New-InboxRule` e `Set-InboxRule` no Microsoft Sentinel ou SIEM equivalente. Revisar periodicamente todas as regras de inbox de contas privilegiadas (C-suite, financeiro, RH). |
> [!warning] Configurações Adicionais Recomendadas
> **Microsoft 365:**
> - Habilitar `Conditional Access` com MFA para todos os usuários, especialmente financeiro e C-suite
> - Configurar alertas de `Suspicious inbox manipulation rules` no Microsoft Defender for Office 365
> - Revisar permissões de criação de Transport Rules - limitar a administradores globais com MFA
> - Implementar `Attack Simulator` para treinar usuários sobre phishing de credenciais
>
> **Google Workspace:**
> - Habilitar `Alert Center` para notificações de criação suspeita de filtros de email
> - Configurar `Gmail log events` via BigQuery para auditoria centralizada
> - Revisar periodicamente os filtros de todos os usuários em contas de alto risco
> [!tip] Detecção Comportamental
> Correlacionar criação de regras de inbox com:
> - Login de novo IP ou país nas últimas 24h
> - Ausência de MFA na sessão que criou a regra
> - Volume de email recebido mas não lido aumentando após criação da regra
> - Transferências financeiras não-padrão nas 72h seguintes à criação da regra
## Contexto Brasil/LATAM
> [!danger] Alta Relevância - BEC é principal vetor de perda financeira corporativa no Brasil
> O FBI IC3 Report 2024 posiciona o BEC como o crime cibernético com maior prejuízo financeiro globalmente (US$ 2,9 bilhões em 2023). No Brasil, a Polícia Federal e o CERT.br registram crescimento consistente de casos de BEC corporativo, frequentemente envolvendo regras de email como mecanismo de persistência.
No Brasil, o BEC tem características específicas do mercado local:
**Vetores Preferidos:**
- **Tema fiscal:** "Nota Fiscal Eletrônica NFe-XXXXX" é o assunto de phishing mais comum para comprometimento inicial de credenciais corporativas em PT-BR
- **LGPD como isca:** emails fingindo ser notificações de compliance relacionadas à [[lgpd|LGPD]] para obter credenciais de DPOs e líderes jurídicos
- **PIX como destino:** transferências via PIX são irreversíveis em segundos - o tempo entre a criação da regra de ocultação e o prejuízo financeiro pode ser inferior a 2 horas
**Setores Mais Afetados no Brasil:**
- [[_sectors|Setor Financeiro]] - tesourarias corporativas, gestoras de fundos
- Importadoras e exportadoras (fraude de mudança de conta bancária com fornecedor estrangeiro)
- Construtoras (pagamentos de fornecedores de material de construção)
- Prefeituras e órgãos públicos - menos maturidade de segurança, maior exposição
**Grupos Relevantes:**
O [[g1015-scattered-spider|Scattered Spider]] tem histórico de comprometer empresas de telecomúnicações - setor importante no Brasil (Claro, Vivo, TIM, Oi). Embora suas operações primárias sejam em inglês, técnicas como Email Hiding Rules são transferíveis e usadas por grupos de BEC locais.
O [[g0085-fin4|FIN4]], embora com operações focadas nos EUA, representa o modelo de ataque que grupos locais replicam para targets de mercado de capitais brasileiro (B3, gestoras, bancos de investimento).
**Regulatório:** O Banco Central do Brasil e a CVM têm orientações sobre proteção de email corporativo em instituições financeiras, e incidentes de BEC podem resultar em notificações obrigatórias ao Bacen sob o Marco de Cibersegurança para IFs.
## Referências
- [MITRE ATT&CK - T1564.008](https://attack.mitre.org/techniques/T1564/008/)
- [FBI IC3 - Business Email Compromise Report 2024](https://www.ic3.gov/Media/Y2024/PSA240417)
- [Microsoft - Detecting and Remediating Illicit Consent Grants](https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediaté-illicit-consent-grants)
- [Mandiant - FIN4 Report](https://www.mandiant.com/resources/fin4-stealing-insider-information-for-an-advantage-in-global-financial-markets)
- [Crowdstrike - Scattered Spider Profile](https://www.crowdstrike.com/blog/scattered-spider-attempts-to-avoid-detection-with-bring-your-own-vulnerable-driver-tactic/)
- [CERT.br - Fraudes BEC](https://www.cert.br/docs/whitepapers/bec/)
- [[g1015-scattered-spider|Scattered Spider]] · [[g0085-fin4|FIN4]]
- [[t1564-hide-artifacts|T1564 - Hide Artifacts]] · [[t1534-internal-spearphishing|T1534 - Internal Spearphishing]]
- [[t1059-001-powershell|T1059.001 - PowerShell]] · [[t1110-brute-force|T1110 - Brute Force]]
- [[t1528-steal-application-access-token|T1528 - Steal Application Access Token]]
- [[m1047-audit|M1047 - Audit]]
---
*Fonte: [MITRE ATT&CK - T1564.008](https://attack.mitre.org/techniques/T1564/008)*