HAProxy troyanizado en Corea del Sur: la puerta trasera ted intercepta tráfico y oculta el control remoto

Rapid7 Labs ha descubierto un kit de herramientas para Linux, hasta ahora no documentado, integrado en compilaciones modificadas de HAProxy 2.8.12 en dos organizaciones surcoreanas de los sectores automotriz y de medios. El malware, denominado ted a partir de sus símbolos y cadenas de depuración, permite manipular selectivamente las respuestas HTTP, ejecutar comandos y robar credenciales.

No se trata de una vulnerabilidad de HAProxy. Antes, los atacantes deben obtener ejecución de código en el servidor y sustituir el binario legítimo del balanceador. Por tanto, la presencia del implante demuestra una intrusión más profunda en el sistema, cuyo vector inicial sigue siendo desconocido.

Rapid7 atribuye la operación, con confianza media, a actores patrocinados por Corea del Norte. Los indicios técnicos se solapan con infraestructuras y métodos operativos asociados a APT37, Lazarus y Kimsuky, aunque no permiten una atribución más precisa.

Las compilaciones comprometidas dependen de HAProxy 2.8.12

Ambas víctimas ejecutaban HAProxy 2.8.12, versión distribuida el 8 de noviembre de 2024. ted no se limita a ejecutarse junto al software: el binario de HAProxy se sustituye por una compilación troyanizada que contiene directamente el código del implante.

El malware accede a las estructuras internas del programa mediante offsets fijos específicos de la versión observada. Rapid7 no ha podido determinar si otras compilaciones de la serie 2.8 son compatibles con el mismo código.

Esta limitación puede aportar un elemento útil para la investigación, pero no reduce la gravedad de la intrusión. Una versión distinta podría requerir a los atacantes únicamente recompilar el malware o adaptar los offsets, aunque no existen evidencias al respecto.

La versión actual de la rama es HAProxy 2.8.28, publicada el 27 de agosto de 2026, dieciséis versiones menores después de la comprometida. El rastreador del proyecto enumera 529 errores presentes en la 2.8.12 y corregidos posteriormente en la rama 2.8, entre ellos un problema crítico y 16 clasificados como importantes.

Actualizar sigue siendo necesario, pero no constituye una remediación completa. ted no explota ninguno de esos errores, y un sistema ya infectado puede conservar otros componentes maliciosos incluso después de sustituir HAProxy. Además, una compilación recompilada puede mostrar la misma cadena de versión que el binario auténtico.

La versión declarada, por sí sola, no demuestra nada.

Como no se ha identificado una vulnerabilidad del producto, en este caso no existe un identificador CVE que corregir. Tampoco se plantea su inclusión en el catálogo KEV de CISA: el ataque requiere una intrusión previa y la sustitución del software.

La inyección afecta únicamente a visitantes seleccionados

ted aplica cuatro comprobaciones antes de modificar una respuesta HTTP. La solicitud debe contener un User-Agent, mientras que la URL y el Referer deben coincidir con los patrones configurados por los operadores.

También se verifica el origen del cliente. La dirección debe estar incluida en una lista de permitidos, mediante coincidencia exacta o a nivel de red /24, a menos que la solicitud contenga una clave específica en el campo Accept-Language.

Esta última funciona como una puerta de acceso: permite al operador ignorar por completo el filtro de IP. Por tanto, puede utilizarse para probar el implante o acceder a él desde direcciones que no se hubieran incluido previamente en la configuración.

Cuando se cumplen todas las condiciones, el malware sustituye el contenido destinado al visitante. Durante el proceso, reescribe el tipo y la longitud de la respuesta, fuerza el estado HTTP 200 y elimina la cabecera Accept-Ranges.

La eliminación de Accept-Ranges impide que el cliente solicite fragmentos concretos del archivo. De este modo, reduce la posibilidad de que las diferencias en el tamaño o el comportamiento de la respuesta revelen la manipulación.

La selectividad es un elemento central de la operación. Los usuarios comunes, los escáneres y los sistemas automatizados pueden recibir contenido legítimo, mientras que únicamente los objetivos seleccionados ven la página manipulada. Por ello, una comprobación ocasional del sitio puede no detectar nada.

El canal C2 desaparece de las estadísticas del balanceador

Una solicitud dirigida a una ruta de imagen específica activa el modo de command-and-control. La conexión termina directamente en el HAProxy comprometido y no llega a los servidores backend.

Para ocultarla, ted reduce los contadores de conexiones activas del balanceador. Por tanto, el intercambio no aparece en las estadísticas nativas de HAProxy, mientras que los backends tampoco pueden registrarlo porque no reciben la solicitud.

El cuerpo que contiene el comando se escribe en una named pipe ubicada bajo /tmp. Después de utilizarlo, el canal de la solicitud se vacía. La salida del comando vuelve al operador a través del socket sin procesar, precedida por una cabecera común HTTP/1.0 200 OK.

Mediante este canal, los atacantes pueden:

• enviar beacons;
• cargar y descargar archivos;
• ejecutar comandos de shell;
• sustituir la configuración de ted.

El resultado es un C2 camuflado en el tráfico web y excluido de las principales fuentes de telemetría del servicio. Para detectarlo es necesario contrastar HAProxy con datos independientes, como flujos de red capturados fuera del servidor.

Persistencia, eliminación de rastros y robo de contraseñas

El kit incluye un stager que inicia la instalación únicamente si detecta que HAProxy o cron ya están en ejecución. Antes de continuar, también comprueba que dispone de privilegios de root.

Una vez activo, sobrescribe el binario legítimo crond y asigna al sustituto la marca de tiempo de creación asociada a /usr/bin/ssh. Esta manipulación pretende dificultar la detección de la introducción de un nuevo ejecutable.

ted también modifica los rastros generados durante la instalación. Elimina de la historia de Bash de root los términos tmp, wget, cron y crond; las mismas palabras se borran de seis registros del sistema, incluidos auth.log y audit/audit.log.

Por tanto, la ausencia de estas cadenas no equivale a la ausencia de actividad. Las lagunas temporales, las líneas incoherentes o las diferencias con respecto a copias centralizadas de los registros pueden resultar más indicativas que una simple búsqueda textual.

Rapid7 también ha identificado un componente sshd troyanizado capaz de capturar contraseñas en texto claro, cifrarlas y guardarlas en una ruta fija. Se ha observado código similar en versiones modificadas de agetty, atd y polkitd.

La operación va más allá de la manipulación del tráfico web. Incluye persistencia, control remoto, recopilación de credenciales y alteración de varios componentes fundamentales del sistema.

El kit también está asociado con curlRAT, un troyano de acceso remoto que normalmente realiza beaconing cada 12 horas. Un indicador controlado por el operador reduce el intervalo a 30 segundos. El malware interrumpe su ejecución si no encuentra un archivo marcador que confirme la virtualización del host.

curlRAT no debe confundirse con CurlBack RAT, una familia distinta atribuida a SideCopy, un grupo vinculado a Pakistán.

La atribución norcoreana aún no es definitiva

Las víctimas conocidas son dos organizaciones surcoreanas de los sectores automotriz y de medios. No se sabe cuándo comenzó la intrusión ni cómo obtuvieron los operadores el acceso inicial.

Una posible línea de investigación apunta a un portal de Groupware expuesto. ENKI había documentado una intrusión anterior, atribuida a Kimsuky, contra un proveedor coreano de software colaborativo mediante una vulnerabilidad en un servidor de correo. Sin embargo, no existen pruebas directas de que se utilizara la misma vía en los casos analizados por Rapid7.

La atribución con confianza media combina distintos elementos: dominios asociados con APT37, un modelo de distribución similar al de Lazarus y la hipótesis de que el acceso inicial estuviera relacionado con Kimsuky.

Una evaluación de Mandiant de 2023 describía las operaciones norcoreanas como caracterizadas por el intercambio de herramientas y la coincidencia de objetivos entre distintos clústeres. Estas intersecciones explican por qué los indicadores pueden apuntar simultáneamente a varios grupos.

El método también recuerda a Operation SyncHole, en la que los visitantes de sitios web informativos surcoreanos eran filtrados en el servidor y redirigidos. Kaspersky evaluó con confianza media que el destino pudiera ejecutar código malicioso contra una vulnerabilidad de Cross EX.

En otra actividad, AhnLab y ENKI WhiteHat describieron en julio una campaña de watering hole basada en sitios surcoreanos comprometidos y dirigida contra el cliente de firma AnySign4PC. La comparación indica continuidad en las técnicas de selección de víctimas, pero no demuestra que las operaciones pertenezcan al mismo actor.

Indicadores que deben buscarse y prioridades de respuesta

Los indicadores en disco incluyen:

• ~/cache/haproxy-1000.cache
• /var/lib/sshd/c8c68e629bba773a10ac80012d10bf19
• /var/lib/snapd/g580
• /tmp/jasper-log

Los hashes SHA-256 publicados son:

• 72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558
• 4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5

Los seis dominios asociados con la actividad son:

• img.monderhouse[.]space
• img.smartnords[.]site
• img.darklights[.]store
• img.responsive.pstatic[.]autos
• img.socialteams[.]store
• img.worksongo[.]store

Al 4 de septiembre de 2026, ninguno resolvía mediante Google Public DNS: las consultas de registros A y NS devolvían NXDOMAIN. Por tanto, son indicadores especialmente útiles para el análisis retrospectivo de registros DNS, proxy, firewall y flujos de red, pero no para bloquear el tráfico actual.

La respuesta debería comenzar por aislar el host y verificar los binarios frente a copias obtenidas de fuentes fiables. No basta con comprobar HAProxy: también deben revisarse crond, sshd, agetty, atd y polkitd.

Asimismo, deben buscarse named pipes anómalas en /tmp, modificaciones de la historia de root, limpiezas selectivas de registros y conexiones que no se expliquen por los contadores de HAProxy. El análisis de memoria puede detectar código o estructuras extrañas residentes en los procesos.

Reinstalar únicamente el balanceador no es suficiente. Dado que se han visto afectados componentes privilegiados y se han robado contraseñas, la remediación debe incluir la rotación de las credenciales potencialmente expuestas y, cuando no pueda demostrarse la integridad del host, la reconstrucción del sistema a partir de fuentes fiables.