Detecção de AiTM no SOC: Tycoon 2FA e Roubo de Token

O Tycoon 2FA é hoje o kit de Phishing-as-a-Service líder em ataques adversary-in-the-middle (AiTM), capazes de roubar o token de sessão de um usuário depois de ele concluir o MFA corretamente. Em seu pico, respondeu por cerca de 62% do phishing bloqueado pela Microsoft e atingiu mais de 500 mil organizações por mês. Mesmo após o takedown coordenado de março de 2026, os operadores se adaptaram em semanas. Para o SOC, a lição é dura: confiar apenas nos sinais de risco nativos do provedor de identidade deixa buracos — a detecção real depende de pivoteamento cruzado por ASN e de entender a persistência por device-PRT.

Item	Detalhe
Ameaça	Tycoon 2FA, kit PhaaS atribuído ao grupo Storm-1747
Vetor	Adversary-in-the-middle rouba o token de sessão após MFA válido
Impacto	Em pico, 62% do phishing bloqueado pela Microsoft; 500 mil+ organizações/mês
Lacuna comum	Revogar sessões e resetar senha não basta — há persistência via device-PRT
Sinal-chave	Dois ASNs distintos (cloud-VPS + residencial) autenticando o mesmo usuário em minutos
Defesa base	MFA resistente a phishing (FIDO2/passkeys) + Conditional Access por dispositivo

Como o AiTM derrota o MFA

Num ataque adversary-in-the-middle, o kit funciona como um proxy reverso entre a vítima e o provedor de identidade legítimo (Microsoft Entra ID ou Google Workspace). Não é um coletor estático de credenciais: ele encaminha o fluxo de login em tempo real. A vítima vê uma réplica perfeita da página da Microsoft ou do Google — frequentemente com a marca da organização-alvo, buscada dinamicamente do serviço real. A senha é validada, o desafio de MFA é disparado e repassado, a vítima aprova normalmente e o provedor emite o token de sessão. O proxy intercepta esse token antes que ele chegue ao navegador da vítima. A partir dali, o MFA perdeu o sentido: o atacante tem um token de acesso totalmente autenticado.

O ativo que o operador monetiza é o cookie de sessão. Conforme o Token Theft Playbook oficial da Microsoft, um roubo de token ocorre quando ameaças comprometem e repetem tokens emitidos a um usuário, mesmo que ele já tenha satisfeito a autenticação multifator. Como os requisitos de autenticação foram cumpridos, o atacante recebe acesso aos recursos da organização usando o token roubado.

O kit Tycoon 2FA em 2026

Atribuído ao Storm-1747 pela Microsoft Threat Intelligence e observado pela primeira vez em agosto de 2023, o Tycoon 2FA provê capacidade AiTM pronta para uso contra Microsoft 365 e Google Workspace. Em seu pico, respondeu por aproximadamente 62% das tentativas de phishing bloqueadas pela Microsoft, alcançando mais de 500 mil organizações por mês, segundo a análise publicada pelo Elastic Security Labs em maio de 2026.

Um takedown coordenado em março de 2026 — liderado pela Microsoft e pela Europol, com apoio da Cloudflare, SpyCloud e eSentire — apreendeu mais de 300 domínios. Mas os operadores se adaptaram em semanas. Já no final de abril de 2026 a eSentire documentou campanhas combinando o tradecraft do Tycoon com fluxos de phishing por OAuth Device Code. O kit continua no topo do rastreador de tendências da ANY.RUN. Há duas variantes estruturais em rotação: a AiTM clássica por WebSocket e o abuso do device-code grant.

Arquitetura em duas camadas do kit

O detalhe que mais confunde analistas de SOC: o kit divide sua operação em duas camadas com ASN, papel e assinatura comportamental distintos. Quem procura um padrão único captura uma camada e perde a outra.

Camada 1 — Relay do kit. O backend automatizado que adquire e renova tokens. Sai por IPs de provedores de cloud-VPS baratos (Alibaba Cloud e ASNs similares), rotando entre vários IPs em blocos /16 diferentes durante um único ataque. O user agent é de cliente HTTP Node.js: node, axios/1.15.2, node-fetch/1.0, undici. O app cliente é o Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e). Os sign-ins seguintes são não-interativos — atualizações de token servidor-a-servidor.

Camada 2 — Console do operador. O humano (ou ferramenta que o simula) que faz o reconhecimento pós-comprometimento. Sai por IP com formato residencial ou proxy de ASN pequeno, normalmente ausente das feeds de ameaça de hosting. Um único user agent de navegador (por exemplo, Firefox no Windows) fixo em todos os IPs do cluster — ferramenta configurada, não usuários independentes. Sign-ins interativos em apps web do Microsoft 365: My Profile, Outlook Web, OfficeHome. Costuma aparecer 10 a 20 minutos depois do primeiro token emitido pelo relay — a janela de handoff kit-para-operador.

O sinal durável e cruzado: dois ASNs distintos (um cloud-VPS, um residencial) autenticando o mesmo usuário em minutos. Regras de ASN único pegam uma camada; o pivoteamento entre camadas é o indicador de alta confiança.

Sinais de detecção para o SOC

Quatro famílias de sinais cobrem a cadeia inteira de ataque. Cada uma é actionable no SIEM:

User agent de automação em sign-in do Auth Broker: sign-ins no OfficeHome ou Graph vindos de UAs como node, axios ou undici. Quase nunca são legítimos para um login interativo humano.
Pivoteamento cross-ASN: o mesmo UPN autenticando a partir de um ASN de hosting e, minutos depois, de um ASN residencial. Geolocalização é não-confiável para IPs de cloud — ASN é o enriquecimento que funciona.
Rajada de enumeração no Graph API: 20 a 30+ chamadas em 30 a 60 segundos, batendo endpoints de alto valor — transitiveRoleAssignments, memberOf/directoryRole, tenantRelationships/getResourceTenants, me/contactFolders/contacts com $top=1000, uso de /beta/, C_DeviceId vazio. Usuário normal toca uma ou duas categorias; quatro ou mais categorias distintas numa janela curta é a impressão digital de ferramenta ofensiva.
Gatilhos do Entra ID Protection: token anômalo (detecção offline), propriedades de sign-in não-familiares e, principalmente, sign-in não-interativo não-familiar. A própria Microsoft recomenda escrutínio imediato em sign-ins não-interativos.

O Elastic mapeou a cadeia ao MITRE ATT&CK: T1566.002 (spearphishing via link), T1539 (roubo de cookie de sessão), T1098.005 (manipulação de conta via registro de dispositivo), T1550.001 (uso de token de aplicação como material alternativo de autenticação) e T1087.004 (descoberta de conta em nuvem). Esses IDs devem virar nomes de regras e filtros na sua plataforma de caça a ameaças.

Por que revogar sessões falha

É aqui que o runbook padrão de resposta a phishing quebra. O kit consegue estabelecer persistência via registro de dispositivo que sobrevive à sequência clássica de revogação de sessão. O mecanismo: o refresh token do Microsoft Authentication Broker é trocado por um token cujo audience é o Device Registration Service; o kit posta um CSR PKCS#10 com metadados sintéticos de dispositivo e recebe um certificado de dispositivo; então constrói um JWT assinado com a chave privada do dispositivo e obtém um Primary Refresh Token (PRT).

O detalhe operacional decisivo: quando o SOC dispara revokeSignInSessions — que invalida todos os tokens e refresh tokens em nível de usuário — o device-PRT continua válido, porque o dispositivo é um principal separado no Entra ID. O atacante, a partir dos novos IPs do relay, usa o PRT e a chave de sessão para assinar asserções HMAC-SHA256 e brokerar tokens de acesso para qualquer client_id de primeira parte (Teams, Outlook, OneDrive, Intune).

Conclusão direta do Elastic Security Labs: a sequência padrão de “revogar sessões e depois resetar a senha” é insuficiente. O SOC precisa enumerar e deletar os dispositivos registrados antes de revogar as sessões, para quebrar a cadeia device-PRT de forma atômica.

Ordem correta de resposta a incidente

A ordem dos passos importa tanto quanto os passos em si. Faça fora de ordem e o atacante mantém acesso. A sequência correta, derivada do playbook da Microsoft e da automação documentada pelo Elastic:

Desabilitar a conta (accountEnabled: false) para parar novas autenticações.
Enumerar dispositivos registrados e de propriedade do usuário comprometido (registeredDevices, ownedDevices).
Deletar cada principal de dispositivo — é isso que invalida de fato um device-PRT.
Disparar revokeSignInSessions para invalidar refresh tokens e cookies de sessão em nível de usuário.
Resetar a senha (conta híbrida exige duplo reset, conforme a Microsoft).
Auditar regras de inbox, métodos de autenticação adicionados e concessões OAuth — o atacante costuma criar regras de encaminhamento de e-mail e registrar novos métodos de MFA.

Contenção em segundos, não em horas

A janela de handoff kit-para-operador do Tycoon 2FA é de 10 a 20 minutos — o tempo entre o primeiro token emitido pelo relay e o início do reconhecimento pela camada do operador. Uma resposta manual de SOC rotineiramente leva mais do que essa janela, e é por isso que o operador termina a fase de recon antes de a contenção chegar.

Fechar essa lacuna é o que torna a detecção acionável e derruba o MTTR da identidade em nuvem. O Elastic demonstrou um workflow que, a cada alerta, adquire um bearer do Graph via client_credentials, desabilita a conta, enumera e deleta os dispositivos, dispara revokeSignInSessions e abre um caso no Kibana — executando ponta-a-ponta em menos de 10 segundos, dentro da janela de handoff. A camada do operador nunca chega a iniciar o reconhecimento. O mesmo molde de workflow serve para qualquer detecção de identidade em nuvem: AiTM, impossible travel, concessão OAuth ilícita, escalonamento de papel, fadiga de MFA. Conecte a regra a um workflow que chame a API de nuvem relevante e o SOC obtém contenção em escala de segundos.

Defesas que fecham a porta

A detecção e a resposta unificadas reduzem dano; prevenção remove o vetor. As defesas de maior alavanca contra AiTM por roubo de token, segundo o Elastic e a Microsoft:

MFA resistente a phishing: chaves FIDO2 e passkeys são os únicos métodos imunes ao roubo de sessão AiTM. TOTP, SMS e push podem todos ser proxied.
Conditional Access por dispositivo em conformidade: exigir dispositivo gerenciado e compatível para emissão de token é o controle mais eficaz contra o roubo de token AiTM.
Bloquear o fluxo de device code: a política Conditional Access Block device code flow rejeita o relay do kit na fase de grant (erro 53003). Ative para todos os usuários, exceto cenários explícitos de quiosque/headless.
Token protection (token binding): vincula o token ao dispositivo em que foi emitido. Um token roubado e repetido de outro dispositivo é rejeitado.
Continuous Access Evaluation (CAE): revogação de token quase em tempo real quando as condições de risco mudam.