O kit de phishing batizado de Wazza mira organizações bancárias, de manufatura e de governo nos Estados Unidos, Europa e Austrália, e sua diferença para um clone comum de página de login está no caminho até a isca: a vítima passa por validação de campanha, tokens de sessão de curta duração e filtros anti-bot antes de entregar a isca final, uma página de phishing por código de dispositivo com tema Adobe Document Cloud. Para o time de defesa, há duas ações prioritárias: reproduzir o fluxo completo do navegador em ambiente controlado antes de dar veredito sobre um link suspeito e restringir o uso do fluxo de código de dispositivo no ambiente Microsoft.
O kit já tem análise primária e confirmação independente. A seguir, a anatomia da cadeia, o que muda na investigação quando a isca filtra o visitante e a ordem de contenção por prioridade.
O que é o kit Wazza
O Wazza foi identificado pela ANY.RUN na telemetria de setembro como um phishkit que embute roteamento em múltiplas etapas, gestão de sessão e controles de tráfego na infraestrutura que serve a página. Não é uma cópia estática de uma tela de login: o kit decide quem vê a isca, em que momento e com qual marca. Em análise independente publicada em outubro, a LevelBlue SpiderLabs descreveu ondas do Wazza ativas desde pelo menos o início de julho de 2026, entregues por e-mails enviados de contas corporativas comprometidas, com PDFs de tema comercial — notas fiscais, contratos e pedidos de revisão urgente — contendo links embutidos.
O ponto de partida lembra a campanha que roubava e-mails corporativos via EWS da Microsoft: a mensagem sai de um endereço real e conhecido, o que aumenta a credibilidade e contorna filtros de remetente. A infraestrutura de apoio também se apoia em serviços legítimos — páginas do Google Sites como invólucro inicial, Cloudflare Workers na etapa final e uma lista extensa de domínios.eu e.com recém-registrados como intermediários.
Como a cadeia funciona
No rastreio da SpiderLabs, o PDF leva a vítima a uma página do Google Sites quase vazia, que funciona como invólucro confiável e carrega, pela funcionalidade legítima de conteúdo incorporado, um recurso hospedado em domínio controlado pelos atacantes. Esse recurso é um script de pré-carregamento de 56 KB que inicializa os parâmetros da campanha, valida requisitos de roteamento, seleciona o tema visual, gera tokens específicos da vítima e redireciona para os estágios seguintes por subdomínios dedicados.
O kit carrega 19 temas de phishing pré-definidos, que cobrem compartilhamento de arquivos, bancos, gestão de documentos, pagamentos, recursos humanos, nuvem e assinatura eletrônica. A variabilidade permite trocar a marca da isca sem trocar o motor: quando um domínio cai, o operador registra outro e mantém a lógica de roteamento intacta.
| Etapa | O que acontece | Sinal para a defesa |
|---|---|---|
| Isca em PDF | Anexo comercial com marca de serviço conhecido e link embutido | PDF externo com hiperlinks para domínios desconhecidos |
| Invólucro confiável | Página do Google Sites carrega conteúdo externo | Acesso a sites.google.com seguido de requisição a domínio.eu |
| Pré-carregamento | Script gera token da vítima e escolhe o tema | Redirecionamentos rápidos por subdomínios longos |
| Validação e filtro | Telemetria do navegador é checada; tráfego indesejado recebe decoy | Scanner recebe conteúdo benigno e o veredito fica inconclusivo |
| Página final | Tema Adobe com fluxo de código de dispositivo | Concessão de código de dispositivo pouco depois do clique |
A página final imita serviços como Adobe, DocuSign e Microsoft OneDrive e abusa do fluxo de autorização de dispositivo da Microsoft: em vez de capturar uma senha em formulário falso, o operador inicia a autenticação na página verdadeira da Microsoft e conduz a vítima a digitar o código exibido. Como o login ocorre no domínio autêntico, as dicas visuais tradicionais falham e a senha nunca passa pela infraestrutura do golpe. O painel do kit mantém uma sessão no backend, exibe o código e monitora continuamente a tentativa de autenticação até a conclusão ou a expiração.
Por que o veredito limpo engana
O filtro de tráfego muda o trabalho do analista. Um scanner que acessa a URL suspeita recebe uma página benigna ou um redirecionamento inócuo — e um veredito limpo deixa de provar qualquer coisa, porque só indica que a infraestrutura decidiu não mostrar a isca para aquele visitante. Em vez de analisar a primeira URL, o time precisa reproduzir o percurso inteiro com navegador realista, seguir cada redirecionamento e só então classificar o comportamento.
Um único link rende vários pivôs de investigação: subdomínios.eu com nomes genéricos, hosts em workers.dev cujos nomes imitam serviços Microsoft e, no lado da identidade, concessões de código de dispositivo que aparecem nos logs horas depois da abertura do anexo. Bloquear um domínio encerra uma campanha, não o kit; a lógica de roteamento sobrevive à troca de infraestrutura.
Impacto para os setores visados
O foco em bancos, manufatura e governo segue a lógica do maior valor por comprometimento: processos financeiros de alto montante, ambientes corporativos interconectados e informações sensíveis. O raciocínio é o mesmo do trojan que trocava apps de banco por versões adulteradas: a marca financeira é a isca, mas o alvo é a conta corporativa e as sessões que ela abre. Uma concessão de código de dispositivo bem-sucedida entrega tokens de acesso válidos, e a troca de senha posterior não os revoga — a resposta precisa incluir a revogação de sessões e tokens, não apenas o reset da credencial.
Ações de contenção priorizadas
P1 — desativar o fluxo de código de dispositivo no Microsoft Entra ID onde não houver exigência operacional; quando o fluxo for necessário, restringir o grant com políticas de acesso condicional a usuários aprovados, dispositivos gerenciados ou redes confiáveis.
P1 — monitorar autenticações por código de dispositivo que ocorram pouco depois de eventos de e-mail com anexos externos; investigar tokens de acesso e de atualização emitidos sem login interativo correspondente e revogar as sessões de vítimas confirmadas.
P2 — aplicar controles mais rígidos a PDFs de remetentes externos com links incorporados, monitorar domínios.eu recém-observados com subdomínios longos e correlacionar a telemetria de e-mail, navegação e identidade para reconstruir a cadeia completa em vez de tratar cada alerta como evento isolado.
P2 — testar a detecção de rede: a cobertura pública da ANY.RUN inclui regra Suricata de atividade HTTP associada ao kit, identificada como SID 84004715, e o treinamento de usuários deve tratar qualquer solicitação inesperada de código de dispositivo como incidente a reportar.
Sinais de comprometimento a procurar
- Relato do usuário sobre solicitação inesperada de código de dispositivo em página de documento.
- Nos logs do Entra ID, concessões pelo fluxo de dispositivo logo após a abertura de anexo externo.
- Registros de dispositivos e tokens de acesso novos sem login interativo correspondente.
- Alterações de caixa de entrada após o incidente, sinal de reuso da conta na onda seguinte.