BEC, Fraude e Abuso de Identidade

Nota 08 do capítulo 25, que trata do caso em que o e-mail é a fraude inteira: sem anexo, sem link malicioso e sem malware.
O foco são as tipologias de BEC, os sinais de fraude, os procedimentos de verificação fora de banda e os controles que fecham o ciclo.
Dialoga com as notas 06 e 07 deste capítulo, com a nota 15 do capítulo 08 e com a nota 02 do capítulo 26 sobre identidade.

1. Contexto e Posicionamento na Biblioteca

Business Email Compromise, ou BEC, é a fraude que usa e-mail, autoridade percebida e contexto de negócio para mover dinheiro ou dados, e é uma das modalidades de maior perda financeira registrada pelas forças policiais, na ordem de bilhões de dólares expostos por ano segundo os relatórios anuais do IC3 do FBI. A particularidade que interessa ao analista é a ausência de payload: em muitos casos não há anexo, link ou código, apenas texto persuasivo apoiado em uma identidade falsificada ou comprometida. Sem binário para examinar, a EDR não vê nada, e a detecção desloca-se do endpoint para a identidade, o conteúdo da mensagem e o processo de negócio.

Esta nota fecha a trilogia de fraude do capítulo 25: a nota 06 fornece a leitura de cabeçalhos, a nota 07 persegue os links quando existem, e aqui o e-mail é tratado como a fraude inteira. A nota também prepara o terreno do capítulo 26, que trata identidade como o novo perímetro, porque o BEC abusa exatamente de identidade, autoridade e processo. O contexto é defensivo e legítimo: descrever a mecânica da fraude é o que permite detectá-la, interrompê-la e treinar os processos que a tornam inviável.

2. Definição e Tipologias de BEC

As tipologias de BEC compartilham uma mecânica única, o abuso de identidade combinado com o desvio de processo, mas variam no vetor de entrada e no alvo organizacional. A tabela abaixo organiza as cinco formas mais recorrentes, e cada uma delas deixa marcas diferentes na telemetria, o que determina onde a detecção deve morar.

A escolha da tipologia depende da indústria: varejo e indústria sofrem mais com fatura falsa e VEC, escritórios e empresas de capital fechado com CEO fraud, e o setor de serviços com payroll diversion. O perfilamento é insumo de inteligência, porque o mesmo grupo tende a reaparecer com a tipologia que funcionou na primeira execução contra a organização. A frequência de tentativa também é padrão: a CEO fraud costuma ser ensaiada com mensagem de teste, sem conteúdo fraudulento, para medir quem responde antes do golpe real.

A leitura da tabela destaca o ponto mais importante para a arquitetura de detecção: a CEO fraud pura deixa evidência abundante nos cabeçalhos, porque o domínio é falso, enquanto o Vendor Email Compromise deixa quase nada, porque a mensagem sai da caixa real do fornecedor comprometido. O caso da seção 6 ilustra justamente a segunda forma, a mais difícil, e mostra que o controle decisivo muda de lugar quando os cabeçalhos estão limpos.

3. Por que a Ausência de Malware Dificulta a Detecção

A ausência de payload desmonta a arquitetura tradicional de detecção camada por camada. O endpoint não tem processo, arquivo ou chave de registro para alertar; o gateway tem apenas conteúdo textual, o tipo de evidência mais ambígua que existe; e o SIEM fica sem os IOCs de rede que sustentariam uma regra. Restam três superfícies de detecção possíveis: os cabeçalhos quando o domínio é falso, os padrões de linguagem e de fluxo de mensagens quando a caixa é real, e o processo de negócio, que é o único controle que funciona nos dois casos.

O segundo agravante é a qualidade do contexto. A mensagem de BEC costuma ser derivada de uma conversa real, obtida por comprometimento prévio ou por reconhecimento de OSINT, e por isso cita projetos, valores e nomes verdadeiros; a IA generativa dos últimos anos eliminou também o marcador do português torto que antigamente entregava os textos fabricados. O terceiro agravante é operacional: o dinheiro se move em minutos pela rede de contas laranja, enquanto a descoberta costuma levar dias, porque só aparece na conciliação ou na cobrança do fornecedor original. Por isso a resposta a BEC é, antes de tudo, uma corrida contra o relógio de liquidação bancária.

A economia do BEC completa o quadro de dificuldades: a operação é conduzida por grupos especializados em acesso e fraude, com rede de contas laranja recrutada como "agente financeiro", e o produto final é dinheiro, não acesso revendido. Essa especialização significa que o mesmo grupo opera contra múltiplas vítimas com playbook padronizado, e os padrões de domínio, de redação e de horário reaparecem entre casos distintos. A coleta desses padrões em uma base própria de casos é o que permite correlacionar tentativas aparentemente isoladas em uma campanha dirigida ao setor.

4. Sinais de Fraude no E-mail e no Processo

Os sinais de BEC se dividem entre os que aparecem na mensagem e os que aparecem no processo, e a segunda categoria é a que salva o caso quando os cabeçalhos estão limpos. Os itens abaixo reúnem os sinais mais produtivos observados em campanhas reais, e a convergência de dois ou três deles justifica acionar o protocolo de verificação da seção 5.

• Divergência entre From e Reply-To de domínios diferentes, ou Reply-To externo em thread interna.
• Domínio lookalike recém-registrado, com homoglifo, troca de letra ou TLD alternativo, verificável via WHOIS e DNS passivo do capítulo 03.
• Urgência artificial com sigilo, tipicamente "não conte a ninguém antes da liberação", que bloqueia justamente a verificação que desarmaria a fraude.
• Pedido de alteração de dados bancários ou de destino de pagamento, que é por si só um sinal de processo independente de qualquer indicador técnico.
• Horários fora do padrão do remetente real, tanto no carimbo do Date quanto no histórico de acesso da caixa comprometida.
• Tentativa de migrar a conversa para canal novo, como aplicativo de mensagem ou telefone pessoal, onde não há trilha de auditoria corporativa.

No lado do processo, o sinal universal é simples: qualquer alteração de conta bancária solicitada por e-mail, sem verificação fora de banda, é tratada como tentativa de fraude até prova em contrário. Essa regra não depende de intel, de ferramenta ou de contexto, e é o controle com melhor razão entre custo e retorno de toda a defesa contra BEC.

A tabela abaixo organiza os sinais por superfície de observação, com a verificação imediata que cada um exige, e serve de roteiro para a triagem antes do protocolo formal da seção 5.

A lista acima é produtiva na triagem individual, mas o BEC em escala só aparece na correlação: o mesmo domínio de envio usado contra dois setores, a mesma conta de resposta reaproveitada em campanhas separadas e o mesmo padrão de horário repetido em semanas distintas. Essa camada de correlação pertence ao hunting da nota 15 do capítulo 08, e os casos individuais são os grãos que a caça agrupa.

5. Procedimentos de Verificação Fora de Banda

O protocolo de verificação é curto, barato e funciona porque ataca a mecânica central da fraude: o atacante precisa que a verificação não aconteça. O fluxo abaixo deve estar formalizado no processo financeiro, e não apenas no treinamento, porque procedimento informal não sobrevive à pressão da urgência simulada.

1. Tratar toda alteração de conta bancária e todo pedido de pagamento urgente como suspeito por padrão.
2. Verificar fora de banda: ligar para o número já cadastrado no sistema, nunca para o número trazido no e-mail.
3. Exigir dupla aprovação com separação de funções para mudanças de cadastro bancário de fornecedor.
4. Conferir os cabeçalhos conforme a nota 06 antes de responder; responder a um Reply-To externo alimenta a fraude.
5. Registrar o caso e os indicadores no sistema de gestão e repassá-los à equipe de CTI para correlação.
6. Se o pagamento ocorreu, acionar imediatamente o banco e a autoridade policial; a taxa de recuperação cai drasticamente com as horas.

A tabela de gatilhos abaixo formaliza quando cada etapa é obrigatória, e o prazo de cada ação é o que transforma o protocolo em controle auditável.

A janela de congelamento completa o protocolo: pedidos urgentes que chegam fora do horário de confirmação do contato oficial ficam pendentes até a abertura do dia seguinte, e o custo de esperar 12 horas é sempre menor do que o custo de liquidar uma fraude. A trilha de auditoria fecha o ciclo operacional, porque cada verificação, aprovada ou recusada, fica registrada com quem executou, quando e por qual canal. Sem essa trilha, o protocolo vira costume informal que a pressão do dia a dia dissolve.

A matriz de contatos formaliza o passo 2 e resolve o dilema do analista que não sabe a quem confirmar: para cada fornecedor e cada executivo, o sistema financeiro mantém o canal oficial de contato, atualizado e protegido contra alteração via e-mail. O cadastro desse canal só muda por processo controlado, com prova de identidade e registro no sistema, e qualquer tentativa de alteração por e-mail vira alerta automático. A responsabilidade pela manutenção da matriz é da área financeira, com a equipe de segurança auditando o processo, e não o contrário.

6. Caso Ilustrativo: Fluxo Completo de uma Fraude de Fornecedor

O caso abaixo, com dados fictícios, mostra a tipologia mais difícil, o Vendor Email Compromise, em que os cabeçalhos estão limpos e o controle técnico tradicional falha. O fluxo documenta as seis etapas observadas, desde o comprometimento inicial até a descoberta.

O contexto da vítima importa para a leitura: uma distribuidora de médio porte, com processo de contas a pagar consolidado e fornecedor de mais de cinco anos de casa. É justamente o histórico longo que empresta credibilidade à thread comprometida, e é ele que o atacante aproveita ao escolher a fatura da vez. O valor da fraude, R$ 486 mil, é plausível dentro da carteira de fornecedores, e essa plausibilidade é critério de design do atacante, não coincidência.

Etapa 1: a caixa do fornecedor real é comprometida por password spray e o atacante passa a observar as conversas
Etapa 2: dias depois, na thread de uma fatura legítima, o "fornecedor" informa a mudança de conta bancária
Etapa 3: um segundo e-mail, do "diretor financeiro interno", reforça a pressão e pede agilidade
Etapa 4: o analista de contas a pagar aprova a alteração sem call-back, pois a thread é autêntica
Etapa 5: o pagamento de R$ 486 mil é liquidado em conta laranja e disperso em transações menores
Etapa 6: o fornecedor original cobra a fatura vencida; a conciliação revela a fraude 12 dias depois

A análise posterior do caso deixa três lições estruturais. Primeira, os cabeçalhos das mensagens da thread eram autênticos, e nenhuma regra de gateway baseada em autenticação teria disparado; o único marcador técnico era a caixa interna do "diretor financeiro", possivelmente spoofada conforme a nota 06, e mesmo assim não determinante. Segunda, o controle que teria parado a fraude era o call-back da seção 5, um procedimento de processo sem custo de licença. Terceira, a detecção tardia mudou o esforço de recuperação para o campo jurídico e policial, que tem margem estreita; por isso a caça proativa à fraude, com regras sobre alterações de cadastro bancário no sistema financeiro, vale mais do que qualquer filtro de conteúdo.

A detecção posterior ao caso usou três regras implantadas a partir do registro do incidente: alerta de alteração de cadastro bancário com dupla aprovação pendente, monitoramento de criação de regras de caixa de entrada no domínio do fornecedor, quando há telemetria de parceiro disponível, e cruzamento diário de novos registros de domínio com a lista de fornecedores críticos. As três regras operam em superfícies diferentes, mas atacam o mesmo ponto da mecânica, o momento em que a instrução bancária nova entra no processo. O registro das três no TIP, com a referência ao caso de origem, é o que permite reusá-las na próxima campanha do mesmo grupo.

7. Controles Preventivos e de Detecção

A defesa contra BEC combina controles técnicos, de processo e de inteligência, e a tabela abaixo organiza o conjunto mínimo com o que cada controle efetivamente bloqueia ou revela. A prioridade de implantação recomendada segue a ordem da tabela, porque os controles de processo têm retorno imediato e os de inteligência consolidam a defesa no médio prazo.

| Monitoramento de fluxo anômalo de envio e de regras de caixa | Técnico | Caixa interna comprometida que responde por novos alvos |
| Base própria de casos e correlação de padrões | Inteligência | Reconhecimento do mesmo grupo em tentativas separadas |

O monitoramento de lookalike merece detalhamento prático: a equipe de CTI mantém a lista de marcas internas e de fornecedores críticos, consulta diariamente novos registros que os imitem, registra os próprios domínios defensivamente para endurecer o DMARC e aciona o provedor de hosting para takedown quando a página de captura aparece. Esse circuito conecta a nota com o EASM do capítulo 21, que fornece a descoberta de superfície externa em escala.

A medição dos controles evita que o programa vire papel: taxa de conformidade do call-back em amostragem mensal, tempo médio entre o pedido suspeito e a verificação, número de tentativas interrompidas pelo protocolo e tempo de descoberta em incidentes reais. Os indicadores vão para a mesma governança das métricas de CTI, com metas acordadas com a área financeira, porque o controle de processo é dela e não do SOC. A revisão trimestral do protocolo incorpora as variantes observadas no período, mantendo o procedimento vivo e coerente com a ameaça real.

8. Erros Comuns e Pontos de Atenção

O erro mais comum é confundir BEC com phishing de credencial e enviar o caso para a esteira de sandbox, que não produz nada quando não há payload. O erro mais caro é tratar o call-back como burocracia dispensável em pagamentos "aprovados pela diretoria", exatamente o cenário que a fraude fabrica. Ambos os erros se corrigem com a mesma mudança cultural: a urgência declarada na mensagem é motivo para mais verificação, nunca para menos.

Completam a lista os itens abaixo.

• Responder à mensagem suspeita, confirmando ao atacante que a caixa está ativa e abrindo a fase de exploração.
• Apostar em treinamento anual único, quando o que funciona são campanhas curtas dirigidas aos públicos de risco.
• Ignorar o canal telefônico e as mensageiras, onde a segunda fase da fraude costuma ser conduzida por vishing.
• Não registrar indicadores, apesar de domínios e contas de BEC recorrerem em campanhas posteriores contra a mesma organização.
• Tratar o incidente apenas como problema de segurança, sem envolver financeiro, jurídico e compliance desde o primeiro momento.

• Deixar de revogar acessos e redefinir segredos quando a caixa interna do segundo e-mail estava de fato comprometida.

• Considerar encerrado o caso na devolução do pagamento, sem investigar como o atacante obteve o contexto real da transação.

• Delegar a verificação ao mesmo analista que processa o pagamento, concentrando no mesmo ponto a execução e o controle.

• Tratar o BEC como problema exclusivo do SOC, sem envolver financeiro, jurídico e compliance desde o primeiro dia.

• Ignorar a fase de reconhecimento, em que mensagens de teste sem fraude medem quem responde antes do golpe.

9. Integração com o Restante da Biblioteca

Os controles técnicos desta nota ancoram na resposta a incidentes do capítulo 07 e na nota 15 do capítulo 08, que transforma os padrões de BEC em caça proativa sobre telemetria de e-mail, incluindo as regras de caixa de entrada e o fluxo anômalo de envio citados na nota 06. A nota 02 do capítulo 26 eleva a discussão para a identidade como alvo central, com os sinais de password spray e de MFA fatigue que precedem o comprometimento das caixas de fornecedores. No ciclo de inteligência, os casos de BEC alimentam o agrupamento de campanhas do capítulo 05 e o documento da nota 09, com a particularidade de que a infraestrutura aqui é quase toda de identidade e de processo, e não de rede. A mensagem final da trilogia é direta: quando o atacante para de entregar código, a organização precisa detectar intenção, e intenção se detecta com processo bem desenhado.