Escuchó música — perdió sus datos: la nueva técnica de TeamPCP para ocultar virus en archivos de audio

Una filtración que no se cerró a tiempo se convirtió en una reacción en cadena y afectó a varios servicios importantes. En marzo de 2026 el grupo TeamPCP realizó uno de los ataques a la cadena de suministro de software más extensos de los últimos años, usando tan solo una cuenta robada.

La historia comenzó en febrero, cuando los atacantes obtuvieron acceso al sistema de verificación de código de la popular herramienta Trivy. La vulnerabilidad consistía en que el proceso automático que manejaba las solicitudes de cambio de código se ejecutaba con acceso a los secretos del proyecto. A través de él lograron extraer una clave de acceso con amplios privilegios. Tras detectar el incidente se cerró el acceso formalmente, pero no de forma completa. Parte de las claves siguió funcionando, y ese error fue el punto de partida de toda la cadena.

El 19 de marzo TeamPCP volvió a los datos ya robados e inició la ofensiva. A través del sistema de compilación de Trivy los atacantes inyectaron código malicioso en actualizaciones que luego se propagaron por repositorios, imágenes de contenedores y otros canales de distribución. El código se ejecutaba en servidores de desarrollo y compilación, recopilaba claves de acceso a servicios en la nube, credenciales, archivos de entorno e incluso monederos de criptomonedas, y luego enviaba todo a servidores bajo su control.

La campaña se desarrolló como un efecto dominó. Desde un entorno comprometido se extraían nuevas claves y se usaban de inmediato para el siguiente paso. En cuestión de días resultaron afectadas las ecosistemas de Aqua Security, npm, LiteLLM, Checkmarx y Telnyx. En cada caso el esquema se repetía: el código malicioso entraba en el proceso de compilación, de allí obtenía secretos y abría el acceso al siguiente objetivo.

El componente malicioso se propagó especialmente rápido en el repositorio npm. Allí el programa identificaba automáticamente cuentas de desarrolladores, incrementaba las versiones de sus paquetes y publicaba actualizaciones infectadas. En cuestión de minutos la infección alcanzó a decenas de paquetes. Como resultado, el código malicioso llegaba a proyectos de desarrolladores como una dependencia más.

Un episodio separado está relacionado con la biblioteca LiteLLM. Los atacantes robaron la clave de publicación y subieron versiones maliciosas directamente al catálogo de paquetes de Python, eludiendo el proceso oficial de lanzamiento. El código se ejecutaba incluso sin importación explícita y permitía recopilar claves de servicios en la nube populares. En algunos casos intentaba apoderarse de clústeres enteros de contenedores.

El ataque a Telnyx mostró una nueva técnica de camuflaje. La carga maliciosa se ocultaba dentro de archivos de audio. Al cargarlos, la biblioteca extraía de ellos código ejecutable. En Windows ese código se añadía al inicio automático, y en Linux y macOS recopilaba datos rápidamente y desaparecía, dejando casi sin rastros.

Paralelamente TeamPCP accedió a los repositorios internos de Aqua Security. Renombraron todos los proyectos y dejaron mensajes sobre la intrusión. Se logró el acceso mediante una cuenta de servicio con privilegios excesivos que vinculaba los sistemas públicos e internos de la empresa.

Un componente destructivo de la campaña llamó la atención. El script malicioso comprobaba la configuración del sistema y, si detectaba indicios de infraestructura en Irán, ejecutaba una eliminación completa de archivos y un reinicio. En los demás casos el código malicioso se limitaba al robo de datos y a la instalación de accesos ocultos.

En los últimos dos años TeamPCP ha aumentado notablemente sus capacidades. Si antes el grupo buscaba servicios mal configurados y se dedicaba a la minería de criptomonedas, ahora ha construido una cadena de ataques totalmente automatizada. Toda la operación duró menos de una semana, y las acciones clave se realizaron en cuestión de segundos.

La relación con el grupo LAPSUS$ añade un contexto preocupante. En canales cerrados se discutían anticipadamente objetivos futuros, y más tarde la colaboración se confirmó públicamente. De hecho, ya no se trata de un grupo aislado, sino de una red más amplia con intercambio de datos y coordinación.

La característica principal de esta historia es que los atacantes no necesitaron vulnerabilidades complejas. Aprovecharon debilidades conocidas desde hace tiempo: privilegios excesivos, claves de acceso de larga vida y configuraciones inseguras de procesos automáticos. La automatización permitió convertir esos errores en un ataque a gran escala.

Otra conclusión importante se refiere a la confianza en las herramientas de seguridad. Esta vez las soluciones de ese tipo fueron el objetivo. Las empresas normalmente les otorgan máximos privilegios, por lo que la compromisión de herramientas similares abre acceso a toda la infraestructura de inmediato.