6 min de leitura Por Excello Mail Team

Confiável por Design: Como Chaves Roubadas da AWS Transformam o Amazon SES em uma Arma de Phishing Autenticada

Pesquisadores da Kaspersky e da Wiz mapearam separadamente o mesmo esquema: atacantes encontram chaves IAM da AWS vazadas, levam contas do Amazon SES à produção em todas as regiões, e enviam e-mails de phishing e BEC que passam por SPF, DKIM e DMARC porque realmente vêm da infraestrutura da Amazon.

Duas equipes de pesquisa independentes mapearam agora o mesmo esquema de ataque a partir de ângulos diferentes. O grupo Securelist da Kaspersky documentou um forte aumento nas campanhas de phishing e comprometimento de e-mail corporativo que abusam do Amazon Simple Email Service no início de 2026, enquanto a empresa de segurança em nuvem Wiz rastreou separadamente a mecânica técnica: como uma chave de acesso da AWS vazada se transforma em uma plataforma de phishing funcional em questão de minutos. Nenhuma das duas equipes encontrou uma falha no SPF, DKIM ou DMARC. Encontraram algo mais desconfortável: atacantes enviando e-mails através de infraestrutura que passa legitimamente pelos três controles, porque é a própria infraestrutura da Amazon, alugada com credenciais roubadas de outra pessoa.

De uma Chave Vazada a uma Cota de Envio em Produção

O esquema começa com um reconhecimento que não tem nada a ver com e-mail. Bots automatizados, muitas vezes construídos sobre ferramentas de código aberto de varredura de segredos, vasculham repositórios públicos do GitHub, arquivos .env expostos, imagens Docker e buckets S3 mal configurados em busca de chaves de acesso IAM da AWS que desenvolvedores deixaram para trás. Quando uma chave aparece, os atacantes verificam o que ela pode fazer com uma simples chamada GetCallerIdentity. Um nome de chave contendo “ses” costuma ser suficiente para indicar que foi provisionada para o serviço de e-mail da Amazon.

O próximo passo é o que transformou isso de um incômodo em uma arma em escala. A Amazon limita contas novas do SES em um modo sandbox com limites de envio rígidos até que um humano solicite acesso à produção. Os pesquisadores observaram atacantes automatizando essa solicitação, disparando chamadas PutAccountDetails em todas as regiões da AWS com segundos de diferença entre elas, levando a conta ao modo de produção região por região e destravando uma cota padrão de dezenas de milhares de e-mails por dia, multiplicada pelo número de regiões ativadas de uma só vez.

Duas Iscas, um Único Envelope de Confiança

Com o acesso de envio garantido, a Kaspersky documentou dois tipos distintos de campanha rodando sobre a mesma infraestrutura. A primeira se passa por serviços de assinatura eletrônica, mais comumente o Docusign, pedindo ao destinatário que clique para revisar um documento. O link resolve para amazonaws.com, infraestrutura que a maioria dos usuários e muitos filtros de segurança tratam como inerentemente segura, antes de redirecionar para uma página de roubo de credenciais. A segunda é uma jogada de comprometimento de e-mail corporativo mais paciente: um fio de mensagens fabricado para parecer uma conversa em andamento entre um funcionário e um fornecedor sobre uma fatura pendente, enviado à equipe financeira do alvo com um pedido urgente para liberar um pagamento.

Por Que a Autenticação Passa Sem Problemas

Essa é a parte que vale a pena parar para analisar. SPF, DKIM e DMARC existem para responder a uma pergunta: o proprietário do domínio autorizou essa infraestrutura a enviar em seu nome? Nunca foram projetados para fazer uma segunda pergunta que aqui importa igualmente: quem detém hoje as chaves dessa infraestrutura ainda é a parte em quem o proprietário do domínio confia? O Amazon SES é infraestrutura autorizada. Uma chave IAM roubada não muda esse fato do ponto de vista do protocolo, então o e-mail enviado por uma conta SES sequestrada se autentica com a mesma limpeza que o e-mail enviado pelo dono legítimo da conta.

A pesquisa da Wiz acrescenta um detalhe mais afiado. Os atacantes verificaram novas identidades na conta comprometida para domínios que controlavam totalmente, o que é esperado. Mas também encontraram atacantes reutilizando identidades de domínio que já estavam verificadas na conta antes de ela ser roubada, especificamente domínios com políticas DMARC fracas ou não aplicadas, o que permitiu que se passassem por uma marca real e previamente confiável através de infraestrutura que a própria equipe daquela marca havia configurado. Bloquear as faixas de IP de envio da Amazon também não é uma defesa viável, já que isso derrubaria enormes volumes de tráfego legítimo do SES usado por empresas comuns em todo o mundo.

Fechando a Lacuna nas Duas Pontas

Trate as credenciais de envio em nuvem como um problema de identidade, não de e-mail. Limite as políticas IAM ao privilégio mínimo, migre de chaves estáticas de longa duração para papéis de curta duração onde a automação do SES permitir, aplique MFA nas contas que administram essas credenciais, e vasculhe seus próprios repositórios e backups de configuração em busca de chaves expostas antes que o bot de um atacante as encontre primeiro.

Aplique o DMARC com cobertura total em cada identidade de domínio que você já verificou em um serviço de envio em nuvem, não apenas no seu domínio principal. A descoberta da Wiz foi específica: foram as identidades com DMARC fraco que foram reutilizadas para a falsificação. Um subdomínio esquecido ou uma identidade legada sem política é exatamente o tipo de ponta solta que essa campanha foi feita para encontrar.

Vigie a conta, não apenas a caixa de entrada. Uma rajada de chamadas de API abrangendo várias regiões, uma solicitação repentina de acesso à produção, ou uma nova verificação de identidade que ninguém da equipe iniciou são sinais visíveis bem antes de o primeiro e-mail de phishing ser enviado. Essa telemetria pertence ao mesmo canal de monitoramento que seus relatórios agregados de DMARC.

Do lado do destinatário, lembre-se do que a alinhamento do DMARC realmente certifica. Ele confirma que a infraestrutura de envio foi autorizada por um proprietário de domínio em algum momento, não que a mensagem de hoje venha das mesmas mãos que foram autorizadas originalmente. Mensagens que passam pela autenticação ainda precisam de uma camada adicional de inspeção de conteúdo e comportamento, especialmente as que pedem para o financeiro movimentar dinheiro.

A Conclusão

Infraestrutura confiável em nuvem se transformando em uma plataforma de phishing não é uma ideia nova, mas a escala aqui é um lembrete de quanta defesa hoje acontece antes de chegar à caixa de entrada, na higiene de credenciais e na cobertura de DMARC que a maioria das equipes nunca pensa em revisar. Um domínio com uma política DMARC forte e práticas de IAM limpas não deixa ao atacante nada com que trabalhar, mesmo depois de encontrar uma chave funcional.


Uma cobertura completa de DMARC em cada domínio e subdomínio que você possui fecha exatamente o tipo de identidade reutilizada e fracamente protegida em que essa campanha se apoia. Cadastre-se gratis no Excello Mail para obter a visibilidade e as ferramentas de aplicação necessárias para encontrar essas brechas antes que outra pessoa o faça.