Resumen ejecutivo

Entre finales de febrero y marzo de 2026, el grupo de amenazas TeamPCP realizó una secuencia escalonada y muy calculada de amenazas a la cadena de suministro. Logró vulnerar sistemáticamente herramientas de seguridad de código abierto de gran confianza, como los escáneres de vulnerabilidades Trivy y KICS y la popular puerta de enlace de IA LiteLLM. El software afectado también incluye el SDK de Python oficial de Telnyx.

Estos ataques continuos a la cadena de suministro inyectaban cargas útiles maliciosas de robo de información directamente en los registros de GitHub Actions y Python Package Index (PyPI). Una vez ejecutado durante los flujos de trabajo automatizados rutinarios, el malware extrae silenciosamente datos muy sensibles, como los siguientes:

  • Tokens de acceso a la nube
  • Claves SSH
  • Secretos de Kubernetes

Estos ataques también crean puertas traseras persistentes para el movimiento lateral a través de los clústeres.

El software afectado es el siguiente:

  • LiteLLM de BerriAI, una biblioteca de código abierto utilizada para enrutar solicitudes a través de proveedores de LLM (la documentación afirma que tiene más de 95 millones de descargas mensuales)
  • Trivy de Aqua Security y KICS (que significa “Mantener segura la infraestructura como código”) de Checkmarx, que están integrados en millones de canales de CI/CD empresariales
  • El ampliamente utilizado SDK oficial de Python de Telnyx, una plataforma global de comunicaciones que proporciona API programables para voz y mensajería

Fuentes como vx-underground creen que los atacantes ya han exfiltrado más de 300 GB de datos y secretos de 500,000 máquinas infectadas, lo que expone a las principales organizaciones de todos los sectores empresariales a graves ataques posteriores.

A diferencia de los ataques a la cadena de suministro anteriores, esta operación utiliza explícitamente como arma la infraestructura de seguridad y de desarrolladores que requiere privilegios elevados. Esto permite a los atacantes acceder sin obstáculos a los secretos de producción. Así pueden solicitar un rescate a las organizaciones comprometidas, exigiéndoles el pago de extorsiones.

El alcance actual del ataque es significativo:

  • Escala del impacto: el actor podría haber exfiltrado más de 300 GB de datos y 500,000 credenciales, incluidos tokens de nube y secretos de Kubernetes.
  • Amplitud de la vulneración: además de los objetivos principales, TeamPCP aprovechó los tokens recolectados para infectar 48 paquetes adicionales. Identificó y publicó al menos 16 organizaciones de víctimas mediante sitios públicos de filtraciones.
  • Sofisticación: los atacantes introdujeron CanisterWorm, que incluye una arquitectura descentralizada de comando y control (C2) y componentes de limpieza selectiva. Esto demuestra un patrón técnico en evolución centrado en operaciones nativas de la nube.

Desde el 27 de marzo, Cortex Xpanse de Palo Alto Networks ha identificado la presencia de tres certificados autofirmados únicos que están asociados a las tres oleadas de operaciones.

Los clientes de Palo Alto Networks están mejor protegidos frente a las amenazas descritas en este artículo por medio de los siguientes productos y servicios:

Palo Alto Networks también recomienda implementar medidas para identificar los paquetes vulnerables y endurecer las políticas de CI/CD, como se describe en la sección Guías provisionales.

La Evaluación de la seguridad en la nube de Unit 42 es un servicio de evaluación que revisa la infraestructura de la nube para identificar errores de configuración y lagunas de seguridad.

El equipo de respuesta ante incidentes de Unit 42 también puede involucrarse para ayudar con una intrusión o para proporcionar una evaluación proactiva que permita reducir el riesgo.

El alcance actual del ataque a la cadena de suministro

TeamPCP (alias PCPcat, ShellForce, DeadCatx3) ha realizado operaciones que se remontan, al menos, a septiembre de 2025. El grupo ganó notoriedad en diciembre de 2025, a raíz de la campaña masiva React2Shell que se dirigió a entornos de nube.

Esa campaña explotó la vulnerabilidad React2Shell (CVE-2025-55182), lo que le permitió al grupo aprovechar la ejecución remota de código (RCE) en endpoints vulnerables en la nube. Durante estas operaciones, el artefacto de detección más notable del grupo, junto con los indicadores de exploits React2Shell más conocidos, usaba el puerto número 666 para casi todas sus operaciones de explotación.

La trayectoria del grupo ha evolucionado rápidamente. Aunque el grupo inicialmente se centró en el ransomware, también tiene raíces en la criptominería y el robo de criptomonedas. A mediados de marzo de 2026, el grupo comenzó a realizar operaciones de compromiso de la cadena de suministro de alto impacto.

Recientemente, el ritmo de actividad del grupo aumentó. Aumentaron las publicaciones en el canal de Telegram y en su sitio de filtraciones de la web oscura.

Los anuncios más recientes afirman que el grupo está combinando fuerzas con CipherForce, otro grupo de ransomware, para publicar información sobre vulneraciones. Además, en BreachForums, un foro para que los ciberdelincuentes discutan temas de piratería informática y vulneraciones de datos, se anunció que el grupo se está asociando con el grupo de ransomware Vect, como se muestra en la Figura 1.

Captura de pantalla del mensaje en un foro en el que se anuncia una asociación con BreachForums y TeamPCP. La publicación destaca una colaboración para mejorar sus operaciones. La publicación está alojada en una página web de temática oscura, con texto rojo y blanco en negrita.
Figura 1. Captura de pantalla del anuncio en BreachForums.

Es probable que esta asociación le permita a TeamPCP concentrarse en las operaciones de la cadena de suministro. A finales de marzo, TeamPCP anunció el compromiso de 16 organizaciones, como mínimo, como se muestra en la Figura 2.

La imagen es una captura de pantalla de un sitio web de temática oscura titulado “CIPHERFORCE”. Presenta un mensaje grande en texto blanco: “Asegure sus datos”; con un subtítulo: “Aquí se publican las empresas que se negaron a pagar. Las cuentas regresivas se realizan hasta la publicación de los datos”. Debajo hay tres casillas con números: “16” para el total de víctimas, “1” para las cuentas regresivas activas y “11” para las empresas publicadas. Un menú de navegación a la derecha incluye “Inicio”, “Víctimas” y “Noticias”.
Figura 2. Captura de pantalla del sitio de filtración de datos del ransomware CipherForce.

Trivy de Aqua Security

Esta última campaña comenzó el 19 de marzo de 2026, cuando TeamPCP aprovechó una rotación incompleta de credenciales luego de una brecha menor de fines de febrero dentro del repositorio GitHub de Trivy de Aqua Security.

TeamPCP comprometió la cuenta de servicio aqua-bot y ejecutó un ataque de suplantación de commits. El resultado fue la introducción forzada de código malicioso en 76 de las 77 etiquetas de versión en el repositorio aquasecurity/trivy-action y en todas las etiquetas de aquasecurity/setup-trivy.

Esta oleada inicial introdujo la carga útil principal de TeamPCP, el stealer en la nube de TeamPCP. Este realizaba sus acciones a través del script kamikaze.sh, que evolucionó en tres versiones distintas:

  • Versión 1, arquitectura monolítica: un script bash de 150 líneas centrado en la huella digital del entorno y la recolección inmediata de credenciales de AWS/GCP/Azure mediante el servicio de metadatos de instancia (IMDS) del endpoint comprometido. Omitía el enmascaramiento secreto de GitHub leyendo la memoria del proceso runner.worker directamente a través de /proc/<pid>/mem para extraer tokens en texto plano.
  • Versión 2, arquitectura modular: dos horas después del primer lanzamiento de la v1, TeamPCP sustituyó el primer script por un script loader compacto de 15 líneas. Esta versión utilizaba un método pull para descargar una carga útil de segunda fase llamada kube.py. Esto le permitió a los actores actualizar la carga útil sin tener que volver a envenenar las etiquetas de GitHub. En la versión 2, también se introdujo el comando de autoeliminación rm – “$0” para eliminarse a sí mismo tras la ejecución.
  • Versión 3, el gusano y el wiper: en esta última versión conocida, el script evolucionó a malware con capacidad de autorreplicación en una campaña llamada CanisterWorm. Analizaremos CanisterWorm con más detalle a continuación. En la versión 3, se habilitó el escaneo de las API de Docker expuestas, el puerto 2375 y la subred local. También permitió la recolección de claves SSH.

Esta operación fue singularmente engañosa. Por ejemplo, el código malicioso se ejecutaba antes de que la lógica legítima del escáner Trivy pudiera ejecutarse y permitía, al mismo tiempo, que el escáner legítimo continuara sus operaciones. Esto permitía que las operaciones de escaneado volvieran a un estado operativo normal, mientras que, entre bastidores, el malware exfiltraba datos silenciosamente al dominio con typosquatting scan.aquasecurtiy[.]org. Si el servidor C2 primario fallaba, la carga útil utilizaba el dominio de respaldo tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0[.]io.

Además, utilizando los tokens de publicación npm recogidos durante la oleada inicial de vulneraciones Trivy, los actores de TeamPCP iniciaron un script automatizado que identificó e infectó 47 paquetes adicionales en los espacios de nombres @emilgroup, @opengov y @v7. Todos los informes indican que estas operaciones se realizaron en menos de 60 segundos.

La infección se lograba al inyectar un script malicioso de preinstalación o postinstalación en el archivo package.json de cada biblioteca. Esto aseguraba que la carga útil del stealer en la nube de TeamPCP se ejecutara inmediatamente después de que un desarrollador o un ejecutor de integración continua/entrega continua (CI/CD) realizara una instalación npm con cualquiera de estos paquetes npm envenenados. Un ejecutor de CI/CD es un agente o una aplicación ligeros que ejecuta trabajos de canal de software.

Esta oleada se centró, en gran medida, en una técnica denominada suplantación de kits de desarrollo de software (SDK), que se dirige a kits de desarrollo internos para servicios de facturación, seguros y contabilidad. Esto maximizaba la probabilidad de que el malware aterrizara en entornos corporativos con privilegios elevados.

Cada paquete infectado actuaba como un nuevo nodo de telemetría, tomando huellas del entorno e intentando exfiltrar datos de archivos .env locales y directorios de configuración de AWS/Azure a la infraestructura C2 del grupo. De este modo, la vulneración de un único proveedor se convirtió en un riesgo sistémico y potencialmente generalizado para la cadena de suministro de cualquier consumidor posterior de estos SDK privados y públicos.

KICS de Checkmarx

Luego de la vulneración inicial de Trivy de Aqua Security realizada el 21 de marzo de 2026, TeamPCP utilizó tokens de acceso personal (PAT) robados de GitHub para atacar KICS de Checkmarx. KICS es un escáner de infraestructura como código (IaC) de código abierto.

Los atacantes introdujeron a la fuerza commits maliciosos a las 35 etiquetas de versión del repositorio checkmarx/kics-github-action y envenenaron la versión 2.3.28 de checkmarx/ast-github-action. Técnicamente, la operación subvertía el punto de entrada oficial del contenedor setup.sh y, en su lugar, inyectaba una carga útil de tres fases llamada stealer en la nube de TeamPCP.

Esta carga útil tiene una funcionalidad similar a la carga útil de la oleada de Trivy. A fin de evitar la detección manual, el malware exfiltraba los datos robados al dominio con typosquatting que imita al proveedor: checkmarx[.]zone. Contaba con un mecanismo de respaldo secundario, en el que si las comunicaciones C2 primarias fallaban, la carga útil utilizaba el propio GITHUB_TOKEN de la víctima para crear un repositorio oculto llamado docs-tpcp ubicado dentro de la organización GitHub de la víctima.

LiteLLM

El 23 de marzo de 2026, TeamPCP se alejó de los PAT de GitHub y se dirigió a los tokens de publicación del PyPI utilizando LiteLLM de BerriAI. Es probable que el grupo obtuviera estos tokens de una vulneración anterior del escáner de vulnerabilidades Trivy. Los atacantes envenenaron el canal de CI/CD de LiteLLM para permitir la carga de versiones maliciosas (v1.82.7 y v1.82.8) a PyPI.

Esta oleada introdujo un método de ejecución altamente evasivo a través de un archivo .pth llamado litellm_init.pth en la versión 1.82.8. Como el intérprete de Python procesa automáticamente los archivos .pth durante el arranque, el malware se ejecutaba cada vez que se inicializaba cualquier proceso Python en un host, independientemente de si LiteLLM se había importado alguna vez. Esto le permitió a TeamPCP aumentar el alcance de las víctimas potenciales.

La carga útil multifase consistía en un script doble codificado en Base64, diseñado para eludir el análisis estático. El script funcionaba como un recolector integral de secretos, donde extraía lo siguiente:

  • Claves SSH
  • Credenciales en la nube (AWS, Google Cloud, Azure)
  • Archivos de configuración de Kubernetes
  • De forma crítica, las variables de entorno de alta densidad que contienen claves API de LLM (por ejemplo, OPENAI_API_KEY, ANTHROPIC_API_KEY)

En la Figura 3, se muestra un ejemplo de esto en un fragmento de código.

Captura de pantalla de la interfaz de línea de comandos. El comando ejecutado es un script de Python 3 que implica importar el módulo ‘base64’ y ejecutar un script codificado en base64.
Figura 3. Un fragmento de código que representa el script doble codificado en Base64.

Dentro de esta codificación en Base64, había un segundo bloque codificado en Base64 que proporcionaba el endpoint C2 para los comandos C2. En la Figura 4, se muestra el código escrito en la ruta /host/root/.config/sysmon/sysmon.py.

Se muestra un fragmento de código en Python. Define una función que envía una solicitud a una URL especificada por la variable ‘C_URL’. La solicitud incluye un encabezado user-agent.
Figura 4. El código escrito en /host/root/.config/sysmon/sysmon.py.

Los datos exfiltrados se trataron del mismo modo que la oleada de Checkmarx y se cifraron mediante una clave de sesión AES-256-CBC, que se protegió además con una clave pública RSA de 4096 bits integrada en el código. Para el endpoint C2 de exfiltración de LiteLLM, los atacantes usaron el dominio con typosquatting models.litellm[.]cloud. El código que se muestra en la Figura 5 es un ejemplo del subproceso que gestionó la exfiltración de los datos recopilados.

Un fragmento de código Python que utiliza el módulo ‘subprocess’. Envía una petición POST a una URL utilizando ‘curl’.
Figura 5. Subproceso para gestionar la exfiltración de los datos recopilados.

A continuación, se enumeran todos los dominios C2 de exfiltración conocidos hasta el 27 de marzo de 2026:

  • scan.aquasecurtiy[.]org
  • checkmarx[.]zone
  • models.litellm[.]cloud
  • tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0[.]io

Telnyx

El 27 de marzo de 2026, TeamPCP comprometió el SDK de Python de Telnyx. Este ataque siguió un patrón similar al de LiteLLM, donde el actor de amenazas secuestró las credenciales de publicación de PyPI para publicar las versiones maliciosas 4.87.1 y 4.87.2 del paquete telnyx.

Estas versiones contienen un inyector silencioso en la biblioteca del cliente que se ejecuta inmediatamente después de la importación para exfiltrar credenciales de la nube y secretos del sistema. El ataque utiliza esteganografía WAV para ocultar cargas útiles cifradas de segunda fase dentro de archivos de audio válidos, lo que permite al malware eludir los filtros de red mientras establece persistencia en sistemas Windows, Linux y macOS.

El archivo de audio de Windows tenía el nombre integrado en el código hangup.wav y el archivo de audio de Linux tenía el nombre integrado en el código ringtone.wav. Esta campaña se dirige específicamente a la infraestructura y las herramientas de comunicación para recopilar tokens de acceso de alto valor y claves de cuentas de servicio para la explotación de clústeres más amplios.

CanisterWorm

CanisterWorm utiliza un canister descentralizado de Internet Computer Protocol (ICP) como infraestructura de C2, lo que brinda un punto de entrega de la carga útil a prueba de manipulaciones y resistente a las típicas operaciones de desmantelamiento de gusanos. Además de robar credenciales y conseguir persistencia, los actores de amenazas también enmascararon su actividad como servicios legítimos como systemd y disfrazaron la amenaza como una utilidad de PostgreSQL llamada pgmon.

Recientemente, la campaña integró un componente de wiper destructivo, que se observó el 23 de marzo de 2026, cuyo objetivo era Irán. Esto es visible en los bloques de código del archivo kube.py que se muestran en las Figuras 6 y 7.

Fragmento de código que muestra una estructura de función principal con lógica condicional. El script sale con un código de error si se cumplen ciertas condiciones.
Figura 6. Bloque de código de kube.py (1 de 2).
La imagen muestra un fragmento de código Python que comprueba si la zona horaria está establecida en Irán.
Figura 7. Bloque de código de kube.py (2 de 2).

Esta carga útil secundaria realiza toma de huellas de entornos para identificar clústeres de Kubernetes, implementando DaemonSets privilegiados para inutilizar clústeres enteros o ejecutando eliminaciones recursivas de archivos en hosts no contenerizados. Esta mezcla de propagación automatizada, infraestructura descentralizada y destrucción selectiva marca a CanisterWorm como una de las amenazas nativas de la nube más complejas que se identificaron hasta la fecha, pese a su historial operativo ruidoso y efímero.

Guías provisionales

Protección de los activos en la nube contra los ataques a la cadena de suministro

Cortex Cloud ofrece amplias capacidades de gestión de la postura de seguridad de la aplicación (ASPM) y de seguridad de la cadena de suministro para ayudar a identificar las vulnerabilidades y los errores de configuración en los que se basa TeamPCP. La siguiente guía incluye algunas instrucciones específicas para los productos de Palo Alto Networks. Recomendamos que todas las organizaciones busquen un mecanismo adecuado para reforzar los activos en la nube tal y como se ha descrito.

(Nota: Los clientes de Prisma Cloud que aún no hayan migrado a Cortex Cloud deberán tomar las mismas precauciones).

1. Identificación de paquetes vulnerables: análisis de composición de software (SCA) y lista de materiales de software (SBOM)

Dado que las vulnerabilidades y exposiciones comunes (CVE) para estos paquetes maliciosos pueden ir por detrás del ataque, las organizaciones deben confiar en la visibilidad en tiempo real de su lista de materiales de software (SBOM).

  • Modelo de riesgo operativo: para los paquetes sin CVE publicadas, el modelo de riesgo operativo patentado de Palo Alto Networks proporciona protección adicional. Evalúa los paquetes de código abierto en función de factores como la actividad de los mantenedores, el estado de obsoleto y la adopción por parte de la comunidad, lo que nos permite identificar componentes de riesgo incluso en ausencia de vulnerabilidades conocidas.
  • Consulta SBOM: Cortex Cloud le permite consultar la SBOM de su organización y compararla con la lista de paquetes maliciosos conocidos para identificar inmediatamente el impacto.

2. Fortalecimiento de las políticas de CI/CD: reglas listas para usar

TeamPCP prospera en entornos inseguros y expuestos. Los clientes de Palo Alto Networks pueden aprovechar las siguientes reglas de CI/CD de Cortex Cloud listas para usar (OotB) que se diseñaron para evitar ataques similares. Estas normas se ajustan a estándares del sector como Los 10 principales riesgos de CI/CD de OWASP y la Guía de seguridad de la cadena de suministro de software del CIS.

  • Paquetes instalados de forma insegura: en configuraciones comunes, tanto GitHub como npm pueden entregar versiones actualizadas de paquetes sin comprobar su integridad. Esto les permite a los atacantes que controlan un repositorio determinado cargar una versión maliciosa de un paquete que está habilitado para la descarga automática. Es fundamental que las organizaciones confíen en cada paquete, pero lo verifiquen igualmente. Es vital que los canales de CI/CD modernos escaneen todos los paquetes antes de su implementación.
  • Un paquete npm descargado de Git sin una referencia a un hash de commit: sin un hash de commit específico, no se puede garantizar la integridad de un paquete descargado desde una URL de Git, lo que potencialmente permite que un servidor de compilación descargue una versión maliciosa.
  • Un proyecto npm contiene dependencias no utilizadas: las dependencias no utilizadas amplían la superficie de ataque sin justificación. Si una dependencia no utilizada se ve comprometida por TeamPCP, expone el proyecto a riesgos incluso si el código no se utiliza activamente.

Consultas de búsqueda de amenazas gestionadas de Unit 42

El equipo de búsqueda de amenazas gestionadas de Unit 42 sugiere las siguientes consultas XQL. Los clientes de Cortex XDR y XSIAM pueden utilizar estas consultas XQL para buscar indicios de explotación.

Conclusión

Considerando la rápida escalada de las operaciones de la cadena de suministro de TeamPCP, Palo Alto Networks recomienda que las organizaciones auditen inmediatamente lo siguiente en sus entornos de desarrollo y producción:

  • Canales de CI/CD
  • PAT de GitHub
  • Credenciales del proveedor de la nube
  • Tokens de cuenta de servicio (SAT) de Kubernetes
  • Claves SSH basadas en contenedores

Entre febrero y marzo de 2026, este actor pasó del ransomware y la criptominería a un modelo centrado en comprometer la cadena de suministro. Esta operación logró comprometer herramientas de seguridad de confianza como Trivy de Aqua Security y KICS de Checkmarx, así como la puerta de enlace LiteLLM de BerriAI.

Las organizaciones deberían priorizar la implementación de las guías provisionales proporcionadas en este informe, específicamente en relación con la visibilidad de la SBOM y el fortalecimiento de la política de CI/CD, para mitigar el riesgo de movimiento lateral y la exfiltración de datos.

Los clientes de Palo Alto Networks están mejor protegidos gracias a nuestros productos, como se indica a continuación. Actualizaremos este resumen de amenazas a medida que dispongamos de más información pertinente.

Protecciones de productos de Palo Alto Networks para el ataque multifase a la cadena de suministro de TeamPCP

Los clientes de Palo Alto Networks pueden aprovechar varias protecciones y actualizaciones de productos para identificar y defenderse contra esta amenaza.

Las prácticas recomendadas de la cadena de suministro listas para usar de Cortex Cloud están diseñadas para reconocer el uso de canales de CI/CD propiedad de Trivy y LiteLLM no anclados dentro de un entorno y para generar alertas. Animamos a las organizaciones a que fijen versiones de paquetes específicas y conocidas para sus aplicaciones de la cadena de suministro.

En la Figura 8, se muestra qué se verá en la plataforma de Cortex Cloud al visualizar los catálogos de la cadena de suministro para Trivy, Checkmarx y LiteLLM. En la Figura 9, se muestra qué se verá para la cobertura de seguridad de aplicaciones para los activos en un entorno. En la Figura 10, se muestran hallazgos notables de secretos contenidos en recursos de la nube potencialmente vulnerables.

Captura de pantalla de los resultados de una búsqueda en el catálogo de la cadena de suministro desde Cortex Cloud. La consulta incluye trivy, checkmarx y litellm.
Figura 8. Módulo de seguridad de aplicaciones de Cortex Cloud: catálogo de paquetes para la cadena de suministro.
Panel de Cortex Cloud que muestra las estadísticas de cobertura de ASPM: se escanea el 20 % de los activos. Las secciones incluyen datos sobre vulnerabilidades, puntos débiles del código, secretos, errores de configuración y malware, todo al 0 %. Aparecen dos activos con detalles como el tipo de activo y el estado del último escaneado, ambos marcados como completados mediante Acciones de GitHub.
Figura 9. Módulo de seguridad de aplicaciones de Cortex Cloud: pantalla de cobertura.
Panel en Cortex Cloud que muestra una lista de problemas de seguridad etiquetada como “Secretos”. Muestra varias entradas con distintos niveles de gravedad, como alto y bajo. Las entradas muestran los activos asociados y tienen opciones para realizar acciones adicionales.
Figura 10. Módulo de seguridad de aplicaciones de Cortex Cloud: pantalla de secretos detectados.

La evaluación de la seguridad en la nube de Unit 42 es un servicio de evaluación que revisa la infraestructura de la nube para identificar errores de configuración y lagunas de seguridad.

Si cree que podría haber resultado vulnerado o tiene un problema urgente, póngase en contacto con el equipo de respuesta ante incidentes de Unit 42 o llame al:

  • Norteamérica: llamada gratuita: +1 (866) 486-4842 (866.4.UNIT42)
  • Reino Unido: +44.20.3743.3660
  • Europa y Oriente Medio: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japón: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • Corea del Sur: +82.080.467.8774

Servicios de seguridad entregados en la nube para el Next-Generation Firewall

URL Filtering avanzado y Advanced DNS Security identifican como maliciosos los dominios y URL conocidos asociados con esta actividad.

Cortex AgentiX

Los analistas de seguridad pueden utilizar lenguaje natural para solicitar al agente de inteligencia de amenazas de Cortex AgentiX que extraiga indicadores de vulneración (IoC) de archivos de este informe de amenazas. Luego, las organizaciones tendrán que enriquecer el caso y prestar atención a su tenant de Cortex para las alertas relacionadas. El agente AgentiX proporcionará un resumen rápido del impacto en la organización. Los analistas también pueden aprovechar el agente de investigación de casos para obtener más detalles sobre los casos y los artefactos asociados a esta campaña o construir un plan de acción de respuesta.

Cortex XDR y XSIAM

Cortex XDR y XSIAM proporcionan una defensa multicapa, que incluye Behavioral Threat Protection (BTP), Advanced WildFire y Cortex Analytics, para colaborar en la protección contra el acceso inicial, C2 y el potencial movimiento lateral descrito en este artículo.

Cortex Xpanse

Cortex Xpanse tiene la capacidad de identificar dispositivos LiteLLM expuestos en la Internet pública y escalar estos hallazgos a los defensores. Los clientes pueden activar alertas sobre este riesgo asegurándose de que la regla de superficie de ataque de LiteLLM esté activada. Los hallazgos identificados pueden consultarse en el Centro de respuesta a amenazas o en la vista de incidentes de Expander. Estos resultados también están disponibles para los clientes de Cortex XSIAM que hayan adquirido el módulo ASM.

Cortex Cloud

  • Los clientes de Cortex Cloud están mejor protegidos contra los temas analizados en este artículo mediante la ubicación adecuada del agente de endpoint de XDR de Cortex Cloud y de los agentes sin servidor dentro de un entorno de nube. Diseñado para proteger la postura de una nube y las operaciones en tiempo de ejecución contra estas amenazas, Cortex Cloud ayuda a detectar y prevenir las operaciones maliciosas, las alteraciones de configuración o las explotaciones discutidas en este artículo.
  • La seguridad de identidad de Cortex Cloud engloba la gestión de derechos de infraestructura en la nube (CIEM), la gestión de posturas de seguridad de identidad (ISPM), la gobernanza de acceso a datos (DAG) y la detección y respuesta a amenazas de identidad (ITDR), y proporciona a los clientes las capacidades necesarias para mejorar sus requisitos de seguridad relacionados con la identidad. Los módulos de seguridad de la identidad proporcionan visibilidad de las identidades y sus permisos en entornos de nube para detectar con precisión los errores de configuración y los accesos no deseados a datos sensibles. Brindan análisis en tiempo real en torno a los patrones de uso y acceso diseñados para mantener la supervisión de la seguridad.
  • El módulo de seguridad de la aplicación (ASPM) de Cortex Cloud admite la ingesta de registros de auditoría de seguridad y hallazgos de proveedores de SaaS de terceros mencionados en este artículo, así como la priorización de alertas, problemas, políticas y activos en función de las aplicaciones ingeridas. Esto les permite a los equipos de seguridad conocer mejor la seguridad en los entornos de nube y locales, y alertar sobre las amenazas que se comentan en este artículo.
Nombre de la alerta Táctica MITRE ATT&CK
Lectura inusual de archivo de cuenta de servicio de Kubernetes Acceso a credenciales (TA0006)
Acceso inusual al servicio de metadatos de instancias en la nube (IMDS) Acceso a credenciales (TA0006)
Acceso sospechoso a archivos de credenciales en la nube Acceso a credenciales (TA0006)
Actividad de extracción del valor secreto de Kubernetes Acceso a credenciales (TA0006)

Next-Generation Firewalls con Advanced Threat Prevention

El Next-Generation Firewall con la suscripción de seguridad Advanced Threat Prevention puede ayudar a bloquear la exfiltración de datos mediante la siguiente firma de Threat Prevention: 87120.

Indicadores de vulneración

Direcciones IP

  • 23.142.184[.]129
  • 45.148.10[.]212
  • 63.251.162[.]11
  • 83.142.209[.]11
  • 83.142.209[.]203
  • 195.5.171[.]242
  • 209.34.235[.]18
  • 212.71.124[.]188

Dominios

  • checkmarx[.]zone
  • models.litellm[.]cloud
  • scan.aquasecurtiy[.]org
  • tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0[.]io

URL de tunelización

  • championships-peoples-point-cassette.trycloudflare[.]com
  • create-sensitivity-grad-sequence.trycloudflare[.]com
  • investigation-launches-hearings-copying.trycloudflare[.]com
  • plug-tab-protective-relay.trycloudflare[.]com
  • souls-entire-defined-routes.trycloudflare[.]com

Hashes SHA256 de los certificados autofirmados utilizados en el malware

  • 30015DD1E2CF4DBD49FFF9DDEF2AD4622DA2E60E5C0B6228595325532E948F14
  • 41C4F2F37C0B257D1E20FE167F2098DA9D2E0A939B09ED3F63BC4FE010F8365C
  • D8CAF4581C9F0000C7568D78FB7D2E595AB36134E2346297D78615942CBBD727

Nombres de archivo

  • kamikaze[.]sh
  • kube[.]py
  • prop[.]py
  • proxy_server[.]py
  • tpcp.tar[.]gz

Hashes SHA256 de los archivos maliciosos

  • 0880819ef821cff918960a39c1c1aada55a5593c61c608ea9215da858a86e349
  • 0c0d206d5e68c0cf64d57ffa8bc5b1dad54f2dda52f24e96e02e237498cb9c3a
  • 0c6a3555c4eb49f240d7e0e3edbfbb3c900f123033b4f6e99ac3724b9b76278f
  • 18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a
  • 1e559c51f19972e96fcc5a92d710732159cdae72f407864607a513b20729decb
  • 5e2ba7c4c53fa6e0cef58011acdd50682cf83fb7b989712d2fcf1b5173bad956
  • 61ff00a81b19624adaad425b9129ba2f312f4ab76fb5ddc2c628a5037d31a4ba
  • 6328a34b26a63423b555a61f89a6a0525a534e9c88584c815d937910f1ddd538
  • 7321caa303fe96ded0492c747d2f353c4f7d17185656fe292ab0a59e2bd0b8d9
  • 7b5cc85e82249b0c452c66563edca498ce9d0c70badef04ab2c52acef4d629ca
  • 7df6cef7ab9aae2ea08f2f872f6456b5d51d896ddda907a238cd6668ccdc4bb7
  • 822dd269ec10459572dfaaefe163dae693c344249a0161953f0d5cdd110bd2a0
  • 887e1f5b5b50162a60bd03b66269e0ae545d0aef0583c1c5b00972152ad7e073
  • bef7e2c5a92c4fa4af17791efc1e46311c0f304796f1172fce192f5efc40f5d7
  • c37c0ae9641d2e5329fcdee847a756bf1140fdb7f0b7c78a40fdc39055e7d926
  • cd08115806662469bbedec4b03f8427b97c8a4b3bc1442dc18b72b4e19395fe3
  • d5edd791021b966fb6af0ace09319ace7b97d6642363ef27b3d5056ca654a94c
  • e4edd126e139493d2721d50c3a8c49d3a23ad7766d0b90bc45979ba675f35fea
  • e6310d8a003d7ac101a6b1cd39ff6c6a88ee454b767c1bdce143e04bc1113243
  • e64e152afe2c722d750f10259626f357cdea40420c5eedae37969fbf13abbecf
  • e87a55d3ba1c47e84207678b88cacb631a32d0cb3798610e7ef2d15307303c49
  • e9b1e069efc778c1e77fb3f5fcc3bd3580bbc810604cbf4347897ddb4b8c163b
  • ecce7ae5ffc9f57bb70efd3ea136a2923f701334a8cd47d4fbf01a97fd22859c
  • f398f06eefcd3558c38820a397e3193856e4e6e7c67f81ecc8e533275284b152
  • f7084b0229dce605ccc5506b14acd4d954a496da4b6134a294844ca8d601970d

Actualizado el 9 de abril de 2026 a las 8:00 a. m., hora del Pacífico (PT), para agregar la cobertura de Advanced Threat Prevention.

Enlarged Image