Nuevas amenazas en código abierto: gusanos, malware impulsado por IA y abuso de confianza

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.

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 funciona a través de una carga útil de JavaScript altamente minificada y empaquetada con 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.env y 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); } }

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, inyecta bundle.js con un gancho de postinstalación y republicaciones. Este comportamiento autónomo provocó que el número de paquetes infectados aumentara de docenas a cientos 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 han publicado aproximadamente 700 versiones de paquetes maliciosos, dirigidos a objetivos de alto perfil con millones de descargas semanales. Limitado a paquetes npm y repositorios de GitHub.
• Infraestructura: C2 en 217.69.3.218, exfiltración a 140.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 -migration sufijo

Shai-Hulud es un gusano que recolecta Secretos. No intentó robar dinero ni dañar la infraestructura. Los Secretos extraídos y los repositorios expuestos pueden usarse para ataques dirigidos, por lo que el daño derivado del robo de credenciales podría manifestarse posteriormente. El verdadero costo reside en la recuperación, la rotación de credenciales y el riesgo de ataques secundarios.

Un efecto positivo fue obligando a GitHub/NPM a tomar medidas inmediatas : descontinuar 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 ciberdelincuentes regresaron con “The Second Coming”, una oleada significativamente más agresiva que aprendió de las debilidades del primer ataque. La campaña se identificó a sí misma a través de repositorios etiquetados como “Sha1-Hulud: La Segunda Venida”.

Examinemos las diferencias clave con respecto a la primera ola. preinstall El hook 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 Activador de flujo de trabajo. (Si “conoces a algún amigo que use eso”, por favor 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 replicación automatizada. mvnpm La herramienta —que convierte paquetes npm en artefactos Maven sin revisión de seguridad— republicó automáticamente paquetes npm comprometidos como posthog-node@4.18.1 as org.mvnpm:posthog-node:4.18.1.

Este fue el primer gusano de registro cruzado conocido: una vulnerabilidad de npm que afectó al ecosistema Java sin ninguna interacción directa. Maven Central eliminó los artefactos el 25 de noviembre de 2025, pero la ventana de exposición aún afectó las cargas de trabajo de Java/JVM y 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. Aún más avanzado, creó discussion.yaml flujos de trabajo que escuchaban los eventos de GitHub Discussions y ejecutaban los cuerpos de los mensajes de discusión como comandos de shell, convirtiendo efectivamente GitHub Discussions 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 su propagación. Este mecanismo de seguridad garantizaba el daño incluso si la replicación fallaba, lo que indicaba un cambio de operaciones centradas exclusivamente en el espionaje a campañas potencialmente destructivas.

A pesar de emplear técnicas sigilosas (Bun Runtime, 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 autohospedados de larga duración. Este ritmo agresivo contrasta notablemente 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 "abrumar" para maximizar el daño en un corto período 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 de Unicode y una infraestructura de comando y control basada en blockchain.

Técnica de sigilo Unicode:

La principal innovación de GlassWorm reside en el abuso de los selectores de variación Unicode: caracteres especiales que no generan ninguna salida visual, pero que siguen siendo ejecutables en JavaScript. Esto crea código malicioso que aparece como líneas en blanco en los editores de código, las comparaciones de GitHub y el resaltado de sintaxis de los IDE. Esta técnica socava fundamentalmente la revisión humana del código al ocultar lógica ejecutable dentro de regiones visualmente vacías.

El ataque se dirigió a las extensiones de VS Code en el mercado de OpenVSX. El análisis de la extensión CodeJoy (v1.8.3) reveló grandes secciones ocultas que contenían código 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 utilizando la cadena de bloques Solana. El malware busca transacciones desde una dirección de billetera predefinida; los campos de notas de las transacciones 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%3D

https://calendar.app.google/M2ZCvM8ULL56PD1d6 Event title: aHR0cDovLzIxNy42OS4zLjIxOC9nZXRfem9tYmlfcGF5bG9hZC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlUdg== Decodes to: http://217.69.3.218/get_zombi_payload/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3D

Esto 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 envían cargas útiles cifradas mediante AES-256-CBC. Las claves de descifrado se generan para cada solicitud y se transmiten a través de encabezados HTTP personalizados, lo que garantiza que las cargas útiles interceptadas no puedan descifrarse 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. Combinado con el acceso remoto invisible, esto 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 de npm, credenciales de GitHub y tokens de acceso de OpenVSX. Estas credenciales permiten su propagación autónoma a otros paquetes y extensiones, 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 a 140.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 los ataques recientes, uno podría preguntarse: ¿Los actores de amenazas utilizan IA para crear malware? Por supuesto. Pero pueden ampliar aún más los ataques utilizando la IA como arma para la orquestación. A continuación, se describe una campaña de ciberespionaje; pero imaginen estas mismas técnicas aplicadas a ataques automatizados dirigidos a sistemas de código abierto.

En septiembre de 2025, Anthropic detectado e interrumpido El primer ciberataque documentado ejecutado en gran medida sin intervención humana. La campaña logró una ejecución autónoma del 80-90%. utilizando Claude Code como motor de orquestaciónCon agentes de IA realizando reconocimiento, explotación, movimiento lateral y exfiltración de datos. Esto marca el paso de los ataques asistidos por IA a las operaciones cibernéticas orquestadas por IA.

El grupo de ciberdelincuentes GTG-1002 (un grupo patrocinado por el Estado chino) atacó a unas 30 organizaciones de los sectores tecnológico, financiero y gubernamental. Desarrollaron un sistema autónomo que transformó a Claude Code, de un asistente de programación a 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 sistema dividió los ataques multietapa en tareas aisladas, cada una aparentemente inofensiva por sí sola. Mediante indicaciones cuidadosamente elaboradas y perfiles predefinidos, los atacantes indujeron a Claude a ejecutar acciones dañinas sin comprender su contexto malicioso.

La IA ejecutó los pasos técnicos mientras el motor de orquestación supervisaba el estado de la campaña, gestionaba las transiciones de fase y agregaba los resultados a lo largo de sesiones de varios días. La intervención humana se limitó a la supervisión de alto nivel: inicialización, selección de objetivos, aprobación de escalamientos 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ó datos robados para priorizar la información valiosa, manteniendo un contexto persistente 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 de que realizara tareas de intrusión cibernética 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. Combinado con el aislamiento de tareas, esto fue suficiente para vulnerar los controles de seguridad de la IA.

¡Las alucinaciones son geniales!

Claude solía tener resultados alucinantes: reportaba supuestos éxitos que en realidad habían fracasado, inventaba credenciales y fabricaba descubrimientos. Por ahora, esto limita las operaciones totalmente autónomas, pero a medida que los modelos mejoren, estas debilidades disminuirán. Hasta entonces, un fallo común de la IA es, irónicamente, nuestro mejor aliado 🙃.

Detección y Respuesta:

Anthropic detectó la campaña mediante patrones de uso anómalos que indicaban un comportamiento de intrusión sistemática. Bloquearon las cuentas asociadas, notificaron a las organizaciones afectadas, coordinaron con las autoridades e integraron los patrones de ataque en controles de seguridad más amplios.

Implicaciones en la cadena de suministro:

Cada técnica aquí demostrada se aplica directamente a los ecosistemas de paquetes. La IA podría descubrir de forma autónoma a los responsables del mantenimiento vulnerables, generar paquetes maliciosos y orquestar ataques a nivel de registro a la velocidad de la máquina. La barrera ha pasado de ser un «equipo de ciberdelincuentes expertos» a un «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 criptominado global que se propagó de forma autónoma a través de clústeres de Ray expuestos.

Otro ejemplo: S1ngularidad atacar , explotando la misma pull_request_target Problema mencionado anteriormente. Detecta herramientas CLI de IA instaladas localmente (Claude, Gemini, Q con indicadores de derivació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 a través de campañas de spam que inundan los registros con miles de paquetes. El uso de DevOps para el cibercrimen es común: los atacantes utilizan habitualmente SCMs y registros para OSINT, distribución de etapas de malware, extracción de Secretos y mantenimiento de comando y control. Pero estas plataformas también pueden ser abusado con fines no maliciososAunque tradicionalmente no son maliciosas, este tipo de 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 circular para inflar las métricas de contribución. Scripts automatizados publicaban aproximadamente 12 paquetes por minuto con nombres indonesios y términos culinarios generados aleatoriamente. El archivo README de un paquete incluso presumía de ganancias en tokens TEA, lo que confirmaba el motivo financiero.

La campaña abarcó aproximadamente 44 000 paquetes —más del 1 % de npm— y se prolongó durante casi dos años. Las dependencias circulares implicaban que la instalación de un solo paquete podía instalar cientos de paquetes basura. Los resultados de búsqueda se degradaron, la confianza en las métricas de los paquetes se vio mermada y el ancho de banda y el almacenamiento del registro se vieron gravemente afectados.

Si bien el abuso del protocolo TEA se documentó en abril de 2024, la eliminación sistemática no se produjo hasta noviembre de 2025, lo que puso de manifiesto importantes deficiencias en la detección de abusos en el registro. Este 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

El campaña de elfos En diciembre de 2025 se hizo hincapié en el abuso de la infraestructura en lugar de la intención maliciosa. Las descripciones de los paquetes hacían referencia a "desafío de captura de la bandera" y "pruebas" (incluido el texto en francés: "Package généré automatiquement toutes les 2 minutes"), lo que sugiere orígenes en la investigación de seguridad o en ejercicios de CTF.cispor ejemplo.

Los paquetes siguieron de forma consistente elf-stats-* Nombres con temática estacional. Algunos contenían shells inversas triviales (simples líneas de comando bash), tan rudimentarias que parecían diseñadas únicamente para pruebas de detección en lugar de para una explotación real.

El ritmo operativo —un paquete cada 2 minutos en múltiples cuentas— puso a prueba las capacidades de limitación de velocidad y detección de abusos de npm. La campaña demostró que el envío masivo de paquetes automatizado puede persistir durante horas o días antes de que se intervenga, consumiendo recursos de almacenamiento, ancho de banda y moderación.

Lo más importante es que sirvió de advertencia a otros ciberdelincuentes de 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)

Postura Defensiva

Ha llegado la era de los virus informáticos que se propagan solos en la cadena de suministro. La defensa exige automatización, vigilancia y controles arquitectónicos que partan de la base de que existe una vulnerabilidad, en lugar de depender de la detección. Cada instalación de paquete es un vector de infección potencial. Cada credencial es un mecanismo de propagación. La cuestión ya no es si se producirán ataques, sino con qué rapidez se pueden detectar y contener cuando ocurren.

Para protegerse de los paquetes maliciosos con forma de gusano, es necesario pasar del escaneo reactivo a la prevención proactiva y la monitorización continua:

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 el bien o para el mal. Los sistemas de IA no pueden evitar por completo el doble uso, pero 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 permanece innegable: Hacer jailbreak a los sistemas de IA actuales es demasiado fácilEl análisis de las indicaciones maliciosas 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 de origen sólida, aislamiento de contenido confiable y controles basados ​​en políticas para sistemas externos (con MCP y protocolos similares que ahora se están incorporando al panorama). Solo el tiempo dirá si la IA se convierte en la próxima arma para ataques a gran escala contra la infraestructura de software de código abierto.

Descubre 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 la autora

Escrito por Luis Rodríguez , Cofundador y CTO en 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. Hoy en día, se centra en software supply chain security, combinando una investigación profunda con ingeniería práctica para ayudar a los equipos a defender las prácticas modernas de DevSecOps. pipelines de amenazas emergentes.