Microsoft Solutions Partner · Modern Work · Security
Empresa brasileira do setor de bens de consumo
Durante 32 dias, um atacante manteve acesso à caixa de e-mail do CEO de uma empresa brasileira do setor de bens de consumo. Ele entrou com a senha correta, sem nenhuma tentativa errada antes, numa conta que não exigia MFA. Usou o acesso para ler negociações, esconder mensagens e montar fraudes de pagamento contra três parceiros comerciais internacionais.
Recebeu, da caixa real do CEO, cobranças de centenas de milhares de dólares e o aviso de que o pagamento deveria ir para uma nova conta no exterior. Em cópia, “colaboradores” com endereços de um domínio falso da empresa.
O atacante se passou pelo fornecedor do Parceiro B, usando um domínio com uma letra a mais, e pediu a troca da conta de recebimento.
O atacante se passou pelo Parceiro B e pediu ao fornecedor verdadeiro cópias de todas as faturas vencidas, possivelmente para preparar novas fraudes.
A empresa foi o ponto de vazamento das conversas usadas nas fraudes. O atacante teve acesso integral à caixa do CEO e enviou mensagens em nome dele. O vetor inicial mais provável é o roubo da senha por phishing, mas a entrega e o clique não foram comprovados. A ausência de MFA foi o fator determinante.
A fraude foi percebida por um colaborador da área comercial que estava em cópia numa conversa entre dois parceiros: os endereços do fornecedor tinham sido trocados por um domínio quase idêntico, e o distribuidor já havia pago em uma nova conta. A empresa reuniu os prints da conversa e a carta bancária falsa e acionou a Frayha.
A pergunta inicial era objetiva: o vazamento da conversa ocorreu do nosso lado? A investigação começou no dia seguinte à detecção (D+33), com acesso administrativo ao ambiente Microsoft 365 da empresa.
Nenhuma alteração foi feita na conta comprometida antes da preservação do conteúdo e da coleta da configuração da caixa. Todos os arquivos de evidência receberam hash SHA-256 e registro em planilha de cadeia de custódia. As análises foram feitas sempre em cópias de trabalho, com ferramentas somente leitura, e cada achado foi conferido contra a evidência original.
| Fonte / ferramenta | O que foi coletado | Uso na análise |
|---|---|---|
| Purview eDiscovery | Caso dedicado; hold sem filtro; pesquisas KeyQL por domínio; exports PST | Preservação e conteúdo das caixas, inclusive itens apagados |
| Purview Audit | Cerca de 28 mil registros do período; busca por todos os IPs do atacante | MailItemsAccessed, regras, envios, exclusões, quarentena |
| Entra ID | Logs de entrada interativos e não interativos; auditoria de diretório | Separação entre usuário legítimo e atacante; prova da contenção |
| Exchange Online | Message trace, regras de caixa, permissões, Tenant Allow/Block List | Envios, origem das mensagens e bloqueios |
| PowerShell 7 | Scripts de coleta e remoção, com transcript e hash | Coleta reprodutível |
| libpff / pypff | Leitura dos PSTs exportados (somente leitura) | Cabeçalhos, propriedades MAPI, itens recuperáveis |
| RDAP e DNS | Registro e configuração dos domínios falsos | Datas de criação, registrador, servidores de e-mail |
No Business Premium (Entra ID P1), os logs de entrada e de auditoria do Entra ficam disponíveis por 30 dias. Os primeiros dias do ataque só puderam ser reconstruídos pelo Purview Audit (180 dias). A quarentena guarda mensagens por 30 dias, e o message trace, 90. Sem o Defender for Office 365 Plano 2, o Threat Explorer não estava disponível.
D0 = dia do primeiro acesso do atacante. Horários em UTC.
Phishing “Password Recovery – Your Password is About to Expire” enviado ao CEO, com remetente forjado como o próprio endereço dele e caracteres invisíveis no assunto.
Aviso de atraso de entrega vindo do servidor do atacante: o Exchange ainda recusava a mensagem com “451 4.7.500 Server busy”.
Mensagem com o mesmo assunto retida em quarentena, possivelmente a reentrega.
Primeiro login do atacante, pelo Outlook na Web, com a senha correta e sem falhas antes. Três minutos depois já lia as conversas com o Parceiro B.
Registro do primeiro domínio falso, imitando o da empresa (sem uma letra e sem o “.br”). Mensagem de teste enviada ao CEO e apagada em seguida.
Criação da regra de caixa “.”: mensagens do domínio falso e do Parceiro A vão para a pasta RSS Feeds, marcadas como lidas.
Pedido de liberação de uma mensagem da quarentena, num horário com apenas sessões legítimas. Conteúdo não identificável (retenção expirada).
Da caixa real do CEO, cobrança ao Parceiro A de valor na casa das centenas de milhares de dólares, com dois “colaboradores” do domínio falso em cópia.
Nova mensagem ao Parceiro A: a conta bancária habitual estaria “indisponível por auditoria interna” e o pagamento deveria ir para uma conta no exterior. Rascunho sobre o Parceiro B criado e apagado; segundo domínio falso registrado 3,5 h depois.
Mensagem de teste do segundo domínio falso enviada só para o CEO e excluída permanentemente um minuto depois.
Acessos às páginas de suporte e de perfil e segurança da conta.
Extrato de contas legítimo do fornecedor para o Parceiro B, com o CEO entre os destinatários.
Rascunho da mensagem falsa montado dentro da caixa do CEO e apagado. Seis minutos depois, primeira mensagem do domínio falso do fornecedor ao Parceiro B anunciando “nova conta bancária nos EUA”. Um minuto depois, o atacante desativa a regra de caixa.
Aceita, na própria conversa, usar aquele fio de e-mail para atualizar os dados bancários.
Carta bancária falsa enviada. Cada mensagem da conversa que chegava ao CEO era apagada manualmente em segundos.
Duas tentativas de login sem sucesso contra uma diretora, uma delas com a mesma técnica usada contra o CEO.
Confirma a transferência para a conta fraudulenta.
Terceiro domínio falso registrado, imitando o Parceiro B. Nove mensagens ao fornecedor verdadeiro pedindo cópias de todas as faturas vencidas.
Último login e último evento do atacante. No mesmo dia, um colaborador em cópia percebe o domínio trocado.
| Momento | Ação |
|---|---|
| D+33 · tarde | Abertura do caso no eDiscovery e hold sem filtro nas caixas e no OneDrive dos envolvidos |
| D+33 · +2,5 h | Logs de entrada analisados: acesso indevido à conta do CEO identificado |
| D+33 | Varredura do ambiente pelos domínios falsos |
| D+34 · manhã | Análise do Audit: regra oculta, envios ao Parceiro A, exclusões manuais e 2.067 itens lidos |
| D+34 | Coleta da configuração da caixa antes de qualquer remoção: sem encaminhamento, sem delegações |
| D+34 | Remoção da regra maliciosa, com transcript |
| D+34 | Exports dos domínios falsos, cabeçalhos das mensagens e manifesto SHA-256 dos PSTs; hold ampliado |
| D+34 | Bloqueio dos três domínios falsos na Tenant Allow/Block List |
| D+34 | Revogação de todas as sessões e redefinição da senha do CEO |
| D+34 | Modelos de comunicado para equipe interna e parceiros |
| D+35 | MFA registrado e conta incluída em política de Acesso Condicional com MFA |
| D+35 | Análise do vetor inicial em cerca de 4.900 itens |
| D+36 | Manifesto SHA-256 completo (171 arquivos); integridade de 84/84 PSTs reverificada |
| D+39 | Registro e DNS dos domínios falsos; atividade por IP em todo o ambiente; auditoria do Entra |
| Atributo | Observação |
|---|---|
| Sistema e navegador | macOS + Chrome, sem dispositivo registrado. O CEO usa Windows com dispositivo registrado, o que facilitou separar sessões legítimas das do atacante. |
| Infraestrutura | IPs rotativos de VPN e hospedagem em vários países, além de rede móvel na Nigéria em dias-chave da fraude |
| Volume | Cerca de 1.700 eventos de login e mais de 400 IPs catalogados |
| Aplicações | Outlook na Web, download de anexos, busca, Teams e Copilot, além das páginas de suporte, perfil e administração |
| Falhas | 45 falhas no período, só 1 por senha incorreta: a credencial estava em poder do atacante desde o início |
A hipótese mais provável é phishing de credencial: uma campanha de “senha expirando” mirou o CEO oito dias antes do primeiro acesso. As evidências, porém, mostram a primeira cópia recusada pelo servidor e a reentrega retida em quarentena. Não há prova de entrega na Caixa de Entrada nem de clique.
Permanecem abertas as hipóteses de senha reutilizada e vazada em outro serviço, de infostealer no notebook ou celular, ou de outro phishing não identificado. Em qualquer hipótese, o fator determinante foi a ausência de MFA.
Nome da regra : "." Condição : remetente contém [domínio falso da empresa]; [domínio do Parceiro A] Ação : marcar como lida → mover para RSS Feeds → parar de processar regras
O nome de um caractere e a pasta RSS Feeds, raramente aberta, são escolhas típicas para passar despercebido. Quando a fraude migrou para uma conversa que a regra não cobria, o atacante passou a apagar cada mensagem manualmente, em segundos, com exclusão permanente. Todas foram recuperadas pelo hold a partir dos itens recuperáveis. Não havia encaminhamento externo nem delegações de caixa.
| Imitação | Técnica | Infraestrutura |
|---|---|---|
| Domínio da empresa | Sem uma letra e sem o “.br”, explorando um erro de digitação que já aparecia em mensagens legítimas havia anos | Google Workspace |
| Domínio do fornecedor (Parceiro C) | Uma letra a mais no plural | Zoho Mail |
| Domínio do distribuidor (Parceiro B) | Uma letra a mais no plural | Zoho Mail |
Os três domínios foram registrados no mesmo registrador, durante o ataque, cada um poucas horas antes do uso. As mensagens passaram em SPF e DKIM e receberam nota de spam baixa (SCL 1): estavam tecnicamente autenticadas e o filtro não tinha motivo técnico para bloqueá-las. A defesa contra esse tipo de ataque está na proteção contra personificação e nos processos, não na autenticação de remetente.
O atacante abriu 2.067 mensagens distintas, a maior parte da Caixa de Entrada, dos Itens Excluídos e dos Itens Enviados, incluindo negociações, dados financeiros e dados de terceiros. Isso exigiu avaliação jurídica sob a LGPD. Das cerca de 180 mensagens enviadas pela caixa no período, só 2 saíram de IPs do atacante.
| Tática | Técnica | Como apareceu no caso |
|---|---|---|
| Desenvolvimento de recursos | T1583.001Adquirir infraestrutura: domínios | Três domínios parecidos registrados durante o ataque |
| Acesso inicial | T1566Phishing (provável) | Campanha de “senha expirando” com remetente forjado |
| Acesso inicial / persistência | T1078.004Contas válidas: nuvem | Login com a senha correta numa conta sem MFA |
| Coleta | T1114.002Coleta remota de e-mail | 2.067 mensagens abertas pelo Outlook na Web |
| Evasão de defesa | T1564.008Regras de ocultação de e-mail | Regra “.” movendo respostas para RSS Feeds |
| Evasão de defesa | T1070.008Limpeza de dados da caixa | Exclusão permanente, uma a uma, das mensagens da fraude |
| Impacto | T1656Personificação | Mensagens como CEO, fornecedor e distribuidor para desviar pagamentos |
Credencial do CEO em poder do atacante numa conta sem MFA, o que permitiu login com fator único por 32 dias.
| Fator contribuinte | Efeito no incidente |
|---|---|
| Conta executiva sem MFA | A senha bastou para entrar e manter o acesso. Fator determinante. |
| Nenhum alerta para comportamento anômalo | Logins de países atípicos, criação de regra oculta e exclusões em massa passaram despercebidos. A detecção veio de uma pessoa. |
| Domínios parecidos não sinalizados | Mensagens autenticadas e com nota de spam baixa; não havia proteção contra personificação de parceiros. |
| Usuário podia liberar itens da quarentena | Aumenta a chance de um phishing retido chegar ao usuário. |
| Troca de conta bancária aceita por e-mail | O parceiro autorizou a troca na própria conversa e pagou, sem confirmação por outro canal. |
| Retenção curta de registros de identidade | Parte da trilha do atacante já não podia ser reconstituída quando a investigação começou. |
| Parte | Impacto |
|---|---|
| Parceiro B Crítico | Pagamento transferido para conta fraudulenta num banco nos EUA |
| Parceiro A Alto | Cobrança legítima desviada, com pedido de pagamento em conta no exterior |
| Parceiro C Médio | Pedido fraudulento de cópias de faturas vencidas |
| Empresa Alto | Conta do CEO comprometida, 2.067 mensagens expostas e nome da empresa usado contra parceiros |
Domínios falsos bem configurados passam em todos os testes técnicos de autenticação. O que impede a fraude é a combinação de MFA em todas as contas, alertas de comportamento e confirmação de dados bancários por um canal fora do e-mail.
Avaliamos MFA, Acesso Condicional, alertas e proteção contra personificação do seu Microsoft 365. Em caso de incidente em andamento, fale direto com a equipe de resposta.
