Red Menshen usa implantes BPFDoor para espionagem em redes de telecomunicações

Campanha ligada à China mantém acesso furtivo em ambientes de telecomunicações com backdoors passivos no Linux, filtros BPF no núcleo e mecanismos de ativação por tráfego cuidadosamente formatado.

Componente	Ambientes de telecomunicações e sistemas Linux comprometidos com o backdoor BPFDoor, além de frameworks e utilitários como CrossC2, Sliver, TinyShell, keyloggers e ferramentas de força bruta.
Vetor	Acesso inicial por infraestrutura exposta à internet, incluindo serviços de borda como VPNs, firewalls e plataformas web associadas a Ivanti, Cisco, Juniper Networks, Fortinet, VMware, Palo Alto Networks e Apache Struts.
Impacto	Persistência de baixo ruído, abertura de shell remoto mediante pacote de ativação, coleta de credenciais e movimentação lateral controlada entre hosts comprometidos.
Prioridade	Revisar exposição de serviços de borda, procurar implantes passivos em sistemas Linux, correlacionar tráfego HTTPS, ICMP e ativações internas incomuns, e validar sinais de frameworks pós-exploração.
Artefatos	Novas variantes de BPFDoor identificadas como F, G, H, I, J, K e L, com versões principais descritas como httpShell e icmpShell.
Técnica	O implante instala filtro BPF para inspecionar tráfego no núcleo e só reage quando recebe um pacote de ativação com marcador específico, incluindo uma variante que usa a sequência 9999 em deslocamento fixo dentro de requisição aparentemente legítima.

Resumo técnico

Uma campanha de longo prazo atribuída ao cluster Red Menshen, também rastreado como Earth Bluecrow, DecisiveArchitect e Red Dev 18, foi descrita como uma operação de posicionamento estratégico em redes de telecomunicações. A atividade tem foco em espionagem contra redes governamentais e usa a presença em provedores de telecomunicações como ponto privilegiado de observação. O histórico informado aponta operações contra provedores no Oriente Médio e na Ásia desde pelo menos 2021, com ênfase em acesso furtivo, persistência prolongada e baixa emissão de sinais tradicionais de comando e controle.

O elemento central da operação é o BPFDoor, um backdoor Linux que não se comporta como malware convencional com porta aberta ou beacon visível. O implante abusa de recursos Berkeley Packet Filter para observar tráfego diretamente no núcleo do sistema operacional e ativar uma capacidade de shell remoto somente após receber um pacote cuidadosamente formatado. Essa arquitetura reduz sinais óbvios em varreduras de portas, inventários de serviços e monitoramento baseado apenas em conexões periódicas para infraestrutura externa.

Fluxo técnico

As cadeias de ataque começam pela busca de infraestrutura exposta à internet. O contexto descreve serviços de borda como VPNs, firewalls e plataformas web ligadas a Ivanti, Cisco, Juniper Networks, Fortinet, VMware, Palo Alto Networks e Apache Struts como alvos de acesso inicial. Depois do primeiro ponto de apoio, o operador instala componentes compatíveis com Linux para pós-exploração, incluindo CrossC2, Sliver, TinyShell, keyloggers e utilitários de força bruta. O objetivo técnico é transformar o acesso inicial em presença persistente, coleta de credenciais e capacidade de deslocamento entre sistemas internos.

O BPFDoor possui dois componentes principais. O primeiro é o backdoor passivo implantado no host Linux comprometido, responsável por instalar o filtro BPF, observar pacotes de entrada e criar um shell remoto quando o pacote de ativação correto chega. O segundo é um controlador administrado pelo operador. Esse controlador envia os pacotes especiais e também pode operar dentro do próprio ambiente comprometido, disfarçando-se como processos legítimos do sistema. Nesse modo, ele consegue acionar implantes em hosts internos ou abrir listener local para receber conexões de shell, permitindo movimentação lateral com menor dependência de comunicação externa ruidosa.

Uma variante não documentada anteriormente introduz mudanças de evasão voltadas a ambientes corporativos e de telecomunicações modernos. O pacote de ativação passa a ser camuflado em tráfego HTTPS aparentemente legítimo, usando mecanismo de parsing no qual a sequência 9999 aparece em deslocamento fixo na requisição. Essa escolha evita deslocamentos variáveis dentro do conteúdo observado pelo implante e permite que o marcador seja testado em posição previsível. Também foi descrito um mecanismo leve de comunicação por ICMP entre dois hosts infectados, além de variantes nomeadas F, G, H, I, J, K e L e duas famílias principais de túnel, httpShell e icmpShell.

Superfície afetada

A superfície de maior risco combina sistemas Linux em redes de telecomunicações, appliances de alto desempenho, camadas de virtualização, sistemas bare-metal e componentes conteinerizados associados a núcleos 4G e 5G. Esse tipo de ambiente favorece implantes de baixa visibilidade porque concentra tráfego legítimo volumoso, serviços críticos e caminhos internos onde uma conexão isolada ou um pacote de ativação pode parecer parte do ruído operacional.

A exposição inicial não depende de um único produto ou de uma única vulnerabilidade informada no contexto. O ponto comum é a presença de serviços de borda acessíveis pela internet, especialmente VPNs, firewalls e aplicações web. Portanto, a avaliação defensiva precisa tratar a borda como caminho de entrada e os hosts Linux internos como possíveis pontos de persistência, mesmo quando não há beacon periódico, porta nova em escuta ou processo com nome obviamente malicioso.

• Serviços de borda expostos associados a VPNs, firewalls e plataformas web citadas no contexto.
• Hosts Linux dentro de ambientes de telecomunicações que possam receber tráfego de ativação sem manter listener persistente visível.
• Segmentos internos onde um controlador comprometido possa acionar implantes adicionais por pacotes de ativação ou receber shells locais.
• Ambientes com virtualização, bare-metal, appliances de rede e componentes conteinerizados de redes 4G ou 5G.

Hunting e telemetria

A busca defensiva deve partir da hipótese de que não haverá beacon periódico clássico. Em vez de depender apenas de conexões de saída para domínios externos, equipes devem combinar telemetria de endpoint Linux, inspeção de rede, inventário de processos, alterações de filtros de pacote e eventos incomuns de shell. Como o backdoor opera no núcleo via BPF, mudanças inesperadas em filtros, uso anômalo de capacidades associadas a captura de pacotes e processos que interagem com tráfego sem função operacional clara merecem investigação.

No plano de rede, o tráfego HTTPS com padrões de requisição incomuns e o uso de ICMP entre hosts internos devem ser avaliados com cuidado, especialmente quando aparecem em sistemas que não costumam trocar esse tipo de comunicação. A variante que procura marcador em deslocamento fixo não exige publicar payloads para ser caçada; a defesa pode priorizar desvios estatísticos, pares de comunicação raros, ativações seguidas por sessões interativas e correlação temporal entre pacotes de entrada e criação de shell ou processo filho.

• Processos Linux com nomes semelhantes a serviços legítimos, mas sem correspondência com pacotes, unidades de serviço ou baseline do host.
• Uso inesperado de frameworks pós-exploração como CrossC2, Sliver ou backdoors Unix como TinyShell em servidores de telecomunicações.
• Eventos de shell interativo surgindo logo após tráfego externo ou interno incomum, sem autenticação administrativa esperada.
• Tráfego ICMP entre hosts internos que normalmente não usam esse protocolo para comunicação operacional.
• Requisições HTTPS com estrutura anômala, especialmente quando correlacionadas com execução de comandos ou criação de processos no host de destino.

Mitigação

A resposta deve começar pela redução da superfície de borda e pela validação de exposição real dos serviços citados. VPNs, firewalls e plataformas web acessíveis pela internet precisam estar inventariados, atualizados e protegidos por controles de identidade, segmentação e monitoramento compatíveis com ativos críticos. Como o contexto não informa uma vulnerabilidade única, a mitigação não deve assumir apenas aplicação de patch; ela exige revisão de acesso inicial, busca de persistência e validação de credenciais possivelmente coletadas.

Em hosts Linux sensíveis, a contenção deve incluir preservação forense, coleta de memória quando aplicável, revisão de filtros BPF, processos, serviços, conexões, contas locais e artefatos de pós-exploração. Credenciais usadas em sistemas de borda e em servidores internos devem ser rotacionadas quando houver indício de keylogger, força bruta ou acesso interativo não autorizado. A validação final precisa confirmar que não restaram controladores internos capazes de reativar implantes passivos em outros hosts.

• Inventariar e restringir serviços de borda expostos, com prioridade para VPNs, firewalls e plataformas web críticas.
• Caçar BPFDoor e variantes relacionadas em servidores Linux, considerando ausência de porta aberta e de beacon persistente.
• Correlacionar tráfego HTTPS e ICMP incomum com eventos de processo, shell e autenticação nos hosts envolvidos.
• Remover frameworks pós-exploração e backdoors encontrados somente após preservar evidências necessárias para análise.
• Rotacionar credenciais potencialmente capturadas e revisar caminhos de movimentação lateral entre hosts internos.
• Reforçar segmentação entre borda, sistemas de telecomunicações, ambientes virtualizados e componentes de núcleo 4G ou 5G.