A Cisco Talos publicou, em outubro de 2026, a análise de uma campanha de spear phishing contra pesquisadores vinculados a organizações de Taiwan que une iscas de evento acadêmico produzidas com apoio de IA e um kit de phishing adversário-no-meio (AitM) que intercepta senhas e desafios de MFA de contas Google enquanto o usuário digita. O ator, rastreado como UAT-11985, não precisa quebrar o segundo fator: ele deixa a vítima concluir a autenticação e recolhe o token de sessão já emitido. A ação prioritária é tratar a sessão, e não só a senha, como o ativo a defender — aplicar as detecções publicadas, bloquear os indicadores conhecidos e caçar logins legítimos seguidos de comportamento anômalo.

Como o golpe chega ao alvo

Os e-mails analisados pela Talos se passavam por instituições reais de Taiwan, como Taiwan European Union Centre, NCCU Institute of International Relations e Taiwan Research Institute. Nenhuma das organizações contactadas confirmou que os remetentes eram funcionários ou representantes. O ator usava nomes legítimos e informações públicas de eventos como cortina de credibilidade: o tema, a data e o local batiam com anúncios verdadeiros, mas o link de inscrição exibia o texto de um Google Forms e o endereço real levava a um site de phishing hospedado em plataforma de terceiros.

A estrutura das mensagens chamou atenção dos analistas. As iscas seguiam o mesmo esqueleto em três partes — contexto geopolítico rebuscado, elogio personalizado ao destinatário e logística do evento —, com frases de admiração intercambiáveis e pouco detalhe verificável sobre o trabalho da vítima. Para a Talos, o padrão indica conteúdo gerado a partir de um modelo de prompt reutilizável, com personalização assistida por IA em escala, embora o relatório ressalve que os indícios linguísticos não provam sozinhos o uso de modelo generativo. Para o leitor, a regra prática permanece: confirmar o convite por canal independente, como o site oficial da instituição, antes de clicar, porque a precisão do evento não valida o remetente.

O kit AitM operado por humanos

O diferencial da campanha está no kit. Em vez de formulário estático que só grava a senha, a página falsa replica o login do Google e funciona como relé controlado por uma pessoa: a infraestrutura do atacante fica entre o navegador da vítima e os servidores reais do Google e conduz cada etapa da autenticação. A página também esconde uma seção HTML que simula uma autenticação bem-sucedida, com um iframe restrito que carrega um arquivo local de confirmação — detalhe que mantém a encenação coerente até o fim.

A arquitetura usa dois canais. O HTTP POST envia, em eventos independentes, o fingerprint inicial do navegador, as credenciais digitadas e batimentos periódicos de sincronização. O WebSocket mantém uma conexão persistente de baixa latência pela qual o servidor do atacante dita qual tela renderizar em seguida. Na prática, o servidor sincroniza o estado de autenticação em tempo real: consulta o serviço real para saber se a conta existe, inclusive se há fluxo de passkey habilitado, e adapta a interface para pedir senha ou biometria conforme a resposta.

O JavaScript da página chega ofuscado com um grande array de strings em Base64 e um laço de rotação resolvido em execução, dificultando a análise estática automatizada. A Talos avalia, com confiança moderada, que a interface foi originalmente escrita em chinês simplificado e depois derivada para chinês tradicional e inglês — indício de um desenvolvedor cujo idioma de trabalho é o chinês simplificado, em um ecossistema que lembra a rede chinesa de phishing desmantelada na operação YAM Store.

Por que o MFA não segura

O kit não derriba o segundo fator: ele o atravessa. A vítima digita a senha na página falsa, o operador repassa ao Google, recebe o tipo de desafio exigido e avança a interface para a etapa correspondente. Quando o MFA é concluído, quem fica com o token é o atacante. A técnica é antiga o suficiente para ter catalogação: o MITRE ATT&CK cataloga o ataque como a técnica T1557, de adversário-no-meio, cuja página registra que essa posição serve para interceptar credenciais, incluindo tokens de acesso e cookies de sessão — exatamente os ativos visados aqui. Ferramentas como o evilginx2 aparecem na mesma entrada como exemplo histórico de relé que captura senhas, tokens e cookies.

A consequência operacional é direta: uma defesa que avalia risco apenas no instante do login ignora o resto da sessão. Em contas corporativas sincronizadas com o Google Workspace, o mesmo token abre e-mail, Drive e agenda, e o alcance do dano depende do que a conta enxerga. Sessões longas, tokens sem vínculo com dispositivo e ausência de revogação transformam um clique em dias de acesso. Quem suspeita de comprometimento pode seguir um roteiro de verificação sem entregar mais dados, como o guia de checagem de vazamentos do portal.

Sinais e detecção na prática

A Talos publicou cobertura pronta para uso: a assinatura ClamAV Html.Phishing.UAT11985-10060614-0 e as regras 1:67198 para Snort2 e 7:31 para Snort3 detectam e bloqueiam o kit. O relatório também lista a infraestrutura usada, com domínios como google.morelessty[.]com e accounts.natrlyi[.]com, que imitam o prefixo do serviço legítimo em domínios de terceiros.

Superfície O que verificar
Gateway de e-mail Divergência entre o texto exibido do link e o endereço real; anexos de pôster com QR code
DNS e proxy Consultas a subdomínios google.* em domínios recém-registrados por terceiros
Tráfego de saída Conexões WebSocket persistentes de estações para domínios novos e sem reputação
Logs de login Autenticação com MFA concluído seguida de ASN, país ou agente incomum na mesma sessão
Endpoint Alertas das regras publicadas pela Talos em inspeção de tráfego e de conteúdo

Essa lista é um procedimento de triagem sugerido pela redação a partir do comportamento descrito no relatório; os identificadores técnicos vêm da fonte.

Quishing amplia o alcance

Alguns e-mails traziam pôsteres de eventos reais com o QR code trocado. A aposta do ator é física: alguém imprime o pôster e cola no mural da instituição, e colegas que nada receberam por e-mail digitalizam o código para se inscrever. O Australian Cyber Security Centre explica por que essa variante escapa de controles comuns: os códigos QR escondem o destino em uma imagem, impedindo a checagem antes da digitalização, e ferramentas de segurança de e-mail têm capacidade limitada para detectar links embutidos em imagens. A entidade recomenda, entre outras medidas, restringir a política organizacional de e-mail para impedir a interação com QR codes em mensagens.

Ações priorizadas de defesa

Prioridade Ação
P1 Aplicar a assinatura ClamAV e as regras Snort publicadas e bloquear os domínios de indicadores no DNS e no proxy
P1 Revogar sessões e redefinir credenciais de usuários que interagiram com as iscas; investigar acessos posteriores
P1 Caçar nos logs autenticações com MFA válido seguidas de uso do token em contexto anômalo
P2 Reduzir o tempo de vida de sessões sensíveis e vincular tokens a dispositivos gerenciados
P2 Incluir a divergência entre link exibido e destino, e QR codes em pôsteres, na conscientização interna
P2 Monitorar conexões WebSocket de estações para domínios recém-registrados

O kit só entrega a conta ao atacante se a sessão sobreviver ao phishing. Encurtar a vida útil do token, exigir dispositivo confiável e revogar sessões em massa diante de um clique confirmado são os controles que mudam o resultado do incidente.

Fontes