TeamPCP Backdoors LiteLLM Versiones 1.82.7–1.82.8 Probablemente a través del compromiso Trivy CI/CD – CYBERDEFENSA.MX

TeamPCP, el actor de amenazas detrás de los recientes compromisos de Trivy y KICS, ahora ha comprometido un popular paquete de Python llamado litelmoimpulsando dos versiones maliciosas que contienen un recolector de credenciales, un conjunto de herramientas de movimiento lateral de Kubernetes y una puerta trasera persistente.

Múltiples proveedores de seguridad, incluidos Laboratorios Endor y JFrogreveló que las versiones 1.82.7 y 1.82.8 de Litellm eran publicado el 24 de marzo de 2026, probablemente debido a la uso del paquete de Trivy en su flujo de trabajo CI/CD. Desde entonces, ambas versiones con puerta trasera se han eliminado de PyPI.

«La carga útil es un ataque de tres etapas: un recolector de credenciales que barre claves SSH, credenciales de nube, secretos de Kubernetes, billeteras de criptomonedas y archivos .env; un conjunto de herramientas de movimiento lateral de Kubernetes que implementa pods privilegiados en cada nodo; y una puerta trasera persistente systemd (sysmon.service) que sondea ‘checkmarx[.]zona/sin procesar’ para binarios adicionales», dijo el investigador de Endor Labs, Kiran Raj.

Ciberseguridad

Como se observó en casos anteriores, los datos recopilados se extraen como un archivo cifrado («tpcp.tar.gz») a un dominio de comando y control llamado «models.litellm».[.]nube» a través de una solicitud HTTPS POST.

En el caso de 1.82.7, el código malicioso está incrustado en el archivo «litellm/proxy/proxy_server.py», y la inyección se realiza durante o después del proceso de creación de la rueda. El código está diseñado para ejecutarse en el momento de la importación del módulo, de modo que cualquier proceso que importe «litellm.proxy.proxy_server» active la carga útil sin requerir ninguna interacción del usuario.

La siguiente iteración del paquete agrega un «vector más agresivo» al incorporar un «litellm_init.pth» malicioso en la raíz de la rueda, lo que hace que la lógica se ejecute automáticamente en cada inicio de proceso Python en el entorno, no solo cuando se importa litellm.

Otro aspecto que hace que 1.82.8 sea más peligroso es el hecho de que el iniciador .pth genera un proceso secundario de Python a través de subproceso.Popenque permite que la carga útil se ejecute en segundo plano.

«Los archivos Python .pth colocados en los paquetes del sitio son procesados ​​automáticamente por site.py al iniciar el intérprete», dijo Endor Labs. «El archivo contiene una sola línea que importa un subproceso e inicia un proceso Python independiente para decodificar y ejecutar la misma carga útil Base64».

La carga útil se decodifica en un orquestador que descomprime un recolector de credenciales y un cuentagotas de persistencia. El recolector también aprovecha el token de la cuenta de servicio de Kubernetes (si está presente) para enumerar todos los nodos del clúster e implementar un pod privilegiado en cada uno de ellos. La vaina entonces chroots en el sistema de archivos del host e instala el cuentagotas de persistencia como un servicio de usuario systemd en cada nodo.

El servicio systemd está configurado para iniciar un script de Python («~/.config/sysmon/sysmon.py»), el mismo nombre utilizado en el compromiso Trivy, que llega a «checkmarx[.]zona/raw» cada 50 minutos para obtener una URL que apunte a la carga útil de la siguiente etapa. Si la URL contiene youtube[.]com, el script aborta la ejecución, un patrón de interrupción común a todos los incidentes observados hasta ahora.

«Es casi seguro que esta campaña no ha terminado», dijo Endor Labs. «TeamPCP ha demostrado un patrón consistente: cada entorno comprometido genera credenciales que desbloquean el siguiente objetivo. El giro de CI/CD (ejecutores de GitHub Actions) a producción (paquetes PyPI que se ejecutan en clústeres de Kubernetes) es una escalada deliberada».

Con el último desarrollo, TeamPCP ha emprendido una incesante campaña de ataque a la cadena de suministro que ha generado cinco ecosistemas, incluidos GitHub Actions, Docker Hub, npm, Open VSX y PyPI, para expandir su huella de objetivos y poner cada vez más sistemas bajo su control.

«TeamPCP está intensificando una campaña coordinada dirigida a herramientas de seguridad e infraestructura de desarrollo de código abierto, y ahora se está atribuyendo abiertamente el mérito de múltiples ataques posteriores en todos los ecosistemas», Socket dicho. «Esta es una operación sostenida que apunta a puntos de alto apalancamiento en la cadena de suministro de software».

en un mensaje al corriente En su canal de Telegram, TeamPCP dijo: «Estas empresas fueron creadas para proteger sus cadenas de suministro, pero ni siquiera pueden proteger las suyas propias, el estado de la investigación de seguridad moderna es una broma, como resultado, estaremos por mucho tiempo robando terrabytes». [sic] de secretos comerciales con nuestros nuevos socios».

«El efecto bola de nieve de esto será enorme, ya nos estamos asociando con otros equipos para perpetuar el caos, muchas de sus herramientas de seguridad favoritas y proyectos de código abierto serán atacados en los próximos meses, así que estén atentos», dijo el actor de amenazas. agregado.

Ciberseguridad

Se recomienda a los usuarios que realicen las siguientes acciones para contener la amenaza:

  • Audite todos los entornos para las versiones 1.82.7 o 1.82.8 de Litellm y, si los encuentra, vuelva a una versión limpia.
  • Aislar los huéspedes afectados
  • Verifique la presencia de pods no autorizados en los clústeres de Kubernetes
  • Revise los registros de red para ver el tráfico de salida a «models.litellm[.]nube» y «checkmarx[.]zona»
  • Eliminar los mecanismos de persistencia.
  • Audite las canalizaciones de CI/CD para detectar el uso de herramientas como Trivy y KICS durante las ventanas de compromiso.
  • Revocar y rotar todas las credenciales expuestas

«La cadena de suministro de código abierto se está derrumbando sobre sí misma», dijo Gal Nagli, jefe de exposición a amenazas en Wiz, propiedad de Google. dicho en una publicación en X. «Trivy se ve comprometido → LiteLLM se ve comprometido → las credenciales de decenas de miles de entornos terminan en manos de atacantes → y esas credenciales conducen al siguiente compromiso. Estamos atrapados en un bucle».

Los expertos advierten sobre una ola de extorsión «ruidosa y agresiva» tras el hackeo de Trivy

SAN FRANCISCO – Mandiant está respondiendo a un importante ataque en curso a la cadena de suministro que involucra el compromiso de Trivy, una herramienta de código abierto ampliamente utilizada de Aqua Security que está diseñada para encontrar vulnerabilidades y configuraciones erróneas en repositorios de código.

Las consecuencias del ataque, que se detectó por primera vez el 19 de marzo, son extensas y plantean un riesgo sustancial de compromisos posteriores e intentos amenazantes de extorsión.

«Conocemos más de 1.000 entornos SaaS afectados en este momento que están lidiando activamente con esta campaña de amenazas en particular», dijo Charles Carmakal, director de tecnología de Mandiant Consulting, durante una sesión informativa sobre amenazas celebrada junto con la Conferencia RSAC 2026. “Esas más de mil víctimas probablemente se expandirán a otras 500, otras 1.000, tal vez otras 10.000”.

Los atacantes robaron un token de acceso privilegiado y establecieron un punto de apoyo en el proceso de automatización del repositorio de Trivy explotando una mala configuración en el entorno GitHub Actions de la herramienta a finales de febrero, dijo Aqua Security en un publicación de blog.

El 1 de marzo, la empresa intentó bloquear una infracción en curso cambiando sus credenciales. Más tarde se dieron cuenta de que el intento falló, lo que permitió al atacante permanecer en el sistema utilizando inicios de sesión válidos. Los atacantes publicaron versiones maliciosas de Trivy el 19 de marzo.

«Si bien esta actividad inicialmente pareció ser un evento aislado, fue el resultado de un ataque más amplio y de múltiples etapas a la cadena de suministro que comenzó semanas antes», dijo Aqua Security en la publicación del blog.

Al comprometer la herramienta, los atacantes obtuvieron acceso a secretos de muchas organizaciones, dijo Carmakal. «Probablemente habrá muchos otros paquetes de software, ataques a la cadena de suministro y una variedad de otros compromisos como resultado de lo que está sucediendo en este momento».

Mandiant espera que en los próximos meses se produzcan revelaciones generalizadas de infracciones, ataques posteriores y una variedad de impactos posteriores.

Los atacantes, que la empresa de respuesta a incidentes aún no ha identificado, están colaborando con múltiples grupos de amenazas con sede principalmente en Estados Unidos, Canadá y el Reino Unido. Estos ciberdelincuentes “son conocidos por ser excepcionalmente agresivos con su extorsión”, dijo Carmakal. «Son muy ruidosos, muy agresivos».

Mandiant todavía está trabajando para identificar la raíz del ataque inicial. «No podemos decir exactamente cómo se robaron esas credenciales, porque creemos que esas credenciales no fueron robadas del entorno de la víctima», dijo Carmakal.

Las credenciales probablemente fueron robadas de otro entorno de nube, un subcontratista de procesos comerciales, un socio o la computadora personal de un ingeniero, agregó.

Aqua dijo que Sygnia, que está investigando el ataque y ayudando en los esfuerzos de remediación, identificó el domingo actividad sospechosa adicional que involucra cambios no autorizados y cambios en el repositorio, actividad que es consistente con el comportamiento observado previamente del atacante.

«Este desarrollo sugiere que el incidente es parte de un ataque continuo y en evolución, en el que el actor de la amenaza restablece el acceso. Nuestra investigación se centra activamente en validar que todas las rutas de acceso hayan sido identificadas y completamente cerradas», dijo la compañía.

Aqua, en su última actualización del martes, dijo que continúa revocando y rotando credenciales en todos los entornos y afirmó que todavía no hay indicios de que sus productos comerciales se vean afectados.

Actualmente, muchos atacantes están utilizando el acceso como arma y probablemente apuntan a víctimas adicionales, cediendo a posibles intentos de extorsión y comprometiendo software adicional, dijo Carmakal.

«Va a ser un resultado diferente para muchas organizaciones diferentes», afirmó. «Este será un foco muy concentrado de los adversarios y su grupo de expansión de socios con los que están colaborando en este momento».

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

Trivy Hack difunde Infostealer a través de Docker, Triggers Worm y Kubernetes Wiper – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han descubierto artefactos maliciosos distribuidos a través de Docker Hub luego del ataque a la cadena de suministro de Trivy, destacando el creciente radio de explosión en los entornos de desarrolladores.

La última liberación limpia conocida de trivia en Docker Hub es 0.69.3. Desde entonces, las versiones maliciosas 0.69.4, 0.69.5 y 0.69.6 se eliminaron de la biblioteca de imágenes del contenedor.

«Las nuevas etiquetas de imagen 0.69.5 y 0.69.6 se publicaron el 22 de marzo sin las correspondientes versiones o etiquetas de GitHub. Ambas imágenes contienen indicadores de compromiso asociados con el mismo ladrón de información de TeamPCP observado en etapas anteriores de esta campaña», dijo el investigador de seguridad de Socket, Philipp Burckhardt. dicho.

El desarrollo se produce a raíz de un compromiso de la cadena de suministro de Trivy, un popular escáner de vulnerabilidades de código abierto mantenido por Aqua Security, que permite a los actores de amenazas aprovechar una credencial comprometida para impulsar a un ladrón de credenciales dentro de versiones troyanizadas de la herramienta y dos acciones de GitHub relacionadas «aquasecurity/trivy-action» y «aquasecurity/setup-trivy».

Ciberseguridad

El ataque ha tenido impactos posteriores, ya que los atacantes aprovecharon los datos robados para comprometer docenas de paquetes npm y distribuir un gusano autopropagante conocido como CanisterWorm. Se cree que el incidente es obra de un actor de amenazas rastreado como TeamPCP.

Según el equipo de OpenSourceMalware, los atacantes han desfigurado los 44 repositorios internos asociados con Aqua Security.aquasec-com» organización GitHub cambiando el nombre de cada uno de ellos con el prefijo «tpcp-docs-«, estableciendo todas las descripciones en «TeamPCP posee Aqua Security» y exponiéndolas públicamente.

Se dice que todos los repositorios se modificaron en una ráfaga programada de 2 minutos entre las 20:31:07 UTC y las 20:32:26 UTC del 22 de marzo de 2026. Se ha evaluado con alta confianza que el actor de amenazas aprovechó una cuenta de servicio «Argon-DevOps-Mgt» comprometida para este propósito.

«Nuestro análisis forense de la API de GitHub Events apunta a un token de cuenta de servicio comprometido, probablemente robado durante el compromiso anterior de Trivy GitHub Actions de TeamPCP, como vector de ataque», dijo el investigador de seguridad Paul McCarty. dicho. «Esta es una cuenta de servicio/bot (ID de GitHub 139343333, creada el 12 de julio de 2023) con una propiedad crítica: une ambas organizaciones de GitHub».

«Un token comprometido para esta cuenta le da al atacante acceso de escritura/administración a ambas organizaciones», agregó McCarty.

El desarrollo es la última escalada de un actor de amenazas que se ha ganado una reputación por apuntar a infraestructuras de nube, mientras construye progresivamente capacidades para exponer sistemáticamente las API de Docker, los clústeres de Kubernetes, los paneles de Ray y los servidores Redis para robar datos, implementar ransomware, realizar extorsión y extraer criptomonedas.

Su creciente sofisticación se ejemplifica mejor con la aparición de un nuevo malware de limpieza que se propaga a través de SSH a través de claves robadas y explota las API de Docker expuestas en el puerto 2375 en toda la subred local.

Se ha descubierto que una nueva carga útil atribuida a TeamPCP va más allá del robo de credenciales y borra clústeres completos de Kubernetes (K8) ubicados en Irán. El script de shell utiliza el mismo recipiente ICP vinculado a CanisterWorm y luego ejecuta comprobaciones para identificar los sistemas iraníes.

Ciberseguridad

«En Kubernetes: implementa DaemonSets privilegiados en cada nodo, incluido el plano de control», investigador de seguridad de Aikido, Charlie Eriksen. dicho. «Los nodos iraníes se borran y se reinician a la fuerza a través de un contenedor llamado ‘kamikaze’. Los nodos no iraníes instalan la puerta trasera CanisterWorm como un servicio systemd. Los hosts iraníes que no son K8 obtienen ‘rm -rf / –no-preserve-root’».

Dada la naturaleza continua del ataque, es imperativo que las organizaciones revisen su uso de Trivy en las canalizaciones de CI/CD, eviten el uso de versiones afectadas y traten cualquier ejecución reciente como potencialmente comprometida.

«Este compromiso demuestra la larga cola de ataques a la cadena de suministro», dijo OpenSourceMalware. «Una credencial obtenida durante el compromiso de Trivy GitHub Actions hace meses fue utilizada como arma hoy para desfigurar toda una organización interna de GitHub. La cuenta de servicio Argon-DevOps-Mgt, una única cuenta de bot que une dos organizaciones con un PAT de larga duración, era el eslabón débil».

«Desde la explotación de la nube hasta los gusanos de la cadena de suministro y los limpiadores de Kubernetes, están creando capacidades y apuntando al propio ecosistema de proveedores de seguridad. La ironía de que una empresa de seguridad en la nube se vea comprometida por un actor de amenazas nativo de la nube no debe pasar desapercibida para la industria.

El ataque de Trivy a la cadena de suministro desencadena un gusano bote que se propaga automáticamente en paquetes de 47 npm – CYBERDEFENSA.MX

Se sospecha que los actores de amenazas detrás del ataque a la cadena de suministro dirigido al popular escáner Trivy están llevando a cabo ataques posteriores que han llevado al compromiso de una gran cantidad de paquetes npm con un gusano autopropagante previamente indocumentado denominado gusano de bote.

El nombre es una referencia al hecho de que el malware utiliza un recipiente de PICque se refiere a contratos inteligentes a prueba de manipulaciones en la cadena de bloques de Internet Computer, como un solucionador de caída muerta. El desarrollo marca el primer abuso documentado públicamente de un recipiente ICP con el propósito explícito de recuperar el servidor de comando y control (C2), según Charlie Eriksen, investigador de seguridad de Aikido. dicho.

La lista de paquetes afectados se encuentra a continuación:

  • 28 paquetes en el ámbito @EmilGroup
  • 16 paquetes en el ámbito @opengov
  • @teale.io/eslint-config
  • @airtm/uuid-base32
  • @pypestream/flotante-ui-dom

El desarrollo se produce un día después de que los actores de amenazas aprovecharan una credencial comprometida para publicar versiones maliciosas de trivy, trivy-action y setup-trivy que contenían un ladrón de credenciales. Un enfoque en la nube operación cibercriminal Se sospecha que el grupo conocido como TeamPCP está detrás de los ataques.

Ciberseguridad

La cadena de infección que involucra los paquetes npm implica aprovechar un gancho posterior a la instalación para ejecutar un cargador, que luego coloca una puerta trasera de Python que es responsable de contactar con el contenedor ICP para recuperar una URL que apunta a la carga útil de la siguiente etapa. El hecho de que la infraestructura de dead drop esté descentralizada la hace resiliente y resistente a los esfuerzos de eliminación.

«El controlador del recipiente puede cambiar la URL en cualquier momento, enviando nuevos archivos binarios a todos los hosts infectados sin tocar el implante», dijo Eriksen.

La persistencia se establece mediante un servicio de usuario systemd, que está configurado para iniciar automáticamente la puerta trasera de Python después de un retraso de 5 segundos si se finaliza por algún motivo mediante el uso de «Reiniciar=siempre» directiva. El servicio systemd se hace pasar por herramientas PostgreSQL («pgmon») en un intento de pasar desapercibido.

La puerta trasera, como se mencionó antes, llama al recipiente de PIC con un agente de usuario del navegador falso cada 50 minutos para recuperar la URL en texto sin formato. Posteriormente, la URL se analiza para buscar y ejecutar el ejecutable.

«Si la URL contiene youtube[.]com, el guión lo omite», explicó Eriksen. «Este es el estado inactivo del recipiente. El atacante arma el implante apuntando el recipiente a un binario real y lo desarma volviendo a un enlace de YouTube. Si el atacante actualiza el contenedor para que apunte a una nueva URL, cada máquina infectada recoge el nuevo binario en su siguiente sondeo. El antiguo binario sigue ejecutándose en segundo plano ya que el script nunca finaliza procesos anteriores».

Vale la pena señalar que un youtube similar[.]Wiz también ha señalado el interruptor de apagado basado en com en relación con el binario troyanizado Trivy (versión 0.69.4), que llega al mismo recipiente ICP a través de otro cuentagotas de Python («sysmon.py»). Al momento de escribir, la URL devuelta por el C2 es una vídeo de youtube de rickroll.

The Hacker News descubrió que el recipiente ICP apoya tres métodos (get_latest_link, http_request, update_link), el último de los cuales permite al actor de amenazas modificar el comportamiento en cualquier momento para servir una carga útil real.

En conjunto, los paquetes vienen con un archivo «deploy.js» que el atacante ejecuta manualmente para distribuir la carga maliciosa a cada paquete al que un token npm robado proporciona acceso de forma programática. El gusano, que se considera codificado por vibración mediante una herramienta de inteligencia artificial (IA), no intenta ocultar su funcionalidad.

«Esto no se activa con la instalación de npm», dijo Aikido. «Es una herramienta independiente que el atacante utiliza con tokens robados para maximizar el radio de explosión».

Para empeorar las cosas, se descubrió que una iteración posterior de CanisterWorm detectada en «@teale.io/eslint-config» versiones 1.8.11 y 1.8.12 se autopropaga sin necesidad de intervención manual.

Ciberseguridad

A diferencia de «deploy.js», que era un script autónomo que el atacante tenía que ejecutar con los tokens npm robados para enviar una versión maliciosa de los paquetes npm al registro, la nueva variante incorpora esta funcionalidad en «index.js» dentro de una función findNpmTokens() que se ejecuta durante la fase posterior a la instalación para recopilar tokens de autenticación npm de la máquina de la víctima.

La principal diferencia aquí es que el script postinstalación, después de instalar la puerta trasera persistente, intenta localizar cada token npm del entorno del desarrollador y genera el gusano inmediatamente con esos tokens iniciando «deploy.js» como un proceso en segundo plano completamente independiente.

Curiosamente, se dice que el actor de amenazas cambió la carga útil de la puerta trasera ICP por una cadena de prueba ficticia («hello123»), probablemente para garantizar que toda la cadena de ataque funcione según lo previsto antes de agregar el malware.

«Este es el punto donde el ataque pasa de ‘la cuenta comprometida publica malware’ a ‘el malware compromete más cuentas y se publica a sí mismo’», dijo Eriksen. «Cada desarrollador o canal de CI que instala este paquete y tiene un token npm accesible se convierte en un vector de propagación involuntario. Sus paquetes se infectan, sus usuarios intermedios los instalan y, si alguno de ellos tiene tokens, el ciclo se repite».

(Esta es una historia en desarrollo. Vuelva a consultarla para obtener más detalles).

Acciones de GitHub de Trivy Security Scanner violadas, 75 etiquetas secuestradas para robar secretos de CI/CD – CYBERDEFENSA.MX

Trivy, un popular escáner de vulnerabilidades de código abierto mantenido por Aqua Security, se vio comprometido por segunda vez en el lapso de un mes para entregar malware que robaba secretos confidenciales de CI/CD.

El último incidente afectó a GitHub Actions «aquasecurity/trivy-acción» y «aquasecurity/configuración-trivy«, que se utilizan para escanear imágenes del contenedor Docker en busca de vulnerabilidades y configurar el flujo de trabajo de GitHub Actions con una versión específica del escáner, respectivamente.

«Identificamos que un atacante forzó 75 de 76 etiquetas de versión en el repositorio aquasecurity/trivy-action, la acción oficial de GitHub para ejecutar análisis de vulnerabilidades de Trivy en canales de CI/CD», dijo el investigador de seguridad de Socket, Philipp Burckhardt. dicho. «Estas etiquetas se modificaron para servir una carga maliciosa, convirtiendo efectivamente las referencias de versiones confiables en un mecanismo de distribución para un ladrón de información».

La carga útil se ejecuta dentro de los ejecutores de GitHub Actions y tiene como objetivo extraer valiosos secretos de desarrollador de entornos CI/CD, como claves SSH, credenciales para proveedores de servicios en la nube, bases de datos, Git, configuraciones de Docker, tokens de Kubernetes y billeteras de criptomonedas.

Ciberseguridad

El desarrollo Marca el segundo incidente en la cadena de suministro que involucra a Trivy. Hacia finales de febrero y principios de marzo de 2026, un robot autónomo llamado hackerbot-claw aprovechó un flujo de trabajo «pull_request_target» para robar un token de acceso personal (PAT), que luego se utilizó como arma para tomar el control del repositorio de GitHub, eliminar varias versiones de lanzamiento y enviar dos versiones maliciosas de su extensión Visual Studio Code (VS Code) a Open VSX.

La primera señal del compromiso fue marcado por el investigador de seguridad Paul McCarty después de que se publicara una nueva versión comprometida (versión 0.69.4) en el repositorio de GitHub «aquasecurity/trivy». Desde entonces, la versión fraudulenta ha sido eliminada. De acuerdo a Fenómenola versión 0.69.4 inicia tanto el servicio legítimo Trivy como el código malicioso responsable de una serie de tareas:

  • Realice el robo de datos escaneando el sistema en busca de variables ambientales y credenciales, cifrando los datos y extrayéndolos a través de una solicitud HTTP POST a scan.aquasecurtiy[.]org.
  • Configurar la persistencia usando un servicio del sistema después de confirmar que se está ejecutando en una máquina de desarrollador. El servicio systemd está configurado para ejecutar un script Python («sysmon.py») que sondea un servidor externo para recuperar la carga útil y ejecutarla.

En un comunicado, Itay Shakury, vicepresidente de código abierto de Aqua Security, dicho los atacantes abusaron de una credencial comprometida para publicar versiones maliciosas de trivy, trivy-action y setup-trivy. En el caso de «aquasecurity/trivy-action», el adversario impulsó 75 etiquetas de versión para señalar las confirmaciones maliciosas que contienen la carga útil del robo de información de Python sin crear una nueva versión ni enviar a una rama, como es la práctica estándar. Se forzaron siete etiquetas de «aquasecurity/setup-trivy» de la misma manera.

«Entonces, en este caso, el atacante no necesitaba explotar Git», dijo Burckhardt a The Hacker News. «Tenían credenciales válidas con privilegios suficientes para enviar código y reescribir etiquetas, que es lo que permitió el envenenamiento de etiquetas que observamos. Lo que no está claro es la credencial exacta utilizada en este paso específico (por ejemplo, un PAT de mantenimiento frente a un token de automatización), pero ahora se entiende que la causa principal es el compromiso de credenciales transferido del incidente anterior».

El proveedor de seguridad también reconoció que el último ataque se debió a una contención incompleta del incidente del hackerbot-claw. «Rotamos secretos y tokens, pero el proceso no fue atómico y es posible que los atacantes hayan estado al tanto de los tokens actualizados», dijo Shakury. «Ahora estamos adoptando un enfoque más restrictivo y bloqueando todas las acciones automatizadas y cualquier token para eliminar completamente el problema».

El ladrón opera en tres etapas: recolecta variables de entorno de la memoria del proceso del ejecutor y del sistema de archivos, cifra los datos y los extrae al servidor controlado por el atacante («scan.aquasecurtiy[.]organización»).

Si el intento de exfiltración falla, se abusa de la propia cuenta de GitHub de la víctima para almacenar los datos robados en un repositorio público llamado «tpcp-docs» mediante el uso del INPUT_GITHUB_PAT capturado, una variable de entorno utilizada en GitHub Actions para pasar una PAT de GitHub para la autenticación con la API de GitHub.

Actualmente no se sabe quién está detrás del ataque, aunque hay indicios de que el actor de amenazas conocido como TeamPCP puede estar detrás. Esta evaluación se basa en el hecho de que el recolector de credenciales se autoidentifica como «ladrón de nubes de TeamPCP» en el código fuente. También conocido como DeadCatx3, PCPcat, PersyPCP, ShellForce y CipherForce, el grupo es conocido por actuar como una plataforma de cibercrimen nativa de la nube diseñada para violar la infraestructura moderna de la nube para facilitar el robo de datos y la extorsión.

Ciberseguridad

«Los objetivos de credenciales en esta carga útil son consistentes con el perfil más amplio de robo y monetización nativo de la nube del grupo», dijo Socket. «El fuerte énfasis en los pares de claves del validador de Solana y las billeteras de criptomonedas está menos documentado como un sello distintivo de TeamPCP, aunque se alinea con las motivaciones financieras conocidas del grupo. El autoetiquetado podría ser una bandera falsa, pero la superposición técnica con las herramientas anteriores de TeamPCP hace que la atribución genuina sea plausible».

Se recomienda a los usuarios que se aseguren de utilizar las últimas versiones seguras:

«Si sospecha que estaba ejecutando una versión comprometida, trate todos los secretos del canal como comprometidos y rótelos inmediatamente», dijo Shakury. Los pasos de mitigación adicionales incluyen bloquear el dominio de exfiltración y la dirección IP asociada (45.148.10[.]212) a nivel de red, y verificar las cuentas de GitHub en busca de repositorios llamados «tpcp-docs», lo que puede indicar una exfiltración exitosa a través del mecanismo de reserva.

«Fije las acciones de GitHub a hashes SHA completos, no a etiquetas de versión», dijo el investigador de Wiz, Rami McCarthy. «Las etiquetas de versión se pueden mover para señalar confirmaciones maliciosas, como se demuestra en este ataque».

(Esta es una historia en desarrollo. Vuelva a consultarla para obtener más detalles).