Como plataformas de nuvem legítimas ajudam phishers a burlar a autenticação multifator

Os invasores recorrem cada vez mais a serviços legítimos para evitar a detecção e simplificar a criação de infraestruturas fraudulentas. Entre esses serviços, as plataformas de nuvem e as redes descentralizadas ocupam um lugar de destaque, pois são nelas que hospedam páginas e sites de phishing. Entre 2025 e 2026, observa-se uma migração constante dos phishers para plataformas como Cloudflare Workers, Vercel, Netlify, GitHub Pages e IPFS. Neste artigo, não apenas analisamos a mecânica de um ataque AiTM (Adversary-in-the-Middle) real em infraestrutura de nuvem, mas também apresentamos estatísticas detalhadas sobre quais plataformas e domínios os invasores mais escolhem para hospedar phishing.

A nuvem como refúgio para phishers

As razões que levam os invasores a escolher PaaS (plataforma como serviço) e outros serviços de nuvem — ou distribuídos — para hospedar sites de phishing são, em grande parte, as mesmas que orientam os desenvolvedores legítimos:

• Confiança e reputação: as páginas de phishing publicadas em plataformas legítimas transmitem mais confiança e despertam menos suspeitas nas vítimas em potencial.
• Disponibilidade: a maioria das plataformas oferece planos gratuitos com limites generosos para desenvolvedores, e o cadastro leva minutos e costuma dispensar o processo KYC (“Know Your Customer”, ou seja, “conheça seu cliente”, que é o processo de verificação de identidade do usuário), o que permite que um único invasor crie centenas de contas.
• Proteção e anonimato: os invasores aproveitam os mecanismos de proteção integrados e ocultam o IP real do servidor atrás de uma CDN, o que dificulta a detecção por parte dos fornecedores de soluções de segurança.

Cabe destacar que essas plataformas atribuem subdomínios próprios aos usuários, nos quais coexistem milhões de projetos e sites legítimos. Isso inviabiliza o bloqueio do domínio ou dos subdomínios sem prejudicar os usuários legítimos — circunstância amplamente explorada pelos invasores. Para neutralizar esses ataques, os fornecedores de soluções de segurança precisam aprimorar os métodos de detecção de ameaças baseados na análise de conteúdo.

Ataque AiTM em múltiplas etapas

Vamos analisar uma campanha de phishing atual, construída segundo o esquema AiTM e que utiliza a popular plataforma de nuvem Cloudflare Workers. O ataque é executado por meio de várias páginas HTML que os invasores hospedam tanto no site comprometido quanto nessa plataforma. Cada página cumpre uma função específica: coletar os endereços de e-mail das vítimas, inicializar a infraestrutura de proxy e falsificar a janela de autenticação para interceptar a sessão de autenticação multifator (MFA).

Etapa 1. Obtenção de contatos reais e evasão do monitoramento de rede

No e-mail de phishing, os invasores frequentemente utilizam um pretexto convincente para induzir a vítima a clicar no link. Pode ser, por exemplo, o pedido de um colega para revisar alguns documentos.

Ao clicar no link de phishing, a vítima é direcionada a uma página com pseudocaptcha, hospedada pelo invasor em um site legítimo comprometido (neste ataque, utilizou-se um site no formato https://t……e.com, embora possa ser qualquer outro). Neste caso, a página comprometida foi utilizada como recurso descartável (visto que fornecedores costumam bloquear links de phishing recebidos por e-mail com maior rapidez) para evitar a detecção precoce do conteúdo principal de phishing hospedado na Cloudflare.

Se o usuário inserir seu e-mail e clicar no botão Continuar, o simulacro de captcha o valida como humano e o redireciona para a próxima etapa. O objetivo principal desta etapa é coletar endereços de e-mail, filtrar bots primitivos e redirecionar o usuário real para a URL .workers.dev. A Cloudflare Workers atribui esse tipo de endereço de forma automática e gratuita. O script insere o e-mail da vítima no fragmento da URL (após o símbolo #) para que a página em .workers.dev recupere o dado sem contactar o servidor do invasor, evitando a detecção.

Etapa 2. Inicialização do proxy transparente

O navegador da vítima carrega uma página no formato .workers.dev/…#user@business.com. Exibe-se à vítima um captcha real (nesta etapa, os invasores precisam confirmar que a página é acessada por uma pessoa real, e não por um ambiente de sandbox).

Outro captcha, desta vez real

Após a solução do captcha, a página do invasor registra um Service Worker no navegador da vítima: um script JavaScript executado em segundo plano, capaz de interceptar todas as solicitações de rede da aba ativa. Esse script constitui a base da tecnologia de aplicativos web progressivos (Progressive Web Apps, PWA): acelera o carregamento de dados e permite que o aplicativo web funcione sem conexão com a internet. O navegador trata o Service Worker como funcionalidade normal do site e, quando o recurso web opera via HTTPS, não solicita confirmação para que o script comece a ser executado.

Sobre esse Service Worker, os invasores implantam o Ultraviolet, uma biblioteca legítima de código aberto projetada para criar proxies web. Os invasores a utilizam para reescrever dinamicamente, em tempo real, todos os links e formulários da página, fazendo com que as solicitações (inclusive o envio de credenciais ao site da Microsoft) não sejam enviadas diretamente aos serviços originais, mas sim roteadas pelo servidor dos invasores.

Imediatamente após o carregamento, a página extrai o e-mail da vítima do fragmento da URL e o salva no armazenamento de sessão do navegador (sessionStorage) para preservá-lo durante o carregamento do captcha. Além disso, isso permite preencher automaticamente o campo de login no formulário. O campo preenchido antecipadamente aumenta a confiança da vítima e torna a página mais convincente. Depois de resolver o captcha com sucesso, o script do invasor gera a URL de redirecionamento para a terceira etapa, devolvendo ao hash o e-mail salvo no sessionStorage. Dessa forma, o e-mail é transmitido via fragmento da URL ao longo de três etapas consecutivas, sem acionar os mecanismos de detecção de anomalias de rede.

Registro do Service Worker para interceptar o tráfego

Criação de um “proxy transparente” por meio de uma biblioteca independente

Etapa 3. Interceptação da sessão por meio da falsificação da janela do navegador

A etapa final ocorre na terceira página: à técnica AiTM (Adversary-in-the-Middle, ataque intermediário) soma-se a técnica BiTB (Browser-in-the-Browser, falsificação de interface). A técnica BiTB consiste no seguinte: dentro de uma página web legítima, abre-se um bloco projetado para imitar uma janela pop-up autêntica. Neste caso, o script hospedado na página do invasor gera uma janela pop-up visualmente idêntica a uma janela do sistema do navegador (com uma barra de endereço falsa exibindo uma URL confiável da Microsoft, além dos botões de controle). Dentro dessa janela, um iframe carrega o formulário de login real, cujo tráfego é roteado por meio do Service Worker configurado na segunda etapa. Quando a vítima insere o nome de usuário, a senha e o código MFA na janela falsa, o script de proxy intercepta não apenas as credenciais, mas também os tokens de sessão. A combinação de BiTB com AiTM torna o ataque especialmente perigoso, pois o BiTB cria uma fachada visual confiável (a vítima vê a URL correta e os logotipos), enquanto o proxy AiTM oculto por trás dessa fachada se encarrega de interceptar o tráfego e roubar os tokens de sessão.

Após a autenticação bem-sucedida, o proxy envia um comando para fechar a janela e redireciona a vítima para uma página de erro do sistema (por exemplo, SessionExpired). Isso reduz a vigilância do usuário, que supõe ter ocorrido uma falha técnica e tenta fazer login novamente, enquanto o invasor já possui acesso total à sessão.

Estatísticas de ataques de phishing em plataformas de nuvem

Analisamos os links de phishing hospedados em plataformas de nuvem populares (Cloudflare, Netlify, GitHub Pages, entre outras) ao longo dos últimos 12 meses (de agosto de 2025 a julho de 2026). A seguir, apresentamos a evolução do número de domínios únicos de terceiro nível usados para distribuir conteúdo de phishing. No total, nos últimos 12 meses, nossas soluções bloquearam 224.984 domínios exclusivos de terceiro nível na nuvem e serviços descentralizados usados para ataques de phishing.

Número de domínios únicos de tercer nivel
(download)

Com base nesses dados, também elaboramos um top 10 de domínios de nuvem mais utilizados em campanhas de phishing durante o período indicado.

Quantidade de links de phishing

Cloudflare e Vercel destacam-se como líderes indiscutíveis, o que é esperado, pois ambas oferecem planos gratuitos, emissão automática de certificados SSL e CDNs globais. O GitHub Pages também integra o top 3. A popularidade do domínio github.io dificulta o bloqueio em massa de páginas de phishing hospedadas nele sem arriscar o acesso a projetos legítimos. As redes descentralizadas merecem atenção especial (em 2023, publicamos um artigo sobre esse tema): os domínios ipfs.io e dweb.link são gateways do IPFS. O principal risco dessas plataformas está na persistência do conteúdo: mesmo que um gateway seja bloqueado, a página de phishing continua acessível por meio de outros nós da rede.

O top 10 também inclui os construtores visuais Wix e Webflow (nas posições 8 e 9, respectivamente). Essas ferramentas permitem criar páginas de phishing rapidamente e sem conhecimentos técnicos profundos de código, o que reduz a barreira de entrada para invasores menos preparados.

Nos últimos 12 meses, registramos mais de 390.000 páginas de phishing hospedadas em plataformas de nuvem legítimas e em redes descentralizadas (IPFS). Esses dados confirmam que os invasores exploram amplamente a confiança depositada em serviços legítimos de PaaS (Cloudflare Workers, Vercel, Netlify, GitHub Pages) e IPFS. A sólida reputação dessas plataformas, seus planos gratuitos e seus mecanismos de camuflagem integrados permitem que os phishers implantem, de forma eficaz, ataques AiTM em múltiplas etapas e interceptem sessões MFA.

Recomendações

Os métodos de proteção tradicionais (como verificar o “cadeado verde” ou bloquear domínios por meio de listas de bloqueios) são insuficientes nesses casos. O domínio principal do provedor permanece confiável, enquanto os subdomínios maliciosos são criados de forma automática e em massa. Para neutralizar essas ameaças, é necessária uma abordagem abrangente:

• Proceda com cautela ao receber solicitações inesperadas, mesmo que provenham de domínios confiáveis ou que a página exiba um certificado SSL válido.
• Em geral, os captchas não solicitam dados pessoais (neste caso, o endereço de e-mail). Se pedirem para concluir uma verificação antibots fornecendo dados pessoais, é bem provável que se trate de uma fraude.
• Verifique atentamente a URL na barra de endereços da janela principal do navegador. Em ataques do tipo Browser-in-the-Browser, os invasores podem renderizar uma janela pop-up falsa e inserir nela qualquer endereço, inclusive um legítimo. No entanto, a barra de endereço real, localizada na parte superior da tela e que inclui os botões de navegação (voltar, avançar, atualizar), continuará exibindo o domínio real do invasor.
• Não insira dados em janelas que surjam repentinamente. Se um formulário para inserir a senha ou o código MFA aparecer sem uma ação explícita da sua parte, fechem a aba e acessem o serviço desejado manualmente, digitando o endereço no navegador.
• Uma proteção adicional é oferecida por soluções confiáveis de e-mail que garantem a segurança da correspondência corporativa (Kaspersky Secure Mail Gateway) e pessoal (Kaspersky Premium), neutralizando os links de phishing já na etapa de entrega da mensagem.