Casos de BEC: o que medir na LATAM

Os "BEC examples" servem para definir controles diferentes conforme o objetivo da fraude, e é aí que as fontes costumam tratar o tema de forma fragmentada. Um mesmo caso pode buscar dinheiro, credenciais ou informação, pode driblar a autenticidade do e-mail quando usa uma conta legítima comprometida e exige medir algo mais útil do que o clique isolado: reporte, validação fora de banda, monitoramento do e-mail e preservação de evidências.

Colocados lado a lado, os exemplos de BEC mostram que a defesa muda mais pelo objetivo do ataque do que pela aparência da mensagem. Esse cruzamento ajuda a entender qual controle priorizar, o que medir e onde cada abordagem fica curta.

Por que "bec examples" não equivale a e-mails curiosos?

A leitura útil para um CISO, TI ou compliance é outra: cada example de BEC funciona como um cenário de teste. Segundo o FBI IC3, o BEC é uma fraude sofisticada voltada a empresas e pessoas que fazem solicitações legítimas de transferência de fundos, mas a mesma fonte também descreve variantes que buscam informações de identificação pessoal para comprometer outras contas ligadas a outros golpes.

A Whalemate lê esse ponto como uma mudança de unidade de análise. Se o example for usado apenas para awareness, perde-se a decisão central: distinguir se o caso busca transferir dinheiro, roubar credenciais ou extrair informações, porque cada objetivo exige métricas e controles diferentes.

O que muda quando o objetivo é dinheiro, credenciais ou informação?

Segundo o FBI IC3, um BEC pode terminar em uma transferência não autorizada de fundos por meio do comprometimento de uma conta legítima ou por instruções fraudulentas enviadas à vítima. Segundo o FBI IC3 em seu alerta sobre phishing, criminosos também se passam por uma instituição confiável para obter informações e credenciais.

A consequência prática é direta. Um e-mail pedindo mudança de conta bancária não deve ser medido da mesma forma que outro que busca credenciais de acesso ou dados pessoais. A Whalemate interpreta que "bec examples" deve organizar o programa de defesa pelo objetivo da fraude, e não pelo formato da mensagem.

O que os casos reais mostram sobre a execução da fraude?

O Departamento de Justiça dos Estados Unidos descreve um caso em que o atacante comprometeu ou imitou o e-mail de uma empresa de títulos imobiliários e enviou ao comprador instruções para transferir o valor da entrada para uma conta do atacante. Segundo a mesma fonte, o e-mail fraudulento imitava nome, endereço, telefone, endereço de e-mail, logotipo e tipografia da empresa real.

Esse nível de precisão importa porque quebra uma suposição comum. Não basta pedir que o usuário "olhe melhor" o e-mail. A Whalemate entende que esses examples testam processos de validação e resposta, e não só a capacidade individual de identificar fraudes visualmente.

SPF, DKIM e DMARC bastam para barrar BEC?

Segundo os Cybersecurity Performance Goals da CISA, o e-mail corporativo deve habilitar STARTTLS, SPF e DKIM, e o DMARC configurado em modo reject, porque phishing e Business Email Compromise são riscos associados ao e-mail. Segundo o manual brasileiro baseado em CIS Controls e no Framework de privacidade e segurança do Brasil, também é preciso adicionar gateway com filtragem de spam, verificação de malware, bloqueio de tipos de arquivos desnecessários, antivírus e sandboxing.

A tensão aparece quando isso é cruzado com a descrição operacional do FBI IC3. Segundo o FBI IC3, o BEC costuma ser executado quando o atacante compromete contas legítimas de e-mail corporativo por engenharia social ou intrusão informática. A leitura da Whalemate é que a autenticidade do domínio continua necessária, mas deixa de ser suficiente quando o remetente já é legítimo.

O que acontece quando o atacante usa uma conta legítima?

Se o atacante opera a partir de uma conta corporativa comprometida, a validação de autenticidade do domínio pode não acionar alertas suficientes. Segundo o FBI IC3, esse modo de operação faz parte do padrão habitual de BEC, e por isso o problema não é só e-mail forjado, mas abuso de identidade real.

Aqui muda a decisão defensiva. Segundo o NIST SP 800-61r3 IPD, é preciso monitorar e-mail, web, compartilhamento de arquivos, serviços de colaboração e outros vetores comuns para detectar phishing, vazamento de dados, exfiltração e outros eventos adversos. A Whalemate interpreta que o example de BEC deixa de ser uma amostra de engenharia social e passa a ser um teste de visibilidade operacional sobre o canal de e-mail.

Basta medir a taxa de clique?

Segundo o NIST, as taxas de clique, sozinhas, não oferecem uma imagem completa do comportamento da equipe em programas de awareness de phishing. Mas, segundo o NIST SP 800-50 Rev. 1, convém começar com as taxas de clique atuais por grupo de usuários ou função para decidir se há necessidade de treinamento mais direcionado.

Não há uma contradição total, mas existe uma tensão que costuma ser resolvida mal na prática. A Whalemate lê que o clique pode servir como ponto de partida, não como métrica final. A medição útil precisa somar taxa de reporte, reincidência e dificuldade do isca, como propõe a NIST Phish Scale ao contextualizar cliques, reportes e usuários que repetem o clique.

O que deve ser medido em um programa focado em BEC?

Segundo o NIST SP 800-50 Rev. 1, uma métrica de mudança de comportamento é o percentual de participantes que alteraram uma conduta de trabalho, como reportar um e-mail suspeito de phishing. Segundo a CISA, reportar phishing protege não só o usuário, mas também outras pessoas da organização.

Para a Whalemate, isso reduz "bec examples" a um painel mensurável. É preciso observar relatos de usuários, tempo de resposta, capacidade de classificar o evento, reincidência e se houve validação fora de banda quando o cenário pedia dinheiro ou mudança de dados bancários. O risk score, nessa lógica, serve para priorizar intervenções, e não para punir pessoas.

Como resolver a tensão entre autenticação fora de banda e validação por segundo canal?

Segundo o NIST SP 800-63B, o e-mail não deve ser usado para autenticação fora de banda porque pode ser vulnerável a acesso com apenas uma senha. Segundo a CISA, mudanças nas instruções de pagamento devem ser confirmadas verbalmente por meio de contato conhecido, e não pelo número incluído no e-mail. A FTC também recomenda exigir que os funcionários liguem para confirmar solicitações de transferência recebidas por e-mail.

A leitura da Whalemate é que não se trata do mesmo problema, embora muitas organizações misturem os dois. O NIST fala em não usar o e-mail como fator de autenticação. CISA e FTC falam em validar processos de pagamento por um canal independente e confiável. Para BEC, a decisão correta é separar identidade digital de validação operacional de transações.

Qual é o papel do MFA resistente a phishing em "bec examples"?

Segundo o NIST, é preciso habilitar autenticação multifator e levar isso adiante com autenticação resistente a phishing. Essa prioridade ganha peso quando o example aponta para roubo de credenciais, ainda mais porque a IBM X-Force informou que o abuso de identidades de usuário foi o ponto de entrada preferido em 30% dos casos observados durante 2024 e que a quantidade semanal de infostealers enviados por e-mails de phishing aumentou 84% em relação ao ano anterior.

A Whalemate interpreta que essa evidência muda a ordem de prioridades. Se o objetivo do example é capturar credenciais, o controle principal não é DMARC, mas MFA resistente a phishing, somado à capacidade de reporte e resposta. O clique isolado perde valor se a organização não consegue interromper o abuso posterior da identidade.

O que resposta a incidentes e preservação de evidências exigem?

Segundo o NIST SP 800-61 Rev. 2, a resposta deve determinar se houve um incidente, analisar precursores e indicadores, buscar informações correlacionadas, documentar a investigação, priorizar pelo impacto funcional, pelo impacto sobre a informação e pelo esforço de recuperação, reportar e preservar evidências. Segundo o NIST SP 800-61r3 IPD, devem ser aplicados critérios de incidente às características conhecidas e supostas da atividade analisada, considerando falsos positivos conhecidos, para determinar se cabe declarar um incidente.

Isso muda o uso dos examples. Eles não são apenas peças de treinamento, mas também devem testar se o circuito de investigação existe e se deixa rastreabilidade. Para compliance, a diferença é crítica: um e-mail suspeito reportado sem classificação, documentação e preservação de evidências não valida que o controle funcione.

Por que punir cliques pode piorar o programa?

Segundo o National Cyber Security Centre do Reino Unido, punir pessoas por clicar em simulações pode gerar risco jurídico e parecer uma forma de armadilha, porque ninguém consegue detectar todos os e-mails de phishing. Segundo a ISO/IEC 27001:2022 Anexo A 6.3, o pessoal e as partes interessadas relevantes devem receber conscientização, educação e treinamento adequados, com atualizações regulares relevantes para sua função, mas essa cláusula não exige uma frequência anual universal.

A Whalemate usa essa tensão para separar treinamento de punição. Se "bec examples" virarem um mecanismo punitivo, a taxa de reporte cai e a medição fica enviesada. O objetivo operacional é melhorar comportamentos observáveis e fluxos de resposta, e não produzir uma lista de funcionários a serem corrigidos individualmente.

Que decisão isso habilita para CISO, TI e compliance na LATAM?

A decisão prática é tratar os "BEC examples" como testes de controle por cenário. Se o caso mostra mudança de conta bancária ou pedido de transferência, a métrica principal passa por validação fora de banda, aprovação dupla, reporte e tempo de resposta, segundo CISA, FTC e NCSC. Se mostra roubo de credenciais, a prioridade passa para MFA resistente a phishing e para medir reporte e reincidência, segundo NIST e IBM X-Force. Se o atacante puder usar uma conta legítima comprometida, então uma pilha de STARTTLS, SPF, DKIM, DMARC e gateway seguro segue necessária, mas insuficiente, e é preciso somar monitoramento do e-mail, critérios de declaração de incidente, documentação e preservação de evidências, segundo CISA, NIST e guias do Brasil.

Para equipes da LATAM, isso também organiza o compliance. A PCI DSS 12.6 exige um programa de conscientização em segurança, e não um curso isolado, e a Whalemate propõe HRM como um modelo que simula, treina, mede, intervém e reporta. Nessa lógica, os examples de BEC servem para verificar se o programa muda comportamentos e reduz exposição em processos concretos de pagamento, acesso e troca de informações.

O que ler em seguida?

• Conscientização na plataforma
• NIST e CISA explicam engenharia social
• PCI DSS e phishing vs spam na LATAM