Forg365, novo PhaaS de assinatura, ataca contas Microsoft 365 com device code phishing e roubo de sessão AitM

Kit vendido no Telegram por US$ 400 mensais usa infraestrutura legítima de email, iscas assistidas por IA e um painel completo de operador para autorizar sessões controladas pelo atacante e operar caixas comprometidas.

Componente	Operação phishing-as-a-service (PhaaS) chamada Forg365, voltada a contas Microsoft 365, descrita pela ZeroBAC e comparada às famílias Kali365 (também Octopi365/Freedom365) e Sneaky 2FA.
Vetor	Iscas de email com tema de documento de negócios ou aprovação de remessa entregues por infraestrutura legítima (Amazon SES no remetente e recursos hospedados no Twilio SendGrid), com cadeia de redirecionamento que termina em domínios controlados pelo Forg365 e um ramo de device code phishing que empurra a vítima para o fluxo real do Microsoft Authentication Broker.
Impacto	O código de verificação exibido autoriza uma sessão controlada pelo atacante (roubo de sessão/token em modelo AitM, sem depender de captura tradicional de senha), habilitando operações pós-comprometimento na caixa de correio, como monitoramento por palavras-chave e redação de respostas assistida por IA.
Prioridade	Bloquear autenticação por device code quando não for necessária, revisar artefatos da caixa após eventos de device code, auditar regras de mail-flow e descomissionar aliases legados sem correspondência a funcionários ativos.
Distribuição	Comercializado por assinatura via Telegram a US$ 400 por mês (ou US$ 3.800 por ano), com painel de operador acessível na clearnet em logfriend[.]com/login (indicador defangado).

Resumo técnico

A ZeroBAC documentou uma operação de phishing-as-a-service (PhaaS) chamada Forg365 que combina device code phishing, técnicas adversary-in-the-middle (AitM), evasão antibot, geração de iscas assistida por inteligência artificial e operações pós-comprometimento em caixas de correio, tudo direcionado a contas Microsoft 365. O modelo é vendido por assinatura via Telegram por US$ 400 mensais ou US$ 3.800 por ano, o que coloca uma cadeia de ataque relativamente sofisticada ao alcance de operadores com pouca ou nenhuma habilidade técnica, permitindo orquestrar campanhas em escala com esforço mínimo.

Segundo a análise, o kit é melhor compreendido como parte do mesmo ecossistema de Kali365 (também conhecido como Octopi365 e Freedom365) e Sneaky 2FA, refletindo a industrialização do negócio, que agora reúne criação de iscas, entrega, evasão, manipulação de token e sessão e operações pós-comprometimento sob um único pacote por assinatura. O painel de operador expõe um fluxo de trabalho maduro: gestão de contas, links, convites, configuração de app OAuth, links de redirecionamento, geração de SVG, envio de campanhas, perfis SMTP com rotação, geração de email por IA, cofre de tokens (token vaulting), inteligência de contas, alertas por palavra-chave, viewer links e suporte a extensão de navegador.

Fluxo técnico

As cadeias observadas usam iscas com tema de documento de negócios ou aprovação de remessa para induzir o destinatário a clicar em links maliciosos. O domínio remetente usa Amazon Simple Email Service (Amazon SES) para a entrega, enquanto o corpo da mensagem contém imagens ou recursos de rastreamento hospedados no Twilio SendGrid. A intenção é imitar uma cadeia de redirecionamento que se mistura ao tráfego de email legítimo antes de terminar em domínios controlados pelo Forg365, reduzindo os sinais que normalmente alertam gateways de email e usuários. Após concluir o registro no Telegram, o cliente do serviço acessa o painel na clearnet, onde gera iscas, configura campanhas e administra os tokens capturados.

O componente central é o ramo de device-auth: ele apresenta uma página de código de verificação com aparência da Microsoft e empurra a vítima para o fluxo real de login do Microsoft Authentication Broker. Do ponto de vista da vítima, as superfícies de autenticação exibidas são autênticas da Microsoft; porém, o código inserido autoriza uma sessão sob controle do atacante. Isso caracteriza roubo de sessão em modelo AitM, no qual o adversário obtém acesso mediado por token válido sem necessariamente capturar a senha em texto claro. A partir daí, o Forg365 vai além da simples coleta de credencial ou token e facilita ações pós-comprometimento, como monitorar palavras-chave específicas nas contas de email comprometidas e redigir respostas a uma thread de email específica com auxílio de IA.

Um caso descrito ilustra como a entrega escapa de controles: a campanha alcançou a caixa de entrada porque a organização destinatária ainda mantinha uma relação ativa de encaminhamento de um namespace pré-aquisição para uma caixa atual. O atacante usou uma identidade histórica ainda resolvível para entregar mensagens que, do ponto de vista do secure email gateway (SEG), pareciam correspondência encaminhada normal, sem sinal visível de que a mensagem tinha percorrido um caminho indireto.

Superfície afetada

O alvo primário são identidades e caixas de correio do Microsoft 365, incluindo os serviços acessíveis após o sequestro de sessão. A publicação também descreve campanhas paralelas que empregam kits de phishing correlatos para roubo de credenciais e tokens, o que amplia a superfície de risco para além do Forg365 e reforça o padrão de industrialização do PhaaS.

• Contas e tenants Microsoft 365 alvo do device code phishing, com sessões que podem alcançar serviços como OWA, OneDrive, SharePoint e o portal administrativo admin.microsoft.com (abuso observado em kits relacionados como o Kali365 via aplicativo OctoLink Live, que abre o mailbox da vítima em uma sessão Chromium a partir do token roubado).
• Ambientes onde persistem aliases legados e relações de encaminhamento de namespaces pré-aquisição, que podem servir de caminho de entrega confiável para as mensagens.
• Cadeias de entrega que abusam de serviços legítimos: Amazon SES no remetente, recursos SendGrid no corpo, além de páginas intermediárias hospedadas em plataformas confiáveis (por exemplo, conteúdo em Canva e, em outra campanha correlata, links de rastreamento Mailjet seguidos de site WordPress comprometido, interstício CAPTCHA e host em Cloudflare Workers).
• Kits e frameworks correlatos citados no mesmo conjunto de descobertas, incluindo Sneaky 2FA, The Quarry (que entrega o software de acesso remoto legítimo ConnectWise ScreenConnect e traz ferramentas como Rocky Gmail Sender, Rocky Email Sorter e VioletRAT), Nyasher e GPPStorm (voltados a contas Google) e o kit EvilTokens, além de um kit de smishing que imita USPS e UPS para capturar dados pessoais e de cartão em tempo real via WebSocket.

Hunting e telemetria

A detecção deve priorizar sinais de autenticação por device code e de sessões autorizadas por token, já que a senha pode não trafegar. A correlação entre eventos de sign-in, consentimentos de aplicativo e alterações de fluxo de correio ajuda a distinguir uso legítimo de abuso, especialmente em tenants que ainda permitem device code de forma ampla.

• Eventos de autenticação por device code nos logs de sign-in do provedor de identidade, sobretudo os associados ao Microsoft Authentication Broker e originados de contextos incomuns.
• Registros e consentimentos de aplicativos OAuth inesperados, coerentes com a configuração de app que o painel do kit oferece.
• Regras de mail-flow e de encaminhamento recém-criadas ou preexistentes ligadas a namespaces pré-aquisição e aliases legados que não correspondem a funcionários ativos.
• Sessões e tokens ativos surgindo logo após a exibição de páginas de código de verificação, bem como acessos subsequentes a OWA, OneDrive, SharePoint e portal administrativo a partir dessas sessões.
• Mensagens entregues por infraestrutura legítima (Amazon SES/SendGrid) que resolvem, após redirecionamentos, para domínios finais fora do escopo esperado da organização.

Mitigação

A resposta recomendada parte da redução do vetor de device code e avança para revisão de artefatos e higiene de identidade. O objetivo é fechar o caminho de autorização de sessão, remover pontos de entrega confiáveis herdados e validar que nenhum token controlado por atacante permanece válido.

• Bloquear a autenticação por device code, a menos que ela seja explicitamente necessária, restringindo-a por política de acesso condicional.
• Revisar os artefatos da caixa de correio após eventos de device code, procurando qualquer sinal de atividade incomum, incluindo respostas automatizadas ou regras criadas após o evento.
• Auditar as regras de fluxo de correio e descomissionar aliases legados que não correspondem mais a funcionários ativos, encerrando relações de encaminhamento de namespaces pré-aquisição.
• Revogar tokens e sessões suspeitas e forçar reautenticação, garantindo que sessões autorizadas de forma fraudulenta deixem de ser válidas.
• Reforçar a educação de usuários sobre páginas de código de verificação de aparência legítima, deixando claro que inserir um código pode autorizar uma sessão de terceiros.