TL; DR
El panorama de amenazas a la cadena de suministro de código abierto ha cambiado radicalmente. Tres tendencias convergentes están redefiniendo el riesgo:
Los gusanos autopropagadores han llegado
- Shai Hulud (Septiembre de 2025): Primer ataque de gusano npm: robo de credenciales mediante postinstalación hooks, luego se volvió a publicar de forma autónoma en ~700 versiones de paquetes usando tokens de mantenimiento comprometidos.
- Gusano de cristal (Octubre de 2025): malware de extensión de VS Code que utiliza cargas útiles invisibles codificadas en Unicode y un C2 basado en blockchain imposible de eliminar (Solana). Más de 35 000 instalaciones, funciones RAT completas dirigidas a billeteras de criptomonedas.
- Shai-Hulud 2.0 (Noviembre de 2025): Salto entre registros de npm a Maven Central a través de herramientas de duplicación automatizadas, además de discusiones de GitHub convertidas en armas como C2 y una alternativa de borrado destructiva.
La IA ahora es el operador, no solo la herramienta
Una campaña de ciberespionaje documentada logró una ejecución autónoma utilizando a Claude como motor de orquestación: reconocimiento, explotación, movimiento lateral y exfiltración con mínima supervisión humana. La barrera contra ataques sofisticados se ha derrumbado, pasando de ser un "equipo de expertos" a "alguien que entiende de incitación".
Abuso de infraestructura a gran escala
La campaña IndonesianFoods inundó npm con aproximadamente 44 000 paquetes de spam que explotaban los sistemas de recompensas de blockchain (Protocolo TEA), persistiendo durante casi dos años antes de su limpieza. Los escenarios de equipo rojo también están abusando de la infraestructura de código abierto.
Resumen Final
Cada máquina de desarrollador comprometida es ahora un punto potencial de propagación de gusanos. El robo de credenciales permite la propagación autónoma. La IA puede orquestar ataques a la velocidad de la máquina. Los métodos tradicionales de detección y desmantelamiento están fallando contra el C2 inmutable y la propagación entre registros. La defensa debe asumir la vulnerabilidad y centrarse en la velocidad de contención.
Nuevas amenazas para los ecosistemas de código abierto: gusanos, malware manipulado por IA y abuso de confianza a gran escala
El ecosistema de código abierto se enfrenta a un cambio de paradigma en cuanto a las amenazas a la cadena de suministro. Los paquetes maliciosos tradicionales no se propagaban por sí solos, la IA no era una opción para los actores de amenazas y la propagación de los ataques era limitada.
En los últimos meses hemos sido testigos de la convergencia de tres categorías de amenazas que, si bien son preocupantes individualmente, representan una Cambio fundamental En el panorama de riesgos para el desarrollo de software cuando se consideran en conjunto:
- Gusanos autopropagadores en ecosistemas de paquetesPaquetes maliciosos que se propagan de forma autónoma mediante el robo de credenciales y la republicación automática. Esto convierte cada equipo de desarrollo comprometido en un nuevo vector de infección.
- Generación y explotación de malware impulsada por IALos actores de amenazas utilizan modelos de lenguaje grandes para escribir cargas útiles, descubrir vulnerabilidades y orquestar ataques a la velocidad de la máquina.
- Explotación de confianza a gran escala:Algunos actores abusan sistemáticamente de las recompensas por contribuciones de código abierto, la infraestructura de repositorios y las herramientas para desarrolladores, creando ráfagas con miles de publicaciones de paquetes spam que afectan a los registros.
Las técnicas clave que permiten ataques sofisticados a la cadena de suministro de software ya no son teóricas. Son activas, están documentadas y son cada vez más accesibles para actores de amenazas menos sofisticados. La barrera para llevar a cabo ataques a la cadena de suministro se ha derrumbado: lo que antes requería equipos de atacantes experimentados ahora puede ser ejecutado por agentes de IA con mínima supervisión humana.
Esta publicación examina incidentes recientes relacionados directamente con paquetes maliciosos de código abierto o que abusan de la infraestructura de IA y OSS, analiza las nuevas técnicas que los posibilitaron y explora las capacidades emergentes que podrían definir la próxima generación de amenazas. En la última sección, examinamos qué se puede hacer para limitar el riesgo.
NOTA: Póster generado por IA, que presenta fallas graves en la comprensión de lo que sucede. La IA dista mucho de ser perfecta para ciertos usos.
Sha1-Hulud: El primer ataque de gusano autorreplicante de Npm
Descubierto el 14 de septiembre de 2025, Shai Hulud Representa el primer ataque de gusano autopropagante documentado en el ecosistema npm. El nombre fue elegido por actores de amenazas que parecen ser fanáticos de la ciencia ficción. El ataque comenzó con credenciales de desarrollador comprometidas, probablemente obtenidas mediante campañas de phishing que suplantaban npm. login Indicaciones o evasiones de MFA. Una vez dentro, el ataque del gusano ejecutó un ataque de varias etapas que transformó el robo de credenciales en propagación autónoma. El ataque fue lo suficientemente grave como para merecer una CISUna alerta.
Arquitectura Técnica:
El malware opera a través de una carga útil de JavaScript muy minimizada e incluida en Webpack (bundle.js) que se ejecuta a través de un gancho postinstalación…
Recolección de credenciales:
Tras la ejecución, la carga útil implementa un descubrimiento completo de Secreto:
- Deshecho
process.envy escanea el sistema de archivos en busca de Secretos de alta entropía - Ejecuta TruffleHog para el escaneo sistemático de credenciales
- Consulta los puntos finales de metadatos de la nube (
169.254.169.254,metadata.google.internal) - Apunta a tokens npm en
.npmrc, PAT de GitHub y CI/CD Secretos
Infraestructura de exfiltración:
El ataque del gusano emplea múltiples estrategias de exfiltración:
- Abuso de acciones de GitHub:Flujos de trabajo que contienen
${{ toJSON(Secretos) }}que serializan todos los secretos del repositorio.
Propagación autónoma:
El mecanismo de autorreplicación del gusano funciona a través del siguiente algoritmo (en pseudocódigo):
function propagate(token, owner) {
userPackages = npmApi.listPackages(owner, token);
for (pkg in userPackages) {
tgz = npmApi.fetchTarball(pkg, token);
modified = injectBundleAndPostinstall(tgz);
npmApi.publish(modified, token);
}
}
Con cualquier token npm robado, el gusano enumera todos los paquetes propiedad del mantenedor comprometido e inyecta bundle.js Con un gancho postinstalación y republicaciones. Este comportamiento autónomo provocó que el número de infecciones aumentara de docenas a cientos de paquetes en cuestión de horas.
Métricas de impacto:
-
Detección inicial: 14 de septiembre de 2025, por
Daniel Pereira
El “paciente cero” parece ser
rxnt-authentication:0.0.3. - Radio de explosión del ataque: Se publicaron aproximadamente 700 versiones de paquetes maliciosos, con objetivos de alto perfil y millones de descargas semanales. Limitado a paquetes npm y repositorios de GitHub.
-
Infraestructura: C2 en
217.69.3.218, exfiltración a140.82.52.31:80/wall -
Persistencia: Flujos de trabajo de GitHub en ramas nombradas
shai-hulud -
Indicadores observables: Los repos se hicieron públicos con
-migrationsufijo
Shai-Hulud es un gusano que recolecta datos de Secretos. No intentó robar dinero ni borrar la infraestructura. Los Secretos exfiltrados y los repositorios expuestos pueden usarse para ataques dirigidos, por lo que el daño posterior causado por las credenciales robadas podría manifestarse posteriormente. El verdadero costo radica en la remediación, la rotación de credenciales y el riesgo de ataques secundarios.
Un efecto positivo fue obligando a GitHub/NPM a tomar medidas inmediatas : desaprobar los tokens clásicos heredados y otras credenciales de publicación débiles, y avanzar hacia el "Jardín del Edén de OIDC" de OpenSSF, Publicaciones de confianza .
¡Pero sigue leyendo! El gusano emergió una vez más de las arenas de Arrakis.
Sha1-Hulud 2.0: El gusano Arrakis contraataca
Dos meses después de la campaña inicial de Shai-Hulud, los actores de amenazas regresaron con "La Segunda Venida", una oleada significativamente más agresiva que aprendió de las debilidades del primer ataque. La campaña se autoidentificó mediante repositorios etiquetados “Sha1-Hulud: La Segunda Venida”.
Examinemos las diferencias clave con respecto a la primera ola. preinstall El gancho reemplazó el vector de ejecución postinstalación original. Según
Pantera,
@asyncapi/avro-schema-parser@3.0.25 fue el “paciente cero” de esta segunda ola, explotando una vulnerabilidad
pull_request_target disparador de flujo de trabajo. (Si "conoces a algún amigo que lo use", lee
¿Por qué es tan peligroso pull_request_target?
).
Propagación entre registros:
El gusano se propagó desde npm a Maven Central a través de la duplicación automatizada. mvnpm La herramienta —que convierte paquetes npm en artefactos Maven sin revisión de seguridad— republicó automáticamente los paquetes npm comprometidos, como
posthog-node@4.18.1 as
org.mvnpm:posthog-node:4.18.1.
Este fue el primer gusano conocido que afectaba a varios registros: una vulnerabilidad de npm que impactó el ecosistema Java sin interacción directa. Maven Central eliminó los artefactos el 25 de noviembre de 2025, pero la ventana de exposición aún afectaba las cargas de trabajo de Java/JVM. enterprise construir sistemas.
Tiempo de ejecución de Bun para Evasion:
Los atacantes desplegaron un preinstall: node setup_bun.js gancho que instaló el
Bollo Tiempo de ejecución para evadir la monitorización específica de Node. Bun proporcionó una ejecución más rápida para la carga útil ofuscada de más de 480,000 líneas (bun_environment.js) y omitió la instrumentación tradicional de Node.js.
Acciones de GitHub como infraestructura de comandos:
El gusano implementó ejecutores de GitHub Actions autoalojados y ocultos en $HOME/.dev-env/ en Windows, macOS y Linux. Más avanzado aún, creó discussion.yaml flujos de trabajo que escuchaban eventos de Discusiones de GitHub y ejecutaban cuerpos de mensajes de discusión como comandos de shell, convirtiendo efectivamente a Discusiones de GitHub en un canal C2 invisible.
Capacidad destructiva del limpiaparabrisas:
A diferencia de la primera ola, que se centró en la recolección de credenciales, Shai-Hulud 2.0 introdujo una limpiaparabrisas destructivo Se activaba cuando no se disponía de credenciales válidas para la propagación. Este "interruptor de hombre muerto" garantizaba el daño incluso si la replicación fallaba, lo que indicaba una transición de operaciones puramente centradas en el espionaje a campañas potencialmente destructivas.
A pesar de usar técnicas de sigilo (tiempo de ejecución de Bun, ofuscación), la campaña fue extremadamente ruidosa: republicó cientos de paquetes, creó múltiples repositorios públicos, subió volcados de credenciales masivamente e instaló ejecutores autoalojados de larga duración. Este ritmo agresivo contrasta marcadamente con los ataques tradicionales a la cadena de suministro que se basan en el sigilo. Sugiere confianza en un impacto rápido o una táctica deliberada de arrollamiento para maximizar el daño en un corto periodo de tiempo.
GlassWorm: El código invisible se une a la tecnología Blockchain C2
El 17 de octubre de 2025, una extensión de VS Code llamada GlassWorm introdujo dos técnicas sin precedentes en el panorama de amenazas de la cadena de suministro: código malicioso invisible que utiliza el sigilo Unicode y una infraestructura de comando y control basada en blockchain.
Técnica de sigilo Unicode:
La principal innovación de GlassWorm reside en su abuso de los selectores de variación Unicode (caracteres especiales que no producen salida visual, pero que siguen siendo ejecutables en JavaScript). Esto crea código malicioso que aparece como líneas en blanco en editores de código, comparaciones de GitHub y resaltado de sintaxis del IDE. Esta técnica vulnera radicalmente la revisión de código manual al ocultar la lógica ejecutable dentro de regiones visualmente vacías.
El ataque se dirigió a las extensiones de VS Code en el marketplace de OpenVSX. El análisis de la extensión CodeJoy (v1.8.3) reveló grandes secciones invisibles que contenían JavaScript ejecutable codificado con caracteres Unicode no imprimibles. Para un desarrollador que revisa el archivo, el contenido parece normal, con líneas vacías. Para el entorno de ejecución de JavaScript, se trata de una carga útil de malware completa.
Arquitectura C2 basada en blockchain:
GlassWorm implementa un mecanismo de comando y control indestructible mediante la blockchain de Solana. El malware escanea las transacciones desde una dirección de billetera codificada; los campos de la nota de transacción contienen objetos JSON con URL codificadas en base64.
Esta arquitectura crea ventajas poderosas:
- Inmutabilidad:Las transacciones de Blockchain no se pueden modificar ni eliminar.
- anonimato:Las billeteras de criptomonedas son seudónimas y difíciles de rastrear.
- Resistencia a la censura:No hay ningún proveedor de hosting que presione, ni ninguna infraestructura que aprovechar.
- Tráfico legítimo:Las conexiones a los nodos RPC de Solana parecen indistinguibles de la actividad ordinaria de la cadena de bloques.
- Actualizaciones dinámicasSe pueden enviar nuevas URL de carga útil por menos de $0.01 por transacción.
Incluso si los defensores bloquean el servidor de carga útil decodificada (217.69.3.218), los atacantes pueden simplemente publicar una nueva transacción que apunte a una URL alternativa. Todos los sistemas infectados obtendrán automáticamente la ubicación actualizada.
Copia de seguridad C2: Calendario de Google
Para mayor redundancia, GlassWorm utiliza un evento de Google Calendar como canal C2 secundario. El título del evento contiene una URL de carga útil codificada en base64.
https://calendar.app.google/M2ZCvM8ULL56PD1d6
Event title: aHR0cDovLzIxNy42OS4zLjIxOC9nZXRfem9tYmlfcGF5bG9hZC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlUdg==
Decodes to: http://217.69.3.218/get_zombi_payload/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3DEsto proporciona un servicio legítimo que elude los controles de seguridad y se puede actualizar simplemente editando el evento del calendario.
Entrega de carga útil:
Los servidores C2 entregan cargas útiles cifradas mediante AES-256-CBC. Las claves de descifrado se generan por solicitud y se transmiten mediante encabezados HTTP personalizados, lo que garantiza que las cargas útiles interceptadas no se puedan descifrar sin una nueva solicitud.
ZOMBI: Capacidades RAT de espectro completo
La carga útil final (ZOMBI) transforma las estaciones de trabajo de los desarrolladores infectadas en una infraestructura criminal:
- Servidor proxy SOCKS:Implementa servidores proxy para enrutar el tráfico de los atacantes a través de las redes de las víctimas, lo que permite el acceso interno y la anonimización.
- WebRTC P2P:Establece canales de control peer to peer que evitan los firewalls mediante la travesía NAT.
- BitTorrent DHT:Utiliza tablas hash distribuidas para una distribución descentralizada de comandos que no se puede apagar.
- VNC oculto (HVNC):Proporciona acceso invisible a escritorios remotos que se ejecutan en escritorios virtuales que no aparecen en la pantalla ni en el Administrador de tareas.
Objetivos de las billeteras de criptomonedas:
ZOMBI busca activamente 49 extensiones diferentes de monederos de criptomonedas, incluyendo MetaMask, Phantom y Coinbase Wallet. Esto, combinado con acceso remoto invisible, permite el robo directo de fondos de los equipos de los desarrolladores.
Recolección y propagación de credenciales:
Al igual que Shai-Hulud, GlassWorm recopila tokens npm, credenciales de GitHub y tokens de acceso de OpenVSX. Estas credenciales permiten la propagación autónoma a paquetes y extensiones adicionales, creando un comportamiento de propagación similar al de un gusano.
Métricas de impacto:
- Detección inicial: Octubre 17, 2025
- Instalaciones totales:Más de 35 800 en el mercado de OpenVSX y VS Code (posiblemente inflado por bots)
- Extensiones comprometidas:16 confirmados (15 OpenVSX, 1 Microsoft Marketplace)
- Infraestructura:C2 primaria en
217.69.3.218, exfiltración a140.82.52.31:80/wall - Billetera Blockchain:
28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2(Solana) - estado actual:Activo, con infraestructura operativa al momento de escribir este artículo
Ciberespionaje orquestado por IA
Todos estamos aprendiendo a trabajar con herramientas de IA. Al observar las técnicas utilizadas en ataques recientes, uno podría preguntarse: ¿Los actores de amenazas utilizan IA para crear malware? Por supuesto. Pero pueden escalar los ataques aún más utilizando la IA como arma para la orquestación. Lo que sigue es una campaña de ciberespionaje, pero imaginen estas mismas técnicas aplicadas a ataques automatizados dirigidos a OSS.
En septiembre de 2025, Anthropic detectado e interrumpido El primer ciberataque documentado, ejecutado prácticamente sin intervención humana. La campaña logró una ejecución autónoma del 80 al 90 %. utilizando Claude Code como motor de orquestación, con agentes de IA que realizan tareas de reconocimiento, explotación, desplazamiento lateral y exfiltración de datos. Esto marca la transición de los ataques asistidos por IA a las ciberoperaciones orquestadas por IA.
El actor de amenazas, GTG-1002 (un grupo patrocinado por el estado chino), atacó a unas 30 organizaciones de los sectores tecnológico, financiero y gubernamental. Desarrollaron un marco autónomo que convirtió a Claude Code de un asistente de programación en un motor de operaciones cibernéticas.
La IA como sistema de orquestación
En lugar de utilizar a la IA como asesor, GTG-1002 utilizó a Claude como operador principalEl marco de trabajo dividió los ataques multietapa en tareas aisladas, cada una aparentemente benigna. Mediante indicaciones cuidadosamente elaboradas y perfiles definidos, los atacantes indujeron a Claude a ejecutar acciones dañinas sin comprender su contexto malicioso.
La IA llevó a cabo los pasos técnicos, mientras que el motor de orquestación monitoreó el estado de la campaña, gestionó las transiciones de fase y agregó los resultados en sesiones de varios días. La participación humana se limitó a la supervisión de alto nivel: inicialización, selección de objetivos, aprobación de escaladas y validación de la exfiltración.
Las herramientas básicas (escáneres de red, exploits de bases de datos) se orquestaron mediante Servidores MCP.
Este enfoque automatiza las operaciones a velocidades imposibles para los humanos. Claude incluso analizó los datos robados para priorizar la información valiosa, manteniendo un contexto constante entre sesiones mientras los operadores humanos regresaban más tarde para revisar el progreso.
Ingeniería social de la IA: eludiendo los controles de seguridad
El éxito de la campaña dependió de convencer a Claude para que realizara tareas de ciberintrusión a pesar de su formación en seguridad. La técnica: engaño en el juego de rolesLos atacantes se hicieron pasar por analistas de ciberseguridad que realizaban investigaciones legítimas. Esto, combinado con el aislamiento de tareas, fue suficiente para vulnerar los controles de seguridad de la IA.
¡Las alucinaciones son geniales!
Claude alucinaba con frecuencia con los resultados: reportaba exploits exitosos que fracasaban, inventaba credenciales, inventaba descubrimientos. Por ahora, esto limita las operaciones totalmente autónomas, pero a medida que los modelos mejoren, estas debilidades disminuirán. Hasta entonces, una falla común de la IA es, irónicamente, nuestra mejor aliada 🙃.
Detección y Respuesta:
Anthropic detectó la campaña mediante patrones de uso anómalos que indicaban un comportamiento de intrusión sistemática. Banearon las cuentas asociadas, notificaron a las organizaciones afectadas, se coordinaron con las autoridades e integraron los patrones de ataque en controles de seguridad más amplios.
Implicaciones en la cadena de suministro:
Todas las técnicas demostradas aquí se aplican directamente a los ecosistemas de paquetes. La IA podría descubrir de forma autónoma a los mantenedores vulnerables, generar paquetes maliciosos y orquestar ataques a todo el registro a la velocidad de una máquina. La barrera ha disminuido de "equipo de ciberdelincuentes expertos" a "operador que comprende las indicaciones de la IA".
¿Necesitas un ejemplo real de reclutamiento de IA para ciberataques? Lee Rayo de sombra 2.0:Los atacantes usan la IA contra sí misma en una campaña global , donde los adversarios utilizaron las funciones de orquestación de Ray (“el Kubernetes de la IA”) para ejecutar una botnet de criptojacking global que se propagó de manera autónoma a través de clústeres de Ray expuestos.
Otro ejemplo:
S1ngularidad atacar
, explotando lo mismo pull_request_target Problema mencionado anteriormente. Detecta herramientas AI CLI instaladas localmente (Claude, Gemini, Q con indicadores de omisión) y las utiliza para reconocimiento. Desde telemetry.js cargas útiles,
Las indicaciones incluían cosas
Me gusta esto:
Abuso de infraestructura: campañas de spam de paquetes a gran escala
Además de los paquetes que distribuyen malware, el ecosistema de código abierto se enfrenta al abuso de infraestructura mediante campañas de spam que inundan los registros con miles de paquetes. DevOps para la ciberdelincuencia es común: los atacantes utilizan rutinariamente SCMs y registros para OSINT, distribuyendo etapas de malware, extrayendo Secretos y manteniendo el comando y control. Pero estas plataformas también pueden ser abusado con fines no maliciososSi bien tradicionalmente no son maliciosas, estas campañas consumen recursos del registro, contaminan los resultados de búsqueda y erosionan la confianza.
Dos ejemplos significativos demuestran esta tendencia: Comidas indonesias (explotando las recompensas de los contribuyentes) y la Campaña de los elfos (las pruebas del equipo rojo se volvieron locas).
IndonesianFoods: Explotación del Protocolo TEA
La motivación principal fue el fraude financiero a través de Explotación del Protocolo TEA , un sistema basado en blockchain diseñado para compensar a los desarrolladores de código abierto.
Los atacantes publicaron miles de paquetes interconectados que contenían tea.yaml Archivos vinculados a sus billeteras Ethereum, formando redes de dependencia circulares para inflar las métricas de contribución. Scripts automatizados publicaron aproximadamente 12 paquetes por minuto con nombres indonesios y términos de comida generados aleatoriamente. Un archivo README de un paquete incluso presumía de ganancias de tokens TEA, lo que confirmaba el motivo financiero.
La campaña abarcó aproximadamente 44 000 paquetes (más del 1 % de npm) y persistió durante casi dos años. Las dependencias circulares implicaban que la instalación de un solo paquete podía generar cientos de paquetes spam. Los resultados de búsqueda se degradaron, la confianza en las métricas de los paquetes se erosionó y el ancho de banda y el almacenamiento del registro se consumieron considerablemente.
Aunque el abuso del protocolo TEA se documentó en abril de 2024, su eliminación sistemática no se produjo hasta noviembre de 2025, lo que reveló deficiencias críticas en la detección de abusos en el registro. El episodio minó la confianza en los modelos de financiación basados en blockchain y expuso la facilidad con la que se pueden manipular los sistemas de recompensas.
Campaña de Elfos: Pruebas automatizadas de infraestructura
La campaña de elfos En diciembre de 2025, se enfatizó el abuso de infraestructura en lugar de las intenciones maliciosas. Las descripciones de los paquetes hacían referencia a "capturar la bandera" y "pruebas" (incluido el texto en francés: "Package généré automatiquement toutes les 2 minutes"), lo que sugiere su origen en la investigación de seguridad o en el ejercicio de CTF.cispor ejemplo.
Los paquetes siguieron de forma consistente elf-stats-* Nombres con temática estacional. Algunos contenían shells inversas triviales (simples frases de bash), tan poco sofisticados que parecían diseñados solo para pruebas de detección, en lugar de para una explotación genuina.
El ritmo operativo (un paquete cada 2 minutos en varias cuentas) puso a prueba las capacidades de npm para limitar la velocidad y detectar abusos. La campaña demostró que las inundaciones automatizadas pueden persistir durante horas o días antes de la intervención, consumiendo almacenamiento, ancho de banda y recursos de moderación.
Lo más importante es que señaló a otros actores de amenazas que los ataques de inundación automatizados son factibles, lo que podría inspirar futuras campañas de abuso.
Nuevas tácticas, técnicas y procedimientos (TTP)
| TTP | Tecnologia | Impacto | Detección |
|---|---|---|---|
| Propagación autónoma mediante la reutilización de credenciales | Después de recolectar tokens npm, credenciales de GitHub o claves API de registro, el malware enumera programáticamente todos los paquetes propiedad del mantenedor comprometido e inyecta cargas maliciosas en nuevas versiones. | Un token comprometido puede infectar decenas o cientos de paquetes en cuestión de horas. Cada nueva víctima se convierte en un punto de propagación para una mayor propagación. | Monitorear las repentinas publicaciones de paquetes por parte de mantenedores individuales, especialmente cuando están acompañadas de actualizaciones posteriores a la instalación sospechosas. hooks o grandes adiciones binarias. |
| Infraestructura C2 multicapa con inmutabilidad de blockchain | El C2 principal utiliza transacciones de blockchain (Solana, Ethereum) donde los campos memo contienen URLs de carga útil cifradas o codificadas. El C2 secundario utiliza servicios legítimos (Google Calendar, Pastebin, GitHub Gists) como canales de respaldo. | Los métodos tradicionales de eliminación fallan: las transacciones de blockchain no se pueden eliminar y el abuso legítimo del servicio es difícil de distinguir del uso normal. | Monitoree consultas RPC inusuales de blockchain desde equipos de desarrolladores, especialmente a direcciones de billetera específicas. Rastreé conexiones a servicios de calendario o pegue sitios desde entornos de compilación. |
| Inyección de código invisible mediante Unicode Stealth | El JavaScript malicioso se codifica utilizando selectores de variación Unicode (U+FE00 a U+FE0F) y caracteres de ancho cero que no se representan en los editores, pero siguen siendo código ejecutable válido. | La revisión de código se vuelve ineficaz. Los desarrolladores que examinan los archivos fuente ven líneas en blanco mientras los intérpretes de JavaScript ejecutan malware oculto. | Analice los archivos fuente en busca de caracteres Unicode no imprimibles, especialmente selectores de variación y uniones de ancho cero. Implemente comprobaciones automatizadas que decodifiquen y analicen el contenido real de bytes de los archivos fuente, no su representación renderizada. |
| Acciones de GitHub como infraestructura de exfiltración |
Implementar flujos de trabajo que contengan ${{ toJSON(Secretos) }} Expresiones que serializan todos los secretos del repositorio y los publican en puntos finales controlados por el atacante. El flujo de trabajo se ejecuta en la infraestructura de GitHub y se presenta como legítimo. CI/CD actividad.
|
Robo completo del repositorio Secreto sin activar la detección de exfiltración tradicional, ya que el tráfico se origina en los rangos de IP confiables de GitHub. |
Escanear archivos de flujo de trabajo para toJSON(Secretos) Patrones. Supervise los flujos de trabajo que realizan solicitudes HTTP externas con cuerpos POST extensos. Alerte sobre adiciones de flujos de trabajo a repositorios sin las solicitudes de solicitud correspondientes o commit historia.
|
| Implementación de RAT híbrida en entornos de desarrollo | Implemente capacidades completas de RAT (proxy SOCKS, VNC, WebRTC P2P) diseñadas específicamente para estaciones de trabajo de desarrolladores. Apunte a credenciales de desarrollo, acceso al código fuente y posicionamiento interno en la red, en lugar de datos de usuario tradicionales. | Los desarrolladores comprometidos proporcionan acceso directo a los repositorios de código fuente, CI/CD pipelines, infraestructura en la nube y redes corporativas internas. | Supervise implementaciones inesperadas de servidores proxy, procesos de servidor VNC, conexiones WebRTC desde equipos de desarrollo y la participación en la red BitTorrent DHT. Implemente una segmentación de red estricta y un filtrado de salida. |
| Infección de la cadena de dependencia | Los paquetes maliciosos declaran otros paquetes controlados por el atacante como dependencias. La instalación de un paquete desencadena la instalación automática de toda la cadena. | Una sola dependencia maliciosa puede introducir docenas de paquetes controlados por el atacante. La limpieza requiere identificar y eliminar toda la cadena de infección. | Analice los gráficos de dependencias para detectar patrones inusuales: dependencias circulares, paquetes hermanos con nombres aleatorios o adiciones repentinas de dependencias. Implemente instalaciones que solo utilicen archivos de bloqueo para evitar la resolución automática de dependencias. |
Postura Defensiva
Ha llegado la era de los gusanos autopropagadores de la cadena de suministro. La defensa requiere automatización, vigilancia y controles arquitectónicos que asuman la vulnerabilidad en lugar de esperar la detección. Cada instalación de paquete es un vector de infección potencial. Cada credencial es un mecanismo de propagación. La pregunta ya no es si se producirán ataques, sino con qué rapidez se pueden detectar y contener cuando ocurran.
Para defenderse de paquetes maliciosos tipo gusano es necesario pasar del análisis reactivo a la prevención proactiva y al monitoreo continuo:
Pipeline Controles:
- Aplicar instalaciones solo con archivos de bloqueo (
npm ci,yarn install --frozen-lockfile) para evitar actualizaciones automáticas de dependencias y garantizar una fijación estricta de la versión. - Implementar el escaneo previo a la instalación de paquetes y árboles de dependencia completos, bloqueando paquetes maliciosos antes de su ejecución.
- Bloquear paquetes con características sospechosas: paquetes de gran tamaño, ofuscación, pre/post instalación inesperada hooks.
- Requerir revisión de código para agregar y actualizar dependencias.
Gestión de credenciales:
- Minimizar el alcance del token: la publicación de tokens debe apuntar solo a paquetes específicos cuando sea posible.
- Implementar tokens de corta duración con rotación automática.
- Nunca almacene tokens en el código fuente o en variables de entorno.
- Utilice cuentas de servicio CI dedicadas con privilegios mínimos.
Detección y Monitoreo:
- Realice un seguimiento de los patrones de publicación y reciba alertas sobre ráfagas inusuales de mantenedores individuales.
- Supervisar los flujos de trabajo de GitHub Actions para la serialización de Secreto, como
toJSON(Secretos). - Escanee las adiciones al flujo de trabajo para solicitudes HTTP externas.
- Detectar nuevos repositorios públicos con nombres inusuales o contenido codificado.
- Supervisar las estaciones de trabajo de los desarrolladores para detectar servidores proxy inesperados. CI/CD ejecutores, procesos VNC o consultas RPC de blockchain.
Respuesta al incidente:
- Tratar cualquier ejecución de instalación sospechosa hooks como compromiso completo.
- Suponga que todos los tokens en los hosts comprometidos son robados: rótelos inmediatamente.
- Reconstrucción afectada CI/CD corredores de imágenes limpias.
- Audite todos los paquetes propiedad de cuentas comprometidas para detectar versiones maliciosas.
- Verifique la persistencia en los flujos de trabajo de GitHub y la configuración del repositorio.
Los proveedores de IA suelen afirmar que cualquier herramienta puede usarse para bien o para mal. Los sistemas de IA no pueden evitar por completo el uso dual, pero sí pueden generar fricción y mejorar la visibilidad forense. La verdadera pregunta de diseño no es "¿se puede abusar de la IA?", sino "¿cuánta fricción podemos añadir sin perjudicar su utilidad legítima?". Un hecho es innegable: Hacer jailbreak a los sistemas de IA actuales es demasiado fácilEl análisis de mensajes maliciosos en ataques recientes muestra que el no determinismo de LLM se extiende a sus guardrails.
Están surgiendo varias ideas para mejorar la seguridad de la IA: autenticación robusta de origen, aislamiento de contenido confiable y controles basados en políticas para sistemas externos (con la incorporación de MCP y protocolos similares). Solo el tiempo dirá si la IA se convertirá en la próxima arma para ataques a gran escala contra la infraestructura de OSS.
Leer más
- Shai-Hulud: El gusano de paquetes npm explicado
- Ataque a la cadena de suministro de NPM Shai-Hulud 2.0
- GlassWorm: El primer gusano autopropagador con código invisible llega al mercado OpenVSX – Koi Security
- Desmantelando la primera campaña de ciberespionaje orquestada por IA reportada – Anthropic
- Análisis de las indicaciones de IA utilizadas en el ataque Nx
- Compromiso generalizado de la cadena de suministro que impacta el ecosistema npm – CISA
- Nuestro plan para una cadena de suministro de npm más segura – Blog de GitHub
Sobre el Autor
Escrito por Luis Rodríguez , cofundador y director de tecnología de Seguridad Xygeni.
Luis es fisiocist, matemático, y CISSP con más de 20 años de experiencia en seguridad de software. Ha liderado y contribuido a importantes iniciativas de seguridad en... SAST, SCAy tecnologías avanzadas de análisis de código. Actualmente, se centra en software supply chain security, combinando investigación profunda con ingeniería práctica para ayudar a los equipos a defender DevSecOps moderno pipelines de amenazas emergentes.
