Malware & Ameaças
Ted: o backdoor que se escondeu dentro do HAProxy
Um proxy funcionando normalmente pode executar um binário adulterado. Entenda o caso Ted, os limites da atribuição e como verificar a integridade da infraestrutura de borda.
O componente que recebe todo o tráfego de uma aplicação também merece investigação quando continua funcionando. O caso Ted chama atenção justamente por isso: o comportamento esperado de um balanceador pode coexistir com uma função clandestina inserida no executável.
Esta análise acompanha uma pesquisa divulgada em 4 de setembro de 2026 e incorpora o esclarecimento posterior do fornecedor. As datas se referem às fontes; a publicação desta matéria é de 6 de outubro de 2026.
O que foi encontrado
A Rapid7 descreveu um kit de espionagem encontrado em duas organizações sul-coreanas dos setores automotivo e de mídia. O Ted foi compilado dentro de uma versão adulterada do HAProxy 2.8.12, utilizando sua API de filtros e estruturas internas. Entre as funções observadas estavam captura de cookies, injeção seletiva de scripts e comunicação clandestina. O conjunto também incluía curlRAT e um keylogger SSH. A atribuição a atores ligados à Coreia do Norte foi feita com confiança média; o acesso inicial e a cronologia completa não foram comprovados. Leia a pesquisa técnica da Rapid7.
Em 21 de setembro, a HAProxy esclareceu que o caso não corresponde a uma vulnerabilidade do produto nem a uma alteração em seus downloads oficiais. O invasor precisava comprometer o servidor antes de substituir o executável legítimo por um build próprio. Essa distinção muda a investigação: atualizar o pacote pode ser necessário, mas não demonstra que o host voltou a ser confiável. Veja o esclarecimento e as orientações de integridade da HAProxy.
Por que um proxy é um alvo tão valioso
Na leitura técnica do NetCatTest, o ponto central é a posição desse processo. Se um proxy termina TLS, ele precisa trabalhar com o conteúdo HTTP já decifrado. O cadeado visto pelo usuário protege o transporte até esse ponto, mas não garante a integridade do programa que processa a mensagem.
Uma avaliação de arquitetura deve perguntar quem pode alterar o binário, modificar o serviço, publicar uma imagem de container ou trocar o pacote instalado. A mesma aplicação pode ter um código bem revisado e ainda depender de uma borda cuja cadeia de implantação não é verificável.
| Camada | Pergunta útil para a investigação |
|---|---|
| Artefato | O executável corresponde ao pacote ou build aprovado? |
| Processo | O serviço iniciou exatamente o arquivo esperado? |
| Implantação | Existe registro verificável da última substituição? |
| Rede | As saídas do host correspondem à sua função? |
Uma rotina prática de verificação
A proposta abaixo é um roteiro de triagem, não um detector exclusivo do Ted. Comece por uma referência obtida fora do servidor investigado: pacote assinado, imagem aprovada ou artefato do pipeline. Um hash calculado apenas no host suspeito registra o estado encontrado, mas não prova que ele é legítimo.
- Identifique o caminho efetivo. Compare a configuração do serviço com o executável usado pelo processo. Evite assumir que o arquivo presente no PATH é o mesmo que está em execução.
- Compare com uma referência confiável. Registre pacote, versão, arquitetura, assinatura e hash. Builds próprios precisam de proveniência e parâmetros de compilação preservados.
- Correlacione fontes independentes. Procure mudanças de implantação, conexões de saída, alterações de permissões e eventos do sistema em registros coletados fora da máquina.
- Preserve antes de substituir. Em uma investigação real, copiar evidências e documentar horários evita perder o material necessário para explicar a adulteração.
Em um laboratório Ubuntu com HAProxy instalado por pacote Debian, duas consultas somente de leitura ajudam a organizar o inventário:
dpkg-query -W -f='${Package} ${Version} ${Architecture}
' haproxy
sha256sum /usr/sbin/haproxyO primeiro comando consulta o cadastro de pacotes; o segundo calcula um hash do arquivo nesse caminho. Nenhum deles, isoladamente, valida o processo em execução, detecta um rootkit ou confirma ausência de comprometimento. Se o caminho for diferente, ajuste-o ao inventário do laboratório.
Como estudar o caso com segurança ofensiva
Um exercício interessante para uma equipe de purple team é criar dois builds benignos em máquinas isoladas: o original e outro com uma alteração inofensiva identificável. O objetivo é medir se a rotina de implantação, integridade e observabilidade percebe a diferença, sem inserir captura de credenciais ou comunicação de comando e controle.
Os critérios de sucesso podem ser simples: identificar o artefato divergente, localizar quem autorizou sua instalação e relacionar o processo com sua referência aprovada. Isso transforma a notícia em uma avaliação concreta da capacidade de detectar substituição de software.
Perguntas frequentes
Instalar a versão mais recente elimina toda a suspeita?
Uma instalação confiável corrige o artefato substituído, mas a investigação ainda precisa determinar como o servidor foi comprometido e quais outros componentes foram alterados.
HTTPS impede um proxy comprometido de observar os dados?
Se o processo termina a conexão TLS, ele participa do processamento do conteúdo decifrado. A proteção do transporte e a integridade do host são verificações complementares.
Como aprofundar a análise de tráfego?
O guia do CatSuite apresenta os módulos de inspeção HTTP. Para o estudo de adulteração de executáveis, mantenha também uma trilha separada de integridade, processo e implantação. A ilustração desta matéria é conceitual e não representa uma captura do incidente.
