A suíte de phishing opera páginas legítimas em tempo real por infraestrutura controlada pelo atacante, capturando credenciais, entradas de formulário e tokens de sessão para tomada de contas.
| Componente | Suíte de phishing Starkiller, executada com Chrome headless em contêiner Docker e painel para impersonação de marcas. |
| Vetor | Proxy reverso AitM que entrega conteúdo real da página de login ao usuário e encaminha entradas, respostas e tokens por infraestrutura do operador. |
| Impacto | Captura de credenciais, códigos e tokens de sessão, com risco de tomada de contas mesmo quando a autenticação multifator está habilitada. |
| Prioridade | Revisar telemetria de autenticação, sessões, encurtadores de URL, fluxos OAuth por código de dispositivo e domínios de phishing com redirecionamentos evasivos. |
| Artefatos | Uso de palavras-chave como login, verify, security e account, integração com encurtadores como TinyURL e páginas reais carregadas dinamicamente. |
| IoCs | Domínios financeiros falsos em formato [.]co[.]com, CAPTCHA Cloudflare fraudulento, redirecionamento por script codificado em Base64 e destino malformado www[.]www. |
A suíte Starkiller representa uma evolução operacional de phishing voltada a reduzir a dependência de páginas falsas estáticas. Em vez de manter modelos HTML que envelhecem conforme o site legítimo muda, a plataforma carrega o próprio site real dentro de uma instância de Chrome headless em um contêiner Docker e atua como intermediária entre a vítima e o serviço legítimo. Esse desenho cria uma página visualmente atualizada, dificulta bloqueios baseados em templates e permite que a infraestrutura do operador observe o fluxo de autenticação em tempo real.
O ponto central da técnica é o uso de proxy reverso Adversary-in-the-Middle. O usuário interage com uma página servida pela infraestrutura do atacante, mas o conteúdo exibido vem do serviço legítimo. As entradas digitadas, submissões de formulário, respostas do servidor e tokens de sessão passam pelo ambiente controlado pelo operador antes de chegar ao destino real ou retornar ao navegador da vítima. Com isso, a autenticação multifator deixa de ser uma barreira suficiente quando o token autenticado ou o estado de sessão é capturado durante o processo.
A plataforma também centraliza tarefas normalmente distribuídas em campanhas de phishing: escolha de marca a impersonar, uso de URL real da marca, seleção de palavras-chave personalizadas e mascaramento por encurtadores de URL. Essa combinação transforma a cadeia em um fluxo de serviço, com painel de operação, implantação de página, observação de sessão e captura de material de autenticação em um mesmo lugar. O efeito defensivo mais importante é que a análise não deve se limitar a páginas falsas visualmente inconsistentes; a página pode ser legítima no conteúdo e maliciosa no caminho de rede.
O fluxo começa com a seleção de uma marca ou com a inserção de uma URL legítima no painel da suíte. O operador pode associar termos como login, verify, security ou account para compor iscas e rotas plausíveis, além de usar encurtadores como TinyURL para esconder o destino final. Quando o destinatário acessa o link, a infraestrutura do operador inicia ou utiliza uma sessão de navegador sem interface gráfica dentro de um contêiner. Esse navegador busca o conteúdo real do site impersonado e o entrega ao usuário por meio do domínio controlado pelo atacante.
Durante a interação, o proxy encaminha as ações da vítima ao site legítimo e devolve as respostas de volta ao navegador. O risco não depende apenas do roubo de senha em um formulário isolado. Cada tecla, submissão e token de sessão trafega pelo intermediário. Se o usuário concluir autenticação multifator em uma página real proxificada, o operador pode capturar o material de sessão emitido após a autenticação e usá-lo para assumir a conta. Isso torna menos eficaz a defesa baseada somente em códigos temporários ou aprovações de MFA quando o canal de autenticação foi intermediado desde o início.
O mesmo cenário se conecta a outras evoluções observadas em kits de phishing. O kit 1Phish, inicialmente descrito como coletor básico de credenciais em setembro de 2025, passou a incorporar etapas de validação antes do phishing, captura de OTPs e códigos de recuperação, além de lógica de fingerprinting de navegador para filtrar bots e análise automatizada. A mudança indica que esses kits não estão apenas reutilizando modelos; eles adicionam controles para aumentar taxa de conversão, reduzir exposição a sandboxes e capturar material de autenticação secundária.
Outro vetor citado no mesmo conjunto técnico envolve abuso do fluxo OAuth 2.0 device authorization grant contra contas Microsoft 365. Nesse caso, o atacante registra uma aplicação OAuth, gera um código de dispositivo e o entrega por phishing direcionado. A vítima é levada ao portal legítimo microsoft[.]com/devicelogin para inserir o código fornecido pelo operador. O resultado é a emissão de um token de acesso válido para a aplicação do atacante, o que pode manter acesso à conta e a dados corporativos sem depender de uma página falsa tradicional.
A superfície de risco principal envolve serviços com autenticação web que emitem cookies ou tokens de sessão após credenciais e MFA. Ambientes de e-mail corporativo, identidade, SaaS, painéis administrativos e portais financeiros são especialmente sensíveis porque o valor para o operador está no estado autenticado e não apenas na senha. A técnica também afeta organizações que dependem de reconhecimento visual de página ou de treinamento genérico contra páginas malformadas, pois o conteúdo proxificado pode refletir fielmente a página legítima no momento do ataque.
Instituições financeiras também aparecem como alvo de campanhas com domínios [.]co[.]com que imitam bancos e cooperativas de crédito dos Estados Unidos. A cadeia descrita começa em links de e-mail, apresenta uma página fraudulenta que imita um CAPTCHA da Cloudflare e introduz uma espera deliberada antes de redirecionar o usuário, por script codificado em Base64, para a etapa de coleta de credenciais. Quando acessados diretamente, esses domínios podem redirecionar para uma URL malformada www[.]www, comportamento útil para frustrar verificações automáticas simples.
- Contas protegidas por MFA que ainda aceitam sessão web capturada por intermediário AitM.
- Usuários direcionados por links encurtados, links em e-mail e domínios com aparência próxima à marca impersonada.
- Ambientes Microsoft 365 expostos ao abuso de OAuth por código de dispositivo quando usuários inserem códigos fornecidos por terceiros.
- Clientes de instituições financeiras atingidos por domínios
[.]co[.]com, CAPTCHA falso e redirecionamentos condicionais.
A investigação deve combinar sinais de identidade, endpoint, navegador e rede. Em identidade, a prioridade é revisar autenticações concluídas com MFA que resultem em sessões anômalas, novos tokens, mudanças de localização, agentes de usuário incomuns ou acesso posterior sem o mesmo padrão de dispositivo. Em Microsoft 365, eventos relacionados a consentimento, emissão de tokens, uso de fluxos por código de dispositivo e aplicações OAuth recém-associadas merecem correlação com relatos de phishing e com mensagens que instruem o usuário a inserir códigos em portais legítimos.
Em rede e segurança de e-mail, sinais relevantes incluem uso de encurtadores em mensagens de autenticação, URLs intermediárias que carregam conteúdo de marcas conhecidas, domínios que redirecionam diferentemente conforme origem da requisição e páginas que exibem CAPTCHA falso antes de encaminhar para coleta de credenciais. Como páginas proxificadas podem não conter templates estáticos reutilizáveis, a detecção por hash de HTML ou blocos visuais fixos tende a ser menos confiável. A defesa deve valorizar comportamento de sessão, encadeamento de redirecionamentos, reputação de domínio e inconsistências entre domínio acessado e serviço autenticado.
No endpoint, a telemetria pode ajudar quando o usuário acessa links a partir de e-mail corporativo ou navegador gerenciado. O objetivo não é procurar apenas payload malicioso, mas reconstruir a cadeia: mensagem recebida, URL encurtada, domínio intermediário, página proxificada, momento de MFA e emissão de sessão. Em casos de suspeita de AitM, preservar registros de autenticação e de proxy seguro é essencial para diferenciar senha digitada em página falsa de token já autenticado capturado em trânsito.
- Autenticação com MFA seguida por sessão nova em localização, ASN, navegador ou dispositivo incompatível com o usuário.
- Acesso a encurtadores de URL antes de páginas de login, especialmente quando o domínio final não corresponde à marca exibida.
- Eventos OAuth com código de dispositivo, aplicação desconhecida e emissão de token após interação iniciada por e-mail.
- Domínios defangados no padrão
[.]co[.]com, CAPTCHA falso, script codificado em Base64 e redirecionamento parawww[.]wwwmalformado.
A resposta deve partir da premissa de que credenciais e MFA podem ter sido concluídos com sucesso, mas a sessão resultante foi comprometida. Em suspeita de uso de Starkiller ou proxy AitM semelhante, a ação defensiva prioritária é invalidar sessões, revogar tokens, revisar aplicações OAuth autorizadas, forçar nova autenticação em dispositivos confiáveis e investigar acessos posteriores. Troca de senha isolada pode ser insuficiente se tokens persistentes ou consentimentos maliciosos continuarem válidos.
Controles preventivos devem reduzir a utilidade de páginas proxificadas e fluxos delegados. Autenticação resistente a phishing, políticas condicionais baseadas em dispositivo gerenciado, revisão de fluxos OAuth por código de dispositivo e inspeção de consentimentos de aplicações ajudam a limitar o impacto. Para e-mail, é importante tratar encurtadores, domínios recém-criados e cadeias com redirecionamentos condicionais como sinais de risco, principalmente quando a mensagem direciona o usuário a páginas de login ou a portais legítimos com códigos fornecidos pelo remetente.
A validação pós-incidente precisa confirmar se houve apenas tentativa de coleta ou se ocorreu emissão de sessão. Para isso, as equipes devem correlacionar horário do clique, autenticação, MFA, token, IP de origem, aplicação acessada e ações executadas depois da autenticação. Em campanhas financeiras com CAPTCHA falso, a contenção deve incluir bloqueio de domínios, remoção de mensagens, orientação aos usuários afetados, revisão de tentativas de login e monitoramento de novas variações de domínio que reutilizem a mesma cadeia de redirecionamento.
- Revogar sessões e tokens associados a autenticações suspeitas, não apenas redefinir senha.
- Auditar aplicações OAuth, consentimentos recentes e uso do fluxo por código de dispositivo em contas corporativas.
- Bloquear ou elevar a inspeção de links encurtados e domínios intermediários usados em mensagens de login.
- Correlacionar clique, MFA, emissão de token e atividade posterior para identificar tomada de conta.
- Registrar domínios fraudulentos de forma defangada e compartilhar apenas exemplos necessários para defesa.
0 Comentários