Dos olas paralelas en la cadena de suministro: TeamPCP comprometió Trivy y ShinyHunters extorsiona a Cisco

⏱️ Lectura: 14 min

Entre el 27 de febrero y el 22 de marzo de 2026, el grupo conocido como TeamPCP comprometió la cadena de suministro de Aqua Security Trivy, el escáner de vulnerabilidades open source más popular del ecosistema cloud-native. Reescribió 75 de 76 tags del GitHub Action trivy-action para apuntar a versiones maliciosas, distribuyó binarios troyanizados durante tres horas en los registros oficiales y desplegó un payload con tres etapas que cosechó credenciales de GitHub, AWS, GCP, Azure, Kubernetes, SSH, Docker, GPG y carteras de cripto desde más de diez mil workflows en producción. Una semana después, ShinyHunters —grupo de extorsión activo desde 2019— publicó un manifiesto en la dark web reclamando 3 millones de registros de Salesforce de Cisco, fragmentos de su código fuente y volúmenes EC2 con datos atribuidos a personal del FBI, IRS y NASA, con un ultimátum vencido el 3 de abril de 2026. Varios medios mezclaron ambos eventos en una sola narrativa. No lo son: son dos grupos independientes operando en paralelo, con métodos completamente distintos, en el peor mes para la cadena de suministro de software desde la oleada Shai-Hulud que comprometió Bitwarden CLI semanas después.

📑 En este artículo

1. Qué es Trivy y por qué su compromisión importa
2. El vector: pull_request_target mal configurado, otra vez
3. Cronología del compromiso
4. Qué hace el payload
5. CanisterWorm — la innovación de C2 sobre ICP
6. Quiénes son TeamPCP y qué relación tienen con Shai-Hulud
7. La segunda ola: ShinyHunters extorsiona a Cisco
8. El método de ShinyHunters: vishing y OAuth tokens, no Trivy
9. ShinyHunters en 2026: una racha imparable
10. Cómo defenderse: lecciones operacionales
11. Por qué este mes importa
12. Fuentes
    1. 📚 Artículos relacionados

Qué es Trivy y por qué su compromisión importa

Trivy es el escáner de vulnerabilidades de código abierto más usado para detectar problemas en imágenes de contenedor, sistemas de archivos, repositorios Git, infraestructura como código y entornos Kubernetes. Lo desarrolla Aqua Security y se ejecuta tanto en pipelines CI/CD como en clusters productivos. La integración más común no es el binario directo: es el GitHub Action trivy-action, que decenas de miles de proyectos invocan automáticamente en cada pull request para auditar dependencias antes del merge. Cuando un atacante controla trivy-action, en términos prácticos controla la línea de defensa que muchas organizaciones tienen entre el código y producción. Es un blanco con palanca enorme: una sola compromisión escala a todos los repositorios que confían en el action.

El reporte técnico publicado por Wiz Research y corroborado por SafeDep y otros equipos de inteligencia documenta que el alcance fue exactamente eso: 75 de 76 tags del action force-pusheados a versiones maliciosas, 7 tags de setup-trivy también, el binario v0.69.4 distribuido durante aproximadamente tres horas en los registros oficiales, y más de 135 paquetes maliciosos en npm como vector secundario.

El vector: pull_request_target mal configurado, otra vez

Igual que en el caso de Bitwarden CLI tres semanas después, el punto de entrada fue un workflow de GitHub Actions configurado con pull_request_target en lugar de pull_request. La diferencia entre los dos triggers parece sutil pero es la grieta más explotada del ecosistema reciente.

Cuando un workflow se dispara con pull_request_target, GitHub lo ejecuta con los secretos de nivel repositorio del proyecto destino, pero corriendo el código del fork del atacante. Es decir: cualquiera puede abrir un pull request que ejecute código arbitrario en el contexto autenticado del repo objetivo. El feature existe por razones legítimas —por ejemplo, etiquetar PRs según contenido sin exponer secretos al fork— pero el manejo seguro requiere disciplina que muy pocos proyectos tienen.

TeamPCP encontró esa configuración en la cadena de Aqua, ejecutó código arbitrario con los privilegios del repo y desde ahí pivoteó. Una vez con tokens de mantenedores, force-pusheó tags Git en los repositorios trivy-action y setup-trivy. Force-push a tags es la pieza clave: los tags Git no son inmutables, y muchos proyectos los referencian en lugar de pinear por SHA. Cuando un workflow consumidor hace uses: aquasecurity/[email protected], va a buscar el tag, no el commit. Si el tag fue reescrito, descarga código distinto al que estaba allí ayer.

Cronología del compromiso

El reporte de Wiz reconstruye una ventana de actividad sostenida durante casi cuatro semanas:

• 27 de febrero, 2026 — Inicio de la campaña, primer movimiento documentado contra Aqua.
• 19 de marzo, 17:43:37 UTC — Push del tag v0.69.4 con el binario Trivy malicioso.
• 19-20 de marzo — Ventana de compromiso activo de GitHub Actions.
• 22 de marzo, ~16:00 UTC — Imágenes Docker maliciosas 0.69.5 y 0.69.6 publicadas en registros.
• 22 de marzo — Expansión al ecosistema npm con un componente bautizado CanisterWorm.
• 23 de marzo — Compromisión de kics-github-action (Aqua/Checkmarx KICS, otro escáner del mismo grupo de productos).
• 22 de marzo — Cierre de la ventana activa, cuando Aqua revierte tags.

Wiz también identificó commits con identidades suplantadas en el repositorio: TeamPCP firmó cambios falsificando los autores rauchg y DmitriyLewen, dos nombres reconocibles del ecosistema GitHub. La técnica no es nueva pero resulta efectiva contra revisores que confían en las cabeceras de los commits sin verificar firmas GPG.

Qué hace el payload

El entrypoint.sh malicioso ejecuta tres etapas en cascada.

Primera etapa — recolección. En los runners de GitHub Actions, el malware escala privilegios y scrapea memoria del proceso Runner.Worker vía /proc/<pid>/mem. Busca específicamente el patrón JSON {"value":"<secret>","isSecret":true}, que es exactamente el formato con el que GitHub enmascara secretos en memoria. En paralelo, cosecha SSH keys del filesystem, credenciales de cloud, tokens de Kubernetes, configs de Docker Hub, GPG keys, secretos de Twitter y Slack, y carteras de criptomonedas. En máquinas de desarrollador donde el binario malicioso fue instalado, escribe además un dropper Python codificado en base64 y mantiene persistencia a través de un systemd unit llamado sysmon.py.

Segunda etapa — cifrado. Todo el material exfiltrado se empaqueta en un archivo tpcp.tar.gz, cifrado con un esquema híbrido AES-256-CBC + RSA-4096. El esquema híbrido es lo que se espera de una operación profesional: la sesión usa AES (rápido, simétrico), y la llave AES se envuelve con RSA-4096 (asimétrico, costoso pero solo aplicado a la llave). El operador ofensivo recibe los paquetes cifrados sin que el receptor del exfil pueda descifrarlos sin la llave privada.

Tercera etapa — exfiltración. El canal primario es HTTPS hacia un dominio typosquatted: scan.aquasecurtiy[.]org (nótese la inversión del par «ti» → «tt-i» en el dominio falso, una variante visualmente cercana a aquasecurity.org). Como mecanismo de respaldo, el malware sube los paquetes cifrados a repositorios públicos de GitHub bajo el nombre tpcp-docs, una técnica de «covert channel» que aprovecha que GitHub permite tráfico de salida desde casi cualquier red corporativa.

CanisterWorm — la innovación de C2 sobre ICP

El componente más novedoso técnicamente no es ninguno de los anteriores. Es CanisterWorm: la primera campaña documentada que utiliza Internet Computer Protocol (ICP) canisters como infraestructura de comando y control. ICP es una plataforma blockchain descentralizada para ejecutar smart contracts (canisters) que pueden servir HTTP. Al usar canisters como C2, los operadores ofensivos consiguen tres propiedades difíciles de igualar con C2 tradicional: rotación de payload cada 50 minutos, ausencia de un punto único de takedown porque los canisters viven en una red distribuida, y tráfico que se ve como llamadas legítimas a una blockchain pública.

Para los equipos defensivos esto es mala noticia operacional: las reglas de detección de C2 que dependen de IP/dominio bien identificados no se aplican aquí. Detectar tráfico anómalo hacia canisters ICP exige pivots distintos a los habituales con CDN, HTTP redirect chains o domain generation algorithms.

Quiénes son TeamPCP y qué relación tienen con Shai-Hulud

TeamPCP —»PCP Cats»— se atribuyó la operación con commits firmados con su propio handle. Es el mismo cluster atribuido a la oleada Shai-Hulud que comprometió Bitwarden CLI el 22 de abril de 2026, descrita en nuestra cobertura previa. La narrativa unificada se sostiene: Trivy en marzo, KICS y LiteLLM en paralelo, Bitwarden en abril, todos con el mismo patrón de explotación de pull_request_target en la cadena de suministro de tooling de seguridad. El grupo demostró acceso continuado a Aqua incluso después de que la compañía revirtiera los tags maliciosos: publicó repositorios internos de Aqua en GitHub público, una señal explícita destinada a humillar la respuesta institucional.

La segunda ola: ShinyHunters extorsiona a Cisco

Independiente del incidente de Trivy y operando con métodos completamente distintos, el grupo ShinyHunters publicó el 31 de marzo de 2026 un listing en un foro de la dark web con un ultimátum dirigido a Cisco. El claim, recogido por CyberPress, Infosec Bulletin y TechChannel News, exige que Cisco contacte al grupo antes del 3 de abril de 2026, o los datos serán liberados públicamente.

El alcance reclamado:

• Más de 3 millones de registros de Salesforce con datos personales identificables.
• Acceso vía tres vectores distintos: Salesforce CRM, Salesforce Aura (Experience Cloud) y entornos AWS de Cisco.
• Repositorios de GitHub y buckets AWS S3.
• Volúmenes EC2 con fechas de creación entre el 16-17 de marzo de 2026 sugiriendo acceso reciente y persistente.

CyberPress reporta además que el dataset incluiría registros vinculados a personal de FBI, DHS, DISA, IRS, NASA, el Ministerio de Defensa Australiano y múltiples agencias gubernamentales de la India. Investigadores que examinaron las screenshots publicadas por ShinyHunters como prueba las califican de «plausibles» pero advierten que no se ha subido data verificable y la afirmación sigue, hasta el cierre de esta nota, sin validación independiente. Cisco no ha emitido declaración pública sobre este claim, en línea con su práctica habitual cuando los datos no son verificables.

El método de ShinyHunters: vishing y OAuth tokens, no Trivy

Aquí es donde la narrativa popular se equivoca. Varios análisis publicados durante la primera semana de abril asumieron que el robo a Cisco se ejecutó vía la compromisión de Trivy, basándose en la coincidencia temporal y en que Aqua KICS y Checkmarx KICS son el mismo escáner. La hipótesis es razonable pero no se sostiene con la evidencia disponible. El propio ShinyHunters describe su método en el listing, y los reportes técnicos lo confirman:

1. Vishing —voice phishing— atribuido al cluster UNC6040. Los operadores llaman por teléfono a empleados haciéndose pasar por IT support y los persuaden de instalar software o aprobar un OAuth scope amplio en su sesión activa. Es ingeniería social pura, no explotación de código.
2. Vulnerabilidades de Salesforce Aura (Experience Cloud) para escalar privilegios una vez dentro.
3. Cuentas AWS comprometidas, probablemente vía las credenciales obtenidas en los pasos anteriores.

Es una cadena de identidad, no de código. Los OAuth tokens que ShinyHunters obtuvo permiten saltarse MFA y otros controles porque ya están post-autenticación. Y por eso el incidente no aparece en logs de phishing tradicional ni en alertas de malware: para el SIEM corporativo, son sesiones legítimas de usuarios autorizados haciendo cosas que sus roles permiten.

ShinyHunters en 2026: una racha imparable

El grupo lleva siete años activo y vio en 2026 un repunte de actividad significativo, según el perfil consolidado en Wikipedia. Se atribuye, además del caso Cisco:

• Comisión Europea (30 de marzo de 2026): 350 GB exfiltrados, incluyendo archivos NextCloud, sistema Athena, signing keys de la PKI institucional, mail servers, dumps de bases de datos y código. La infraestructura comprometida estaría vinculada a Europa.eu sobre AWS. Detalle técnico cubierto por eBuilder Security. La Comisión confirmó el ciberataque pero negó la magnitud reportada.
• Rockstar Games: aproximadamente 80 millones de registros, vía sistemas linkeados a cloud.
• Telus: claim de 1 petabyte de datos.
• Universidades: Harvard, Princeton, University of Pennsylvania.
• Odido (telecom holandesa): 6.2 millones de usuarios, en febrero.

ShinyHunters reportadamente se fusionó en 2026 con el grupo Scattered Spider, formando un supergroup que opera contra más de 100 organizaciones simultáneamente. Las arrestos previos de afiliados —Sébastien Raoult sentenciado a 3 años en 2024, Matthew D. Lane que se declaró culpable en el caso PowerSchool en 2025, cuatro detenidos en Francia en junio de 2025— no pararon la operación: el liderazgo opera bajo seudónimos y los arrestados fueron afiliados, no los operadores centrales.

Cómo defenderse: lecciones operacionales

El primer instinto al leer estos casos es defensivo individual («¿está mi pipeline pinneando por SHA?»). Es necesario pero insuficiente. Las lecciones más importantes están en el lado sistémico:

Pin por SHA, no por tag. Tanto en GitHub Actions como en Docker images. El force-push a tags es un vector activo. Si tu workflow consume aquasecurity/[email protected] y un día ese tag apunta a otro commit, no te enterás. Si lo consume por SHA (aquasecurity/trivy-action@a1b2c3d4...), tu workflow falla el día del compromiso pero no ejecuta código malicioso.

Auditá tus dependencias de tooling de seguridad con la misma severidad que tus dependencias de runtime. El razonamiento «es una herramienta de seguridad, no la cuestionemos» es exactamente la asunción que TeamPCP explotó. Aqua, Checkmarx, Snyk, todos los escáneres mainstream han sido o pueden ser víctimas. La compromisión de tu escáner es peor que la compromisión de tu app, porque te quita la capacidad de detectarla.

Revisá pull_request_target en todos los workflows. Cualquier workflow disparado por ese trigger debe ejecutar únicamente código de la rama base, no del fork. Si necesita comportamiento del fork, debe ser en un workflow separado disparado por pull_request que no tenga acceso a secretos.

Vishing es un control administrativo, no técnico. Ningún parche elimina el ataque a tu helpdesk. Lo que reduce el riesgo es entrenamiento, doble validación de aprobaciones de OAuth scopes amplios, segregación de tokens por integración, y rotación periódica de credenciales privilegiadas. Una llamada de 4 minutos puede burlar a un SIEM de 4 millones.

Tratá los OAuth scopes como pólvora. Cualquier integración que pida *.read.all o admin.* debería pasar por revisión humana explícita, con documentación del por qué. Si la respuesta es «no lo sé, lo aprobé porque me lo pidieron en una llamada», ya estás dentro del manual de ShinyHunters.

Por qué este mes importa

Marzo y abril de 2026 quedarán como referencia en la literatura de seguridad por dos razones combinadas. La primera es la escala simultánea: dos grupos sin relación demostrada entre sí ejecutaron operaciones de gran impacto en un margen de menos de tres semanas, contra blancos estructurales del ecosistema (un escáner de vulnerabilidades líder, un fabricante de hardware con presencia global, instituciones gubernamentales con datos sensibles). La segunda es la diversidad de métodos: un ataque puramente técnico de cadena de suministro de código vs un ataque puramente humano de cadena de suministro de identidad, ambos efectivos, ambos difíciles de detectar con stacks de defensa tradicionales.

La conclusión incómoda es que la industria sigue protegiendo perímetros que ya no existen. Los atacantes ya no necesitan romper el perímetro: comprometen el código que va a entrar al perímetro, o convencen al humano que tiene la llave. Cualquiera de las dos es más barata que un zero-day y, como demuestra este mes, escalable a clientes que el atacante nunca tocó directamente.

Fuentes

• Wiz Research — Trivy Compromised: TeamPCP Supply Chain Attack
• SafeDep — Trivy & TeamPCP: Supply Chain Compromise
• CyberPress — Cisco Source Code and Data Leak Allegedly Claimed by ShinyHunters
• Infosec Bulletin — ShinyHunters Claim to Hit Cisco: 3M Salesforce Records
• TechChannel News — ShinyHunters Claims Data Theft Targeting Cisco
• eBuilder Security — ShinyHunters European Commission AWS Data Breach
• Wikipedia — ShinyHunters