Rastreando a campanha de phishing BigBear 2.0 Evilginx2

Resumo Executivo

Em junho de 2026, a TRIAD da CloudSEK descobriu o BigBear 2.0, uma estrutura de phishing-as-a-service baseada no Evilginx2 e renomeada, e conseguiu obter acesso administrativo ao painel do agente de ameaças. Observou-se que o painel gerenciava 42 nós VPS durante o ciclo de vida da campanha — hospedados principalmente pela The Constant Company LLC (Vultr) — configurados com o phishlet "offy", voltado exclusivamente ao Microsoft 365. O operador, usando o pseudônimo "General Boss", implantou pools de proxies residenciais com correspondência geográfica, exfiltração em tempo real via Telegram e reprodução automatizada de cookies para contornar o MFA e manter acesso persistente.

O painel exfiltrou 5.137 registros de credenciais — incluindo 474 autenticações completas com MFA contornado, 1.032 senhas em texto simples e 4.148 cookies de sessão — afetando 3.331 IPs de vítimas únicas em mais de 40 países (com destaque para Índia, França, Arábia Saudita, Nova Zelândia e Alemanha), sendo que a operação ainda estava ativa no momento da redação deste documento. O painel multiusuário de PhaaS é alugado para pelo menos cinco operadores afiliados identificados por meio de bots de exfiltração ao vivo no Telegram, cada um recebendo credenciais roubadas em tempo real; injeções personalizadas de JavaScript desativam o MFA FIDO2/WebAuthn e pools de proxies residenciais contornam a detecção anti-bot do ipapi.is. Usando esses recursos, o atacante manipula o fluxo de autenticação para que a vítima acabe usando um método de autenticação alternativo que seja mais fraco ou não resistente a phishing. Desde o final de julho de 2026, o agente de ameaças excluiu 26 dos 42 nós VPS observados no painel — uma evidência de operações ativas de contra-forense em resposta à detecção.

Estatísticas da Campanha

Contexto: Evilginx2 e Adversary-in-the-Middle (AiTM)

2.1 Configuração do Phishlet (Evilginx2 "offy")

O phishlet padrão do painel BigBear — designado como "offy" — está configurado para interceptar a autenticação do Microsoft 365. Os phishlets do Evilginx2 operam como proxies man-in-the-middle (AiTM): quando uma vítima acessa a URL de phishing, o mecanismo faz o proxy de todo o tráfego entre a vítima e o portal de login legítimo da Microsoft (login.microsoftonline.com), capturando cada envio de credencial e cookie de sessão em trânsito.

Principais características do phishlet observadas na configuração do painel:

• Modelo de subdomínio: <custom>.<phishing-domain> (por exemplo, login.konceptenterprises[.]com)
• SSL Let's Encrypt provisionado automaticamente via desafio HTTP-01 em cada subdomínio
• DNS wildcard necessário — *.phishing-domain aponta para o IP do VPS
• Intercepção de MFA: O Evilginx2 captura o cookie de sessão (token MFA) após a vítima concluir o segundo fator, permitindo acesso persistente sem a necessidade do código de uso único
• O phishlet "offy" tem como alvo específico o fluxo de autorização OAuth 2.0 usado pelo Microsoft 365, tornando-o eficaz contra qualquer organização que utilize Azure AD / Entra ID para autenticação

2.2 Mecanismo de Relay AiTM

A técnica central empregada é o phishing Adversary-in-the-Middle (AiTM). Ao contrário do phishing clássico que captura apenas senhas, o proxy reverso do Evilginx2 retransmite toda a sessão:

1. Passo 1: A vítima clica no link de phishing (geralmente enviado por e-mail) e é redirecionada via proxy para a página de login legítima da Microsoft.
2. Passo 2: A vítima insere o e-mail → o proxy captura o dado e o encaminha para a Microsoft.
3. Passo 3: A vítima insere a senha → o proxy captura o texto simples E encaminha para a Microsoft.
4. Passo 4: A vítima conclui o MFA (TOTP, notificação push, SMS) → o token de sessão emitido pela Microsoft é capturado pelo proxy.
5. Passo 5: O atacante replica o cookie de sessão capturado para acessar a caixa de entrada, Teams, SharePoint e todos os aplicativos SaaS conectados da vítima — sem disparar uma nova autenticação.

As métricas do próprio painel confirmam essa eficácia: 80% das inserções de senha resultaram na captura do cookie de sessão, e a taxa de conversão de senha para conclusão excedeu 100%, indicando que o relay AiTM capturou tokens de sessão mesmo sem a inserção explícita de senha em alguns casos.

2.3 Pool de Proxy com Correspondência Geográfica para Evasão

Um facilitador crítico para a isca do O365 é a integração de proxy residencial do painel. O BigBear 2.0 implanta 69 proxies residenciais específicos por país que correspondem automaticamente à geolocalização do visitante. Quando uma vítima na Índia acessa a página de phishing, o mecanismo roteia o tráfego de upstream para a Microsoft através de um endereço IP residencial indiano. Isso:

• Faz com que o tráfego pareça um login legítimo vindo do país da vítima
• Ignora a detecção de anomalia geográfica da Microsoft (login de local incomum)
• Supera listas de bloqueio de IP de datacenters/VPN/proxy por meio da integração com ipapi.is
• Aumenta a probabilidade de cumprimento das políticas de acesso condicional

Atribuição pelo Modelo Diamante

O Modelo Diamante de Análise de Intrusão fornece uma estrutura organizada para compreender esta campanha através de quatro vértices principais: Adversário, Infraestrutura, Capacidade e Vítima.

Resumo do Perfil do Adversário

O adversário (conhecido como "General Boss") opera um modelo de Phishing-as-a-Service com pelo menos 5 operadores afiliados identificados que recebem credenciais roubadas via bots dedicados no Telegram. O adversário apresenta um perfil cibercriminoso, e não de um grupo patrocinado por Estado:

• Modelo de negócio Phishing-as-a-Service — painel multiusuário com funções de administrador/usuário. Cinco tokens de bot do Telegram distintos, atribuídos a diferentes grupos de VPS, confirmam que a infraestrutura foi alugada para atores afiliados ou suboperadores, cada um recebendo a exfiltração de credenciais em seu próprio chat do Telegram.
• Nenhuma evasão avançada além dos padrões do Evilginx2 (nenhum rootkit personalizado ou LOLBins observados)
• Monetização provavelmente via corretagem de acesso inicial — cookies de sessão permitem a implementação de ransomware, extorsão de dados ou campanhas de BEC contra organizações vítimas
• O token do bot do Telegram e os metadados do painel não coincidiram com grupos APT conhecidos em inteligência de código aberto. No entanto, a sondagem em tempo real dos tokens dos bots identificou com sucesso 5 usuários do Telegram recebendo ativamente credenciais roubadas — estes são operadores afiliados que utilizam a plataforma PhaaS BigBear 2.0.

Operadores Afiliados Identificados

A sondagem da API do bot do Telegram em tempo real confirmou 5 operadores afiliados ativos recebendo credenciais roubadas. Cada operador controlava um ou mais nós VPS. A tabela abaixo mapeia as identidades do Telegram, tokens de bot, padrões de uso e a infraestrutura VPS específica atribuída a cada operador.

Nota de Estrutura: O user_id 5 do painel funciona como um nível de revendedor com dois operadores subordinados (@Sunagashison com 4 nós, @app_ham com 3 nós). O user_id 6 do painel hospeda, de forma semelhante, dois operadores (@donplayer00, @Mazal100). O user_id 3 (VPS "Kingkong") corresponde ao bot administrador principal @comeandget_bot (revogado). O user_id 2 ("FATHOM") é um afiliado individual.

Análise

Escala da Campanha e Maturidade Operacional

Infraestrutura VPS com múltiplos nós (42 nós) com gerenciamento centralizado via painel — todos os nós hospedados pela The Constant Company LLC (Vultr), indicando um relacionamento comercial em vez de hosts comprometidos.

Pipeline automatizado de processamento de credenciais: 

captura → notificação no Telegram → anexo de arquivo cookie.js → motor de reprodução da API de Cookies. Este pipeline totalmente automatizado permite o sequestro de sessão em tempo quase real.

O pool de proxies residenciais (69 países) representa um investimento operacional significativo — proxies residenciais custam de US$ 10 a US$ 50/GB e exigem relacionamento com provedores de proxy. O recurso de correspondência geográfica automática indica um software de gerenciamento de pool de proxy personalizado, que vai além dos recursos padrão do Evilginx2.

Medidas anti-análise: a integração com ipapi.is bloqueia pesquisadores que utilizam VPNs/datacenters. Durante a análise, o painel só estava acessível via IPs residenciais, e vários nós VPS foram configurados com respostas de erro de autenticação para tentativas de sondagem.

Notificações em tempo real no Telegram com formato de webhook estruturado permitem o processamento automatizado a jusante por operadores afiliados. O bot do Telegram comeandget_bot[@]telegram serve como o principal canal de Comando e Controle (C2) para a exfiltração de credenciais.

Análise de Vitimologia e Segmentação

Análise da concentração na Índia: A Índia é o país mais visado, com 658 registros (12,8% do total de 5137), seguida pela França (463, 9,0%) e Arábia Saudita (353, ~6%). Isso é amplamente proporcional à participação da Índia nas licenças globais do Microsoft 365 (~8–10%). As explicações incluem: (a) aquisição de listas de e-mails corporativos indianos de corretores de dados, (b) menor adoção de MFA resistente a phishing em PMEs indianas, (c) uso de iscas em inglês que ressoam com a força de trabalho proficiente em inglês da Índia e (d) presença significativa do setor de TI/Software na Índia, fornecendo alvos de alto valor.

Justificativa da segmentação por setor: Serviços de TI/MSP (151 organizações) foi o setor alvo dominante, seguido por SaaS/Tecnologia (38), Petróleo e Gás (22), Farmacêutico (20) e Consultoria (16). Provedores de serviços de TI são alvos de alto valor porque:
(a) eles gerenciam a infraestrutura do cliente — o comprometimento de um único provedor de TI pode permitir ataques à cadeia de suprimentos contra dezenas de clientes a jusante,
(b) a equipe de TI geralmente tem acesso privilegiado ao Azure AD, AD local, ferramentas RMM e gerenciadores de senhas.

Spray-and-pray vs. segmentação direcionada: A ampla distribuição setorial (outros/misto (incluindo Desconhecido)), juntamente com a segmentação concentrada no setor de TI, sugere que o invasor utilizou tanto o envio em massa de listas de e-mail (baseado em volume) quanto listas específicas do setor (baseado em qualidade). Os 438 domínios exclusivos abrangendo mais de 40 países sustentam um modelo de segmentação híbrido.

Evolução da campanha: A exportação original do painel — primeira detecção (1.442 registros) — mostrou segmentação principalmente indiana e europeia. Desde então, a campanha expandiu-se para 5.137 registros totais em 42 nós VPS, com exportações posteriores adicionando organizações com novos nós VPS (29.06 KALA, Kingkong) e novas organizações vítimas, indicando que a campanha estava expandindo ativamente sua infraestrutura e escopo de segmentação.

Análise do Backdoor JS personalizado BigBear 2.0

A análise da página de phishing do M365 ativa capturada em management[.]daengrentacar[.]com/meetings revelou três injeções de JavaScript proprietárias aplicadas em cada página de login via proxy. Elas não estão presentes no Evilginx2 padrão: 2014 são modificações personalizadas do BigBear 2.0.

Injeção 1: 2014 Desativação do FIDO2/WebAuthn

window.__bb_fido_down = true;

Object.defineProperty(window, 'PublicKeyCredential', { value: undefined });

Aplica monkey-patch em navigator.credentials.get/create para rejeitar opções publicKey.

Força usuários de chaves de segurança de hardware a recorrerem a MFA suscetível a phishing (SMS/OTP/TOTP).

‍

Injeção 2: Bloqueio de Telemetria Anti-Phishing da Microsoft de 2014

Lista de bloqueio: ['canarytokens', 'events.data.microsoft.com', 'OneCollector']

Modifica window.fetch + XMLHttpRequest para descartar silenciosamente solicitações correspondentes.

MutationObserver remove tags <img> correspondentes.

Impede que a Microsoft detecte phishing em curso via telemetria/canary tokens.

‍

Injeção 3: Auto-KMSI (Manter-me conectado) de 2014

Marca automaticamente #KmsiCheckboxField após o carregamento da página.

Clica em idSIButton9 após um atraso de 800ms.

Maximiza o tempo de vida do cookie de sessão para acesso estendido.

Análise de Infraestrutura Técnica

Terminação TLS no proxy: Cada instância do Evilginx2 termina a conexão TLS da vítima no domínio de phishing (usando certificados Let's Encrypt). O proxy então inicia uma NOVA conexão TLS com o servidor real da Microsoft. Isso significa que: (a) a vítima vê um cadeado HTTPS válido, (b) o proxy corporativo/inspeção SSL da vítima não consegue ver o tráfego para a Microsoft (ele é criptografado entre o Evilginx2 e a Microsoft), e (c) os servidores da Microsoft veem o IP da VPS, não o IP da vítima.

Integração anti-bot ipapi.is: O painel verifica o IP de cada visitante no ipapi.is antes de exibir a página de phishing. Se o IP for de um datacenter, VPN ou proxy, o visitante é bloqueado. Isso impede efetivamente a raspagem automatizada, a análise por pesquisadores de segurança e a detecção por sandbox. Durante a análise, o painel só estava acessível ao rotear o tráfego através de um IP residencial.

Arquitetura de painel multiusuário: O painel oferece suporte a acesso baseado em funções (usuário/administrador). Usuários administradores podem visualizar todos os nós de VPS e credenciais de todos os usuários locatários. Esse design multilocatário é consistente com o modelo de negócios de Phishing-as-a-Service (PhaaS), no qual o operador da infraestrutura aluga o acesso para agentes afiliados.

Streaming de logs do motor: O painel fornece streaming em tempo real via SSE (Server-Sent Events) dos logs do motor Evilginx2 diretamente no navegador. Isso permite que os operadores monitorem sessões de phishing ativas conforme elas ocorrem, incluindo solicitações de URL, envio de credenciais e captura de cookies com latência de milissegundos.

Mecânicas de desvio de MFA — Análise técnica aprofundada

O desvio de MFA do Evilginx2 não é uma vulnerabilidade em nenhum protocolo de MFA — é uma limitação arquitetônica de como a autenticação baseada em navegador funciona. Os detalhes a seguir explicam por que todos os métodos de MFA existentes (exceto FIDO2/WebAuthn) são igualmente suscetíveis:

Mecânicas de interceptação de cookies: Quando a vítima conclui a MFA na página de login via proxy, a Microsoft emite um cookie de autenticação (ESTSAUTH para Azure AD, AppSessionId para Outlook Web Access) no cabeçalho Set-Cookie da resposta HTTP. Como todo o tráfego flui através do proxy do Evilginx2, o servidor envia essa resposta ao Evilginx2 antes que ela chegue ao navegador da vítima. O Evilginx2 captura o cookie, armazena-o no banco de dados do painel e, opcionalmente, encaminha uma resposta modificada para a vítima (ou redireciona-a para outlook.office.com como disfarce).

Estrutura do cookie ESTSAUTH: O cookie ESTSAUTH é um token de sessão emitido pela Microsoft que contém declarações criptografadas sobre o evento de autenticação — incluindo a confirmação de que a MFA foi concluída. Este cookie está vinculado à sessão do navegador, mas NÃO a um dispositivo ou local específico. Um invasor que importa este cookie para seu próprio navegador herda a sessão totalmente autenticada com todos os direitos de acesso associados.

Por que TOTP/push são desviados: Senhas de uso único baseadas em tempo (TOTP) e notificações push de MFA verificam a posse de um dispositivo confiável pelo usuário no momento do login. O proxy não precisa derrotar o desafio criptográfico — ele simplesmente aguarda que o usuário o conclua na página de autenticação legítima da Microsoft (que a vítima vê através do proxy) e, em seguida, intercepta o token de sessão emitido como resultado. O invasor nunca vê nem precisa do código TOTP.

Desvio de MFA por SMS: Códigos SMS são igualmente ineficazes — o código é inserido na página de phishing (que faz proxy para a Microsoft), a Microsoft valida o código no servidor e emite o cookie de sessão que o Evilginx2 captura. O invasor nunca precisa saber o código SMS para sequestrar a sessão.

Por que o FIDO2/WebAuthn é resistente: O FIDO2 (chaves de segurança de hardware, autenticadores de plataforma como Apple Face ID / Windows Hello) utiliza credenciais vinculadas à origem. A asserção criptográfica está atrelada ao domínio de origem (por exemplo, login.microsoftonline.com). Quando o Evilginx2 faz o proxy do tráfego, a origem vista pelo navegador é o domínio de phishing (login.evil-domain.com), e não o domínio real da Microsoft. A asserção FIDO2 falha porque a origem não corresponde à origem registrada da credencial. Este é o único método de MFA que impede estruturalmente o phishing AiTM.

Replay de cookies e persistência de sessão

Mecanismo de keepalive: O painel inclui um recurso de keepalive que atualiza periodicamente os cookies de sessão capturados reutilizando o token de atualização, estendendo a janela de acesso além da expiração inicial do cookie (geralmente de 1 a 24 horas para tokens de sessão da Microsoft).

Automação via API de cookies: O BigBear 2.0 expõe um endpoint de API REST (/api/jobs) que aceita cookies capturados e os reproduz automaticamente contra o serviço alvo. Isso permite o sequestro de sessão em massa e programático, sem a necessidade de intervenção manual no navegador.

Roubo de token de atualização: Quando o Evilginx2 captura o cookie de sessão, ele frequentemente obtém também o token de atualização. Os tokens de atualização da Microsoft são geralmente válidos por 90 dias (com janela deslizante), permitindo acesso persistente mesmo após a expiração da sessão inicial.

Movimentação lateral pós-comprometimento: Com um cookie de sessão válido, o invasor pode acessar o portal do Entra ID, enumerar aplicativos com permissões delegadas (concessões de consentimento OAuth) e potencialmente migrar para recursos em nuvem (Azure, AWS, Salesforce) conectados via SSO.

Lacunas de detecção e análise de evasão

Lacuna na telemetria de logs: Como o proxy encerra o TLS no domínio de phishing, o IP real da vítima nunca chega à Microsoft. Qualquer log de entrada no Entra ID mostra o IP do VPS (proxy residencial), e não o IP do invasor, dificultando a atribuição forense.

Burlar o Acesso Condicional: Proxies residenciais com geolocalização correspondente superam as políticas de AC baseadas em localização. As políticas de conformidade de dispositivo não são avaliadas porque o proxy se apresenta como uma nova sessão de navegador.

Irrelevância do método de MFA: TOTP, notificação push, SMS e até mesmo MFA por chamada de voz são igualmente vulneráveis — o proxy captura o cookie de sessão resultante independentemente do tipo de MFA.

Evasão de gateway de e-mail: As URLs de phishing usam domínios legítimos (comprometidos ou semelhantes) com certificados SSL válidos. Sem análise de reputação de URL, a maioria dos gateways de e-mail permite esses links.

Avaliação de impacto

Exposição de credenciais

Os 5.137 registros do painel incluem 474 sessões completas com bypass total de MFA, 1.032 senhas em texto simples e 4.148 cookies de sessão em 461 organizações. Cada sessão completa representa uma conta do Microsoft 365 totalmente comprometida com potencial acesso a:

• E-mail e calendário (tomada de conta de e-mail — BEC, roubo de dados, phishing interno)
• Microsoft Teams (comprometimento de canal de comunicação persistente)
• SharePoint Online e OneDrive (roubo de documentos e propriedade intelectual)
• Azure AD / Entra ID (potencial movimentação lateral para a infraestrutura em nuvem)
• Aplicações SaaS conectadas (CRM, ERP, sistemas de RH federados via Azure AD)

Impacto nos negócios

• Fraude financeira: Contas de e-mail comprometidas permitem ataques de BEC (Comprometimento de E-mail Corporativo) contra parceiros, fornecedores e clientes — a perda média por incidente de BEC supera US$ 100 mil
• Violação de dados: O acesso ao SharePoint/OneDrive expõe dados comerciais confidenciais, incluindo contratos, registros financeiros, propriedade intelectual e PII
• Risco na cadeia de suprimentos: Provedores de TI/Software comprometidos nesta campanha criam um risco indireto para as organizações clientes
• Exposição regulatória: GDPR (UE), Lei DPDP (Índia), CCPA (Califórnia) e outros regulamentos de proteção de dados impõem penalidades significativas para violações baseadas em credenciais
• Vetor de ransomware: O acesso a cookies de sessão é frequentemente utilizado como um vetor de acesso inicial para a implantação de ransomware

Distribuição do impacto geográfico

Distribuição por setor 

Mapeamento MITRE ATT&CK

Indicadores de Comprometimento (IOCs)

Indicadores de aplicação
   - Cabeçalho HTTP: "x-evg-token", "x-evg-server", "x-evg-session"
  - Cookie: "evginx_session", "evginx_token", "evginx_admin"
  - Cookie: "bigbear_session", "bigbear_token"

Mitigações

• Redefinir senhas afetadas
• Revogar tokens de sessão e de atualização
• Forçar a reautenticação do usuário
• Habilitar MFA resistente a phishing - FIDO2 ou WebAuthn
• Impor Acesso Condicional
• Exigir dispositivos compatíveis

‍Regras SIGMA

title: Evilginx BigBear Session Cookies
id: 0b8d50f4-fc0f-4ef5-9001
status: stable
description: Detects known Evilginx and BigBear session cookies.

logsource:
  category: webserver

detection:
  selection:
    http_cookie|contains:
      - "evginx_session"
      - "bigbear_session"
      - "evginx_admin"

  condition: selection

falsepositives:
  - Unknown

level: high

tags:
  - attack.credential-access

title: Communication With Known Evilginx Infrastructure
id: 0b8d50f4-fc0f-4ef5-9002
status: experimental
description: Detects outbound communication to known Evilginx infrastructure.

logsource:
  category: network_connection

detection:
  selection:
    destination_ip:
      - 130.94.82.180
      - 70.34.208.46
      - 130.94.113.184
      - 78.141.193.59
      - 64.176.72.180
      - 38.54.124.58
      - 208.85.18.18

  condition: selection

falsepositives:
  - IP reassignment

level: critical

tags:
  - attack.command-and-control

title: Evilginx Custom Headers
id: 0b8d50f4-fc0f-4ef5-9003
status: experimental
description: Detects uncommon Evilginx-specific HTTP headers.

logsource:
  category: proxy

detection:
  selection:
    http_headers|contains:
      - "x-evg-"

  condition: selection

falsepositives:
  - Unknown

level: high

tags:
  - attack.credential-access


title: Telegram Credential Exfiltration
id: 0b8d50f4-fc0f-4ef5-9004
status: experimental

logsource:
  category: proxy

detection:
  telegram:
    url|contains: "api.telegram.org"

  methods:
    url|contains:
      - "/sendMessage"
      - "/sendDocument"

  secrets:
    http_request_body|contains:
      - "cookie"
      - "session"
      - "password"
      - "credential"

  condition: telegram and methods and 1 of secrets

falsepositives:
  - Approved Telegram automation

level: critical

tags:
  - attack.exfiltration

title: Multiple Evilginx Indicators
id: 0b8d50f4-fc0f-4ef5-9005
status: stable

logsource:
  category: webserver

detection:
  cookies:
    http_cookie|contains:
      - "evginx_session"
      - "bigbear_session"

  headers:
    http_headers|contains:
      - "x-evg-"

  condition: cookies and headers

falsepositives:
  - Unknown

level: critical

tags:
  - attack.credential-access

Referências

• *Fonte de inteligência e confiabilidade da informação - Wikipedia
• ^#Protocolo de Semáforo (TLP) - Wikipedia