Espionagem silenciosa: Coreia do Norte compila backdoor dentro do HAProxy das vítimas e intercepta o tráfego web

Notícia

Espionagem silenciosa: Coreia do Norte compila backdoor dentro do HAProxy das vítimas e intercepta o tráfego web

Rodrigo ColissiRodrigo Colissi
08 de setembro de 202614 min de leitura
CibercrimesThreat Intelligence

Introdução

Pesquisadores da Rapid7 (empresa de segurança e inteligência de ameaças) identificaram uma operação de espionagem digital atribuída com confiança média à Coreia do Norte que vem atingindo, desde o início de 2025, organizações de mídia e do setor automotivo na Coreia do Sul. Diferente de campanhas barulhentas, o toolkit batizado de ted backdoor foi compilado dentro de uma versão legítima do HAProxy (balanceador de carga e proxy open source), o software que as próprias vítimas usam para distribuir o tráfego web, e passou despercebido enquanto interceptava sessões, capturava credenciais e injetava scripts maliciosos nas páginas servidas.

O achado foi divulgado em relatório da Rapid7 Labs compartilhado com o Cyber Security News em 7 de setembro, e detalha um conjunto de ferramentas desenhado para permanência de longo prazo: além do backdoor no balanceador, a operação usou um keylogger SSH, binários de sistema trojanizados e um RAT (Remote Access Trojan — trojan de acesso remoto) chamado CurlRAT, que fazia contato periódico com os servidores de comando dos atacantes.

Contexto: espionagem setorial na Coreia do Sul

A escolha de alvos não é aleatória. Empresas de mídia e montadoras sul-coreanas têm valor estratégico para programas de inteligência da Coreia do Norte, que historicamente coletam informações sobre tecnologia, política e economia da região. O padrão da campanha — roubo de credenciais, coleta de sessões web, alteração seletiva de páginas e redirecionamento de tráfego — aponta para espionagem persistente, não para extorsão ou vandalismo.

Nas duas organizações analisadas, as vítimas rodavam um servidor de borda (edge server — máquina na fronteira da rede que recebe tráfego externo) com as portas 80, 443 e 25 expostas: a porta 443 hospedava o portal de login de um groupware (plataforma de colaboração corporativa, como e-mail, calendário e documentos compartilhados) e a porta 25 expunha o servidor de correio. Esse é um vetor de entrada plausível — mas a Rapid7 ressalta que o ponto exato de acesso inicial e a eventual vulnerabilidade explorada ainda não foram confirmados. O que se sabe é que o comprometimento de um servidor de borda é grave por natureza: quem controla essa máquina observa o tráfego que passa por ela, coleta credenciais de quem a acessa e ganha uma ponte para a rede interna.

Como o toolkit ataca: do acesso inicial ao balanceador trojanizado

A operação avançou em etapas encadeadas, começando pela entrada na rede e terminando em espionagem contínua. Abaixo, o fluxo resumido da cadeia de ataque, detalhado em seguida.

Cadeia de ataque

Acesso inicialgroupware / mail serverEdge serverbalanceador HAProxyted backdoorcompilado no binárioIntercepta HTTPsessões + injeçãoCurlRATC2 por pollingEspionagemlongo prazo

O acesso inicial pelo groupware e servidor de e-mail

O primeiro passo da cadeia foi obter uma posição inicial na DMZ (zona desmilitarizada — segmento de rede que isola serviços expostos da rede interna), provavelmente explorando o portal de login do groupware ou o servidor de correio expostos na borda. Esse comportamento é consistente com o modus operandi de APTs norte-coreanos: no início de 2026, por exemplo, o grupo Kimsuky foi observado explorando vulnerabilidades de execução remota de código em servidores de e-mail acessíveis externamente para comprometer fornecedores de groupware sul-coreanos.

De posse do servidor de borda, os atacantes instalaram persistência e passaram a colher credenciais na própria máquina — com um keylogger no serviço SSH — enquanto ela servia de base de preparo para os binários trojanizados que seriam distribuídos para a rede interna. Em seguida, um stager (programa pequeno que baixa e instala a carga principal) era despejado em servidores internos: ele verificava o sistema operacional e a presença de cron ou HAProxy e só então implantava o CurlRAT, buscando o payload embutido na própria seção de dados ou no servidor de borda comprometido.

ted backdoor: um implante compilado dentro do HAProxy

O coração da operação é o ted backdoor, um HAProxy 2.8.12 substituído por uma build modificada com o implante compilado diretamente dentro do binário — não como um processo separado que poderia ser detectado. O implante usa a API de filtros nativa do balanceador, os pools de memória internos, o agendador de eventos e a infraestrutura de gerenciamento de processos do próprio HAProxy para se conectar ao parser HTTP e inspecionar o tráfego descriptografado, enquanto o balanceamento de carga legítimo continua funcionando normalmente.

Esse posicionamento dá aos operadores controle raro: o backdoor captura session cookies (identificadores de sessão que mantêm o usuário logado) e detalhes de requisições selecionadas, executa comandos no servidor, sobe e baixa arquivos e ainda escolhe, com base no IP do cliente, se vai injetar um script malicioso na página renderizada para aquele visitante específico — configurando uma armadilha do tipo watering hole (envenenamento de páginas frequentadas pelas vítimas). Para se esconder do monitoramento, o implante reduz os contadores de conexão do HAProxy, mascarando a própria atividade nas estatísticas do serviço. O canal de comando oculto usa uma requisição a um caminho com aparência de imagem.

CurlRAT: a camada de comando e controle

Acompanhando o backdoor está o CurlRAT, a camada de controle remoto. Ao contrário de RATs de uso geral que circulam em fóruns, como o XWORM, o CurlRAT é um componente sob medida: ele faz polling (verificação periódica de novas instruções) no servidor de comando e controle (C2) a cada 43.200 segundos — 12 horas —, com um modo rápido que reduz o intervalo para 30 segundos quando ativado pelo operador. Cada ciclo baixa um arquivo de configuração via HTTPS (com fallback para HTTP), usando o protocolo libcurl, e o autentica com um token embutido e o identificador da vítima no cabeçalho da requisição.

As instruções recebidas selecionam, por um byte de modo, uma de seis rotinas: executar comandos no shell com saída capturada, gravar nova configuração, baixar e instalar payloads adicionais, abrir um reverse shell (shell que conecta de volta ao atacante) com privilégios elevados via chamadas de sistema que forçam o usuário root, enviar um beacon com informações do sistema ou abrir um shell interativo completo com PTY (pseudo-terminal — interface de terminal interativa). Toda a comunicação é codificada com um cifrador XOR de realimentação seguido de Base64. Uma thread separada atua como watchdog do HAProxy: a cada hora lê o PID em /var/run/haproxy.pid e reporta ao C2 se o serviço iniciou, parou, reiniciou ou recarregou — dando aos atacantes visibilidade sobre qualquer tentativa de intervenção na infraestrutura.

Keylogger SSH, stager e binários trojanizados

O toolkit ainda inclui um keylogger no SSH que intercepta as senhas em texto puro digitadas pelos usuários legítimos — verificando antes se elas não coincidem com senhas-mestre dos próprios atacantes — e as salva criptografadas com uma cifra de substituição personalizada mais Base64. Além do HAProxy, versões trojanizadas de sshd, crond, agetty, atd e polkitd — serviços e utilitários legítimos do Linux — foram observadas, ampliando as opções de persistência e coleta.

O stager que entrega esses binários é meticuloso: depois de substituir o daemon crond legítimo pelo trojanizado, ele copia os timestamps do binário SSH original para o novo arquivo (técnica chamada timestomping, que falsifica datas de criação para parecer inofensivo) e remove de logs do sistema palavras-chave como tmp, wget, cron e crond — apagando vestígios da instalação de /root/.bash_history e dos arquivos de log em /var/log (messages, audit, secure, syslog, entre outros). Isso significa que os logs do servidor comprometido não podem ser tratados como fonte confiável de verdade.

Indicadores de comprometimento (IoCs)

A Rapid7 publicou os hashes SHA-256 das amostras e os domínios de comando e controle usados na campanha. Os hashes abaixo podem ser usados para busca em plataformas de inteligência de ameaças e para varredura de arquivos suspeitos — as amostras podem ser submetidas a análise estática com ferramentas como o pestudio.

SHA-256Descrição
5db1b6d52faf60b4f32d6fd0c7c938e4d05d29a14c32ded4a9668357c08b6a91CurlRAT stager
09739441ed4599bac2f8159028f772f71e4b25c8badfff95574e56d7384f3dbeCurlRAT stager (variante)
fea1bc36632c71e5a839803469ef60ac47595d36b2c50934ac109ade6df06e61CurlRAT stager (variante)
83f7d565b0465546027052b597af46eae3a199e7a91fcc2ab936341147349130CurlRAT
7007a78d50a993cb174c685eba96eb442c9507e38fd9d8e5dffc712f613ec110CurlRAT
6cf1b5e92a9c0756f597a5ddefb38eba32961c52efac7ab2a0aa52c639a8fc53CurlRAT
ed72f4cd8d467b5c5d95ae6aeca4aaeea14d79565d379c1ca5871a714727be16CurlRAT
feeea9d0bf6ae7396d28271baa51ae50df5169ce5d32a516865856f91abc50b3CurlRAT
12810854c8b2c391b23e2e18b013e873d0369b0637aa3cf993136c07188ba3b8Amostra CurlRAT
009a1e2d7a582a24e50cf2ffc2a005482c8e38f22bf5ed416053855f8d054e1eAmostra CurlRAT
d53c760c23b4405eb04ad0f20ead375440344b3bdf1fb7854ed12e40d155eabeBinário cronie trojanizado
2f02b09d61d432134e994ad671258f523bbf289ae6091fd4eae192c60bd51b6fBinário agetty trojanizado
8f30b57928934ae67478d0e690c91d046e35a638da098d02922a4a88a0fdb66cBinário atd trojanizado
a1d8af3a6acb731f07f72040eccb3450c1c83d40e29f736c2a63d35388660be4Binário polkitd trojanizado
4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5Keylogger SSH
94630b96f628c96a6bff7904b40ffc9ad67c86f8a4ff6080c3b524831c93f402ted backdoor
72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558Build modificado do HAProxy com ted backdoor
a8bfab4de81a1acb04aacdf757346946b0f5e30f0c9f402004016d0e425119c7Amostra ted backdoor

Os domínios de comando e controle listados seguem um padrão deliberado: todos usam o subdomínio "img" e imitam serviços de entrega de conteúdo estático — um deles, img.responsive.pstatic.autos, copia o estilo de nomenclatura do pstatic.net, plataforma coreana de conteúdo estático, para que o tráfego de comando passe por uma requisição de imagem inofensiva.

DomínioDescrição
img.monderhouse.spaceInfraestrutura de comando e controle
img.smartnords.siteInfraestrutura de comando e controle
img.darklights.storeHost de configuração de backup do CurlRAT
img.responsive.pstatic.autosC2 disfarçado de conteúdo estático
img.socialteams.storeInfraestrutura de comando e controle
img.worksongo.storeInfraestrutura de comando e controle

Como se proteger

Verifique a integridade dos binários. Compare os binários do HAProxy e dos serviços Linux em produção com as versões oficiais conhecidas — a build comprometida é um HAProxy 2.8.12 que, na data de compilação mais antiga possível, remonta a 22 de novembro de 2024. Um SIEM com monitoramento de integridade de arquivos, como o Wazuh, ajuda a detectar substituições de binários e alterações fora do ciclo de atualização.

Audite bibliotecas compartilhadas e agendadores. Implantes compilados costumam depender de bibliotecas dinâmicas incomuns ou carregar payloads por serviços de agendamento: revise bibliotecas compartilhadas fora do esperado, mudanças em entradas de cron e substituições recentes de daemons como sshd, crond e polkitd.

Rotine as credenciais que passaram pelo servidor. Todo login efetuado através do servidor de borda comprometido — inclusive senhas de SSH — pode ter sido capturado pelo keylogger. Rotacione imediatamente credenciais de administradores, contas de serviço e acessos ao groupware e ao correio.

Monitore a rede de forma independente. Como o stager apaga palavras-chave dos logs, os registros da máquina comprometida não são confiáveis. A visibilidade real precisa vir de fora: monitoramento de rede independente no perímetro, capaz de flagrar conexões de saída inesperadas de balanceadores de carga e requisições a domínios desconhecidos.

Investigue tráfego HTTP atípico. Pedidos a caminhos com aparência de imagem vindos do balanceador, respostas que mudam apenas para determinados visitantes (sinal de injeção seletiva de script) e acessos frequentes aos mesmos domínios "img" merecem investigação imediata.

Mantenha groupware e servidores de e-mail atualizados. O acesso inicial provável é a exploração de vulnerabilidades em portais de groupware e servidores de correio expostos: corrija esses serviços, reduza a superfície exposta e trate qualquer aplicação autenticada na borda como alvo prioritário de hardening.

Conclusão

O ted backdoor representa um salto qualitativo na arte de esconder malware: em vez de um processo separado que luta para sobreviver a varreduras, o implante vive dentro do próprio software de infraestrutura, usa os mecanismos legítimos do HAProxy para interceptar tráfego e manipula até os contadores de conexão para não aparecer nas estatísticas. Combinado com o CurlRAT, o keylogger SSH e a frota de binários trojanizados, o toolkit forma um conjunto de espionagem de longo prazo, discreto o bastante para operar por mais de um ano sem detecção.

A atribuição à Coreia do Norte é feita com confiança média — os domínios de C2 já haviam sido associados ao grupo APT37 (grupo de espionagem ligado à Coreia do Norte), e há paralelos de cronologia e conceito com outras operações de grupos como Lazarus (grupo de ameaça persistente ligado à Coreia do Norte) — mas ainda falta a confirmação forense do ponto de entrada. Para quem opera servidores de borda, a lição é direta: software legítimo e "funcionando normalmente" não é garantia de integridade, e a confiança em logs e binários precisa ser verificada de fora.

Perguntas frequentes

O que é o ted backdoor?

É um implante de espionagem compilado dentro de uma versão trojanizada do HAProxy 2.8.12, o balanceador de carga usado pelas vítimas. Ele intercepta o tráfego HTTP, captura sessões, executa comandos, transfere arquivos e injeta scripts em páginas de visitantes selecionados, tudo enquanto o balanceador continua funcionando normalmente.

Como o backdoor fica escondido dentro do HAProxy?

Ele não roda como um processo separado: o código malicioso é compilado diretamente no binário e usa a API de filtros nativa do HAProxy, seus pools de memória e o agendador de eventos para se conectar ao parser HTTP. O implante ainda reduz os contadores de conexão do serviço para não aparecer nas estatísticas de monitoramento.

O que é o CurlRAT e o que ele faz?

É o trojan de acesso remoto da operação, um sub-artigo nosso em produção. Ele faz polling no servidor de comando e controle a cada 12 horas, executa comandos, instala payloads adicionais e pode abrir shells reversos ou interativos com privilégios de root, além de reportar o status do HAProxy aos atacantes.

Quem está por trás da campanha?

A Rapid7 atribui a operação a APTs ligados à Coreia do Norte com confiança média: os alvos sul-coreanos, o uso de criptografia XOR simples, a cifra de substituição e os domínios de comando e controle já associados ao grupo APT37 apontam nessa direção, mas o ponto exato de entrada e a vulnerabilidade explorada ainda não foram confirmados.

Por que empresas de mídia e automotivas foram alvo?

Os setores de mídia e automotivo sul-coreanos têm valor de inteligência estratégica para a Coreia do Norte, que historicamente coleta informações políticas, econômicas e tecnológicas da região. A combinação de roubo de credenciais, coleta de sessões e injeção seletiva de conteúdo indica espionagem de longo prazo, não extorsão.

Empresas fora da Coreia do Sul estão em risco?

O alvo observado foi sul-coreano, mas a técnica não tem fronteira: qualquer organização que exponha groupware, servidores de e-mail ou balanceadores na borda da rede está sujeita ao mesmo padrão. No Brasil, grupos de espionagem já atacaram instituições — o BREEZE COMET, por exemplo —, então as defesas descritas valem para qualquer ambiente.

Os logs do servidor comprometido podem ser confiáveis?

Não. O stager da campanha remove de logs palavras-chave como tmp, wget, cron e crond, apagando vestígios da instalação do arquivo de histórico do root e dos logs em /var/log. Por isso a recomendação é monitorar a rede de forma independente, com sensores fora da máquina comprometida.

O que fazer se os IoCs aparecerem na minha rede?

Trate como incidente de alta prioridade: isole o servidor de borda, colete evidências (memória, binários e tráfego) sem confiar nos logs locais, compare os binários com versões oficiais, rotacione todas as credenciais que passaram pela máquina e investigue conexões de saída para os domínios listados.

Fontes e leituras adicionais

Gostou? Receba novos conteúdos por e-mail.

Entre na comunidade

Discussões técnicas e novidades em primeira mão.