O que é Business Email Compromise (BEC) e por que é diferente de “phishing comum”
Business Email Compromise (BEC) é um tipo de fraude em que o criminoso usa e-mail corporativo (ou um e-mail muito parecido) para induzir uma organização a realizar ações financeiras ou administrativas de alto impacto, como alterar dados bancários de um fornecedor, aprovar um pagamento urgente, comprar gift cards, enviar informações sensíveis ou mudar instruções de cobrança. O ponto central do BEC não é “infectar” a vítima com malware, mas sim explorar processos de pagamento, rotinas de aprovação e confiança em comunicações internas e com parceiros.
Em BEC, o atacante busca parecer legítimo dentro do fluxo normal de trabalho. Em vez de mensagens genéricas, ele tende a usar linguagem compatível com o contexto do negócio, horários plausíveis, referências a projetos reais e uma narrativa alinhada ao que a empresa já faz (pagamentos, compras, reembolsos, contratos, mudanças de conta). Muitas vezes, o e-mail não contém link nem anexo, justamente para reduzir sinais técnicos de suspeita e passar por filtros.
O BEC costuma envolver uma destas duas situações: (1) comprometimento real de uma conta (Account Takeover), em que o atacante obtém acesso a uma caixa de e-mail legítima e passa a operar “por dentro”; ou (2) falsificação/impersonação, em que ele não invade a conta, mas usa domínios parecidos, display name enganoso, ou manipula cabeçalhos para parecer alguém da empresa. Em ambos os casos, o objetivo final é desviar dinheiro ou obter vantagem financeira por meio de instruções de pagamento fraudulentas.
Principais modalidades de BEC (com exemplos práticos)
1) Fraude de pagamento a fornecedor (Vendor/Supplier Payment Diversion)
O atacante se passa por um fornecedor real (ou compromete o e-mail do fornecedor) e solicita alteração de dados bancários para “próximos pagamentos”. O golpe funciona bem porque mudanças de conta podem ocorrer legitimamente (troca de banco, mudança de filial, reorganização financeira).
Exemplo: “Olá, equipe de Contas a Pagar. Atualizamos nossa conta para recebimentos. Segue novo IBAN/PIX. Favor confirmar para o pagamento da fatura 18473.” A fatura pode ser real (capturada de uma conversa comprometida) ou forjada com aparência legítima.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
2) Fraude do CEO/CFO (Executive Impersonation)
O criminoso se passa por um executivo e pede um pagamento urgente, geralmente fora do padrão (adiantamento, taxa, “fechamento de aquisição”, “pagamento confidencial”). A pressão costuma ser por velocidade e sigilo, tentando contornar controles.
Exemplo: “Preciso que você faça uma transferência hoje, é sensível e não pode envolver mais ninguém. Me confirme quando estiver pronto que envio os dados.”
3) Interceptação de conversas e alteração de instruções (Thread Hijacking)
Quando o atacante tem acesso a uma caixa de e-mail (da empresa ou do parceiro), ele acompanha uma negociação real e, no momento do pagamento, envia uma mensagem no mesmo encadeamento pedindo para pagar em outra conta. Como a conversa é verdadeira, a fraude fica muito convincente.
Exemplo: em uma troca de e-mails sobre um projeto, o atacante responde no mesmo thread: “Atualização: por mudança de auditoria, favor pagar a próxima parcela na nova conta. Segue comprovante de alteração.”
4) Fraude de folha de pagamento e dados de RH
O atacante se passa por um funcionário ou por RH e solicita alteração de conta para depósito de salário, ou pede envio de documentos e dados pessoais. Embora nem sempre seja “pagamento a terceiros”, é uma fraude financeira e de identidade.
Exemplo: “Sou o João, mudei de banco. Pode atualizar meus dados para o próximo pagamento? Estou sem acesso ao portal.”
5) Golpe de gift cards e compras rápidas
Um executivo “pede” que alguém compre cartões-presente e envie os códigos. É comum em empresas com cultura de resposta rápida e pouca verificação.
Exemplo: “Estou em reunião. Compre 10 cartões de R$ 500 e me envie os códigos por e-mail agora.”
Como o BEC acontece na prática: cadeia operacional do golpe
Em BEC, o atacante precisa alinhar três elementos: (1) identidade crível (real ou parecida), (2) contexto de negócio (faturas, projetos, prazos), e (3) um caminho de pagamento que ele controle (conta bancária, laranja, fintech, cripto, intermediários). O comprometimento de conta facilita muito porque permite observar padrões internos: assinaturas, horários, nomes de fornecedores, termos usados e etapas de aprovação.
Quando há comprometimento real, o atacante pode criar regras na caixa de e-mail para ocultar mensagens (por exemplo, mover e-mails de “financeiro@” para arquivo), marcar como lidas, ou encaminhar cópias para si. Também pode esperar o “momento certo”: perto do vencimento de uma fatura ou no fechamento do mês, quando o volume de pagamentos aumenta e a equipe está sob pressão.
Quando não há comprometimento, o atacante tenta simular legitimidade com domínios parecidos (ex.: “empresa-co.com” em vez de “empresa.com”), nomes de exibição (display name) idênticos ao do executivo, ou respostas que parecem continuação de uma conversa. Em muitos casos, a fraude depende menos de tecnologia e mais de falhas de processo: ausência de validação fora do e-mail, falta de dupla aprovação, e inexistência de procedimento formal para mudança de dados bancários.
Sinais de alerta específicos de BEC (além de “parece suspeito”)
- Solicitação de mudança de dados bancários para um fornecedor já cadastrado, especialmente com urgência ou justificativas vagas (“auditoria”, “mudança de banco”, “nova conta”).
- Pedido para contornar processo: “não envolva mais ninguém”, “não abra chamado”, “faça direto”.
- Instruções de pagamento fora do padrão: novo beneficiário, país diferente, conta de pessoa física, ou instituição financeira incomum para aquele fornecedor.
- Alterações sutis no endereço de e-mail (um caractere, domínio semelhante, troca de .com por .net) ou uso de “Responder para” (Reply-To) diferente do “De”.
- Pressão por tempo em horários atípicos (fim do expediente, véspera de feriado, fechamento do mês).
- Inconsistências administrativas: CNPJ/razão social divergente, dados bancários incompatíveis com o país do fornecedor, fatura com formatação diferente do habitual.
- Pedidos de confirmação por e-mail apenas, evitando telefone, reunião ou portal oficial.
Controles preventivos: como reduzir a chance de cair em BEC
1) Processo formal para alteração de dados bancários (controle-chave)
O controle mais efetivo contra desvio de pagamento é tornar a mudança de dados bancários um evento “de alto risco” com validação obrigatória fora do e-mail. Isso vale para fornecedores e para funcionários (folha).
- Regra: nenhuma alteração de conta bancária é aceita apenas por e-mail.
- Validação fora de banda: confirmar por telefone usando número já cadastrado (não o número do e-mail), ou via portal do fornecedor, ou por reunião rápida com contato conhecido.
- Registro: documentar quem solicitou, quem validou, data/hora, canal usado e evidências.
- Período de carência: alterações entram em vigor após X dias, exceto com aprovação adicional.
2) Dupla aprovação e segregação de funções
Pagamentos acima de determinado valor devem exigir duas aprovações independentes, preferencialmente de áreas diferentes (ex.: solicitante + financeiro; financeiro + controladoria). Também é importante separar quem cadastra fornecedor de quem aprova pagamento.
- Quem cadastra/edita dados bancários não deve ser a mesma pessoa que autoriza o pagamento.
- Pagamentos urgentes devem seguir o mesmo fluxo (urgência não pode ser justificativa para pular etapas).
3) “Call-back” obrigatório para instruções de pagamento
Defina uma política simples: qualquer instrução de pagamento recebida por e-mail que altere destino, valor, ou prazo deve ser confirmada por call-back para um contato conhecido. O call-back deve usar um número obtido de fonte confiável (cadastro interno, contrato, site oficial previamente validado), nunca o número informado no e-mail suspeito.
4) Proteções de e-mail e identidade (camada técnica)
Embora BEC possa ocorrer sem malware, controles técnicos reduzem impersonação e dificultam comprometimento de conta.
- MFA (autenticação multifator) obrigatório para e-mail e para sistemas financeiros.
- Políticas de acesso condicional: bloquear logins de países incomuns, exigir dispositivo gerenciado, alertar sobre “impossible travel”.
- SPF/DKIM/DMARC bem configurados para reduzir spoofing do domínio da empresa e melhorar detecção de domínios falsos.
- Alertas de regras suspeitas na caixa de e-mail (criação de forwarding, regras que apagam/movem mensagens, alteração de assinatura).
- Banner de e-mail externo (marcação visual para mensagens vindas de fora da organização), reduzindo confusão em pedidos “do CEO” que chegam de domínios externos.
5) Controles no ERP/banco e reconciliação
- Lista de beneficiários confiáveis e bloqueio de pagamento para novos beneficiários sem validação.
- Limites e alertas para transferências fora do padrão (valor, horário, conta nova).
- Conciliação diária e revisão de pagamentos “excepcionais”. Quanto mais cedo detectar, maior chance de recuperar.
Passo a passo prático: procedimento para lidar com pedido de mudança de conta bancária
Este roteiro pode ser aplicado por Contas a Pagar, Compras e Financeiro sempre que chegar um e-mail solicitando alteração de dados bancários de fornecedor.
Passo 1 — Classificar a solicitação como “alto risco”
Se o pedido envolve mudança de banco, agência, conta, chave PIX, IBAN/SWIFT, ou beneficiário, trate como alto risco automaticamente, mesmo que o e-mail pareça legítimo.
Passo 2 — Congelar a ação no sistema até validação
Não altere cadastro e não programe pagamento. Abra um registro interno (ticket ou formulário) com: data/hora, remetente, assunto, fatura relacionada, e dados bancários solicitados.
Passo 3 — Verificar autenticidade do remetente (checagens rápidas)
- Compare o domínio do e-mail com o domínio oficial do fornecedor (atenção a letras trocadas).
- Verifique se o “Reply-To” é diferente do “From”.
- Procure por mudanças de tom, assinatura, idioma, ou padrão de resposta.
- Se houver thread, confirme se a mensagem realmente pertence à conversa (às vezes o atacante simula assunto, mas não está no thread original).
Passo 4 — Fazer validação fora do e-mail (call-back)
Use um contato já cadastrado (nome e telefone do contrato, cadastro do fornecedor, ou número previamente validado). Ao ligar, não leia os dados bancários recebidos; peça que o fornecedor informe os dados “do zero” e compare com o que chegou por e-mail.
Script sugerido (objetivo e neutro):
Olá, aqui é [nome] do Financeiro da [empresa]. Recebemos uma solicitação de alteração de dados bancários para pagamentos. Por política, preciso confirmar por telefone. Você pode me confirmar: (1) se a solicitação é legítima, (2) qual é o banco/agência/conta (ou chave PIX) corretos e (3) a partir de quando a mudança deve valer?Passo 5 — Exigir evidência formal quando aplicável
Dependendo do porte e criticidade, solicite documentação: carta em papel timbrado assinada, aditivo contratual, ou confirmação via portal do fornecedor. Para fornecedores críticos, considere validação por dois contatos independentes.
Passo 6 — Atualizar cadastro com trilha de auditoria
Somente após validação, atualize o cadastro no ERP e anexe evidências. Registre quem aprovou e quem executou. Se possível, configure o sistema para notificar automaticamente a área de compliance/controladoria sobre alterações de dados bancários.
Passo 7 — Aplicar “período de segurança” e teste de pagamento
Para valores altos, use um pagamento de teste (microdepósito) ou aguarde um período de carência antes de pagar faturas grandes na nova conta. Em alguns contextos, isso reduz perdas quando a validação falha.
Passo a passo prático: como responder a um incidente de BEC (suspeita ou confirmação)
O tempo é crítico. A resposta deve ocorrer em paralelo em três frentes: contenção de conta, bloqueio/recuperação financeira e preservação de evidências.
Passo 1 — Interromper pagamentos e acionar responsáveis
- Se um pagamento ainda não foi feito: pause imediatamente e sinalize como potencial fraude.
- Se já foi feito: acione o banco/tesouraria imediatamente para tentativa de recall/contestação e bloqueio do beneficiário.
- Notifique liderança do Financeiro e Segurança/IT (ou responsável equivalente) para coordenação.
Passo 2 — Preservar evidências do e-mail
Não apague mensagens. Salve o e-mail original, incluindo cabeçalhos completos (headers). Registre: data/hora, remetentes, contas envolvidas, valores, dados bancários, e qualquer anexo/fatura.
Passo 3 — Verificar se houve comprometimento de conta (ATO)
- Checar logs de login: localizações, IPs, dispositivos, horários.
- Procurar regras de encaminhamento e filtros criados recentemente.
- Revisar permissões delegadas e aplicativos conectados (OAuth) que possam ter acesso à caixa.
Passo 4 — Conter e recuperar acesso
- Reset de senha e revogação de sessões ativas.
- Habilitar/forçar MFA e revisar métodos de recuperação de conta.
- Remover regras maliciosas, encaminhamentos e apps suspeitos.
- Se houver risco de comprometimento amplo, ampliar para outras contas com padrões semelhantes.
Passo 5 — Comunicar parceiros afetados e bloquear continuidade do golpe
Se o ataque envolveu fornecedor/cliente, comunique por canal confiável (telefone oficial, portal, contato conhecido) que houve tentativa de fraude e que instruções de pagamento por e-mail devem ser desconsideradas até validação. Isso reduz a chance de o atacante explorar a mesma conversa com outras pessoas.
Passo 6 — Revisar pagamentos recentes e cadastros alterados
Audite alterações de dados bancários e pagamentos dos últimos dias/semanas, priorizando: novos beneficiários, mudanças de conta, pagamentos urgentes e transações fora do padrão. Em BEC, pode haver mais de uma tentativa antes do desvio “bem-sucedido”.
Checklist operacional para equipes de Financeiro, Compras e RH
Antes de pagar
- O beneficiário e a conta já existiam no cadastro? Se mudou, houve validação fora do e-mail?
- O pedido pede sigilo, urgência ou bypass de processo?
- O e-mail veio de domínio oficial e o Reply-To confere?
- O valor e o prazo são compatíveis com o histórico?
- Há duas aprovações registradas para pagamentos acima do limite?
Ao receber pedido de alteração de conta
- Registrar solicitação e congelar execução.
- Call-back para contato conhecido.
- Evidência formal anexada.
- Atualização com trilha de auditoria.
- Notificação interna de alteração (controladoria/compliance).
Ao suspeitar de BEC
- Parar pagamentos e acionar banco imediatamente.
- Preservar e-mail e cabeçalhos.
- Checar comprometimento de conta e conter.
- Alertar áreas envolvidas e parceiros por canal confiável.
- Auditar alterações e transações recentes.
Exemplo guiado: tentativa de desvio de pagamento em fatura real
Cenário: a empresa recebe mensalmente faturas de um fornecedor de logística. Um analista de contas a pagar recebe um e-mail: “Mudamos nossa conta para recebimentos. Favor pagar a fatura deste mês na nova chave PIX.” A fatura anexada parece idêntica às anteriores, com mesmo layout e valores compatíveis.
Aplicação do procedimento:
- Classificação: alto risco (mudança de dados bancários).
- Congelamento: não alterar cadastro nem agendar pagamento.
- Checagens: domínio do remetente tem uma letra a mais; Reply-To aponta para outro domínio.
- Call-back: ligação para o contato do contrato (número já cadastrado). O fornecedor nega a mudança.
- Ação: registrar incidente, avisar Segurança/IT, bloquear o domínio semelhante em filtros, e reforçar com o fornecedor um canal oficial para mudanças cadastrais.
Observe que a fatura “perfeita” não é prova de legitimidade: em BEC, o atacante pode copiar modelos reais ou até obter faturas verdadeiras se tiver acesso a conversas comprometidas.
