La TeamPCP vuelve a estar en el foco tras una actuación de las autoridades en Australia. La Australian Federal Police (AFP) y la policía de Australia Occidental han presentado cargos contra dos hombres, relacionándolos con una serie de ataques de cadena de suministro que, según las acusaciones, habrían afectado a herramientas de seguridad y a un flujo de publicación de software.
Más allá del proceso judicial, el mensaje para organizaciones es práctico: cuando hay filtración de credenciales y se alteran componentes en repositorios confiables, el impacto no se limita al “primer” incidente. La guía del caso apunta a tratar los accesos comprometidos como un riesgo persistente.
Qué se alega en el caso de TeamPCP
Las autoridades acusan a Louis Michael Gaebler (23 años) y Ruben Ian Thomson (21 años) por su presunta participación en TeamPCP, un grupo asociado a intrusiones relevantes en marzo de 2026. En esa fase, se comprometieron escáneres de seguridad de código abierto vinculados a Trivy y Checkmarx KICS, y además se mencionó una cadena de ataque que involucró LiteLLM.
Gaebler y Thomson comparecieron en el Tribunal de Magistrados de Perth el 27 de agosto de 2026. El día anterior, AFP y la Western Australia Police Force realizaron allanamientos en propiedades de Cottesloe, Hamilton Hill y Mandurah, incautando equipos para análisis forense.
Según las alegaciones, ambos habrían sido participantes principales de la supuesta organización y habrían recibido pagos en criptomonedas. El valor exacto de esos pagos aún estaría bajo investigación.
Un patrón: robar credenciales y publicar versiones “contaminadas”
El caso describe una forma de operar que no depende únicamente de vulnerar sistemas finales. En cambio, el enfoque apuntaría a aprovechar la confianza depositada en proyectos de open source y sus canales de distribución.
De acuerdo con la información reportada, el grupo habría robado credenciales de publicación desde proyectos confiables y, con ellas, habría introducido versiones manipuladas que luego se publicaban a través de los propios mecanismos de lanzamiento de esos proyectos.
Un elemento clave del patrón es el efecto en cadena: el compromiso de un componente aportaría credenciales o capacidades que servirían para atacar el siguiente paso del flujo de publicación.
Los ecosistemas afectados y por qué importa
Las autoridades y el análisis asociado al incidente sitúan la campaña en cinco entornos de distribución: GitHub Actions, Docker Hub, npm, PyPI y OpenVSX. Este detalle es importante porque muchos equipos integran estos ecosistemas en su cadena de desarrollo y despliegue.
Cuando una pieza llega a esos canales, no solo afecta a quienes descargan directamente el paquete. También puede afectar a pipelines automatizados, tareas de build y validaciones que incorporan herramientas como parte de CI/CD.
De Trivy a KICS: cómo se encadena el ataque
Uno de los recorridos descritos es el siguiente: las credenciales obtenidas durante el incidente relacionado con Trivy habrían sido usadas después contra Checkmarx KICS.
La información disponible señala que los accesos se habrían activado en acciones de KICS días después del compromiso inicial. Es decir, la secuencia no habría sido instantánea, sino escalonada, lo que sugiere una planificación y una reutilización de credenciales para mover el ataque de un punto a otro.
En términos defensivos, esto refuerza una idea: si una credencial se ve comprometida en cualquier etapa del flujo, puede dar soporte a operaciones posteriores incluso cuando el incidente “visible” haya terminado.
LiteLLM y la puerta hacia el mundo de las llaves del proveedor
El informe también vincula el ataque con LiteLLM. Se describe que el pipeline de construcción de LiteLLM habría instalado Trivy sin fijarlo a una versión verificada. El resultado sería que el escáner “contaminado” pudiera tomar el token de publicación del proyecto.
Con ese token, el actor habría publicado versiones manipuladas de LiteLLM a finales de marzo. Debido a que LiteLLM rutea solicitudes entre proveedores de modelos de lenguaje y suele colocarse donde se consolidan las claves del proveedor dentro de una organización, el impacto potencial se amplía.
En otras palabras: un componente que administra o concentra llaves de proveedores puede convertirse en un punto sensible si su cadena de suministro es alterada.
Cantidad de víctimas y señales de alcance global
Las autoridades sostienen que el código malicioso asociado habría comprometido a más de 1.000 organizaciones en todo el mundo, facilitando el robo de más de 500.000 credenciales y provocando el exfiltrado de al menos 300 GB de datos.
Otras publicaciones vinculadas al seguimiento del evento ofrecieron cifras adicionales y con matices. En el reporte se menciona que algunas estimaciones se expresaron como “lo que podría haberse exfiltrado”, en lugar de un conteo totalmente confirmado.
También se describen reconstrucciones basadas en datos de exposición: por ejemplo, se habla de un número de organizaciones y pipelines CI/CD reconstruidos a partir de archivos y conjuntos de evidencia. En ese sentido, el caso no solo destaca el volumen, sino la dificultad de convertir telemetría e indicadores en un recuento final.
Cargos y posibles penas: qué implica la acusación
El tribunal incluye 14 cargos en total, sin que la lista mencione de forma explícita proyectos específicos como objeto del compromiso. El desglose apunta a distintos tipos de conducta: posesión de datos con intención, modificación no autorizada con intención de cometer delitos graves, suministro de datos, y también un cargo relacionado con una orden legal.
Para uno de los acusados, el marco incluye el incumplimiento de una orden bajo la sección 3LA del Crimes Act 1914 (Cth), con una pena máxima de 10 años. Para el cargo de manejo de beneficios del delito, se menciona un máximo de 20 años.
El detalle del proceso judicial deja claro que, incluso sin enumerar “Trivy”, “KICS” o “LiteLLM” en cada cargo, las autoridades asocian la conducta a una actividad de cibercrimen de alto impacto y alcance.
Qué recomiendan los avisos: tratar el riesgo como persistente
Más allá de los cargos, la parte operativa del caso se centra en el riesgo. En una advisory asociada, el FBI recomendó que las organizaciones afectadas traten los datos exfiltrados y las credenciales como un riesgo que puede mantenerse en el tiempo.
El motivo es sencillo: los atacantes podrían reutilizar accesos para acciones posteriores, incluso cuando el compromiso inicial ya no esté “en curso”. Por eso, el aviso insiste en medidas concretas en la cadena de CI/CD.
Medidas clave citadas en el aviso
- Rotar secretos de integración continua y despliegue continuo (CI/CD).
- Revisar y cambiar tokens, incluidos los que se publican o quedan accesibles durante ventanas de exposición.
- Reemplazar credenciales de nube que pudieran haber estado disponibles durante esos periodos.
- Buscar repositorios relacionados con nombres de directorios asociados a un “gusano” (worm) en infraestructura creada con credenciales robadas.
- Fijar workflows de GitHub Actions a hashes de commit verificados en lugar de etiquetas flotantes.
En conjunto, el enfoque apunta a cerrar puertas: si las credenciales y tokens se mantienen, el atacante puede reactivar el acceso. Si los pipelines se ejecutan con versiones no verificadas, el riesgo de reintroducción también aumenta.
Señales adicionales: desaparición de builds y rastreo temporal
Se reporta que, al menos en el caso de PyPI, dos versiones maliciosas de LiteLLM ya no aparecen en el historial de releases. Sin embargo, todavía se indica que ciertas URLs directas seguirían devolviendo respuesta desde la red de distribución, varios meses después de su retiro del índice.
Este matiz sirve como recordatorio: “eliminado del índice” no siempre equivale a “desaparecido del mundo”. Las organizaciones deben revisar dependencias y fuentes, además de considerar mecanismos de caché y distribución.
También se menciona que infraestructura asociada a la actividad podría rastrearse hasta 2020, conectando el grupo con historiales de seguimiento previos a través de superposición de dominios, rutas de despliegue, técnicas de staging e infraestructura backend.
Aun así, el reporte indica que no es posible determinar con certeza absoluta si se trata de un cambio de nombre, un conjunto compartido de operadores o una colaboración estrecha entre actores relacionados.
Conclusión: qué deben hacer hoy los equipos de seguridad y desarrollo
El caso de TeamPCP pone en evidencia una realidad incómoda: los ataques de cadena de suministro no se limitan a “parches técnicos”. Exigen disciplina de gestión de secretos, validación de integridad en pipelines y respuesta sostenida ante credenciales comprometidas.
Si tu organización usa ecosistemas como GitHub Actions, Docker Hub, npm o PyPI en rutas automatizadas, el aprendizaje es claro: fija versiones verificadas, rota credenciales con rapidez, y asume que el riesgo puede persistir aunque el incidente inicial parezca resuelto.
Mientras el proceso judicial avanza en Australia, el mejor camino para protegerse es convertir estas lecciones en controles: seguimiento de tokens, hardening de CI/CD y revisión de dependencias, con atención especial a los componentes que actúan como puentes hacia llaves y servicios críticos.
Fuente: https://thehackernews.com/2026/08/alleged-teampcp-hackers-charged-in.html
