Notícia
Phishing por assinatura derruba o MFA de empresas: BigBear 2.0 rouba sessões do Microsoft 365 em 258 organizações
Rodrigo ColissiIntrodução
A CloudSEK (empresa de inteligência de ameaças) identificou em junho de 2026 a operação BigBear 2.0, uma plataforma de phishing como serviço (PhaaS) baseada no framework de ataque Evilginx2 que conseguiu contornar a autenticação multifator (MFA) de mais de 250 organizações que usam o Microsoft 365 (suíte de produtividade em nuvem da Microsoft). Ao obter acesso administrativo ao painel da operação, os pesquisadores encontraram 5.137 registros de credenciais roubadas ligados a 461 organizações e 3.331 endereços IP de vítimas em mais de 40 países — incluindo 474 sessões autenticadas completas, 1.032 senhas em texto puro e 4.148 cookies de sessão.
O diferencial da campanha não é quebrar o segundo fator: é roubar a prova de que o usuário passou por ele. O BigBear 2.0 se posiciona entre a vítima e o login legítimo, deixa a Microsoft validar a senha e o desafio de MFA normalmente e, no instante em que o servidor emite o cookie de sessão autenticada, copia esse cookie antes de devolvê-lo ao navegador. Com ele, o atacante entra na conta sem tocar no código de um só fator — uma técnica conhecida como adversary-in-the-middle (AiTM) (intermediário no meio do caminho, que espelha o tráfego entre vítima e serviço legítimo).
Contexto: por que o MFA deixou de ser a linha de defesa
A campanha derruba a premissa de que "ter MFA ativado é estar protegido". Códigos por SMS, aplicativos autenticadores (TOTP) e notificações push confirmam o usuário durante a sessão viva — exatamente o que o proxy captura. A mecânica representa uma evolução em relação ao roubo clássico de credenciais, o mesmo alvo de trojans como o OtterCookie, mas atacado em tempo real, durante o login, com a sessão já autenticada.
O modelo de negócio também chama a atenção: operações como o BigBear 2.0 transformam o roubo de contas em serviço de assinatura, com painel multi-usuário, afiliados e exfiltração automática via bots de Telegram. Para empresas brasileiras — em especial provedores de serviços gerenciados (MSPs), escritórios de contabilidade e fornecedores de TI, que concentram acesso privilegiado a clientes —, a mesma mecânica já é usada contra bancos e organizações locais. Se um único fornecedor cai, a porta se abre para dezenas de clientes.
BigBear 2.0: o PhaaS que transforma MFA em mercadoria
O BigBear 2.0 é a versão rebatizada do Evilginx2, framework open source de phishing que atua como proxy reverso entre a vítima e o serviço alvo. A operação é administrada por um operador identificado pelo alias "General Boss" e roda sobre uma rede de 42 servidores virtuais privados (VPS) (máquinas virtuais alugadas usadas como servidores dedicados), hospedados majoritariamente na nuvem da Vultr. O phishlet padrão — a configuração que ensina o framework a imitar um site — é batizado de "offy" e mira exclusivamente o fluxo de autenticação do Microsoft 365 (protocolo OAuth 2.0 do Azure AD/Entra ID), o que o torna eficaz contra qualquer organização que use essa identidade corporativa.
O painel que a CloudSEK acessou revela uma operação industrial, com pipeline automatizado de processamento de credenciais: a captura dispara uma notificação via bot de Telegram, anexa um arquivo cookie.js e alimenta um motor de replay de cookies via API — tudo em tempo quase real. Ao menos cinco afiliados alugavam acesso à plataforma, cada um recebendo as credenciais roubadas em seu próprio chat de Telegram. Os números do painel:
| Métrica | Valor |
|---|---|
| Registros de credenciais roubadas | 5.137 |
| Sessões completas com MFA burlado | 474 (9,2%) |
| Senhas capturadas em texto puro | 1.032 |
| Cookies de sessão roubados | 4.148 |
| Organizações afetadas | 461 |
| IPs de vítimas (países: 40+) | 3.331 |
| Nós VPS gerenciados | 42 |
A monetização provável, segundo os pesquisadores, é a revenda de acesso inicial (initial access brokerage): cookies de sessão viram porta de entrada para ransomware, extorsão de dados ou fraudes de business email compromise (BEC) (comprometimento de e-mail corporativo para fraudar pagamentos e pedidos). A operação ainda estava ativa quando o relatório foi escrito — desde o fim de julho de 2026, o operador apagou 26 dos 42 VPS do painel, um movimento típico de contramedida forense após a detecção.
A cadeia AiTM: o proxy entre a vítima e o login real
O ataque segue um fluxo em cinco etapas, começando pelo e-mail de phishing e terminando com o acesso à conta já autenticada em outro navegador. Abaixo apresentamos o diagrama da cadeia e detalhamos cada etapa em seguida.
Cadeia AiTM do BigBear 2.0
A página falsa que entrega um cadeado verdadeiro
Cada nó VPS roda uma instância do Evilginx2 com certificados TLS provisionados automaticamente via Let's Encrypt para cada subdomínio de phishing — no padrão login.<domínio-falso>, com DNS curinga apontando para o IP do servidor. O resultado: a vítima vê um cadeado HTTPS válido e uma página visualmente idêntica à da Microsoft. A terminação TLS acontece no próprio proxy, que abre uma segunda conexão criptografada com o servidor real da Microsoft — a inspeção SSL do firewall corporativo não enxerga esse tráfego, e a Microsoft vê o IP do VPS, não o IP da vítima.
A captura: senha, código MFA e cookie de sessão
Quando a vítima digita o e-mail e a senha, o proxy encaminha tudo ao login legítimo (login.microsoftonline.com) e copia as credenciais no caminho. O passo seguinte é o coração do ataque: a vítima completa o segundo fator — TOTP, push ou SMS — na página real espelhada, a Microsoft valida o código e responde com o cookie de sessão no cabeçalho Set-Cookie. Como todo o tráfego passa pelo proxy, o servidor entrega esse cookie ao atacante antes de chegar ao navegador da vítima. O atacante nunca precisa ver o código: ele espera o usuário validá-lo e rouba o resultado. O painel confirma a eficiência: 80% das entradas de senha resultaram em captura do cookie de sessão.
O replay: a sessão roubada em outro navegador
O cookie capturado (no caso do Azure AD, o ESTSAUTH) é importado no navegador do atacante, que herda a sessão completa — sem novo desafio de MFA. A operação automatiza isso com um endpoint de API REST (/api/jobs) que reproduz os cookies em massa contra o serviço alvo, e mantém o acesso vivo por um mecanismo de keepalive que reutiliza o refresh token (token que renova a sessão sem novo login), normalmente válido por até 90 dias. Um script injetado marca automaticamente a opção "Manter conectado" (KMSI) para maximizar a vida útil do cookie. De posse da sessão, o atacante acessa e-mail, Teams, SharePoint, OneDrive e todos os aplicativos de SSO conectados — e pode até navegar pelo portal do Entra ID em busca de permissões delegadas (grants OAuth) para pivotar para outros serviços na nuvem.
FIDO2 na mira: como a operação desarma a chave de segurança
O BigBear 2.0 não se limita a capturar o que passa pelo proxy: ele ativamente empurra a vítima para longe da única autenticação que resiste ao AiTM. A análise da página de phishing ao vivo revelou três injeções de JavaScript proprietárias, ausentes no Evilginx2 padrão. A primeira redefine window.PublicKeyCredential como indefinido e intercepta navigator.credentials, quebrando na prática o FIDO2 (padrão de autenticação sem senha com chaves de segurança) e o WebAuthn (padrão web de autenticação por chaves criptográficas) — o usuário com chave de segurança cai para um segundo fator "phishable", como SMS ou código. A segunda bloqueia a telemetria anti-phishing da Microsoft (requisições a canarytokens, events.data.microsoft.com e OneCollector), dificultando a detecção. A terceira marca o "Manter conectado" automaticamente.
A infraestrutura completa a evasão com um pool de 69 proxies residenciais por país, com correspondência automática de geolocalização: uma vítima na Índia vê o tráfego sair de um IP residencial indiano. Isso derruba os alertas de "login de localização incomum", satisfaz políticas de Conditional Access baseadas em local e ainda bloqueia pesquisadores — o painel consulta o serviço ipapi.is e recusa visitantes vindos de VPNs, datacenters e proxies, como aconteceu durante a própria investigação.
Foco em MSPs: um fornecedor comprometido, muitos clientes
O setor mais atingido foi o de serviços de TI e provedores de serviços gerenciados (MSPs) (empresas que administram a TI de terceiros por assinatura), com 151 organizações — seguido por SaaS/tecnologia (38), óleo e gás (22), farmacêutico (20) e consultoria (16). A escolha é estratégica: um MSP comprometido é uma rota para dezenas de clientes downstream, e seus técnicos costumam ter acesso privilegiado a Azure AD, Active Directory local, ferramentas de gerenciamento remoto (RMM) e gerenciadores de senhas. A distribuição setorial ampla — 438 domínios únicos em mais de 40 países — sugere uma mistura de disparo em massa de listas de e-mail com listas setoriais compradas.
Indicadores de comprometimento (IoCs)
Os indicadores abaixo foram publicados pela CloudSEK e pelo Cyber Security News. Os IPs e domínios estão defangados, com a entidade . no lugar dos pontos, para evitar resolução acidental; reative-os apenas em plataformas controladas de inteligência de ameaças, como MISP, VirusTotal ou seu SIEM. Como a infraestrutura pode ser reatribuída, a ausência de um indicador não descarta atividade.
| IP do VPS (defangado) | Tipo |
|---|---|
| 38.60.250.157 | Nó VPS |
| 95.179.233.79 | Nó VPS |
| 80.240.27.55 | Nó VPS |
| 65.20.103.58 | Nó VPS |
| 208.85.20.79 | Nó VPS |
| 130.94.82.180 | Nó VPS |
| 38.54.124.58 | Nó VPS |
| 208.85.18.18 | Nó VPS |
| 45.32.147.239 | Nó VPS |
| 70.34.208.46 | Nó VPS histórico |
| 130.94.113.184 | Nó VPS histórico |
| 78.141.193.59 | Nó VPS histórico |
Domínios de phishing (defangados): konceptenterprises.com, dnsforward.com, dataclust.com, offtic.com, annastudios-paros.com, cifutura.com, hoaivt.com, dronalms.com, kgsscans.com, soil-management.com e management.daengrentacar.com (página viva observada em /meetings).
Indicadores de aplicação: cabeçalhos HTTP x-evg-token, x-evg-server e x-evg-session; cookies evginx_session, evginx_token, evginx_admin, bigbear_session e bigbear_token. Bots de Telegram associados: @comeandget_bot (administrador, revogado) e os bots de afiliados @botterxyz_bot, @PackingitonG_bot, @donplayer_bot, @bolywan_bot e @rdsxtdytguyg75d_bot.
Como se proteger
Autenticação phishing-resistant. A única forma de MFA que neutraliza estruturalmente o AiTM é a baseada em FIDO2/WebAuthn — chaves de segurança físicas, passkeys ou autenticadores de plataforma como Windows Hello e Face ID. A asserção criptográfica é vinculada ao domínio de origem: no proxy, o navegador vê o domínio falso e a chave se recusa a assinar, porque o origin não corresponde ao registrado. Priorize a implantação para administradores e usuários sensíveis, e trate qualquer tentativa de "rebaixar" para SMS/código como sinal de ataque.
Trate o cookie roubado como incidente de identidade, não como senha vazada. Diante de suspeita, redefina a senha, revogue as sessões ativas e os refresh tokens e force nova autenticação das contas afetadas — no Azure AD, a revogação de tokens invalida o cookie capturado.
Monitore o que acontece depois do login. Regras de encaminhamento de caixa postal criadas do nada, grants de consentimento OAuth para aplicativos desconhecidos, apps com acesso inesperado e atividades de sign-in de IPs residenciais incomuns ou navegadores novos são os rastros típicos de uma sessão sequestrada. Centralizar esses logs em um SIEM, como o Wazuh, e regras de detecção como as SIGMA publicadas pela CloudSEK ajuda a flagrar o replay antes que vire dano.
Encurte a vida das sessões e use Conditional Access. Políticas que exigem dispositivos conformes, sessões com duração curta e alertas para novos navegadores reduzem a janela de uso do cookie roubado. Filtros de e-mail devem inspecionar links que imitam páginas de login mesmo com certificados válidos — o cadeado não é prova de legitimidade.
Para o usuário final. Uma página familiar da Microsoft e um desafio de MFA que funciona não provam que o navegador está conectado diretamente à Microsoft. Confirme solicitações inesperadas de login acessando o serviço por um bookmark confiável ou aplicativo conhecido — nunca pelo link do e-mail.
Conclusão
O BigBear 2.0 demonstra que o MFA tradicional deixou de ser suficiente diante de operações profissionais de phishing por assinatura: não é o código que é quebrado, é a sessão que é roubada — e a infraestrutura de vítimas se espalha por mais de 40 países, com concentração deliberada em fornecedores de TI cujo comprometimento abre caminho para cadeias inteiras de clientes. A defesa eficaz combina autenticação phishing-resistant (FIDO2/WebAuthn), controles de sessão, monitoramento ativo de pós-login e a consciência de que roubo de cookie é incidente de identidade — não problema de senha. Enquanto houver MFA phishable e usuários clicando em links de e-mail, haverá proxies esperando do outro lado.
Perguntas frequentes
O que é o BigBear 2.0?
É uma operação de phishing como serviço (PhaaS) baseada no framework Evilginx2, identificada pela CloudSEK em junho de 2026. Ela usa proxies adversary-in-the-middle para capturar senha, código MFA e cookie de sessão de contas Microsoft 365. O painel da operação continha 5.137 registros de credenciais roubadas de 461 organizações em mais de 40 países.
O que significa PhaaS?
Phishing as a Service, ou phishing como serviço: o operador desenvolve e mantém a infraestrutura de ataque (painel, servidores, phishlets) e a aluga para afiliados, que recebem as credenciais roubadas em tempo real — no caso do BigBear 2.0, via bots de Telegram. É o mesmo modelo de negócio dos ransomware-as-a-service, aplicado ao roubo de contas.
Como o ataque burla o MFA se o código é validado pela Microsoft?
O atacante não quebra nem intercepta o código. O proxy deixa a vítima digitar o código na página legítima da Microsoft (espelhada), a Microsoft valida normalmente e emite o cookie de sessão autenticada — mas o cookie passa pelo proxy antes de chegar ao navegador da vítima, e o atacante o copia. A partir daí, ele importa o cookie no próprio navegador e herda a sessão completa, sem novo desafio de MFA.
O que é um ataque adversary-in-the-middle (AiTM)?
É uma evolução do man-in-the-middle: em vez de interceptar passivamente, o atacante opera um proxy reverso que espelha o site legítimo e retransmite todo o tráfego entre vítima e serviço real em tempo real. No caso do BigBear 2.0, a vítima conversa com a Microsoft de verdade — só que toda a conversa passa pelo atacante, que copia senhas e cookies no caminho.
Por que FIDO2 e WebAuthn resistem ao BigBear 2.0?
Porque a asserção criptográfica é vinculada ao domínio de origem: a chave de segurança só assina para o origin registrado (por exemplo, login.microsoftonline.com). No proxy, o navegador vê o domínio falso, o origin não confere e a autenticação falha. Por isso a operação injeta JavaScript que desativa o suporte a chaves no navegador da vítima, forçando a queda para SMS ou código — métodos phishable.
Como saber se minha organização foi alvo?
Verifique nos logs do Entra ID/Azure AD a atividade de sign-in por IPs residenciais incomuns ou navegadores novos, procure regras de encaminhamento de caixa postal criadas recentemente, grants OAuth para aplicativos desconhecidos e sessões ativas em locais inesperados. Os indicadores publicados (IPs de VPS, domínios, cabeçalhos x-evg- e cookies evginx/bigbear) podem ser correlacionados no SIEM, inclusive com as regras SIGMA da CloudSEK.
O que fazer se um cookie de sessão foi roubado?
Trate como incidente de identidade: redefina a senha da conta afetada, revogue sessões ativas e refresh tokens (a revogação no Azure AD invalida o cookie capturado) e force nova autenticação. Depois, revise regras de encaminhamento, grants OAuth e acessos de aplicativos, e monitore a conta por atividade anômala nas semanas seguintes.
A operação já foi desmantelada?
Não — segundo o relatório, ela ainda estava ativa quando foi publicado. O operador apagou 26 dos 42 VPS do painel desde o fim de julho de 2026, movimento de contramedida forense após a detecção, e a infraestrutura pode ser reatribuída. Por isso os indicadores devem ser monitorados continuamente e a ausência de um IoC não significa ausência de atividade.
Fontes e leituras adicionais
- Cyber Security News — BigBear 2.0 Evilginx2 Phishing Campaign Bypasses Microsoft 365 MFA With Session Cookie Theft — 08/09/2026
- CloudSEK — Tracking BigBear 2.0 Evilginx2 Phishing Campaign — 07/09/2026