Un paquete de Python ampliamente utilizado fue convertido en un arma de forma sigilosa, y la mayoría de los desarrolladores afectados no tuvieron idea de lo ocurrido. El 27 de marzo de 2026, un actor de amenazas conocido como TeamPCP subió dos versiones maliciosas del SDK de Python de Telnyx a PyPI, el principal repositorio donde los desarrolladores de Python descargan paquetes de software. Las versiones comprometidas,

Un paquete de Python ampliamente utilizado fue convertido en un arma en silencio, y la mayoría de los desarrolladores que resultaron afectados no tuvieron idea de lo que ocurrió.

El 27 de marzo de 2026, un actor de amenazas conocido como TeamPCP subió dos versiones maliciosas del SDK de Python de Telnyx a PyPI, el principal repositorio donde los desarrolladores de Python descargan paquetes de software.

Las versiones comprometidas, 4.87.1 y 4.87.2, estuvieron activas durante aproximadamente cuatro horas antes de que PyPI interviniera y pusiera ambas en cuarentena.

Durante esa breve ventana, cualquier desarrollador o sistema que ejecutara una simple instalación del paquete podría haber sido infectado silenciosamente, sin advertencias, errores ni señales visibles de que algo salió mal.

El paquete de Telnyx no es una biblioteca pequeña u oscura. Registra alrededor de 750,000 descargas mensuales, lo que significa que el radio potencial de impacto de este ataque se extiende mucho más allá de los usuarios directos, afectando a todos los proyectos, pipelines y servicios que dependen de él. Lo que hace que este ataque sea especialmente preocupante es su precisión.

Solo se modificó un único archivo dentro del paquete. Todo lo demás en el paquete era idéntico byte por byte a la versión limpia.

El código malicioso se ejecutaba en el momento en que cualquier aplicación importaba la biblioteca, sin necesidad de clics, configuración ni interacción del usuario.

Analistas de Hexastrike identificaron el ataque como parte de una campaña más amplia y de rápido movimiento en la cadena de suministro por parte de TeamPCP, un grupo vinculado al antiguo actor de amenazas TeamTNT.

Los investigadores señalaron que el mismo grupo ya había atacado Trivy de Aqua Security, Checkmarx, LiteLLM y más de 46 paquetes npm en solo nueve días.

Cada nuevo ataque mostraba mayor sofisticación que el anterior, y el compromiso de Telnyx es la versión más completa que han analizado hasta ahora.

El ataque siguió una estructura de tres etapas. Primero, el paquete troyanizado activaba un cargador específico para cada plataforma. Segundo, ese cargador obtenía una carga oculta desde un servidor remoto, escondida dentro de un archivo de audio WAV mediante esteganografía.

Tercero, la carga decodificada desplegaba un recolector de credenciales completo que robaba silenciosamente claves SSH, credenciales de proveedores en la nube, secretos de Kubernetes, configuraciones de bases de datos, billeteras de criptomonedas y archivos de entorno antes de cifrar todo y enviarlo a un servidor controlado por el atacante.

El malware funcionaba en todos los principales sistemas operativos y podía propagarse a través de clústeres Kubernetes completos desplegando pods privilegiados en cada nodo.

Cómo se construyó el mecanismo de infección para permanecer oculto

El punto de entrada para todo el ataque fue una modificación dentro de un archivo llamado _client.py. Cuando Python carga la biblioteca de Telnyx, ejecuta automáticamente el código dentro de ese archivo.

TeamPCP añadió dos llamadas a funciones al final: setup() para sistemas Windows y FetchAudio() para Linux y macOS. Ambas funciones verificaban primero el sistema operativo y se detenían silenciosamente si estaban en la plataforma incorrecta.

Todos los posibles errores eran capturados y silenciados mediante un manejador de excepciones general, lo que significaba que la aplicación que ejecutaba la biblioteca nunca se bloquearía ni mostraría una alerta.

Para ocultar lo que realmente hacían estas funciones, el atacante envolvió cada cadena sensible dentro de un ayudante de codificación base64. URLs, rutas de carpetas, nombres de archivos y encabezados estaban todos codificados para que una revisión rápida del código no revelara el ataque.

Una vez decodificado, el código de Windows descargaba un archivo llamado hangup.wav desde un servidor de comando y control en 83.142.209.203:8080. Ese archivo no era realmente de audio.

Era un contenedor WAV válido que escondía un binario ejecutable dentro de sus frames de audio mediante esteganografía.

El binario se extraía, decodificaba usando una clave XOR y se escribía en la carpeta de Inicio de Windows bajo el nombre msbuild.exe, un nombre tomado de una herramienta legítima de Microsoft para evitar sospechas.

Se ejecutaba en silencio sin ventana visible y se iniciaba automáticamente cada vez que el usuario iniciaba sesión.

En Linux y macOS, el enfoque era diferente pero igualmente sigiloso. En lugar de soltar un archivo, el código decodificaba una gran carga útil en Python almacenada en una variable y la ejecutaba en un proceso hijo independiente.

Ese proceso seguía ejecutándose incluso después de que la aplicación principal se cerrara. Descargaba un segundo archivo WAV llamado ringtone.wav, extraía el recolector de credenciales oculto en los datos de audio y lo ejecutaba completamente en memoria, sin escribir nunca el script en el disco.

Una vez que el recolector terminaba de recopilar credenciales, los resultados se cifraba con AES-256-CBC y la clave de sesión se envolvía usando una clave pública RSA-4096 codificada. Esto significaba que solo el atacante podía descifrar los datos robados.

Todo se empaquetaba en un archivo y se enviaba al servidor del atacante mediante una solicitud HTTP POST con el encabezado X-Filename: tpcp.tar.gz, una firma que aparece en todas las campañas conocidas de TeamPCP y sirve como un fuerte indicador de detección a nivel de red.

Las organizaciones deben tratar cualquier instalación de las versiones 4.87.1 o 4.87.2 como una brecha confirmada e iniciar una respuesta a incidentes de inmediato.

Todas las credenciales accesibles desde los sistemas afectados deben rotarse, incluyendo claves SSH, credenciales de AWS, GCP y Azure, tokens de Kubernetes, credenciales de Docker, contraseñas de bases de datos, claves API y cualquier secreto almacenado en archivos de entorno.

Simplemente desinstalar el paquete no elimina la puerta trasera persistente. En Linux, el archivo ~/.config/sysmon/sysmon.py y su servicio systemd asociado deben eliminarse manualmente.

En Windows, msbuild.exe en la carpeta de Inicio y el archivo oculto .lock deben borrarse. En entornos Kubernetes, cualquier pod llamado node-setup-* en kube-system debe auditarse y eliminarse, y cada nodo debe revisarse en busca de un servicio systemd inesperado llamado sysmon.service.

Los desarrolladores también deben fijar todas las dependencias a versiones exactas, usar archivos de bloqueo, habilitar la autenticación de dos factores en las cuentas de PyPI, usar credenciales de corta duración siempre que sea posible, evitar almacenar secretos en archivos .env en el disco y bloquear las conexiones salientes a 83.142.209.203, checkmarx.zone y la subred 83.142.209.0/24 a nivel de firewall.

Fuentes:
https://cybersecuritynews.com/hackers-backdoor-telnyx-python-sdk/