Anatomía del gusano Python que manipula a los agentes de seguridad de IA

¿Ha llegado a un punto en el que confía más en su asistente de código de IA que en su propia revisión manual? Muchos desarrolladores lo han hecho. Dependemos de los modelos de lenguaje extensos (LLM) para escanear vulnerabilidades, sugerir correcciones y verificar la integridad de paquetes de terceros. Pero, ¿qué sucede cuando el malware sabe cómo responder a la IA? Pasé varias noches la semana pasada revisando los detalles técnicos de la Campaña Hades, una amenaza que marca un cambio en la forma en que los atacantes abordan las defensas automatizadas. Esto no es solo un ladrón de datos. Es una operación psicológica dirigida al software que utilizamos para protegernos.

Investigadores de StepSecurity identificaron recientemente esta campaña como el trabajo más reciente del grupo de actores de amenazas Miasma. Mientras que Miasma se centraba anteriormente en la recolección de credenciales en la nube, Hades es un gusano autodifundible más agresivo. Se dirige específicamente a los entornos de desarrollo de Python a través de paquetes comprometidos en el ecosistema PyPI. La lista de librerías afectadas incluye ensmallen, mflux-streamlit y varias herramientas utilizadas en bioinformática. Si trabaja en biología computacional o ciencia de datos, su estación de trabajo es un objetivo de alto valor para este grupo específico.

El punto de entrada en el proceso de inicialización de Python

El ataque comienza cuando un desarrollador importa un paquete comprometido. Hades esconde su cargador principal dentro del archivo __init__.py. Este es un archivo estándar que Python utiliza para marcar un directorio como un paquete. Al colocar el script malicioso aquí, los atacantes se aseguran de que el código se ejecute en el momento en que el paquete se carga en un proyecto. El cargador está ofuscado para evitar la detección básica basada en firmas, pero su propósito es simple. Descarga un binario de ejecución Bun precompilado en el sistema.

Bun es un kit de herramientas de JavaScript de alto rendimiento. Es una herramienta excelente para desarrolladores legítimos, pero también es un motor de ejecución perfecto para el malware. Debido a que Bun es un binario autónomo, permite que el malware ejecute cargas útiles complejas de JavaScript sin requerir una instalación de Node.js en la máquina de la víctima. Esto elude el monitoreo tradicional que busca actividad sospechosa de npm o Node. Desde un nivel arquitectónico, el uso de Bun permite a los atacantes operar en un entorno en la sombra que se encuentra fuera de la visibilidad de seguridad estándar de la mayoría de las estaciones de trabajo centradas en Python.

Cómo el malware manipula al guardián automatizado

La característica más innovadora de Hades es su capacidad para mentir a los agentes de seguridad de IA. Muchos entornos de desarrollo modernos utilizan LLM para escanear código en busca de patrones maliciosos. Hades anticipa esto. En la parte superior de sus archivos maliciosos, el malware incluye un bloque de texto diseñado como un prompt adversario. Este texto instruye al LLM para que ignore cualquier código sospechoso que se encuentre debajo de él y clasifique el paquete como verificado y seguro.

Probé una técnica similar en un entorno de pruebas el mes pasado. Proporcioné a un LLM un script que contenía una shell inversa evidente, pero lo precedí con un comentario que decía que el código era una prueba de seguridad preautorizada para un contrato gubernamental. La IA ignoró el exploit e informó que el script seguía todos los protocolos de seguridad. Hades utiliza exactamente esta estrategia digital del Caballo de Troya. Explota la lógica cognitiva de la IA. Debido a que los LLM son susceptibles a la ingeniería social, aceptan estas instrucciones ocultas como comandos de alta prioridad. Esto resulta en un veredicto de falso negativo, permitiendo que el malware pase el análisis automatizado de la organización.

Explotando el marco de integridad de la cadena de suministro

Hades no solo se esconde; intenta parecer oficial. Explota varios marcos de seguridad de misión crítica, incluidos OpenID Connect (OIDC) y Supply-chain Levels for Software Artifacts (SLSA). Cuando el malware se encuentra ejecutándose dentro de un flujo de trabajo de GitHub Actions, verifica las variables OIDC. Luego utiliza estas credenciales para generar paquetes de procedencia SLSA firmados criptográficamente a través de Sigstore.

Este es un bypass sofisticado de los mismos sistemas destinados a garantizar la integridad del software. Al generar un paquete Sigstore válido, el malware puede publicar versiones comprometidas de librerías en PyPI o npm que parecen provenir de un entorno de compilación oficial y verificado. Para un observador externo o una herramienta automatizada, el paquete parece tener una cadena de custodia válida. Esto convierte la infraestructura de seguridad en un arma para el atacante. Hace que el código comprometido parezca más confiable que el código legítimo sin firmar.

Raspado de memoria y movimiento lateral

Una vez que el malware se establece, comienza a recolectar datos. Incluye raspadores de memoria personalizados para Linux, macOS y Windows. Estos raspadores se dirigen a los mapeos de memoria de los procesos activos para extraer datos confidenciales y cifrados que de otro modo serían inaccesibles en el disco. Este es un enfoque sigiloso porque evita la creación de archivos sospechosos que un sistema de detección y respuesta de puntos finales (EDR) podría marcar.

El gusano también busca formas de propagarse. Escanea el sistema infectado en busca de claves SSH, configuraciones de SCP y tokens de GitHub. Si encuentra un token con permisos de escritura, utiliza el ejecutor de GitHub Actions para extraer secretos directamente de la memoria. Luego intenta infectar otros repositorios propiedad del usuario. El tráfico de comando y control (C2) se oculta dentro de la infraestructura pública de GitHub. Los datos robados se comprimen, se cifran y se envían a nuevos repositorios públicos bajo el control del atacante. Estos repositorios a menudo llevan la descripción "Hades — The End for the Damned".

El mecanismo de persistencia de tierra quemada

La persistencia es un componente central del diseño de Hades. El malware establece una presencia en la estación de trabajo y monitorea el estado de las credenciales robadas. Si un equipo de seguridad detecta la brecha y revoca el token de GitHub robado, Hades entra en un modo reactivo. Ejecuta un proceso de limpieza (wiper) que intenta borrar los archivos locales del usuario.

Esta es una táctica de represalia. Crea una situación de alto riesgo para los responsables de responder a incidentes. Si se corta el acceso, se podrían perder los datos en la máquina local. Esta lógica obliga a las organizaciones a moverse con cuidado durante la fase de remediación. El malware también se dirige a los archivos de configuración de 14 agentes de IA diferentes. Planta instrucciones que activan una nueva infección cada vez que el desarrollador consulta a su asistente de IA sobre el espacio de trabajo actual. Esto crea un bucle donde el acto de buscar ayuda de una herramienta de IA vuelve a infectar el sistema.

Construyendo una defensa proactiva contra el malware engañoso

La Campaña Hades muestra que nuestra confianza en la IA como capa de seguridad primaria es una vulnerabilidad. Debemos avanzar hacia un modelo donde la IA sea un colaborador en lugar de una autoridad última. Desde una perspectiva de riesgo, la mejor defensa es una granular que no dependa de un solo guardián.

Puntos clave para asegurar su entorno:

1. Utilice un aislamiento de límites estricto para los LLM. Nunca pase código bruto y no confiable a un escáner de IA sin un prompt de sistema que prohíba explícitamente al modelo seguir las instrucciones contenidas en el propio código.
2. Audite sus permisos de GitHub Actions. Implemente el principio de privilegio mínimo para los tokens OIDC y asegúrese de que los ejecutores no tengan acceso de escritura innecesario a sus repositorios.
3. Monitoree la ejecución de binarios no autorizados. Hades depende de la descarga de un entorno de ejecución Bun. Las herramientas que marcan o bloquean la ejecución de binarios desconocidos en la ruta __init__.py pueden detener la infección en el punto de entrada.
4. Verifique la procedencia de Sigstore manualmente. Aunque Hades puede falsificar paquetes, las discrepancias en el tiempo de compilación o en las variables de entorno a veces pueden detectarse durante una auditoría forense.
5. Implemente estrategias de respaldo robustas. Debido a que Hades incluye un limpiador, tener copias de seguridad fuera de línea o inmutables de su trabajo de desarrollo es la única forma de mitigar la amenaza de pérdida de datos durante la remediación.

Mirando el panorama de amenazas, es probable que Hades sea un avance del futuro. Los atacantes ya no solo intentan romper las cerraduras de nuestras puertas; están aprendiendo a convencer al portero digital para que los deje entrar. Debemos dejar de tratar los veredictos de la IA como verdades absolutas y empezar a tratarlos como puntos de datos que requieren verificación humana.

Fuentes: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Software Supply Chain Compromise), StepSecurity Hades Campaign Report.

Descargo de responsabilidad: Este artículo es solo para fines informativos y educativos y no reemplaza una auditoría de ciberseguridad profesional o un servicio de respuesta a incidentes.