Una organización que figuraba en el archivo de credenciales de TeamPCP comunicó a Kevin Beaumont que se había solucionado el problema de seguridad y que todas las credenciales se habían renovado. Él consultó su política de divulgación responsable, confirmó que permitía probar las credenciales y las probó.
Se trata de una sola publicación, de una sola organización, y Beaumont no ha revelado su nombre. Tómalo como un único dato. Pero es un dato sobre la distancia que hay entre un ticket de corrección cerrado y una credencial revocada, y hay un segundo dato, procedente de la primera víctima de la cadena.
Lo que aportaron las revelaciones de agosto
En julio escribí sobre el archivo de credenciales de TeamPCP y sostuve que el riesgo de verse afectado por la campaña del ransomware VECT dependía de si tus tokens de cloud figuraban en él. En agosto, el archivo ya tenía un tamaño concreto y una lista de víctimas.
- CloudSEK, 11 de agosto: más de 2.500 organizaciones y aproximadamente 434.000 procesos de CI/CD.
- Hudson Rock, 12 de agosto: un archivo de 153 GB con 433 909 archivos, obtenidos y analizados, con 118 829 volcados de CI Runner atribuidos a 2 488 dominios corporativos.
Lee la advertencia de CloudSEK que precede al titular. Sus cifras «describen una exposición reconstruida» y «no deben interpretarse como prueba de que todas las organizaciones incluidas en la lista hayan sido vulneradas con éxito ni de que se hayan sustraído todas las credenciales». La presencia en el conjunto de datos es un motivo para investigar, no una filtración confirmada. La publicación de Hudson Rock no incluye ninguna salvedad equivalente, lo cual conviene tener en cuenta al comparar ambas listas.
Ambas empresas mencionan las organizaciones con las que se ha detectado una coincidencia. No voy a repetir esos nombres aquí. Una coincidencia de exposición reconstruida no equivale a una filtración confirmada, y esa distinción se pierde cuando se convierte en una lista de nombres de empresas.
Ninguna de las dos empresas publicó el archivo. Hudson Rock lo integró en su plataforma Cavalier y lleva a cabo un proceso de divulgación individualizado por víctima; CloudSEK realiza una búsqueda en el dominio público. No está claro si el corpus está circulando más ampliamente, y las personas más cercanas al asunto no se ponen de acuerdo:
- Alon Gal, de Hudson Rock, declaró a Help Net Security que «por el momento no se ha filtrado en ningún sitio y no está circulando de forma generalizada».
- Beaumont, esa misma semana, afirmó que «en estos momentos circulan por Internet terabytes de credenciales».
- SOCRadar ha detectado que un intermediario en Telegram ofrecía un paquete con datos de LiteLLM, Trivy y CanisterWorm que, una vez comprimidos, ocupaban más de 150 GB, lo que se interpreta como que un único vendedor posee dicha colección, en lugar de que se trate de una amplia difusión.
Esa distinción determina la rapidez con la que cabe esperar que se utilicen las credenciales. No cambia el hecho de que se copiaran en marzo.
El margen es mayor que el que todos habían indicado
Esto corrige mi publicación de julio tanto como cualquier otra información publicada.
La campaña se denominó «la filtración de LiteLLM», en referencia a los aproximadamente 40 minutos del 24 de marzo en los que los paquetes maliciosos permanecieron en PyPI. SOCRadar analizó las marcas de tiempo de los 2.188 registros de organizaciones y descubrió que la exposición se había producido antes:
- Primera entrada registrada: 19 de marzo, a las 18:05 UTC
- Última actualización: 24 de marzo, 20:09 UTC
- Registros que muestran actividades de cobro anteriores al 24 de marzo, es decir, antes de que se pusieran en marcha los paquetes LiteLLM: 2.085 de 2.188, lo que supone un 95 por ciento.
SOCRadar interpreta que esa cronología apunta a la intrusión en Trivy, en lugar de a la ventana de instalación de LiteLLM, y SecurityWeek lo planteó de la misma manera el 14 de agosto. La formulación de SOCRadar es la que hay que tener en cuenta: los 40 minutos fueron el acto final, no toda la obra.
Por lo tanto, la búsqueda en los registros limitada al 24 de marzo era demasiado restrictiva. Esa fecha sigue siendo relevante si instalaste las versiones infectadas, pero la mayor parte de la exposición es anterior a ella.
El propio proceso de corrección de Trivy es el caso práctico
Una de las razones por las que falla la rotación queda patente en la primera víctima.
Aqua revocó las credenciales el 1 de marzo, lo que afectó a las identidades de automatización que los investigadores sabían que se habían visto comprometidas. La línea temporal de CloudSEK, leída junto con la cronología de Aqua y el registro del NVD correspondiente a CVE-2026-33634, describe lo que ocurrió a continuación. La actividad continuó a través de un usuario y un token diferentes. El token detectado durante el periodo del 1 de marzo reapareció en una actividad maliciosa el 19 de marzo. El 22 de marzo, una cuenta de servicio que nadie había considerado comprometida accedió a 43 repositorios de otra organización. CloudSEK reconstruye un periodo aproximado de 20 días en los que un token de automatización siguió siendo utilizable tras su rotación, y señala esa cifra como una reconstrucción propia, más que como un intervalo forense verificado.
Flare lo expresa de forma más directa: «Aqua renovó las credenciales, pero se le pasaron algunas por alto. El acceso restante se mantuvo».
Las credenciales no se invalidaron simultáneamente, lo que dejó al menos una identidad operativa mientras se emitían los secretos de sustitución. La conclusión que CloudSEK extrajo de ello, expresada como una inferencia, es la siguiente: si una identidad que seguía activa pudiera acceder a los secretos recién rotados, la rotación de tokens individuales no eliminaría necesariamente al intruso. Al ejecutarse como una secuencia de sustituciones de tokens, en lugar de como un único evento de contención que abarque todas las identidades de la ruta de liberación, la rotación corre el riesgo de entregar al atacante su propio resultado.
«Lo hemos rotado todo» y «las credenciales ya no funcionan» son afirmaciones diferentes. Solo la segunda es comprobable, y la de Beaumont es la única comprobación pública que he visto al respecto.
La mitad a la que nadie puede llegar
El segundo modo de fallo se debe al modelo de divulgación y no a ninguna víctima en concreto.
Hudson Rock resolvió 118 829 volcados de memoria de ejecutables asociados a dominios concretos, y es muy claro respecto a lo que no pudo resolver: un gran número de archivos «contienen secretos altamente confidenciales, pero carecen por completo de una atribución organizativa clara». Esas organizaciones tienen secretos activos en el corpus y no tienen forma de saberlo. GitGuardian expuso claramente las consecuencias el 14 de agosto: ninguna de las dos empresas puede notificar a una compañía a la que no puede identificar, la divulgación responsable requiere una dirección, y un ejecutor de CI configurado de forma genérica no deja ninguna.
Por lo tanto, el hecho de que no aparezca en una herramienta de búsqueda es una prueba poco sólida. Si ejecutaste las acciones de Trivy afectadas o LiteLLM 1.82.7 o 1.82.8 en esa ventana, tus propios registros del pipeline responden a la cuestión de la exposición, no a si un investigador podría asociar tu ejecutor a un dominio.
¿Por qué se llama «Gap 2»?
Una clave de AWS, un token de repositorio, una cuenta de servicio de Kubernetes o una clave de proveedor de modelos sustraídos se autentican a través de la misma interfaz que utiliza el pipeline, desde una infraestructura que parece automatizada, y realizan operaciones para las que la identidad está autorizada. El proveedor « cloud » registra una llamada a la API realizada con éxito por parte de un sujeto reconocido. La autenticación se realiza con éxito. No se produce ningún ataque en ninguna fase de la actividad posterior.
Cuando la credencial sigue siendo válida, el resultado de la autenticación no aporta ninguna información, ya que el resultado es «éxito». Sin embargo, sí que se registran señales durante el inicio de sesión —como una red desconocida o un cliente inusual—, y merece la pena alertar sobre ellas. Las señales duraderas son de carácter conductual: una cuenta de servicio que accede a un recurso al que nunca ha accedido, o un token caducado que sigue presentándose y siendo aceptado. Cada una de ellas puede explicarse de forma individual, pero no en su conjunto.
Qué hacer esta semana
Comprueba la rotación en lugar del ticket. Para cada clase de credencial a la que pueda acceder el proceso afectado, confirma que el valor anterior ya no se acepta:
- Cloud claves y cualquier dato que se pueda leer del servicio de metadatos de la instancia
- Tokens de repositorio, registro y publicación de paquetes
- Claves SSH y cuentas de servicio de Kubernetes
.envcontenidos, direcciones URL de bases de datos y claves de proveedores de IA
El enfoque de Flare es el que hay que tener en cuenta en una revisión de medidas correctivas: considerar la rotación como una tarea de inventario, no como una tarea derivada de un incidente. Solo funciona si se conoce el conjunto completo y, tal y como señala CloudSEK, la ausencia de registros no es prueba de que nunca se haya copiado una credencial.
A continuación, amplía la búsqueda desde el 27 de febrero hasta finales de marzo:
- Cuentas de servicio de Pipeline que se autentican en el entorno de producción
- Repositorios denominados
docs-tpcpotpcp-docsdentro de tu propia organización - Cualquier token emitido antes de abril de 2026 que siga en uso
El capítulo «La brecha 2» de Mind Your Attack Gaps trata el mismo modo de fallo a través de la cadena de asistencia técnica « Scattered Spider », en la que la credencial era legítima y el inicio de sesión se realizó correctamente. En « Vectra AI » modelamos cómo se comporta una identidad tras la autenticación, a través de cloud, la identidad y la red, que es donde se hace visible un token válido robado.
El archivo data de marzo. Si en septiembre sigue siendo relevante es una pregunta que puede responder tu almacén de credenciales.
---
Aviso: Vectra AI aparece en el conjunto de datos de CloudSEK. Una acción de GitHub de Trivy comprometida se ejecutó en un conjunto limitado de nuestros flujos de trabajo de CI/CD los días 19 y 20 de marzo, lo que expuso metadatos de compilación y credenciales de corta duración específicas para cada trabajo. Lo identificamos internamente, sustituimos las herramientas y rotamos las credenciales pertinentes en cuestión de horas, y volvimos a comprobar nuestros registros cotejándolos con los hallazgos de CloudSEK en agosto. Nuestra declaración completa se encuentra aquí.