Mientras veías series, tu router TP-Link ayudaba a hackear GitHub
Cómo un router doméstico terminó siendo cómplice de un gran delito.
El compromiso de un router puede parecer una molestia local, y la manipulación de código en GitHub Actions una historia de otro mundo. Sin embargo, marzo de 2026 mostró que a veces hay un mismo hilo que conecta los routers domésticos y los canalizadores corporativos de CI/CD. Los autores de la investigación Ctrl-Alt-Intel concluyeron que el ataque contra Xygeni, sobre el que antes se hablaba por separado, está relacionado con una campaña para comprometer TP-Link y ASUS y crear una red proxy oculta.
El equipo trabajaba en un tema distinto: seguía a actores maliciosos que convierten dispositivos comprometidos en el borde de la red en proxies residenciales. Durante la investigación, los especialistas encontraron rastros de la herramienta microsocks en routers de consumo TP-Link, y junto a ellos un módulo de control ShadowLink.
El análisis mostró una coincidencia inesperada: el mismo protocolo de comunicación con el servidor de control, el mismo orden de intercambio de comandos y el mismo secreto de autenticación se usaban en el componente malicioso, implantado el 3 de marzo en un GitHub Action de Xygeni.
Según Ctrl-Alt-Intel, en TP-Link los atacantes explotaron la vulnerabilidad CVE-2024-21833 para descargar un script, seleccionar un binario adecuado para la arquitectura del dispositivo, levantar un proxy SOCKS5 y persistir en el sistema mediante cron, rc.local y NVRAM.
Ese nodo se camuflaba como un proceso del sistema y permitía enrutar tráfico a través de una dirección IP doméstica normal, lo que ayuda a eludir bloqueos, CAPTCHA y restricciones por frecuencia de solicitudes. En ASUS se encontró una versión ligera de ShadowLink que, al parecer, recopilaba información del dispositivo y preparaba el terreno para un despliegue posterior.
La conexión con el ataque a Xygeni resulta especialmente notable porque el código malicioso en el GitHub Action funcionaba casi con el mismo esquema. A principios de marzo los atacantes abrieron varios Pull Request falsos y luego redirigieron la etiqueta v5 hacia un commit modificado.
Al ejecutarse, ese Action enviaba información al servidor de control, recibía comandos, los ejecutaba y devolvía el resultado comprimido y codificado. Para camuflarse se usó un dominio a través de nip.io, que parecía más verosímil que una conexión directa a la dirección IP.
Los autores del informe compararon por separado sus hallazgos con la actividad de TeamPCP — un grupo que ya se había vinculado con los incidentes de marzo alrededor de Trivy y Checkmarx. No se encontraron pruebas técnicas directas de una infraestructura común, aunque el intervalo temporal, la selección de objetivos y el interés por redes proxy se solapan notablemente.
Ctrl-Alt-Intel no hace una atribución categórica, pero afirma otra cosa: el operador que había construido la red proxy residencial basada en TP-Link y ASUS también estaba detrás de la compromisión de Xygeni. Queda por entender si se trata de TeamPCP, de una estructura afín o de otro actor que llegó a los mismos métodos antes que los demás.