Detecção de ataques Tycoon 2FA AiTM no Entra ID e no Google Workspace

Atualmente, o Tycoon 2FA é a plataforma de Phishing-as-a-Service (PhaaS) mais prolífica entre os kits de phishing da AiTM. Observado pela primeira vez em agosto 2023 e atribuído ao Storm-1747 (de acordo com a Microsoft Threat Intelligence), o kit fornece recursos de adversário no meio (AiTM) prontos para uso que contornam a autenticação multifator e roubam tokens de sessão autenticados de contas da Microsoft 365 e do Google Workspace. Em seu auge, o Tycoon 2FA foi responsável por aproximadamente 62% das tentativas de phishing bloqueadas pela Microsoft, atingindo mais de 500.000 organizações mensalmente.

Apesar de uma operação coordenada em março 2026 liderada pela Microsoft e pela Europol, com o apoio da Cloudflare, SpyCloud, eSentire e outros parceiros que apreenderam mais de 300 domínios, os operadores adaptaram-se em poucas semanas. No final de abril de 2026, a eSentire documentou campanhas que combinavam técnicas do Tycoon com fluxos de phishing de código de dispositivo OAuth, e o kit permanece como a entrada número 1 no rastreador de tendências de malware da ANY.RUN.

Como funciona a autenticação de dois fatores (2FA) em Tycoon

O mecanismo AiTM

O Tycoon 2FA funciona como um intermediário reverso entre a vítima e o provedor de identidade legítimo (Entra ID ou Google). Não se trata de um coletor de credenciais estáticas. Ele simula o fluxo de login real em tempo real:

1. A vítima recebe um e-mail de phishing contendo um link ou código QR incorporado em um anexo PDF, SVG, HTML ou PPTX.
2. O link é roteado através de uma cadeia de redirecionamento de múltiplas camadas. O kit realiza a identificação do navegador, desafios CAPTCHA e verificações anti-análise antes de apresentar a página de login.
3. A vítima vê uma réplica idêntica, em pixels, da página de login da Microsoft ou do Google, frequentemente incluindo a identidade visual da organização-alvo, obtida dinamicamente do serviço real.
4. As credenciais são transmitidas em tempo real ao provedor de identidade legítimo. O verdadeiro desafio da MFA (autenticação multifator) é quando ela é acionada e encaminhada de volta para a vítima.
5. A vítima completa a autenticação multifator (MFA) normalmente. O provedor de identidade emite um token de sessão. O proxy intercepta esse token antes que ele chegue ao navegador da vítima.
6. O atacante agora possui um token de acesso totalmente autenticado.

O cookie de sessão é o valor que o operador monetiza. Uma vez capturado, o MFA torna-se irrelevante porque o operador reproduz os tokens criados após o MFA.

Duas variantes estruturais na rotação atual

Analisamos duas variantes distintas do kit que estavam em uso ativo:

WebSocket AiTM (o fluxo "clássico" de autenticação de dois fatores do Tycoon): A vítima se autentica por meio de um proxy hospedado no kit que encaminha o tráfego para a Microsoft ou o Google via WebSocket (Socket.IO) e captura o cookie de sessão pós-MFA. O controlador JavaScript do cliente do kit mantém um canal bidirecional em tempo real com o servidor C2, retransmitindo credenciais e respostas de autenticação à medida que a vítima digita. Essas respostas incluem tokens de acesso e atualização gerados para uso.

Abuso de concessão de código de dispositivo (somente Microsoft): O retransmissor do kit obtém um código de dispositivo do endpoint oauth2/devicecode da Microsoft com o Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) como cliente, exibe-o para a vítima por meio de uma isca de "código de verificação" e troca o código por tokens de acesso/atualização depois que a vítima faz login no legítimo microsoft.com/devicelogin. ponto final.

Técnicas de evasão

O kit emprega mecanismos anti-análise em camadas, confirmados por meio da descompilação de JavaScript:

• Filtragem de pesquisadores baseada em IP: Antes de qualquer conteúdo ser exibido, o kit chama api.ipapi.is (ou serviço equivalente) para verificar o IP do visitante em relação a uma lista de bloqueio de provedores de nuvem/hospedagem (Leaseweb, M247, DigitalOcean, Linode, Amazon, OVH, Hetzner, Google, Microsoft, Cloudflare, Akamai, Fastly, armazenados como strings invertidas para evitar varreduras estáticas). Visitantes em infraestrutura de nuvem são redirecionados para um site falso e inofensivo.
• Detecção de bots/ferramentas: Verifica a presença de navigator.webdriver (Selenium), window.callPhantom / window._phantom (PhantomJS) e "Burp" na string do agente do usuário. A detecção aciona um redirecionamento para about:blank.
• Bloqueio das Ferramentas de Desenvolvedor: Intercepta os atalhos de teclado para as ferramentas de desenvolvedor (F12, Ctrl+Shift+I/J/C, Ctrl+U, equivalentes no macOS) e desativa os menus de contexto do botão direito do mouse.
• Armadilha de depuração: Um loop setInterval executado a cada 100ms insere uma instrução de depuração e mede o tempo de execução. Se as DevTools estiverem abertas (pausas de execução superiores a 100 ms), a vítima será redirecionada para um site falso.
• Desaparecimento do DOM: O JavaScript malicioso se remove do DOM após a execução, não deixando nenhum rastro para inspeção estática.
• Criptografia por vítima: A carga útil utiliza uma cifra personalizada de dois estágios (deslocamento de César + XOR com um fluxo de chaves gerado por um gerador de números pseudoaleatórios) inicializada com valores por sessão. A semente, a chave e o blob criptografado são gerados no servidor para cada vítima, tornando impossível a detecção de assinaturas estáticas.
• Plataforma alvo: Em desktops Linux, o programa escreve uma string vazia para limpar a página, provavelmente presumindo que os usuários de Linux sejam mais propensos a serem pesquisadores de segurança.
• CAPTCHA falso: Na versão atual, um CAPTCHA personalizado em formato de grade de imagens substitui o Cloudflare Turnstile. Imagens provenientes do Unsplash, dispostas em uma grade 3x3, fornecem verificação humana antes do carregamento da página de phishing.

Em campanhas direcionadas ao Google, a isca inicial geralmente é veiculada em infraestrutura legítima do Google, como o Google Storage ou o Google Sites, embora domínios controlados por operadores ou comprometidos também sejam observados. Quando a hospedagem do próprio Google é usada, a origem storage.googleapis.com ou sites.google.com fornece cobertura de reputação integrada antes que a vítima chegue ao relay AiTM.

Em outros casos, o e-mail da vítima é preenchido automaticamente e o botão "Próximo" é clicado automaticamente: a vítima é direcionada diretamente para a página de senha, dando a impressão de que já está parcialmente autenticada (aumentando a confiança):

var emailcheck = "victim@email.corp";
// ...
function tryfindingele(email) {
   emailinputcheck.value = email;
   emailsectionelecheck.querySelector(".btn-blue-next-btn").click();
}
if (emailcheck !== "0") { tryfindingele(emailcheck); }

Microsoft 365 / ID de entrada

Uma arquitetura operacional de dois níveis

O modelo operacional atual da Tycoon 2FA se divide em dois níveis de infraestrutura distintos, cada um com seu próprio ASN, função e assinatura comportamental. Defensores que buscam um padrão único irão identificar um nível e perder o outro.

Nível 1 - Kit de Revezamento

O sistema automatizado que gerencia a aquisição e renovação de tokens. Características:

• Os endereços IP de saída do Cloud-VPS são provenientes de provedores de hospedagem (Alibaba Cloud, ASNs de VPS baratos semelhantes), alternando entre vários IPs em diferentes blocos /16 durante uma única conexão.
• Agentes de usuário do cliente HTTP Node.js: node (node.js puro, agente de usuário padrão do Node.js), axios/1.15.2, node-fetch/1.0, undice.
• Aplicativo cliente: Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e), posteriormente usado com o Device Registration Service (DRS) para gerar um primaryRefreshToken (PRT).
• Progressão do tipo de token: incomingTokenType: none (autenticação inicial da vítima) > refreshToken (loop de renovação do kit de retransmissão, repetido em IPs rotativos) > Registro de Dispositivo Rogue > primaryRefreshToken (reprodução do PRT, escopo mais amplo).
• Logins não interativos: Após a conclusão inicial do código interativo do dispositivo, as operações subsequentes com o token são atualizações de servidor para servidor.

Nível 2 - Console do Operador

O ser humano (ou ferramenta que simula um ser humano) que realiza o reconhecimento pós-comprometimento. Características:

• Saída de ISP ou proxy com formato residencial, geralmente um ASN pequeno não presente nos feeds de ameaças comuns de provedores de hospedagem. Vários endereços IP em uma única rede /24, todos atuando de forma coordenada.
• Um único agente de usuário do navegador (por exemplo, Firefox no Windows) é fixo em todos os IPs do cluster. Uma ferramenta configurada, não usuários independentes.
• Acessos interativos baseados em navegador para aplicativos da Web da Microsoft: Meu Perfil, Meus Acessos, Gerenciamento de Aprovações da Microsoft, Outlook Web e OfficeHome.
• Um único c_sid (ID da sessão do cliente nos Logs de Atividade do Graph) é compartilhado entre todos os IPs, confirmando uma única sessão distribuída pelo pool.
• Ritmo operacional: Normalmente aparece de 10 a 20 minutos após a primeira emissão bem-sucedida de tokens do sistema de retransmissão. A lacuna representa o período de transferência do kit para o operador.

Sinal de detecção consistente entre camadas: Dois ASNs distintos (um em nuvem-VPS e outro com formato residencial) autenticando-se como o mesmo usuário principal em questão de minutos. As regras de ASN único abrangem um nível; o indicador de alta confiança é o pivô entre níveis.

Enumeração da API Graph pós-comprometimento

Assim que o console do operador obtém um token válido, ocorre uma rápida sequência de chamadas à API do Microsoft Graph, normalmente dezenas de solicitações em 30 a 60 segundos, atingindo endpoints de reconhecimento de alto valor:

Principais indicadores de telemetria para reconhecimento automatizado pós-comprometimento:

• Volume e velocidade: 20 a 30+ chamadas em um intervalo de 30 a 60 segundos, cada uma atingindo um ponto final diferente.
• Métodos HTTP mistos: GET para a maioria dos endpoints, POST para ações como getResourceTenants.
• Parâmetros de consulta estruturada: $select, $top=999, $count=true - otimizados para extração máxima de dados por chamada.
• Uso da API /beta/: Utilizada de forma desproporcional por ferramentas ofensivas em comparação com a navegação normal do portal.
• Sucesso/fracasso misto: Alguns endpoints retornam 400 ou 403 (o kit sonda tudo independentemente), enquanto a maioria retorna 200. Tentativas de reconhecimento malsucedidas ainda são consideradas reconhecimento.
• C_DeviceId vazio: O token foi emitido para um dispositivo não gerenciado e não registrado.
• Aplicativos próprios com escopos amplos pré-consentidos: os tokens para Meu Perfil incluem escopos como RoleManagement.ReadWrite.Directory, MailboxSettings.ReadWrite, UserAuthenticationMethod.ReadWrite e User.RevokeSessions.All — todos pré-consentidos, não exigindo solicitação de consentimento do OAuth.

Persistência do dispositivo-PRT

Conforme mencionado anteriormente, o kit pode estabelecer a persistência do registro do dispositivo, resistindo aos procedimentos padrão de revogação de sessão. O mecanismo:

1. O token de atualização MAB é trocado em oauth2/token por um token de acesso cujo público-alvo é urn:ms-drs:enterpriseregistration.windows.net (mesmo ID do cliente, novo público-alvo, sem solicitação de consentimento).
2. O kit utiliza o token de acesso urn:ms-drs:enterpriseregistration.windows.net para o endpoint POST EnrollmentServer/device com um CSR PKCS#10 gerado localmente, metadados sintéticos do dispositivo e um blob de chave de transporte. O DRS cria um objeto de dispositivo, atribui um ID de dispositivo, assina e retorna um certificado de dispositivo.
3. O kit cria um JWT contendo o token de atualização do usuário, assina-o via RS256 com a chave privada do dispositivo e incorpora o certificado do dispositivo no cabeçalho do JWT. Ele envia isso via POST para login.microsoftonline.com/common/oauth2/token como uma concessão ao portador JWT. A Entra valida a assinatura em relação ao certificado e retorna o PRT mais uma chave de sessão criptografada (JWE).
4. Quando um defensor dispara o comando revokeSignInSessions (que invalida todos os tokens de nível de usuário e tokens de atualização), o PRT do dispositivo permanece válido porque o dispositivo é uma entidade separada no Entra ID.
5. A partir dos novos IPs de retransmissão, o kit usa a chave de sessão PRT mais para assinar declarações HMAC-SHA256 por solicitação para /oauth2/token, intermediando tokens de acesso para qualquer serviço de primeira parte client_id que ele nomeie (Teams, Outlook, OneDrive, Office, Intune).

Por que revogar as sessões não impede a autenticação de dois fatores (2FA) do Tycoon?

Isso significa que a sequência padrão de resposta a incidentes, "revogar sessões > redefinir senha", é insuficiente. Para quebrar atomicamente a cadeia dispositivo-PRT, os defensores devem enumerar e excluir os dispositivos registrados antes de revogar as sessões.

Nuances de detecção - Microsoft

A proteção de identidade pode não sinalizar a infraestrutura do kit. Os endereços IP de saída atuais do Tycoon 2FA sofrem rotações agressivas e podem não estar incluídos no conjunto de ativos de risco da Microsoft. Os defensores que dependem exclusivamente dos sinais de risco do Entra ID para detecção de AiTM não verão nada.

O c_sid nos Logs de Atividade do Graph NÃO é o ID do objeto do usuário. É um identificador de sessão/contexto de segurança. Os analistas que filtrarem os registros de atividade do Graph por c_sid == user_object_id obterão resultados vazios e concluirão que o invasor não usou tokens do Graph. O ponto de partida correto para a busca é o endereço IP de origem + ID do aplicativo, cruzando as informações com os registros de login para mapear o IP ao usuário.

A geolocalização não é confiável para endereços IP de provedores de nuvem. O mesmo endereço IP de retransmissão do kit pode geolocalizar para diferentes cidades dentro da mesma sessão de login. ASN é o único enriquecimento confiável para regras de detecção.

Visibilidade da emissão de tokens. A criação ou emissão de tokens não é registrada; eventos de autenticação que utilizam esses tokens sugerem um sinal de busca mais reativo.

Status de usuário de risco na proteção de ID da Entra. A proteção de ID da Entra analisa eventos de login, sessões, tokens e muito mais para atribuir um nível de risco e um status aos usuários. O status aiConfirmedSafe foi observado durante o relay de nível 2 , marcando o usuário como não apresentando risco. Em seguida, foram identificadas anomalias de risco do usuário com base no token anômalo, o que reclassificou o usuário para um risco médio. Simplesmente excluindo eventos em que o aiConfirmedSafe pode impedir que as organizações detectem falsos negativos na rotulagem da Microsoft.

Google Workspace

Relé de kit de nível único

A variante do Google funciona como um relé de kit de nível único, sem o nível distinto de console do operador visto no lado da Microsoft. Vários endereços IP de retransmissão de kits (normalmente de ASNs de hospedagem baratos como Clouvider, Host Telecom ou similares) autenticam o mesmo usuário em questão de minutos, cada um executando a mesma sequência de quatro eventos:

1. login_success Senha validada (T+0,000s)
2. login_verification com is_second_factor: true - o kit retransmite o código TOTP/SMS/push em tempo real, completando 2SV (T+0,000s)
3. token: autorizar para o cliente OAuth do Chrome do Google (77185425430) (T+0,4 a 0,6s)
4. DEVICE_REGISTER_UNREGISTER_EVENT (Novo dispositivo registrado pelo Google devido à autenticação de perfil) (T+0,6 a 1,2s)

Essa compressão de aproximadamente 1 segundo é um sinal de logins automatizados.

O kit autoriza consistentemente o mesmo cliente OAuth em todas as sessões de retransmissão:

O escopo OAuthLogin é o escopo de login inicializado interno do Chrome. Não se trata de um escopo de plano de dados (por si só, não concede acesso ao Gmail, Drive ou Calendário). O alcance do kit, considerando apenas esse recurso, está limitado a um login de longa duração capaz de se tornar uma sessão do Chrome Sync, e não ao acesso direto a caixas de correio ou arquivos sem novas trocas de tokens.

O evento token.authorize de um ASN de VPS confirma que a autorização ocorre no servidor durante o retransmissão, e não no dispositivo da vítima, o que a torna suspeita independentemente da intenção do operador.

Arquitetura Kit JavaScript (variante do Google)

A descompilação da variante do WebSocket direcionada ao Google revela uma arquitetura de 5 camadas:

Os campos de entrada 15 abrangem todos os métodos de autenticação de dois fatores (2FA) do Google: senha, TOTP, SMS, chamada de voz, códigos de backup, e-mail de recuperação, verificação por telefone, fallback para chave de segurança, aviso no celular e alteração forçada de senha. O nome do evento Socket.IO “recieveid” (observe o erro de digitação) é uma impressão digital consistente do kit.

Nuances de detecção - Google

O Centro de Alertas do Google pode permanecer inativo. Mesmo quando vários logins de diferentes ASNs atingem o mesmo usuário em questão de minutos, os registros do Alert Center podem não ser enviados para a API de Alertas. Os e-mails de alerta de segurança do Google enviados para a caixa de entrada da vítima não são um substituto, pois são enviados para a caixa de entrada do usuário comprometido, e não para a área administrativa.

is_suspicious pode não ser acionado. Os endereços IP de retransmissão de kits provenientes de ASNs de hospedagem barata podem não estar no conjunto de riscos do Google. Os defensores que dependem desse campo como sinal principal terão pontos cegos. No engajamento canário, is_suspicious era falso em cada login_success de todos os quatro IPs do kit em Clouvider e Host Telecom.

Sem agente do usuário em eventos de login: Os eventos de login da API de Relatórios não incluem dados de agente do usuário ou impressão digital do dispositivo. As detecções baseadas em UA que funcionam no lado Entra (node / axios / undici) não têm equivalente direto no Google.

A visibilidade do fluxo de trabalho OAuth é superficial: o evento token.authorize do Google expõe o client.id. nome_do_aplicativo, tipo.do_cliente, e valor de escopo, E esse é o conjunto completo. Não existe um resource_id distinto de scope, nenhum campo grant-type e nenhum campo incoming-token-type.

A maioria dos fluxos auxiliares permanece silenciosa: sem google_workspace.context_aware_access Eventos foram disparados (apesar de cinco novos registros de dispositivos no usuário) e nenhum registro do Alert Center chegou à API de Alertas. O rastreamento do kit se dá em apenas três fluxos: login, token e dispositivo. Caçadas que dependem de qualquer outro fluxo de água não detectarão este kit.

Tycoon 2FA entre Entra ID e Google Workspace

A variante M365 é operacionalmente mais pesada, e o registro de dados fornece detalhes extensos antes e depois da violação da identidade. A variante do Google Workspace é mais leve (apenas os logins foram observados), mas o registro padrão carece de contexto importante.

Regras de detecção de comportamento 2FA para magnatas

Implementamos regras de detecção em fontes de telemetria da Microsoft e do Google, abrangendo toda a cadeia de ataque: phishing inicial do AiTM, retransmissão de tokens, reconhecimento do console do operador e persistência do dispositivo.

Microsoft - Kit de detecção de relés

Entrada potencial de ID Entra AiTM via OfficeHome (Tycoon2FA) - Esta é uma detecção de sinal alto que é acionada em logins do Auth Broker ou OfficeHome para Graph/Exchange com agentes de usuário no estilo Node.js (node, axios, undici). Captura as operações de token do lado do servidor da camada de retransmissão do kit.

M365 Potencial AiTM Usuário conectado via aplicativo do Office (Tycoon2FA) - Mesma lógica de detecção que a regra de login do Entra, mas contra o Log de Auditoria Unificado do M365 para locatários que ingerem o365.audit em vez de (ou além de) logs de login do Entra.

Entra ID OAuth Device Code Phishing via AiTM : Detecta logins bem-sucedidos por meio do fluxo de código de dispositivo interativo, utilizando o Auth Broker, visando o Exchange, Graph ou SharePoint. Detecta especificamente a variante de abuso de concessão de código de dispositivo.

ID de entrada do Microsoft Authentication Broker em recurso incomum : Detecta logins bem-sucedidos do Auth Broker em que o recurso de destino está fora do conjunto de recursos primários comumente observados. Detecta a troca de tokens FOCI para APIs inesperadas ou aplicativos corporativos.

Microsoft - Detecção de persistência

Entra ID Registrar dispositivo com agente de usuário incomum (Azure AD Join) : Detecta eventos de registro de dispositivo bem-sucedidos onde o agente de usuário não é um dos clientes de registro nativos conhecidos (Dsreg, DeviceRegistrationClient, Dalvik). Captura a estratégia de persistência do dispositivo PRT do kit, também originada pelo agente de usuário axios:

Enumeração da API Graph pós-comprometimento (ES|QL)

Para o reconhecimento pós-comprometimento da camada de console do operador, criamos uma regra ES|QL que classifica cada solicitação da API do Microsoft Graph em uma das cinco categorias de reconhecimento e é acionada quando 4 ou mais categorias distintas são atingidas dentro da janela de agregação (<= 60s):

O recurso Multi-Category Reconnaissance Burst do Microsoft Graph detecta enumerações sistemáticas pós-comprometimento, filtrando o uso orgânico de portais. A atividade normal do usuário pode atingir uma ou duas dessas categorias, atingir 4 ou mais categorias de reconhecimento distintas de uma única sessão dentro de um curto período (33 segundos) é a impressão digital de ferramentas automatizadas.

Google - Kit de retransmissão e detecção de persistência

Google Workspace Impossible Travel Login - Regra ES|QL usando *st_distance()* funções geoespaciais para detectar logins bem-sucedidos de locais que implicam viagens mais rápidas que 800 km/h com pelo menos 500 km de separação. Detecta o padrão de retransmissão de kits multi-ASN, onde vários IPs em diferentes geolocalizações autenticam o mesmo usuário em questão de minutos:

Login de usuário do Google Workspace a partir de um ASN atípico - nova regra de termo que detecta a primeira vez que um usuário do Google Workspace faz login com sucesso a partir de um determinado ASN de origem dentro de um período histórico de 14 dias.

Registro de dispositivo do Google Workspace após OAuth de ASN suspeito : regra de sequência EQL detectando autorização OAuth para o cliente Chrome (77185425430.apps.googleusercontent.com) de ASN de hospedagem barata, seguida em 30 segundos por um registro de dispositivo com estado de conta REGISTERED.

Detecção de picos de registro de dispositivos do Google Workspace para um único usuário - Detecta picos de eventos de registro de dispositivos do Google Workspace para o mesmo usuário, onde três ou mais valores distintos de
google_workspace.device.id são emitidos em um intervalo de um minuto:

Automatizando o controle de pragas com o Elastic Workflows

Uma vez que o conteúdo de detecção esteja implementado, a próxima lacuna é o tempo entre o alerta e a ação. O período de transferência do kit Tycoon 2FA M365 para o operador, que documentamos anteriormente, é de 10 a 20 minutos, o intervalo entre a primeira emissão bem-sucedida de tokens pelo relé do kit e o início da sessão do operador, após a invasão do Graph.

Uma resposta manual ao SOC normalmente leva mais tempo do que esse período, e é por isso que o operador realiza o trabalho de reconhecimento antes que o confinamento chegue. Preencher essa lacuna é o que torna a detecção viável.

O Elastic Workflows, fornecido com o pacote (9.4+), permite que as regras de detecção invoquem fluxos de trabalho personalizados com um pipeline de etapas definido em YAML para cada alerta.

Como prova de conceito, criamos um fluxo de trabalho personalizado conectado a uma regra de detecção de possível login AiTM via OfficeHome (Tycoon2FA) do Entra ID , que espelha as ações de resposta necessárias.

Em cada alerta, o fluxo de trabalho é o seguinte:

1. Adquire um portador do Graph através de client_credentials (uma vez por execução).
2. Aplica um PATCH no UPN comprometido com accountEnabled: false para impedir novas autenticações.
3. Enumera os dispositivos registrados e os dispositivos de propriedade do usuário.
4. O comando DELETE exclui cada entidade de dispositivo, o que invalida, na prática, um PRT vinculado ao dispositivo.
5. Requisições POST para revogar SignInSessions invalidam tokens de atualização e cookies de sessão em nível de usuário.
6. Abre um caso no Kibana preenchido com o contexto de alerta para auditoria pós-incidente de resposta a incidentes (redefinição de senha, revisão do método de autenticação, auditoria de concessão OAuth).

A cadeia é executada em menos de 10 segundos de ponta a ponta no Microsoft Graph, bem dentro da janela de transferência de 2FA do Tycoon de 10 a 20 minutos. A sessão de nível de operador nunca tem a chance de iniciar o reconhecimento.

O padrão se estende para além dessa única regra. O mesmo fluxo de trabalho funciona para qualquer detecção de identidade na nuvem que se beneficie de contenção imediata: logins AiTM, viagens impossíveis, concessões ilícitas de consentimento OAuth, escalonamento de funções, fadiga de MFA e registro anômalo de dispositivos. Conecte a regra a um fluxo de trabalho que chama a API de nuvem relevante e o SOC obtém contenção em segundos.

Defendendo-se contra ataques Tycoon 2FA AiTM

• Implemente MFA resistente a phishing: as chaves de segurança FIDO2 e as senhas são os únicos métodos imunes ao roubo de sessão do AiTM. TOTP, SMS e MFA baseado em notificações push podem ser usados como proxy.
• Garanta a conformidade do dispositivo por meio do Acesso Condicional: Exija que os dispositivos gerenciados e em conformidade sejam usados para a emissão de tokens. Este é o método de controle mais eficaz contra o roubo de tokens AiTM.
• Fluxos de código do dispositivo de bloco: A política de Acesso Condicional Block device code flow rejeita claramente o relé do kit na fase de concessão (erro 53003). Habilite para todos os usuários, exceto em cenários de quiosque/sem interface gráfica explicitamente aprovados.
• Ativar proteção de token (vinculação de token): Vincula os tokens ao dispositivo para o qual foram emitidos. Um token roubado, reproduzido a partir de um dispositivo diferente, será rejeitado.
• Habilitar a Avaliação Contínua de Acesso (CAE): Revogação de tokens quase em tempo real quando as condições de risco mudam.
• Ativar configurações de segurança padrão no Entra ID (somente para locatários sem Acesso Condicional personalizado): rejeita autenticação legada, como ROPC, e bloqueia o fluxo de código do dispositivo por padrão. Habilitar as Configurações de Segurança Padrão desativa as políticas de AC personalizadas, portanto, isso não se aplica a locatários que já executam AC granular.

Mapeamento MITRE ATT&CK

Referências

• Blog de Segurança da Microsoft - Por dentro do Tycoon2FA: Como um dos principais kits de phishing AiTM operava em grande escala (março de 2026)
• Análise e visão geral do malware Tycoon 2FA por ANY.RUN
• Cloudflare - Remoção do Tycoon 2FA (março de 2026)
• SpyCloud - Remoção da autenticação de dois fatores do TycoonPor dentro da disrupção da infraestrutura global de phishing (março de 2026)
• eSentire - Operadoras de 2FA de grande porte adotam phishing por código de dispositivo OAuth (maio de 2026)
• Sekoia - Tycoon 2FA: uma análise detalhada da versão mais recente do kit de phishing AiTM (março de 2024)