Tycoon 2FA

01Sumário executivo

O Tycoon 2FA é uma plataforma de phishing como serviço, ou PhaaS (Phishing-as-a-Service), dedicada ao roubo de credenciais e de sessões do Microsoft 365 e do Google. Foi descoberta pela equipe de pesquisa da Sekoia em outubro de 2023, já em operação desde pelo menos agosto do mesmo ano [1]. A Microsoft rastreia o grupo que a desenvolve e opera sob a designação Storm-1747 [2].

A técnica central é adversary-in-the-middle (AiTM). Diferentemente do phishing clássico, que armazena a senha digitada e nada mais pode fazer diante de um segundo fator, o kit intermedia a sessão inteira: relaia as credenciais ao servidor autêntico, apresenta ao usuário o desafio real de segundo fator e, quando este é concluído, captura o cookie de sessão emitido [1]. O que o operador leva não é uma senha, é uma sessão viva.

A escala é industrial. A Microsoft mediu dezenas de milhões de mensagens por mês alcançando mais de 500 mil organizações, com educação nomeada entre os setores alvo, ao lado de saúde, finanças, terceiro setor e governo [2]. A infraestrutura da Digital Crimes Unit da Microsoft, em conjunto com a Europol e parceiros do setor, desarticulou a plataforma em março de 2026 [2].

A desarticulação não encerrou o problema, e é por isso que este relatório existe. Em abril de 2026, a equipe de resposta da eSentire documentou a operação de volta, com uma mudança de técnica relevante: em vez de proxy reverso, abuso do Device Authorization Grant do OAuth, no qual a vítima autentica em infraestrutura genuína da Microsoft e entrega o token ao atacante sem jamais visitar uma página falsa [3]. A seção 07 trata dessa variante em separado, porque ela derrota controles desenhados para a variante de proxy.

As recomendações se organizam em duas frentes. A detecção (seção 09) parte de logs de resolvedor e de proxy, os mais baratos, e converge para os logs de autenticação do provedor de identidade, que são a fonte de maior valor neste caso. A resposta (seção 10) inverte a ordem habitual de contenção, porque aqui a revogação de sessão precede a troca de senha.

02Identificação do objeto analisado

03Adversary-in-the-middle: por que o segundo fator não protege

O phishing tradicional é um formulário morto: ele copia a aparência da tela de login, guarda o que foi digitado e devolve uma mensagem de erro. Diante de autenticação multifator, ele falha, porque o código de uso único expira antes que o operador possa aproveitá-lo. O AiTM (Adversary-in-the-Middle) resolve esse problema do atacante colocando um proxy reverso vivo entre a vítima e o serviço legítimo [1]. A sequência é a seguinte:

• a vítima digita usuário e senha na página do atacante, que é uma cópia da tela real;
• o servidor do atacante submete esses dados imediatamente ao servidor autêntico da Microsoft ou do Google;
• o serviço autêntico responde com o desafio real de segundo fator, e essa resposta é repassada à vítima, que vê exatamente o que veria numa sessão legítima;
• a vítima aprova a notificação no aplicativo autenticador, ou digita o código recebido, satisfazendo o desafio de verdade;
• o serviço emite o cookie de sessão, e ele é entregue ao servidor do atacante, não à vítima.

Isso reordena a hierarquia de controles. Segundo fator por notificação por envio, por senha de uso único em aplicativo e por SMS são todos relaiáveis, porque o usuário os conclui de boa-fé contra um desafio autêntico [1]. O que não é relaiável é a autenticação vinculada à origem, ou seja, chaves de segurança e senhas-chave em FIDO2 e WebAuthn, nas quais o navegador se recusa a assinar para um domínio que não é o registrado. A seção 10.4 desenvolve essa recomendação.

04O negócio por trás do kit

4.1Assinatura, preço e volume

O Tycoon 2FA não é operado por quem o escreve. É alugado. A Sekoia identificou a divulgação por canal de Telegram, sob os apelidos Tycoon Group, SaaadFridi e Mr_XaaD, com preço a partir de US$ 120 por dez dias de operação, mais caro conforme o domínio de topo escolhido [1]. O assinante recebe páginas prontas e modelos de anexo de e-mail, sem precisar entender nada do que compra.

A análise da carteira de bitcoin atribuída ao operador registrou cerca de 700 transações recebidas, somando mais de US$ 250 mil desde agosto de 2023, o que sugere várias centenas de assinaturas vendidas no período [1]. Entre agosto de 2023 e fevereiro de 2024, a mesma equipe catalogou mais de 1.200 nomes de domínio associados à plataforma [1].

Esse modelo tem uma consequência defensiva direta: não existe um adversário com um alvo. Existem dezenas de assinantes simultâneos, cada um com sua lista de destinatários e seu pretexto. A sua instituição não precisa ser interessante para ser atingida, basta constar de uma lista comprada.

4.2Parentesco com o Dadsec

A pesquisa da Trustwave SpiderLabs, hoje publicada sob a marca LevelBlue, documenta sobreposição de infraestrutura entre o Tycoon 2FA e o kit Dadsec, indicando linhagem comum de desenvolvimento sob a mesma operação [5]. As evidências reunidas foram:

• domínios das duas campanhas resolvendo para um conjunto compartilhado de endereços, com concentração no AS19871;
• uso do mesmo painel de hospedagem de código aberto, o Cyber Panel, nas duas operações;
• entrega por arquivo PHP de nome fixo, que evoluiu de res444.php para cllascio.php e .000.php até março de 2025;
• padrão de nomenclatura de domínio estável, com rótulo de 5 a 10 caracteres alfanuméricos e subdomínio de 15 a 20, predominantemente sob o topo .ru.

4.3A desarticulação de março de 2026

Em 4 de março de 2026, a Microsoft publicou o balanço da operação conduzida pela sua Digital Crimes Unit em conjunto com a Europol e parceiros do setor, que derrubou a infraestrutura e a operação do Tycoon 2FA [2]. O mesmo documento registra a escala interrompida: dezenas de milhões de mensagens de phishing por mês, alcançando mais de 500 mil organizações, com educação entre os setores nomeadamente atingidos.

05Cadeia de entrega e camadas de evasão

5.1Como o link chega

A entrega é deliberadamente variada, e nenhuma das formas depende de anexo executável. A Microsoft catalogou as seguintes iscas em campanhas do kit [2]:

• anexos em PDF ou DOCX contendo código QR, que move o clique para o telefone pessoal, fora do alcance do proxy e do EDR da instituição;
• arquivos SVG com lógica de redirecionamento embutida, que passam por filtros que tratam imagem como conteúdo inerte;
• anexos HTML com mensagem curta;
• links diretos que se fazem passar por serviços de confiança.

O passo seguinte quase nunca aponta para o domínio do kit. A cadeia atravessa serviços legítimos que nenhuma instituição bloqueia por reputação, entre eles Azure Blob Storage, Firebase, Wix, TikTok, recursos do Google e Cloudflare Workers [2]. Na campanha de abril de 2026, o primeiro salto foi uma URL de rastreamento de cliques do serviço Trustifi, seguida de um subdomínio em workers.dev [3].

5.2As camadas que impedem a análise

Antes de exibir qualquer tela de login, o kit submete o visitante a uma triagem. A finalidade não é enganar o usuário, e sim impedir que analistas e rastreadores automáticos vejam a página. A Cybereason documentou a sequência em estágios [6]:

1. página HTML inicial com carga em base64 comprimida por LZ-string;
2. verificação de domínio, com remoção do código malicioso do DOM enquanto ele segue em execução na memória;
3. extração do endereço de e-mail da vítima a partir de parâmetro da URL, e envio ao servidor do operador;
4. verificação de depurador e de robô, que redireciona para site benigno em caso de suspeita;
5. entrega da tela falsa de Microsoft 365;
6. carga final, que administra o envio das credenciais e a interceptação do segundo fator.

O desafio de CAPTCHA que abre a cadeia começou como Cloudflare Turnstile, com a frase de espera “this page is running browser checks to ensure your security” [1]. Em 2025, o kit migrou para CAPTCHA próprio, desenhado em canvas HTML5, com caracteres, ruído e distorção aleatórios, justamente para deixar de exibir o elemento de terceiro que permitia às equipes de defesa identificar a página por impressão digital [4].

A ofuscação da mesma versão de 2025 merece registro pela originalidade, porque ela derrota busca por padrão em texto [4]:

• o código é codificado em binário usando dois caracteres Unicode invisíveis, o Halfwidth Hangul Filler (U+FFA0) para o bit zero e o Hangul Filler (U+3164) para o bit um;
• a cadeia de bits é fatiada em octetos e reconvertida em caracteres em tempo de execução;
• a decodificação é disparada pelo acesso a uma propriedade de um objeto Proxy do JavaScript, de modo que o nome da propriedade é o próprio veículo da carga;
• o script antidepuração detecta navigator.webdriver, PhantomJS, Burp Suite, atalhos de ferramentas de desenvolvedor e o tempo de abertura do depurador, e redireciona para rakuten.com quando suspeita de análise.

06A página de captura e o relé do segundo fator

Vencida a triagem, o visitante recebe uma réplica da tela de autenticação da Microsoft, já preenchida com o seu endereço de e-mail, extraído da URL em texto claro ou em base64 [1] [6]. O preenchimento prévio é detalhe de engenharia social relevante: ele elimina a etapa em que o usuário costuma reparar no endereço do site, porque a página parece uma continuação de sessão e não um login novo.

A partir daí, a página abre uma conexão WebSocket com o servidor do operador e passa a operar como intermediária [1]. A Sekoia documenta que o estágio de relé suporta as três formas usuais de segundo fator:

• aprovação por notificação no Microsoft Authenticator;
• senha de uso único, por aplicativo autenticador ou por SMS;
• verificação por chamada telefônica.

Concluída a autenticação, a vítima é redirecionada para um destino que reforça a impressão de normalidade, tipicamente login.microsoftonline[.]com/common/SAS/ProcessAuth ou um site de fachada [1]. Do ponto de vista do usuário, nada falhou, e é por isso que este ataque raramente gera denúncia espontânea. A instituição descobre o comprometimento pelo que a conta faz depois, não pelo relato de quem a perdeu.

As credenciais e os tokens capturados são cifrados com CryptoJS e enviados ao servidor do operador por requisição POST assíncrona [6]. A chave e o vetor de inicialização observados em campo são a cadeia literal 1234567890123456, reaproveitada tanto na versão de proxy reverso quanto na campanha de abril de 2026 [3] [6], o que a torna uma impressão digital útil para quem consiga inspecionar o conteúdo servido.

07A pivotada pós-desarticulação: fluxo de código de dispositivo

A campanha documentada pela eSentire entre 29 e 30 de abril de 2026 mantém a marca do Tycoon 2FA na entrega e na ofuscação, mas troca o coração da técnica [3]. Não há mais proxy reverso, nem página falsa de login. Há abuso do Device Authorization Grant, o fluxo do OAuth desenhado para autenticar aparelhos sem teclado, como televisores e impressoras.

O funcionamento inverte a lógica do phishing convencional:

1. o servidor do atacante pede um código de dispositivo ao endereço legítimo da Microsoft;
2. a vítima recebe uma isca de recado de voz que exibe esse código e a instrui a visitar microsoft.com/devicelogin;
3. a vítima autentica em infraestrutura genuína da Microsoft, com senha e segundo fator, e aprova o código;
4. a Microsoft emite tokens de acesso e de atualização para o cliente do atacante, que estava aguardando;
5. o acesso resultante cobre toda a superfície do Microsoft 365 e aparece na telemetria como uso de aplicativo legítimo.

A eSentire descreve a entrega em quatro camadas antes da isca final, e documenta a infraestrutura do operador com precisão incomum [3]:

• carga cifrada em AES-GCM, desembrulhada no navegador da vítima;
• verificações antianálise, incluindo detecção de navegador sem interface, armadilhas de depurador e filtragem por ASN consultado em serviço de enriquecimento de IP;
• invólucro de CAPTCHA com porta de verificação de domínio;
• a isca de consentimento OAuth com tema de recado de voz do Microsoft 365.

O aplicativo personificado é o Microsoft Authentication Broker, de identificador 29d9ed98-a469-4536-ade2-f981bc1d605e, e as operações de token partiram do AS45102 com agentes de usuário node e undici, ou seja, bibliotecas HTTP de servidor, jamais um navegador [3]. Cada amostra trazia carimbo de expiração embutido, com validade de aproximadamente um mês.

08Exposição da rede acadêmica federada

8.1Por que a universidade é alvo preferencial

A Microsoft nomeia educação entre os setores atingidos pelo Tycoon 2FA [2], e há razões estruturais para isso:

• a população de usuários é grande, rotativa e majoritariamente jovem, com renovação anual completa de coortes de ingressantes que ainda não conhecem os canais legítimos da instituição;
• a credencial institucional é uma chave mestra, porque a identidade federada abre correio, VPN, sistemas acadêmicos e o acervo de periódicos assinado;
• a cultura de abertura torna endereços de e-mail institucionais amplamente públicos, o que dispensa o atacante de comprar listas;
• uma conta institucional comprometida é plataforma de lançamento confiável, porque o phishing seguinte parte de um remetente legítimo, com registros de autenticação de e-mail válidos e histórico de conversa real.

8.2Uma campanha contra portais de autenticação acadêmica

A demonstração mais direta desse risco não veio do Tycoon 2FA, e sim de uma campanha paralela documentada pela Infoblox em dezembro de 2025 [8]. Entre 12 de abril e pelo menos 16 de novembro de 2025, um mesmo ator atacou ao menos 18 universidades e entidades de ensino dos Estados Unidos, usando cerca de 67 domínios.

A ferramenta era o Evilginx, provavelmente na versão 3.0, um proxy reverso de AiTM de código aberto, com o mesmo resultado do Tycoon 2FA: roubo de credencial e de cookie de sessão, com o segundo fator relaiado [8]. Os elementos de infraestrutura foram estes:

• iscas personalizadas por estudante, com link encurtado em TinyURL como primeiro salto;
• subdomínios que imitavam o portal de autenticação da instituição alvo, com URI de oito caracteres alfabéticos aleatórios;
• URLs que expiravam em 24 horas, para reduzir a janela de análise;
• páginas geradas dinamicamente a partir de phishlets, os arquivos de configuração que descrevem ao proxy como conversar com o site real.

09Detecção

A ordem abaixo vai do controle mais barato e abrangente ao mais caro e específico. A diferença em relação a um caso de malware residente é que aqui a fonte de maior valor não é a primeira da lista: os logs de autenticação, em 9.3 e 9.4, é que carregam a evidência decisiva, e o restante serve para achar a exposição e datar o incidente.

9.1Resolvedor e proxy

O valor aqui é retroativo. Procure nos logs arquivados os padrões estáveis do kit, sobretudo os nomes de arquivo PHP de entrega, que sobreviveram a várias trocas de domínio [5], e os nomes de recurso das versões antigas [1].

index=proxy (uri_path="*/res444.php" OR uri_path="*/cllascio.php"
             OR uri_path="*/.000.php" OR uri_path="*/myscr*.js"
             OR uri_path="*pages-godaddy.css" OR uri_path="*pages-okta.css")
| stats count, min(_time) AS primeiro, max(_time) AS ultimo,
        values(url) AS urls BY src_ip, user
| sort - count

index=dns query_regex="\.(space|email|solutions|live|today|calendar)$"
| stats dc(query) AS nomes_distintos, count BY src_ip
| where nomes_distintos < 5
| sort - count

9.2Regras de IDS e IPS

As duas regras abaixo cobrem marcadores de conteúdo publicados pela Sekoia [1] e seguem a sintaxe do Suricata. Elas são complementares ao conjunto Emerging Threats, que deve estar atualizado e não silenciado.

# Frase de espera do estagio de CAPTCHA das versoes com Turnstile
alert http $EXTERNAL_NET any -> $HOME_NET any (
  msg:"CIBERLAB PHISHING AiTM Tycoon 2FA pagina de verificacao";
  flow:established,to_client;
  file.data;
  content:"this page is running browser checks to ensure your security"; nocase;
  classtype:credential-theft; priority:1;
  sid:9000101; rev:1;
)

# Nome de recurso das versoes anteriores a fevereiro de 2024
alert http $HOME_NET any -> $EXTERNAL_NET any (
  msg:"CIBERLAB PHISHING AiTM Tycoon 2FA requisicao a myscrNNNNNN.js";
  flow:established,to_server;
  http.uri; content:"/myscr"; nocase;
  pcre:"/\/myscr\d{6}\.js$/Ui";
  classtype:credential-theft; priority:1;
  sid:9000102; rev:1;
)

9.3Logs de autenticação: a fonte de maior valor

É aqui que o ataque fica visível. A consulta a seguir implementa o marcador mais forte descrito pela Elastic e pela eSentire, que é a autenticação bem-sucedida com agente de usuário de biblioteca HTTP de servidor, algo que um usuário humano nunca produz [3] [7].

SigninLogs
| where ResultType == 0
| where UserAgent has_any ("node", "undici", "axios", "node-fetch")
| project TimeGenerated, UserPrincipalName, IPAddress,
          AutonomousSystemNumber, AppId, AppDisplayName,
          AuthenticationProtocol, IncomingTokenType, UserAgent
| order by TimeGenerated asc

SigninLogs
| where AuthenticationProtocol == "deviceCode" and ResultType == 0
| summarize Sucessos=count(), Enderecos=make_set(IPAddress),
            Agentes=make_set(UserAgent), Primeira=min(TimeGenerated)
    by UserPrincipalName, AppDisplayName
| order by Primeira desc

SigninLogs
| where ResultType == 0
| summarize Sistemas=dcount(AutonomousSystemNumber),
            Enderecos=make_set(IPAddress), Agentes=make_set(UserAgent)
    by UserPrincipalName, bin(TimeGenerated, 30m)
| where Sistemas >= 2
| order by Sistemas desc

O padrão que a Elastic aponta como decisivo é a separação em dois níveis: primeiro o relé do kit, saindo de hospedagem em nuvem com agente de usuário de servidor, e de dez a vinte minutos depois o operador humano, saindo de faixa residencial com um navegador único e fixo, sob a mesma conta [7]. Uma conta que exibe as duas assinaturas na mesma janela está comprometida.

9.4Sinais de sessão roubada e de persistência

Vencida a autenticação, os indicadores passam a ser de ritmo e de sequência, e não de origem [7]:

• sequência de login, validação de segundo fator, autorização de token e registro de dispositivo concluída em cerca de um segundo;
• rajada de 20 a 30 chamadas ao Microsoft Graph em 30 a 60 segundos, contra pontos de reconhecimento do locatário, com parâmetros de consulta otimizados;
• escalada do tipo de token recebido, de nenhum para token de atualização e daí para token primário de atualização;
• registro de dispositivo a partir de equipamento não gerenciado, logo após a autenticação, que é a jogada de persistência do kit;
• no Google Workspace, autorização OAuth para o cliente do Chrome partindo de faixa de provedor de hospedagem, e emissão de três ou mais identificadores de dispositivo distintos em um minuto.

9.5Gateway de e-mail

A entrega descrita em 5.1 exige atenção a três classes de anexo que muitos filtros tratam como inofensivas [2]:

• SVG, que é documento com script e não imagem; a triagem deve inspecionar o conteúdo ou converter para formato inerte;
• PDF e DOCX com código QR, que transferem o clique para um telefone fora do perímetro; exigem extração e leitura do código na análise do anexo;
• anexos HTML com mensagem curta e redirecionamento embutido.

10Mitigação e resposta

10.1Contenção imediata

1. Revogue todas as sessões e tokens de atualização da conta afetada, no provedor de identidade. Esta é a única ação que corta o acesso em curso.
2. Redefina a credencial em seguida, e exija novo registro de segundo fator.
3. Enumere e remova os dispositivos registrados pela conta na janela do incidente. O registro de dispositivo é a persistência do kit (seção 06), e ele sobrevive à revogação de sessão se ninguém olhar.
4. Revise consentimentos de aplicativo concedidos pela conta, sobretudo em caso de variante por código de dispositivo, na qual o acesso é um token concedido e não uma sessão roubada (seção 07).
5. Preserve os logs de autenticação da janela relevante antes que a retenção padrão os descarte, incluindo endereço de origem, sistema autônomo, agente de usuário e protocolo de autenticação.

10.2Erradicação e avaliação de alcance

1. Verifique regras de caixa postal criadas ou alteradas pela conta, que são o mecanismo clássico de ocultação de resposta em fraude de correio.
2. Levante o que a conta enviou depois do comprometimento. Uma conta institucional comprometida costuma ser usada para o phishing seguinte, e os destinatários internos precisam ser avisados e verificados (seção 8.1).
3. Levante o que a conta acessou: arquivos em nuvem, sistemas acadêmicos e serviços federados. A credencial é chave mestra, e o alcance do incidente é o alcance da federação.
4. Busque nos logs de autenticação outras contas com a mesma assinatura de origem e de agente de usuário, na mesma janela. Campanha de PhaaS atinge listas, não indivíduos.
5. Reinstalar a estação não é requisito neste caso, porque o ataque não deposita código no equipamento. Só o faça se a investigação encontrar implante, o que seria um incidente distinto.

10.3Comunicação com a comunidade

Este ataque não gera denúncia espontânea, porque a experiência do usuário é a de um login bem-sucedido (seção 06). O aviso à comunidade deve, portanto, abandonar o conselho genérico de desconfiar de e-mails e dizer o que é verificável: que a instituição nunca pede autenticação a partir de link encurtado, que um código exibido em página e digitado em outro lugar nunca faz parte de um acesso legítimo a serviço institucional, e que aprovar uma notificação de autenticação não solicitada deve ser reportado mesmo que o acesso pareça ter funcionado.

10.4Prevenção estrutural

10.5Mapeamento MITRE ATT&CK

As técnicas abaixo derivam integralmente da literatura das seções 04 a 08, e não de observação própria. Os nomes seguem o catálogo oficial [9].

11Indicadores de comprometimento

12Limitações da análise

• Não houve detonação em sandbox nem análise de amostra própria. Todo o conteúdo técnico vem das referências [1] a [8], e nenhuma afirmação deste documento foi reproduzida experimentalmente por esta equipe.
• O objeto é uma plataforma de serviço, não um artefato. Não há hash, tamanho de arquivo nem árvore de processos a apresentar, e nenhum indicador deste relatório casará com varredura de antivírus ou de EDR.
• As fontes descrevem versões distintas do kit em momentos distintos, de outubro de 2023 a abril de 2026. Um recurso descrito em uma seção pode ter sido substituído na versão descrita em outra, e o documento identifica a data sempre que a fonte a fornece.
• Os domínios e endereços da seção 11 são históricos, com vida útil documentada de 24 a 72 horas. Não servem para bloqueio prospectivo, e endereços de rede são reatribuídos.
• A ponte entre a campanha da referência [8] e a arquitetura da CAFe é inferência deste relatório. A fonte trata de instituições dos Estados Unidos e não menciona a federação brasileira.
• Não há, até a data de emissão, pesquisa pública documentando campanha de AiTM dirigida nominalmente à CAFe ou ao eduroam. A ausência de relato não equivale a ausência de exposição, e tampouco a comprova.
• As consultas da seção 09 pressupõem Microsoft Entra ID e Microsoft 365. Instituições em outro provedor de identidade precisam traduzir os campos, e a seção 9.4 registra duas limitações concretas da telemetria do Google Workspace.
• As regras de IDS da seção 9.2 são propostas e não foram validadas em tráfego real por esta equipe. Teste-as em modo de alerta antes de qualquer bloqueio, porque casamento em conteúdo de resposta produz falso positivo com facilidade.
• A desarticulação de março de 2026 altera continuamente o valor dos indicadores. A infraestrutura descrita nas referências [1] a [6] está, em sua maior parte, fora do ar, e o que sobrevive é a técnica.
• O mapeamento MITRE da seção 10.5 é interpretação deste relatório sobre o comportamento descrito nas fontes, e não uma atribuição publicada pelo MITRE ou pelos autores citados.