Os perigos do business email compromise (BEC)

O Comprometimento de E-mail Corporativo (CEC), também chamado de Business Email Compromise (BEC), é uma das ameaças mais silenciosas e devastadoras para empresas. Ao contrário de ransomware ou DDoS, o BEC opera dentro dos canais legítimos de comunicação - tornando-o quase invisível para sistemas de segurança tradicionais.

Impacto financeiro real#

Antes de falar de controles, os números precisam ser colocados na mesa. Dados do FBI IC3 (Internet Crime Complaint Center, 2023):

No Brasil, a Febraban estima prejuízos superiores a R$ 15 bilhões/ano incluindo fraudes derivadas de comprometimento de contas corporativas.

Cases reais notáveis#

Em todos os casos, o vetor comum foi a confiança no canal de e-mail combinada com ausência de verificação fora de banda para transferências financeiras.

6 vetores de ataque detalhados#

1. Phishing interno e ampliação do ataque#

Com a conta invadida, o atacante envia e-mails maliciosos para colegas, fornecedores e clientes. Como o remetente é real e reconhecível, as taxas de clique e resposta são drasticamente superiores ao phishing convencional.

Sinal de alerta: e-mails enviados fora do horário comercial, para grupos incomuns ou com links para domínios recém-registrados.

2. Fraude financeira direta (CEO/CFO fraud)#

O criminoso se passa por executivo sênior (CEO/CFO) e solicita transferências urgentes ou mudança de dados bancários de fornecedores. A pressão de urgência e a autoridade aparente inibem o comportamento de verificação.

Sinal de alerta: pedidos de pagamento não previstos, solicitação de confidencialidade, mudança de banco de fornecedor existente.

3. Exfiltração de dados confidenciais#

Caixas de e-mail corporativas armazenam contratos, negociações, documentos estratégicos e histórico de decisões. O atacante cria regras de encaminhamento automático para exfiltrar conteúdo continuamente.

Sinal de alerta: regras de encaminhamento criadas para domínios externos, aumento súbito de volume de saída de e-mail.

4. Fraude no setor financeiro (invoice fraud)#

Áreas de Financeiro e Compras são alvos primários. Atacantes alteram faturas PDF em trânsito, redirecionam pagamentos para contas mule e manipulam aprovações usando engenharia social sobre fluxos internos conhecidos.

5. Espionagem corporativa#

O acesso indevido ao e-mail permite monitorar temas críticos: novos produtos, estratégias comerciais, fusões e aquisições, decisões de precificação - afetando competitividade e propriedade intelectual.

6. Ataque à cadeia de fornecimento (supply-chain BEC)#

Com identidade corporativa válida, o atacante se comunica com parceiros para aplicar novos golpes, induzir instalação de malware ou comprometer processos de terceiros. O comprometimento de um fornecedor pequeno pode ser o vetor de entrada numa corporação grande.

Controles técnicos: autenticação de e-mail#

O primeiro pilar de defesa é garantir que e-mails falsificados nunca cheguem à caixa de entrada. Os três padrões fundamentais que o artigo original omitia:

SPF - sender policy framework#

; Autoriza apenas os IPs do Google Workspace a enviar por seu domínio
; O -all (hard fail) rejeita qualquer outra origem
domain.com.br. IN TXT "v=spf1 include:_spf.google.com include:_spf.microsoft.com -all"

DKIM - domainkeys identified mail#

; Assinatura criptográfica vincula o e-mail ao domínio remetente
; O seletor "google" é gerado no painel do Workspace
google._domainkey.domain.com.br. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

DMARC - domain-based message authentication#

; p=reject: rejeita mensagens que falham SPF e DKIM
; rua: recebe relatórios de falhas diariamente
_dmarc.domain.com.br. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

Verificando autenticação em headers recebidos#

# No Gmail: "Mostrar original" / No Outlook: "Exibir código-fonte"
# Procure por Authentication-Results no cabeçalho:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender)
   dkim=pass [email protected] header.s=google header.b=AbCdEfGh
   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=domain.com.br

# Se qualquer um desses mostrar "fail", o e-mail é suspeito
# spf=fail → IP de origem não autorizado pelo SPF
# dkim=fail → assinatura inválida ou ausente
# dmarc=fail → política de rejeição acionada

Detecção de BEC: logs, SIEM e UBA#

Indicadores de comprometimento (IoCs) em logs de e-mail#

Auditoria em plataformas de e-mail corporativo#

Microsoft 365 / Exchange Online:

# Verificar regras de encaminhamento criadas nos últimos 30 dias
Get-InboxRule -Mailbox [email protected] | Where-Object {$_.ForwardTo -ne $null -or $_.RedirectTo -ne $null}

# Unified Audit Log: logins suspeitos
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
  -Operations "UserLoggedIn","MailboxLogin" -ResultSize 1000 | `
  Where-Object {$_.AuditData -match "Unknown"}

# Message Trace para auditoria de envios
Get-MessageTrace -SenderAddress [email protected] -StartDate (Get-Date).AddDays(-1) `
  -EndDate (Get-Date) | Format-Table Received, SenderAddress, RecipientAddress, Subject

Google Workspace:

# Google Admin Console → Reports → Audit → Gmail
# Filtrar por: "message_type=email" + "is_inbound=false" + "ip_address NOT IN whitelist"

# Via API (Admin SDK):
# GET https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/token
# Procurar por: "gmail.modify" + "gmail.settings.sharing" como escopos anômalos

Integração com SIEM: eventos-chave para alertas UBA/UEBA#

# Regras de correlação (pseudocódigo agnóstico de plataforma)
rule BEC_ForwardingRuleCreated:
  source: email_audit_log
  condition: event.type == "InboxRuleCreated" AND rule.forward_to CONTAINS "@" AND NOT rule.forward_to ENDSWITH "@domain.com.br"
  severity: CRITICAL
  action: alert + disable_rule + notify_soc

rule BEC_ImpossibleTravel:
  source: identity_log
  condition: user.login_country != user.previous_login_country AND time_delta < 2h
  severity: HIGH
  action: alert + require_mfa_step_up

rule BEC_MassEmailOutbound:
  source: mail_gateway_log
  condition: sender.email_count_1h > 500 AND sender.avg_daily_emails < 50
  severity: HIGH
  action: alert + throttle_sender

Email security gateways e controles complementares#

Comparativo de soluções#

Data loss prevention (DLP)#

# Exemplo de política DLP para prevenir exfiltração via e-mail
# (Microsoft Purview / Google Workspace DLP)
policy_name: "Bloquear PII e dados financeiros em e-mails externos"
conditions:
  - content_matches: ["CPF", "CNPJ", "número de conta", "dados bancários"]
  - recipient_domain: NOT IN ["@domain.com.br", "@parceiro-autorizado.com"]
actions:
  - block_send
  - notify_sender: "Este e-mail contém dados sensíveis. Use o canal seguro aprovado."
  - notify_compliance: [email protected]
  - log_incident: true

S/MIME: criptografia e assinatura digital end-to-end#

# Gerar certificado S/MIME (via openssl para ambiente de teste)
openssl req -x509 -newkey rsa:4096 -keyout user_key.pem \
  -out user_cert.pem -days 365 -subj "/CN=Fulano/emailAddress=[email protected]"

# Em produção: adquirir certificado S/MIME de CA confiável
# (DigiCert, Sectigo, GlobalSign)
# Distribua o certificado público para todos os parceiros que precisam
# verificar a assinatura digital dos seus e-mails

Procedimentos de resposta a incidentes de BEC#

Fase imediata (0–1 hora)#

### Checklist: resposta imediata a BEC

- [ ] **ISOLAR:** Revogar tokens de sessão ativos da conta comprometida
       M365: Revoke-AzureADUserAllRefreshToken -ObjectId <user_id>
       Google: Admin Console → Usuário → Redefinir Cookie de Login

- [ ] **CONTER:** Resetar senha da conta com senha aleatória forte (≥20 chars)
- [ ] **PROTEGER:** Habilitar MFA imediatamente se não estava ativo
- [ ] **PRESERVAR:** Exportar e preservar logs antes de qualquer limpeza
       (Message Trace, Sign-in logs, Audit logs - mínimo 90 dias)
- [ ] **NOTIFICAR:** Acionar SOC / equipe de segurança interna
- [ ] **BLOQUEAR:** Identificar e deletar regras de encaminhamento maliciosas
- [ ] **VERIFICAR:** Checar se houve delegações de caixa ou permissões extras criadas

Fase de curto prazo (1–24 horas)#

- [ ] Verificar se houve transferências financeiras não autorizadas
- [ ] Contatar imediatamente os bancos envolvidos - janela SWIFT de 72h
       para recall de transferências internacionais
- [ ] Auditoria completa de e-mails enviados pela conta comprometida
       (identificar phishing interno enviado a terceiros)
- [ ] Notificar clientes, parceiros e fornecedores que receberam e-mails da conta
- [ ] Verificar se outros sistemas foram acessados com as credenciais roubadas
       (SSO, VPN, ERP, sistemas financeiros)
- [ ] Documentar timeline completo do incidente (para forense e regulatório)

Fase de médio prazo (1–7 dias)#

- [ ] Forense digital completa do dispositivo do usuário comprometido
- [ ] Revisão de todas as contas com padrão de acesso similar
- [ ] Implementação de controles adicionais (Conditional Access, MFA step-up)
- [ ] Treinamento de conscientização direcionado para a equipe afetada
- [ ] Relatório para autoridades se aplicável:
       Brasil: Boletim de Ocorrência + ANPD (LGPD, prazo 72h)
       União Europeia: Autoridade supervisora GDPR (72h)
       EUA: FBI IC3 (ic3.gov)
- [ ] Relatório executivo de pós-incidente com lições aprendidas

Controles de processo para pagamentos#

Preventivos#

## Controles financeiros anti-BEC

### Camada de aprovação
- [ ] Pagamentos >R$10.000: exigir 2 aprovadores independentes
- [ ] Pagamentos >R$100.000: exigir aprovação do CFO + 1 diretor
- [ ] Primeiro pagamento para beneficiário novo: delay obrigatório de 24h

### Verificação fora de banda (crítico)
- [ ] QUALQUER alteração de dados bancários de fornecedor DEVE ser confirmada
       por ligação telefônica para número previamente cadastrado
       (NÃO responder ao e-mail solicitando a mudança)
- [ ] Manter lista branca de contas bancárias autorizadas por fornecedor
- [ ] Alterações de conta bancária exigem aprovação do responsável pelo fornecedor

### Auditoria e monitoramento
- [ ] Alertas automáticos para qualquer mudança de dados bancários no ERP
- [ ] Log imutável de todas as alterações de conta (quem, quando, de onde)
- [ ] Revisão mensal de contas bancárias ativas de fornecedores

Processo de recuperação de fundos#

# Se transferência fraudulenta ocorreu:
# 1. Ligar IMEDIATAMENTE para o banco (não e-mail, não chat)
# 2. Solicitar "Wire Recall" / Recall SWIFT - janela de 72h
# 3. Fornecer: número da transferência, IBAN/SWIFT do destinatário, valor, data
# 4. Registrar Boletim de Ocorrência (necessário para recall bancário)
# 5. Acionar departamento jurídico para carta de cessação às instituições

# Contato de emergência Febraban (Brasil):
# Central Febraban: 0800 722 1222
# Delegacia de Crimes Cibernéticos local

Programa de conscientização com simulações#

Estrutura do programa#

Métricas de eficácia#

## Kpis do programa anti-BEC

### Métricas de simulação (coletadas por ferramenta: knowbe4 / gophish)
- Taxa de clique em simulações de phishing (meta: <5%)
- Taxa de reporte de e-mail suspeito (meta: >80% dos simulados)
- Tempo médio até reporte (meta: <30 minutos)
- Taxa de usuários que fornecem credenciais (meta: <1%)

### Métricas operacionais
- Número de incidentes de BEC confirmados por trimestre
- Valor total de perdas evitadas (baseado em tentativas detectadas)
- % de contas com MFA ativo (meta: 100%)
- % de domínios com DMARC p=reject (meta: 100%)

Sinais de alerta para treinamento#

## Como identificar e-mail BEC

### Sinais de urgência artificial
❌ "URGENTE - transfira agora, não posso atender ao telefone"
❌ "Assunto confidencial - não mencione para ninguém"
❌ "Preciso que resolva isso antes do fim do expediente"

### Sinais de domínio falso (homoglíficos)
❌ domaín.com.br (í com acento)
❌ domain.com.br.malicioso.ru
❌ domain-corp.com vs domain.com

### Verificação rápida antes de agir
✅ Ligar para o solicitante no número cadastrado (não no e-mail)
✅ Verificar se o domínio do remetente é idêntico ao habitual
✅ Confirmar com superior direto qualquer pedido financeiro atípico
✅ Reportar ao SOC/TI qualquer e-mail suspeito (mesmo sem clicar)

Requisitos regulatórios#

Checklist anti-BEC completo#

Autenticação de e-mail#

• [ ] SPF configurado com -all (hard fail) para todos os domínios enviadores
• [ ] DKIM habilitado e assinando todos os e-mails saintes
• [ ] DMARC com política p=reject (após migração progressiva via p=none → p=quarantine)
• [ ] DMARC reporting (rua) configurado para receber relatórios diários
• [ ] MFA habilitado em 100% das contas corporativas
• [ ] Autenticação por app (TOTP/FIDO2) - não SMS (vulnerável a SIM swap)
• [ ] Protocolos legados (IMAP/POP/SMTP auth básico) desabilitados no tenant

Controles de acesso#

• [ ] Princípio do menor privilégio em todas as contas (revisão semestral)
• [ ] Contas de serviço com credenciais rotacionadas e sem MFA interativo
• [ ] Separação de deveres para processos financeiros (quem aprova ≠ quem executa)
• [ ] Revisão trimestral de acessos privilegiados (Global Admin, Finance roles)
• [ ] Conditional Access: bloquear login de países não operacionais

Monitoramento e detecção#

• [ ] Alertas para login de geolocalização incomum (impossible travel)
• [ ] Alertas para criação de regras de encaminhamento de e-mail externo
• [ ] Alertas para mudanças de configuração de caixa (delegações, permissões)
• [ ] Logs centralizados em SIEM com retenção mínima de 12 meses
• [ ] UBA/UEBA habilitado para detecção de comportamento anômalo
• [ ] DLP configurado para dados sensíveis em e-mails externos

Controles de processo financeiro#

• [ ] Dupla aprovação para pagamentos acima do limite definido (ex: >R$10.000)
• [ ] Verificação por telefone (fora de banda) para qualquer alteração bancária
• [ ] Lista branca de contas bancárias autorizadas por fornecedor
• [ ] Delay de 24h para primeiro pagamento a beneficiário novo
• [ ] Alertas automáticos para alterações de dados bancários no ERP

Conscientização#

• [ ] Treinamento anti-BEC na admissão de todos os funcionários
• [ ] Reforço trimestral com casos reais e novos vetores
• [ ] Simulações mensais de phishing (meta: taxa de clique <5%)
• [ ] Canal de reporte de e-mails suspeitos (botão "Reportar Phishing" no cliente)
• [ ] Treinamento intensivo para áreas de alto risco (Financeiro, RH, C-level assistants)

Resposta a incidentes#

• [ ] Procedimento de resposta a BEC documentado e atualizado (revisão semestral)
• [ ] Contatos de emergência definidos: SOC, jurídico, banco, ANPD
• [ ] Processo de recall de transferências (contato bancário emergencial 24h)
• [ ] Obrigação de notificação regulatória documentada (LGPD 72h, GDPR 72h)
• [ ] Exercício tabletop de BEC realizado ao menos uma vez por ano

Veja também

E-mail Por trás do SMTP: como analisei um incidente real de spam, headers e reputação de e-mail

E-mail Adequando o servidor às exigências do Google e yahoo: SPF, DKIM e DMARC na prática

Infraestrutura Gmail rejeitando e-mails do DirectAdmin: como autenticar o hostname com SPF e DKIM

Este post está licenciado sob CC BY-NC.