LinkPro Linux Rootkit

Um comprometimento recente de um ambiente da Amazon Web Services (AWS) revelou um rootkit GNU/Linux até então não documentado, rastreado como LinkPro. Esse backdoor é notável pelo uso duplo de módulos eBPF: um configurado para ocultar artefatos e outro que atua como um gatilho furtivo — uma "batida" que ativa a funcionalidade de comando remoto somente após a detecção de um pacote TCP especialmente criado. A cadeia de ataque e os mecanismos do rootkit ilustram um operador sofisticado que combina abuso de contêiner, ocultação em nível de kernel e ativação flexível de rede para frustrar a detecção e a correlação forense.

Vetor de infecção e implantação inicial

A intrusão começou com a exploração de uma instância exposta do Jenkins, vulnerável à CVE‑2024‑23897 (CVSS 9.8). A partir dessa base, os invasores implantaram uma imagem maliciosa do Docker (kvlnt/vv, já removida do Docker Hub) em vários clusters do Kubernetes. A imagem usava uma base Kali Linux e continha uma pequena pasta de aplicativo destinada a estabelecer persistência, acesso remoto e um download backdoor em etapas.

Por dentro da imagem maliciosa do Docker

A pasta do aplicativo da imagem continha três arquivos principais com funções distintas:

start.sh — um script de shell que inicia um serviço SSH e executa os outros dois componentes.

link — um programa de código aberto (vnt) compilado/empacotado para atuar como um cliente VPN/proxy, conectando-se a vnt.wherewego[.]top:29872. Isso permite que o invasor alcance o host comprometido de qualquer lugar e se direcione para outros alvos por meio dele.

app — um downloader baseado em Rust (chamado de vGet) que busca uma carga útil vShell criptografada de um bucket S3 e, em seguida, estabelece um link WebSocket para seu servidor de comando e controle (C2) em 56.155.98[.]37.

Cargas adicionais entregues aos nós do Kubernetes

Além da imagem maliciosa, os operadores também instalaram dois outros componentes nos nós: um dropper que instala outro backdoor vShell e o LinkPro, um rootkit escrito em Golang. O LinkPro foi projetado para ser executado em um de dois modos — passivo (reverso) ou ativo (encaminhamento) — dependendo de sua configuração. No modo passivo, ele aguarda a ativação de um pacote de rede especial; no modo ativo, ele inicia o contato com o próprio C2. O modo encaminhamento suporta cinco protocolos de transporte (HTTP, WebSocket, UDP, TCP, DNS), enquanto o modo reverso limita as comunicações ao HTTP.

Como o LinkPro persiste

O comportamento geral de execução e persistência do malware segue uma sequência clara:

• Instale o módulo Hide eBPF. Este módulo inclui os programas Tracepoint e Kretprobe eBPF usados para ocultar os processos e a atividade de rede do LinkPro.
• Se a instalação do módulo Hide eBPF falhar — ou se ele tiver sido desabilitado — instale uma biblioteca compartilhada em /etc/libld.so e adicione esse caminho a /etc/ld.so.preload como um mecanismo de ocultação de fallback.
• Para operação reversa (passiva), instale o módulo Knock eBPF. O Knock contém um programa XDP e um programa TC, de modo que o canal C2 só se torna ativo após receber um "pacote mágico" específico.
• Estabeleça persistência criando um serviço systemd.
• Executar comandos recebidos do C2.
• No desligamento ou quando sinalizado (SIGHUP, SIGINT, SIGTERM), desinstale os módulos eBPF e remova/restaure a modificação de pré-carregamento /etc/libld.so para que o sistema retorne ao seu estado anterior.

O Pacote Mágico e o Mecanismo de Ativação de Knock

A ativação passiva do LinkPro depende de um pacote TCP preciso: qualquer pacote TCP cujo tamanho de janela seja igual a 54321 é tratado como o "pacote mágico". Quando o Knock detecta esse pacote, ele armazena o IP de origem e o marca com uma expiração de uma hora. Os pacotes TCP subsequentes dessa origem são monitorados e, quando apropriado, o Knock reescreve os cabeçalhos para que o tráfego da operadora seja redirecionado para a porta de escuta do LinkPro (2333). Os pacotes de saída são ajustados para apresentar a porta original de volta à rede (porta de origem reescrita para 2233). A intenção é simples, mas eficaz: permitir que o invasor acesse o LinkPro por qualquer porta permitida pelo firewall front-end, dificultando a correlação dos logs externos do firewall com a atividade interna da rede do host.

Como o LinkPro se esconde

O LinkPro usa uma estratégia de ocultação de dois níveis:

Ocultação de kernel/eBPF : O módulo Ocultar eBPF instala programas Tracepoint e Kretprobe que interceptam chamadas de sistema, como getdents (para ocultar arquivos/diretórios) e sys_bpf (para ocultar seus próprios programas BPF). Essa abordagem requer um kernel construído com CONFIG_BPF_KPROBE_OVERRIDE habilitado.

Fallback LD_PRELOAD no espaço do usuário : Se a funcionalidade do kernel não estiver presente, o LinkPro grava uma biblioteca compartilhada (libld.so) e coloca seu caminho em /etc/ld.so.preload. Como /etc/ld.so.preload faz com que a biblioteca especificada seja carregada em todos os processos vinculados dinamicamente (aqueles que usam /lib/ld-linux.so e glibc), o libld.so implantado conecta funções libc antecipadamente (antes do próprio comportamento da glibc) e altera os retornos das chamadas libc para ocultar artefatos que, de outra forma, exporiam sua presença.

Recursos e conjunto de comandos do rootkit

O LinkPro suporta ações remotas interativas e automatizadas. Seus recursos implementados incluem:

• Iniciando um pseudoterminal /bin/bash e executando sessões de shell interativas.
• Executando comandos de shell arbitrários.
• Enumerar arquivos e diretórios e executar operações de arquivo.
• Baixando e gravando arquivos no disco.
• Estabelecendo um túnel proxy SOCKS5 para pivotamento e proxy de subsistência.

Suporte ao protocolo de rede e comportamento C2

No modo ativo (encaminhamento), o LinkPro é flexível: pode se comunicar usando transportes HTTP, WebSocket, UDP, TCP ou DNS. No modo passivo (reverso), sua comunicação é restrita a HTTP, mas se beneficia da furtividade, pois só escuta depois que o pacote mágico Knock abre uma janela de comando temporária de uma hora.

Comportamento de limpeza e desinstalação

Se o processo receber sinais de encerramento, o LinkPro visa remover rastros: ele desinstala os módulos eBPF instalados e exclui ou restaura o /etc/libld, reagrupando-o ao seu estado anterior para que o sistema pareça inalterado. Essa rotina de limpeza deliberada indica um operador preocupado com a evasão e com a minimização de rastros forenses a longo prazo.

Contexto Operacional e Atribuição

A campanha utilizou um exploit Jenkins de alta gravidade, imagens de contêiner maliciosas, diversas variantes de backdoor e furtividade em nível de kernel — uma combinação que aponta para um operador motivado e capaz. Nenhuma atribuição definitiva foi tornada pública; no entanto, o conjunto de ferramentas e o aparente uso do comprometimento para proxy e acesso remoto persistente sugerem fortemente atividades com motivação financeira (pivot, proxy para intrusões adicionais ou revenda de acesso).

Dependência do kernel e comportamento de fallback

Como o LinkPro depende dos recursos de substituição do BPF kprobe para sua interceptação furtiva do kernel, ele só aplica a técnica de ocultação em nível de kernel quando o kernel do host expõe CONFIG_BPF_KPROBE_OVERRIDE. Quando esse recurso do kernel está ausente, o LinkPro recorre deliberadamente ao método de biblioteca compartilhada LD_PRELOAD para se ocultar no espaço do usuário, garantindo a ocultação em uma ampla gama de ambientes.

Nota de Encerramento

O LinkPro demonstra como intrusões modernas podem combinar comprometimento de contêineres, carregadores em estágios, instrumentação de kernel (eBPF) e truques de rede inteligentes (ativação de pacotes mágicos e reescrita de portas) para manter a discrição e a flexibilidade. A detecção e a correção exigem uma inspeção cuidadosa em busca de programas eBPF não autorizados, entradas inesperadas em /etc/ld.so.preload, serviços systemd incomuns e conexões de rede com a infraestrutura indicada (os indicadores forenses incluem o IP 56.155.98[.]37, as portas 29872, 2333, 2233 e o nome da imagem Docker removida kvlnt/vv).