Investigadores da Rapid7 Labs documentaram um conjunto de ferramentas de espionagem para Linux até agora desconhecido, construído à volta de um backdoor compilado dentro do próprio balanceador de carga HAProxy da vítima. O toolkit foi identificado em ataques a organizações dos setores automóvel e dos media da Coreia do Sul, recorreu a uma instância de HAProxy batizada «ted backdoor» e a versões trojanizadas de crond, agetty, atd, sshd e polkitd, permitindo execução remota de comandos, injeção de scripts em tráfego web, recolha de credenciais e vigilância de longo prazo. Não existe aqui qualquer falha do HAProxy: o implante não é uma vulnerabilidade do produto e a sua instalação exige execução de código no servidor e a capacidade de substituir o binário em execução.
Resposta rápida: A Rapid7 Labs revelou um toolkit Linux inédito que esconde um backdoor (“ted”) dentro de builds legítimos do HAProxy 2.8.12, acompanhado de um RAT baseado em curl, um keylogger SSH e daemons de sistema trojanizados. A empresa atribui a atividade, com confiança média, a atores estatais norte-coreanos e situa as vítimas nos setores automóvel e dos media sul-coreanos. Não há CVE nem patch aplicável: a defesa passa por verificar a integridade dos binários de servidores de fronteira, correlacionar tráfego a partir de sensores externos ao equipamento e rodar credenciais que tenham passado por esses sistemas.
Um implante que se confunde com a infraestrutura
A característica mais relevante deste caso é a profundidade da integração. Segundo a Rapid7, o ted backdoor é compilado como parte da versão do HAProxy 2.8.12 já existente no ambiente da vítima e utiliza a API nativa de filtros, as pools de memória internas, o agendador de eventos e as funções de gestão de processos do próprio software para intercetar tráfego e escapar à monitorização, enquanto o balanceamento legítimo continua a funcionar normalmente. Os operadores terão obtido execução de código nos servidores de fronteira e substituído o executável legítimo por uma versão modificada.
Ao viver dentro do processo do balanceador, o implante vê o tráfego já desencriptado. O ted liga-se ao processamento HTTP do HAProxy, inspecionando pedidos antes de serem entregues aos serviços de backend, e pode capturar metadados de valor elevado como endereços IP de origem, cabeçalhos Host, Referer, user agents, cookies e tráfego que corresponda a expressões regulares definidas pelo atacante.
Comandos que nunca chegam aos registos
O canal de comando e controlo (C2) é ativado por um pedido aparentemente banal. A Rapid7 verificou que o implante desencadeia comunicações C2 através do endpoint /favorite_list_2x_m500_ico.jpg: quando esse caminho é pedido, o ted interceta a carga útil, encaminha-a por named pipes e impede-a de chegar à aplicação de backend, pelo que o tráfego de comandos fica ausente dos registos aplicacionais. Para reduzir ainda mais a visibilidade, o malware altera os contadores internos de ligações e pedidos do HAProxy, decrementando estatísticas ativas e cumulativas associadas aos seus próprios pedidos. Na prática, nem os registos do backend nem as estatísticas do balanceador guardam vestígio dessas ligações.
curlRAT, keylogger SSH e daemons substituídos
Ao lado do ted operam um keylogger SSH, um RAT baseado em curl e um stager; o RAT mantém uma thread de vigilância dedicada a acompanhar o estado do HAProxy e a reportá-lo à infraestrutura do operador. O curlRAT oferece execução de comandos, descarregamento de payloads, acesso por reverse shell e shell PTY, perfilagem do anfitrião e envio de informação de sistema.
| Componente | Função observada |
|---|---|
ted backdoor (HAProxy 2.8.12) | Interceção de tráfego HTTP já desencriptado através da API de filtros, mantendo o balanceamento legítimo |
curlRAT | Comandos remotos, download de payloads, reverse shell, PTY e recolha de informação do sistema |
sshd trojanizado | Captura de palavras-passe em texto simples guardadas em ficheiro cifrado em /var/lib/sshd/c8c68e629bba773a10ac80012d10bf19 |
| Stager | Só atua com HAProxy ou cron presentes e após verificar privilégios de root; substitui o crond legítimo, copia a data de criação de /usr/bin/ssh e limpa palavras-chave do histórico do root e de seis registos de sistema |
agetty, atd, polkitd | Versões trojanizadas de serviços legítimos usadas no mesmo enquadramento |
A cadeia observada é coerente com uma operação paciente. A partir do ponto de apoio na fronteira da rede, o atacante avança para o interior e coloca o stager em servidores internos; este verifica a presença de crond ou HAProxy antes de instalar o curlRAT, obtido da sua própria secção de dados ou do servidor web de fronteira, enquanto o ted é colocado no balanceador, estabelece o seu canal C2 e permite exfiltração, execução de comandos e injeção de scripts, com o balanceador comprometido a redirecionar silenciosamente ou a servir conteúdo malicioso a clientes selecionados.
Cronologia e atribuição: confiança média, não certeza
| Momento | Facto |
|---|---|
| Novembro de 2024 | Lançamento do build HAProxy 2.8.12-0fdb194, que fixa a data de compilação mais antiga possível para este implante |
| Nov. 2024 – fev. 2025 | Período da Operation SyncHole, campanha do Lazarus documentada pela Kaspersky, em que sites de media sul-coreanos foram comprometidos para redirecionar visitantes |
| Início de 2025 | Data provável do início das campanhas com este toolkit, segundo a Rapid7 |
| Meados de 2025 | Primeiros carregamentos de amostras para o VirusTotal |
| Julho de 2026 | Acesso inicial semelhante reportado pela ENKI WhiteHat, sugerindo que a exploração poderá continuar em curso |
A atribuição deve ser lida com prudência. A Rapid7 atribui o toolkit com confiança média a APT norte-coreanos, com base na vitimologia sul-coreana, no uso de cifra XOR simples e de uma cifra de substituição própria, e no facto de a lista de C2 codificada estar associada ao APT37 pelo ThreatFox e pelo maltrail. A empresa afirma que são necessárias mais provas para uma avaliação mais definitiva. A investigação também não conseguiu estabelecer uma linha temporal firme nem determinar o acesso inicial; ambas as vítimas tinham um servidor web de fronteira com as portas 80, 443 e 25 expostas, com um portal de groupware em 443 e um servidor de correio em 25.
Indicadores de comprometimento
| Tipo | Indicador |
|---|---|
| Domínios C2 | img.darklights.store, img.monderhouse.space, img.smartnords.site, img.responsive.pstatic.autos, img.socialteams.store, img.worksongo.store |
| Ficheiros e caminhos | ~/cache/haproxy-1000.cache, ~/cache/haproxy-1001.cache, /tmp/jasper-log |
| Credenciais capturadas | /var/lib/sshd/c8c68e629bba773a10ac80012d10bf19 |
| Ativação de C2 | Pedidos a /favorite_list_2x_m500_ico.jpg |
Uma ressalva importante para as equipas de resposta a incidentes: os domínios divulgados já não resolvem, pelo que são sobretudo úteis para revisão de registos históricos e não para bloqueio de tráfego em tempo real.
O que fazer: deteção e mitigação
A Rapid7 recomenda correlação de rede, análise comportamental de memória e verificações de integridade dos binários. Há, porém, uma limitação a assumir desde já: o relatório não publica regras de deteção para essa última verificação e um HAProxy recompilado apresenta a mesma string de versão que um build limpo. As medidas práticas passam por:
- Rever sistemas de fronteira que tratem tráfego web, cifra, correio ou módulos em tempo de execução; comparar os binários do HAProxy e dos serviços Linux com versões conhecidas; inspecionar bibliotecas partilhadas inesperadas e alterações no cron; e rodar credenciais que possam ter passado por servidores afetados.
- Recorrer a monitorização de rede independente, uma vez que os registos no equipamento comprometido podem ter sido alterados.
- Investigar pedidos anómalos a caminhos que aparentam ser imagens, ligações de saída inesperadas a partir de balanceadores e respostas web que mudam apenas para determinados visitantes.
- Manter servidores de groupware e de correio atualizados, reduzindo as oportunidades prováveis de entrada.
- Segmentar a rede para limitar o acesso do HAProxy a recursos internos sensíveis e reforçar auditorias de credenciais e autenticação multifator.
Porque é que isto importa em Portugal
Nenhuma vítima portuguesa foi identificada e a campanha é geograficamente circunscrita à Coreia do Sul. A lição, contudo, é transversal: balanceadores de carga, reverse proxies, servidores de correio e portais de colaboração expostos são hoje alvos de primeira linha, precisamente por serem componentes de confiança onde o tráfego surge já desencriptado. Muitas PME portuguesas operam HAProxy, Nginx ou appliances equivalentes na fronteira da rede sem qualquer mecanismo de verificação de integridade dos binários — exatamente o cenário que este toolkit explora.
Há ainda um ângulo de proteção de dados. Um backdoor capaz de recolher cookies de sessão, credenciais e conteúdo de pedidos HTTP representa uma violação de dados pessoais na aceção do RGPD, com obrigação de notificação à CNPD em 72 horas quando existir risco para os titulares — e, se a manipulação de páginas servir malware a visitantes, o impacto estende-se aos clientes da organização. Setores como o automóvel e os media não foram escolhidos ao acaso: propriedade intelectual industrial e acesso a audiências são objetivos clássicos de espionagem estatal, e ambos existem em Portugal.
Perguntas frequentes
O HAProxy tem uma vulnerabilidade que devo corrigir?
Não. Não se trata de uma vulnerabilidade do HAProxy: a instalação do implante exige que o atacante já tenha execução de código no servidor e consiga substituir o binário em execução. Não foi publicado qualquer CVE associado a esta campanha.
Como sei se o meu balanceador foi adulterado?
A Rapid7 aponta para correlação de rede, análise comportamental de memória e verificação de integridade dos binários. Compare os binários instalados com pacotes de origem confiável, verifique o cron e as bibliotecas partilhadas e recolha telemetria de rede a partir de sensores externos ao próprio equipamento.
Quem está por trás desta campanha?
A Rapid7 Labs atribui o conjunto de ferramentas com confiança média a atores estatais norte-coreanos e afirma que são precisas mais provas para uma avaliação definitiva. Existem sobreposições apontadas com infraestrutura associada ao APT37 e com atividade do Lazarus, mas nada está confirmado de forma conclusiva.
Bloquear os domínios divulgados resolve o problema?
Não é suficiente. Os domínios listados deixaram de resolver, servindo sobretudo para pesquisa retroativa em registos históricos e não para bloqueio de tráfego ativo. A prioridade deve ser a verificação de integridade dos servidores de fronteira e a rotação de credenciais.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Rapid7 Labs e por investigadores de segurança que analisaram a campanha.