IronWorm y la nueva variante de Miasma Worm atacan a npm en ataques a la cadena de suministro – CYBERDEFENSA.MX

Múltiples ataques a la cadena de suministro de software han afectado al ecosistema npm, y los actores de amenazas utilizan versiones maliciosas y envenenadas de más de 50 paquetes legítimos para distribuir un ladrón de información basado en Rust y un gusano que se propaga automáticamente, respectivamente.

De acuerdo a JFrogel ladrón de información «elimina todos los secretos que puede encontrar en la máquina de un desarrollador, se esconde detrás de un rootkit del núcleo eBPF y responde a su operador a través de Tor».

El ladrón también utiliza las credenciales robadas como mecanismo de propagación, generando similitudes con el infame gusano Shai-Hulud. El nuevo malware tiene un nombre en clave gusano de hierro por la empresa de seguridad de la cadena de suministro de software. Al publicarse en el registro npm en forma de paquetes troyanizados, este enfoque resulta en un ataque autorreplicante.

La actividad maliciosa se remonta a una cuenta npm comprometida llamada «asteroide«, que se ha descubierto que publica versiones de paquetes que contienen el binario Rust ELF que se ejecuta a través de un gancho de preinstalación.

El malware se dirige a 86 variables de entorno, varios archivos que pueden contener credenciales asociadas con OpenAI Codex, Anthropic, Claude, Google Gemini, Cursor, Amazon Web Services (AWS), Docker, Kubernetes y npm, configuraciones de bóveda y archivos de billetera de criptomonedas Exodus.

Una peculiaridad inusual que vale la pena mencionar aquí es que el ladrón incluye una lógica para que el componente de robo de datos de la billetera omita la billetera del propio actor de la amenaza. Al momento de escribir, el billetera de criptomonedas está vacío y no se han registrado transacciones.

Ciberseguridad

JFrog describió a IronWorm como «un arma de cadena de suministro creada para encontrar secretos, modificar proyectos e inyectar código malicioso para autopropagarse en GitHub». Las confirmaciones maliciosas, que abarcan nueve organizaciones de GitHub, se introdujeron bajo el nombre del autor «claude» («claude@users.noreply.github.com») en un intento de imitar el chatbot de inteligencia artificial (IA) de Anthropic.

«El paquete malicioso npm fue publicado por asteroiddao; asteroiddao corresponde a la organización asteroid-dao GitHub; y ocrybit es miembro de esa organización, así como de organizaciones Arweave relacionadas», explicó la compañía.

«El malware robó las credenciales de ocrybit y las usó para enviar confirmaciones a través de repositorios a los que podía acceder. Esas confirmaciones colocaron malware en otros paquetes, que luego podrían publicarse e infectar al siguiente desarrollador. Y luego desapareció».

Es más, la carga útil maliciosa está equipada para intercambiar los flujos de trabajo de GitHub Actions existentes por uno que sea capaz de recolectar los secretos, escribirlos en un archivo de apariencia inofensiva y cargarlo como un artefacto de compilación, eliminando así la necesidad de un servidor externo de comando y control (C2).

Las capacidades del malware no terminan ahí. En entornos de CI, abusa del flujo de publicación confiable de npm para obtener tokens de corta duración para enviar versiones envenenadas que contienen el malware al registro.

También incorpora una carga útil eBPF que funciona como un rootkit a nivel de kernel para ocultar procesos y frustrar análisis. Sin embargo, en los sistemas donde el bloqueo del kernel está habilitado, los trucos para ocultar procesos fallan y los supuestos procesos y sockets vuelven a ser visibles.

El gusano miasma emerge nuevamente

La revelación surge como Laboratorios Endor y PasoSeguridad arrojar luz sobre una distinta campaña de ataque a la cadena de suministro que ha comprometido 57 paquetes npm en más de 286 versiones maliciosas para servir una nueva variante del gusano Miasma, que previamente infectó 32 paquetes en más de 90 versiones bajo el espacio de nombres npm @redhat-cloud-services en 72 segundos a principios de esta semana.

Algunos de los paquetes afectados se enumeran a continuación:

  • ai-sdk-ollama
  • autotel
  • esperando
  • analizador de efectos
  • complemento-eslint-esperando
  • historias-ejecutables-ciprés
  • http-uploader-dev
  • montado
  • nodo-env-resolver
  • nodo-env-resolver-aws

Los datos robados a través del malware se filtran a una cuenta de GitHub ahora inaccesible «liuende501«, que actuó como un punto de exfiltración. Se almacenaron hasta 236 repositorios en la cuenta. Actualmente no se sabe si GitHub eliminó la cuenta o si el propio actor de la amenaza la eliminó.

«Esta ola utiliza una técnica que llamamos ‘Phantom Gyp’: en lugar de los scripts de ciclo de vida previos o posteriores a la instalación que las herramientas de seguridad normalmente monitorean, el atacante abusa de un archivo vinculante.gyp de 157 bytes para activar la ejecución del código durante la instalación de npm, evitando por completo la mayoría de los controles de seguridad de los scripts de instalación», dijo el investigador de StepSecurity, Sai Likhith.

Como en el caso de Miasmala cadena de ataque está diseñada para descargar e instalar el tiempo de ejecución de Bun JavaScript, usándolo para cargar un recolector de credenciales integral diseñado para extraer secretos de AWS, Google Cloud, Microsoft Azure, HashiCorp Vault, Docker, Kubernetes, GitHub Actions, npm, RubyGems, PyPI, SSH, administradores de contraseñas y asistentes de IA.

«La capacidad más novedosa y preocupante de esta variante es su objetivo en configuraciones de asistente de codificación de IA», dijo la compañía. «El malware inyecta archivos persistentes de puerta trasera en repositorios de proyectos que se ejecutan cada vez que un desarrollador abre el proyecto en su IDE asistido por IA».

Se recomienda a los desarrolladores que hayan instalado una versión afectada que roten las credenciales, desactiven los scripts de instalación y las reconstrucciones nativas de forma predeterminada y se aseguren de que los paquetes estén fijados con hashes de integridad.

Ciberseguridad

En una actualización compartida esta semana, Red Hat reveló que la causa principal detrás del incidente de la cadena de suministro de Miasma fue probablemente una cuenta de GitHub comprometida que se utilizó para enviar confirmaciones no autorizadas a los repositorios de la organización RedHatInsights GitHub.

«La carga útil operaba en Linux, macOS y Windows descargando dinámicamente el tiempo de ejecución de Bun correcto para cada plataforma, aunque los ejecutores de CI/CD de Linux parecían ser el objetivo principal», explicó Microsoft. dicho de la campaña.

«En los sistemas de desarrollo, el malware robó claves Secure Shell (SSH), credenciales de interfaz de línea de comandos (CLI), datos del navegador y de la billetera, mientras que en entornos CI/CD extrajo la memoria del ejecutor de GitHub Actions en busca de secretos, escaló privilegios usando sudo sin contraseña y volvió a publicar paquetes envenenados con niveles de cadena de suministro falsificados para artefactos de software (SLSA) para continuar con la propagación descendente».

Se considera que la carga útil Miasma es un derivado del gusano Shai-Hulud utilizado por EquipoPCP en campañas recientes, introduciendo cambios en gran medida «cosméticos» manteniendo similar la funcionalidad subyacente. A pesar de la superposición en el oficio, la atribución del último conjunto de ataques sigue sin estar clara, dado que TeamPCP ha publicado públicamente el código Shai-Hulud.

Desde entonces, OX Security ha descubierto etapas adicionales en la cadena de ataque de Miasma, incluidas búsquedas de confirmaciones de GitHub que contienen la cadena «firedalazer» (que reemplaza el punto muerto «FIRESCALE» previamente marcado) para recuperar otra carga útil, un archivo JavaScript («index.js») que contiene una versión alternativa del gusano Shai-Hulud, transformando efectivamente la infección en un bucle perpetuo.

En este caso, los datos robados se filtran a repositorios públicos de GitHub, cada uno con la descripción «Miasma: The Spreading Blight» o «Miasma – The Spreading Blight». Es importante señalar aquí que la versión anterior dice «Miasma: The Spreading Blight», que no tiene un espacio entre Miasma y el símbolo «:». Hay actualmente 82 repositorios de este tipo creado en las cuentas de usuario «0tabek16» y «windy629».

«El actor de amenazas puede cambiar dinámicamente las confirmaciones de ‘firedalazer’ en GitHub, haciendo que las nuevas versiones del malware sean más adaptables y más sofisticadas», afirman los investigadores de seguridad Moshe Siman Tov Bustan y Nir Zadok. dicho.

«Esto convierte a GitHub en algo más peligroso que un punto muerto. Es un C2 adaptable, uno que se apoya en una plataforma confiable y ampliamente incluida en la lista blanca, haciendo que la detección a nivel de red sea casi inútil. La mayoría de las herramientas de seguridad no están configuradas para tratar el tráfico de GitHub como sospechoso. El actor de la amenaza lo sabe».

El ataque a la cadena de suministro de Miasma compromete los paquetes npm de Red Hat con un gusano que roba credenciales – CYBERDEFENSA.MX

Una nueva campaña de ataque a la cadena de suministro Mini Shai-Hulud, con nombre en código Miasmaha comprometido paquetes de @redhat-cloud-services para robar credenciales y secretos de las máquinas de los desarrolladores y entregar un gusano autopropagante.

«Esta es efectivamente una campaña Mini Shai-Hulud: utiliza las mismas tácticas centrales de ejecución en el momento de la instalación, recolección de credenciales, segmentación de CI/CD, exfiltración cifrada y posible propagación descendente», afirmó Socket. dicho.

Actualmente se desconoce exactamente quién está detrás de la actividad de ataque, dado que TeamPCP, un infame grupo de cibercrimen, ha abierto las herramientas de ataque vinculadas al gusano Shai-Hulud, abriendo la puerta para que otros actores de amenazas realicen ataques similares y dificultando la atribución definitiva.

Los nombres de algunos de los paquetes afectados se enumeran a continuación:

  • @redhat-cloud-services/vulnerabilidades-cliente
  • @redhat-cloud-services/tsc-transform-importaciones
  • @redhat-cloud-services/cliente-de-inventario-topológico
  • @redhat-cloud-services/fuentes-cliente
  • @redhat-cloud-services/rule-components
  • @redhat-cloud-services/cliente-de-remediaciones
  • @redhat-cloud-services/rbac-client

Por análisis de Seguridad del Aikido, JFrog, microsoft, Seguridad buey, SafeDep, PasoSeguridady Fenómenolos paquetes npm contienen un enlace de preinstalación ofuscado que está diseñado para recopilar secretos de GitHub Actions, tokens npm, credenciales de nube, material de Kubernetes y Vault, claves SSH, credenciales de Git y otros archivos confidenciales.

Ciberseguridad

Como se observó en oleadas anteriores de Mini Shai-Hulud, el malware también contiene una lógica de exfiltración cifrada que transmite los datos a «api.anthropic».[.]com:443/v1/api» y utiliza GitHub como mecanismo alternativo. Esto indica intentos realizados por el atacante de robar credenciales y utilizarlas como arma para envenenar aún más la cadena de suministro de software.

«Confirma el sobre de resultados cifrado a través de la API de GitHub», dijo Socket. «El mensaje de confirmación puede incluir: IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner:«.

Otro paso notable que lleva a cabo el malware es evitar la ejecución en sistemas en idioma ruso, un patrón que también se observa en las campañas de la cadena de suministro de GlassWorm.

«Para npm, la carga útil llama al intercambio de tokens OIDC y a los puntos finales whoami, vuelve a empaquetar un tarball (updateTarball, package-updated.tgz) y firma el artefacto a través de Sigstore», dijo SafeDep. «Las credenciales robadas se filtran a repositorios públicos de GitHub creados por atacantes, cada uno con la descripción Miasma: The Spreading Blight».

La primera confirmación que contiene la cadena «Miasma: The Spreading Blight» apareció el 29 de mayo de 2026, señaló OX Security, lo que indica que esta variante estaba activa desde entonces o que el actor de amenazas comenzó a realizar pruebas en ese momento.

En cuanto a GitHub, el malware enumera los repositorios en los que el token puede escribir, lee action.yml/action.yaml a través de GraphQL y confirma un flujo de trabajo a través de la mutación createCommitOnBranch para que la confirmación aparezca como un cambio firmado y verificado. Otras acciones llevadas a cabo por el malware se enumeran a continuación:

  • Intente escalar privilegios lanzando un contenedor que monte de forma vinculante el host /etc/sudoers.d y otorgue al corredor de CI sudo sin contraseña
  • Verifique la protección de endpoints de CrowdStrike, SentinelOne, Carbon Black y StepSecurity Harden-Runner antes de comenzar las acciones maliciosas.
  • Establezca persistencia inyectando un gancho SessionStart en Anthropic Claude Code y un task.json con «runOn»: «folderOpen» para proyectos de Microsoft Visual Studio Code para que el malware se inicie automáticamente durante cada sesión.

«Uno de los principales cambios en esta nueva variante es la incorporación de nuevos recolectores de datos centrados en identidades en la nube», dijeron los investigadores de Wiz. «Específicamente, se agregaron recopiladores de identidades de GCP y Azure que recopilan todas las identidades a las que tiene acceso la máquina infectada. Mientras que las versiones anteriores del malware se centraban principalmente en extraer secretos de estos entornos, esta variante sugiere un mayor enfoque del atacante en obtener y aprovechar el acceso a la propia nube.

A diferencia de las versiones anteriores, también se ha descubierto que el malware genera una carga útil cifrada de forma única para cada infección, lo que hace que la detección y el seguimiento de versiones sean significativamente más difíciles.

Ciberseguridad

La evidencia sugiere que el compromiso de la cuenta de GitHub de un empleado de Red Hat fue el paciente cero que se utilizó para inyectar la carga útil en estos paquetes. Se dice que la cuenta comprometida envió confirmaciones huérfanas maliciosas a dos repositorios de RedHatInsights, evitando la revisión del código.

Se recomienda aislar los hosts que han instalado las versiones afectadas, eliminar las versiones maliciosas, rotar las credenciales expuestas, revisar si hay signos de actividad sospechosa de GitHub o npm, auditar el entorno en busca de artefactos de persistencia que involucren cambios en los archivos de configuración (~/.claude/settings.json, .vscode/tasks.json, .github/workflows/codeql.yml, .github/setup.js) y aplicar controles de acceso estrictos.

«Debido a que el malware incluye ejecución en segundo plano y posibles mecanismos de persistencia de herramientas de desarrollador, desinstalar el paquete npm o eliminar node_modules no debe considerarse una limpieza suficiente», explicó Socket.

«Para los sistemas CI/CD, suspenda las ejecuciones de flujo de trabajo afectadas, invalide los artefactos de compilación producidos durante la ventana de exposición y revise si se creó alguna versión, imagen de contenedor, paquete npm o artefacto de implementación después de instalar el paquete malicioso».

Tokens de autenticación OpenAI Codex robados en un ataque a la cadena de suministro de codexui-android npm – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de una nueva campaña maliciosa en la cadena de suministro dirigida a desarrolladores que utilizan OpenAI Codex a través de una interfaz de usuario web remota de apariencia legítima.

La herramienta, denominada codexui-androidse anuncia en GitHub y npm como una interfaz de usuario web remota para OpenAI Codex, y atrae más de 29.000 descargas semanales. El paquete todavía está disponible para descargar desde el repositorio.

Lo que hace que esta actividad sea notable es que no es un ataque tradicional que utiliza un typosquat o un paquete desechable para engañar a los desarrolladores. Más bien, el código malicioso está integrado en un paquete npm funcional que ha sido objeto de desarrollo activo. El repositorio de GitHub asociado permanece limpio.

«Y durante el último mes, cada invocación ha estado filtrando silenciosamente sus tokens de autenticación del Codex a un servidor controlado por un atacante», dijo el investigador de Aikido Security, Charlie Eriksen. dicho.

Se dice que los nefastos cambios se introdujeron aproximadamente un mes después de que el paquete se publicara en el registro, probablemente en un esfuerzo por generar confianza en los usuarios y ampliar su alcance. La cuenta npm asociada con el paquete es «friuns» (también conocida como Igor Levochkin).

Dentro del paquete está presente un código que extrae el contenido del archivo «~/.codex/auth.json» del Codex y lo exfiltra a un servidor remoto («sentry.anyclaw[.]store») que se hace pasar por Sentry, una plataforma legítima de monitoreo de aplicaciones y seguimiento de errores. Los datos capturados incluyen los siguientes detalles: access_token, refresco_token, id_token e ID de cuenta.

«El token de actualización no caduca», dijo Eriksen. «Un atacante que lo posea puede hacerse pasar por usted silenciosamente indefinidamente. Un token de actualización del Codex robado va más allá del acceso a una interfaz de chat: es un acceso persistente y silencioso a cualquier cosa que esa cuenta pueda hacer».

Ciberseguridad

Vale la pena mencionar aquí que cada vez que un usuario inicia sesión en la aplicación Codex, CLI o extensión IDE usando ChatGPT o una clave API, los detalles de inicio de sesión se almacenan en caché localmente en un archivo de texto sin formato en ~/.codex/auth.json o en el almacén de credenciales específico del sistema operativo.

«Si utiliza almacenamiento basado en archivos, trate ~/.codex/auth.json como una contraseña: contiene tokens de acceso», OpenAI advierte en su documentación de soporte. «No lo cometas, pégalo en tickets o compártelo en el chat».

Curiosamente, el paquete npm está lejos de ser el único vector de entrega que el actor de amenazas utiliza para atacar a los desarrolladores del Codex. Aikido dijo que observó una aplicación de Android llamada Agente OpenClaw Codex Claude AI (nombre del paquete: «gptos.intelligence.assistant») que ejecuta el paquete npm dentro de su zona de pruebas PRoot y envía las credenciales del Codex al mismo punto final.

«El APK en sí es pequeño (26 MB) y se ve limpio en un análisis previo a la publicación de Play», explicó Eriksen. «En la primera ejecución, extrae un espacio de usuario de Linux derivado de Termux en el almacenamiento privado de la aplicación y ejecuta Node.js dentro de él a través de PRoot».

«La versión no está fijada, por lo que el dispositivo extrae todo lo que está publicado actualmente en npm. La exfiltración ha estado vigente desde codexui-android@0.1.82. El paquete se ejecuta dentro del entorno limitado PRoot de la aplicación, donde el inicio de sesión del Codex en la aplicación escribe su auth.json. Una vez que el usuario inicia sesión, el paquete lee ese archivo fuera del entorno limitado y envía el blob OAuth completo a sentry.anyclaw.store/startlog».

Lanzada por una entidad llamada «BrutalStrike», la aplicación para Android tiene más de 50.000 descargas. La misma cadena de exfiltración también se ha señalado en una segunda aplicación de Android vinculada a BrutalStrike: Codex (nombre del paquete: «codex.app»), que se ha descargado más de 10.000 veces. Las tres aplicaciones restantes ofrecidas por el desarrollador no contienen la funcionalidad.

Al extendiendo la mano Al autor del paquete en GitHub, Aikido dijo que inicialmente publicaron un comentario indicando que habían perdido el acceso a su cuenta npm, solo para editar la respuesta y publicar una diferente en la que afirmaban que «actualmente están investigando este problema internamente» y que «han comenzado a eliminar la funcionalidad afectada y los datos relacionados».

El autor afirmó además que no se compartieron datos de credenciales con terceros, sin responder por qué este código se insertó solo en la compilación del paquete npm o por qué necesitaban acceso a los tokens del Codex en primer lugar. El perfil X vinculado al autor incluye el dominio «anyclaw[.]almacenar.»

Registros de WHOIS indicar que el dominio se registró el 12 de abril de 2026, solo dos días después de que se cargara la primera versión del paquete npm (versión 0.1.72) en npmjs[.]com.

Ciberseguridad

Este desarrollo se produce cuando los actores de amenazas apuntan cada vez más a herramientas y flujos de trabajo de desarrollo de inteligencia artificial (IA) reales para robar credenciales y profundizar en la cadena de suministro de software.

A finales del mes pasado, la empresa de seguridad belga también descubrió que una clave API de Google eliminada permanece activa durante hasta 23 minutos, una ventana que un atacante con acceso a una clave filtrada puede aprovechar para obtener acceso a los datos del usuario y otras API, incluidas las relacionadas con Google Gemini. La ventana de revocación mediana es de alrededor de 16 minutos.

«Un atacante que tenga su clave eliminada puede seguir enviando solicitudes hasta que llegue a un servidor que no se haya puesto al día», investigador Joe Leon dicho. «Si Gemini está habilitado en el proyecto, pueden volcar los archivos que hayas subido y filtrar conversaciones almacenadas en caché».

Aunque Google inicialmente optó por no solucionar el problema, afirmando que es una «propiedad conocida del sistema y no un problema de seguridad», desde entonces el gigante tecnológico ha decidido tratarlo como un problema. Error P0lo que lo convierte en un problema grave que «debe abordarse de inmediato».

Los hallazgos, al igual que con un ventana de explotación similar de 4 segundos observado anteriormente con las claves de acceso eliminadas de Amazon Web Services (AWS), resaltan cómo los retrasos en la revocación de credenciales son explotables y pueden usarse para obtener acceso no autorizado a los entornos de nube, mientras que los defensores asumen que las credenciales han sido revocadas.

CrowdStrike interrumpe la botnet Glassworm que se aprovechaba de la cadena de suministro de código abierto

CrowdStrike tiene desmanteló la botnet Glassworm en una operación con la ayuda de Google y Shadowserver, que despojó a los operadores del acceso a la infraestructura que ayudó a los actores de amenazas a infectar cientos de piezas de software de código abierto con malware desde principios de 2025, dijo la compañía el martes.

El esfuerzo coordinado implicó la eliminación simultánea de cuatro servidores controlados por atacantes que fueron diseñados para ocultar las operaciones de la botnet y permanecer resistentes a las interrupciones.

CrowdStrike y sus socios derribaron la infraestructura, cortaron el acceso a los servicios más críticos de la botnet, impidieron el impulso de la operación y desaceleraron la capacidad de los atacantes para escalar, dijo a CyberScoop Adam Meyers, vicepresidente senior de operaciones contra adversarios de CrowdStrike.

«El objetivo más amplio es una presión sostenida que obligue al adversario a gastar tiempo, recursos y energía operativa en reconstituir la infraestructura en lugar de atacar a las víctimas», añadió Meyers. «Al exponer el oficio y compartir inteligencia, los defensores pueden fortalecer los entornos de desarrollo, los canales de CI/CD y las cadenas de suministro de software contra actividades similares. Eso aumenta el costo operativo para el adversario y da a los defensores una ventaja».

Glassworm se ha dirigido a desarrolladores de software para acceder a repositorios de código fuente, plataformas en la nube, procesos de integración y entrega y registros de paquetes de código abierto para introducir malware en la cadena de suministro y desencadenar compromisos posteriores.

El grupo de amenazas detrás de la botnet, que probablemente tiene su sede en Rusia, según CrowdStrike, introdujo malware en extensiones VSCode, paquetes npm y Python y más de 300 repositorios de GitHub, dijeron los investigadores.

Glassworm afectó los sistemas Windows, macOS y Linux con robo de datos y credenciales, y una herramienta de acceso remoto llamada GlasswormRAT.

«Lo que destacó de Glassworm fue la sofisticación operativa en torno a la propagación y la automatización», dijo Meyers. «Esto no fue simplemente un compromiso de romper y apoderarse de un repositorio de paquetes. La operación fue diseñada para moverse a través de flujos de trabajo de desarrolladores confiables de una manera que podría expandir el alcance muy rápidamente si no se controla».

La botnet se basó en cuatro canales en capas que CrowdStrike interrumpió, incluida la cadena de bloques Solana, la red peer-to-peer de BitTorrent, Google Calendar y servidores privados virtuales alojados por proveedores comerciales.

«Como parte de nuestros esfuerzos de disrupción, estamos trabajando con socios para causar más dolor a los atacantes, especialmente cuando los vemos abusando de nuestros productos o atacando a nuestros usuarios», dijo John Hultquist, analista jefe de Google Threat Intelligence Group, en un publicar en X.

Las contramedidas destruyeron “el tejido conectivo de la operación para crear un dolor operativo en cascada”, dijo Meyers. «Esto obliga al adversario a reconstruir, al tiempo que expone el comercio».

CrowdStrike dijo que la eliminación demuestra cómo la industria de la seguridad puede frustrar eficazmente las amenazas a la cadena de suministro al interrumpir de manera proactiva la infraestructura precisa que utilizan los atacantes sin esperar largos procesos judiciales.

«Cuando los actores de amenazas operan desde jurisdicciones donde la cooperación policial es limitada o inexistente, la disrupción se convierte en una de las herramientas más eficaces disponibles. Si no se pueden poner esposas al operador, hay que centrarse en desmantelar la infraestructura, las relaciones de confianza y las dependencias operativas», añadió Meyers.

La empresa de seguridad compartió indicadores de compromiso para ayudar a las organizaciones a buscar posibles infecciones en sus entornos y pidió a otros proveedores, agencias de aplicación de la ley, operadores de plataformas y el ecosistema de código abierto que reúnan la misma determinación para responder a las amenazas en la cadena de suministro de software.

«Cuanto más visibilidad y alineación se cree en todo el ecosistema, más difícil será para el actor mantener silenciosamente la operación», dijo Meyers. «Es posible que no se elimine por completo al actor de la amenaza, pero se puede reducir absolutamente la eficacia, limitar el alcance y aumentar el costo de hacer negocios».

Greg Otto

Escrito por Greg Otto

Greg Otto es el editor en jefe de CyberScoop y supervisa todo el contenido editorial del sitio web. Greg ha dirigido una cobertura de ciberseguridad que ha ganado varios premios, incluidos los de la Sociedad de Periodistas Profesionales y la Sociedad Estadounidense de Editores de Publicaciones Empresariales. Antes de unirse a Scoop News Group, Greg trabajó para Washington Business Journal, US News & World Report y WTOP Radio. Tiene una licenciatura en periodismo televisivo de la Universidad de Temple.

La eliminación del malware GlassWorm interrumpe la infraestructura de ataque a la cadena de suministro de los desarrolladores – CYBERDEFENSA.MX

CrowdStrike, en asociación con Google y Shadowserver Foundation, ha anunciado la interrupción simultánea de todos los canales de comando y control (C2) asociados con GlassWorm, una campaña de cadena de software persistente dirigida a desarrolladores de software a través de paquetes y extensiones maliciosos.

«Desde al menos principios de 2025, los operadores de GlassWorm se han dirigido sistemáticamente a los desarrolladores de software, una población con acceso a repositorios de código fuente, plataformas en la nube, canales de CI/CD y registros de paquetes», CrowdStrike dicho.

El desarrollo se produce cuando los desarrolladores se han convertido en objetivos cada vez más lucrativos para realizar ataques a la cadena de suministro de software, lo que permite a los atacantes aprovechar una única estación de trabajo comprometida para impactar a miles de organizaciones y usuarios a la vez.

GlassWorm, desde su aparición el año pasado, ha llevado a cabo una «campaña multifacética» que utiliza extensiones de VS Code troyanizadas publicadas tanto en Microsoft VS Code Marketplace como en Open VSX, lo que permite dirigirse a usuarios de bifurcaciones de VS Code como Cursor, Positron, Windsurf y VSCodium.

Ciberseguridad

También se sabe que la campaña introdujo código malicioso a través de paquetes npm y Python comprometidos. El objetivo final de los ataques es ofrecer un marco de robo de datos con capacidades de recolección de credenciales, exfiltración de billeteras de criptomonedas y creación de perfiles del sistema.

Se ha descubierto que iteraciones posteriores de GlassWorm implementan una RAT de JavaScript basada en Websocket llamada GlassWormRAT para robar datos del navegador web y ejecutar código arbitrario, incluida la instalación de una extensión de Google Chrome que, a su vez, recopila datos confidenciales, incluidas capturas de pantalla, pulsaciones de teclas y contenido del portapapeles, del sistema infectado.

«Una vez activo, el malware busca en el host credenciales de desarrollador (GitHub, NPM, tokens OpenVSX, billeteras criptográficas), lo que permite comprometer aún más los repositorios y las cargas de paquetes», dijo el investigador de Endor Labs, Kiran Raj. dicho.

«Los hosts infectados se convierten en infraestructura encubierta: proxies SOCKS, servidores VNC (HVNC) ocultos y nodos de ejecución remota (a través de WebRTC o procesos Node.js generados). Eso les da a los atacantes acceso anónimo a redes corporativas y personales y una plataforma para propagarse más».

En conjunto, se dice que la actividad maliciosa ha envenenado más de 300 repositorios de GitHub utilizando credenciales de desarrollador robadas. Lo que hizo que la operación fuera notable fue el uso de cuatro canales C2 distintos para mejorar la resiliencia:

«La combinación de blockchain, peer-to-peer y servicios web legítimos como capas de resolución fue diseñada para ser resistente contra derribos: un frente dinámico que protege los servidores C2 reales detrás de múltiples capas de indirección», dijo CrowdStrike.

Ciberseguridad

Como resultado de la eliminación, los cuatro canales han sido neutralizados simultáneamente en un esfuerzo coordinado para que las máquinas infectadas ya no puedan recibir nuevas instrucciones o cargas útiles.

Al describir a los operadores de GlassWorm como «con buenos recursos y persistentes», la compañía de ciberseguridad atribuyó la actividad a probables ciberdelincuentes con sede en Rusia, dado que el malware finaliza la ejecución en sistemas ubicados en los países de la Comunidad de Estados Independientes (CEI) y contiene comentarios en ruso.

«La cadena de suministro de software sigue siendo una de las superficies de ataque más importantes en la informática moderna», concluyó CrowdStrike. «Los adversarios están convirtiendo la dependencia de una organización de herramientas, actualizaciones y bibliotecas en mecanismos de entrega armados y multiplicadores de fuerza».

«La barrera para envenenar un paquete o extensión es baja; el radio potencial de explosión es enorme. Mientras los entornos de desarrollo, los canales de construcción y los repositorios de código permanezcan desprotegidos, cada organización que consume software hereda el riesgo de todos los que lo producen. GlassWorm demuestra que los atacantes lo saben y están invirtiendo en infraestructura resistente para mantener un acceso persistente a los ecosistemas de desarrolladores».

El ataque TrapDoor a la cadena de suministro propaga malware de robo de credenciales a través de npm, PyPI y CratesIO – CYBERDEFENSA.MX

Una nueva campaña coordinada de ataque a la cadena de suministro de software entre ecosistemas se ha dirigido a npm, PyPI y Crates.io para distribuir malware de robo de credenciales.

La campaña, cuyo nombre en clave Trampaabarca más de 34 paquetes maliciosos en más de 384 versiones. La actividad más temprana se registró el 22 de mayo de 2026, a las 8:20 p.m. UTC, con nuevos paquetes publicados en los ecosistemas en oleadas desde un grupo de cuentas en rápida sucesión.

«TrapDoor se dirige a desarrolladores de comunidades de criptografía, DeFi, Solana e IA», dijo Socket. «Los paquetes maliciosos están diseñados para robar secretos de desarrolladores, billeteras criptográficas, claves SSH, credenciales de la nube, datos del navegador y variables de entorno».

«Varios paquetes npm también implementan una carga útil compartida, trap-core.js, que busca credenciales, valida tokens de AWS y GitHub, intenta el movimiento lateral basado en SSH y planta la persistencia a través de .cursorrules, CLAUDE.md, ganchos de Git, ganchos de shell, systemd, cron y SSH».

Vale la pena señalar que la actividad no tiene conexión con otra campaña del mismo nombre que el Equipo de Investigación e Inteligencia de Amenazas Satori de HUMAN detalló la semana pasada como involucrada en fraude publicitario al distribuir 455 aplicaciones de Android a través de Google Play Store.

Ciberseguridad

El lista de paquetes identificados está debajo –

  • Cajas.io

    • construcción del analizador de movimientos
    • mover-herramientas-compiladoras
    • constructor-de-proyectos-de-movimiento
    • ayudantes-sui-framework
    • sui-move-build-ayudante
    • sui-sdk-build-utils
  • npm

    • constructor de canalizaciones asíncronas
    • utilidades de scripts de compilación
    • validador-de-clave-de-cadena
    • escáner de credenciales criptográficas
    • auditor-defi-env
    • escáner-de-amenazas-defi
    • auditor-clave-de-despliegue
    • dev-env-bootstrapper
    • centinela-billetera-eth
    • compresor-de-contexto llm
    • control-de-seguridad-mnemotécnico
    • modelo-switch-router
    • ayudantes de configuración de nodos
    • herramientas-init-del-proyecto
    • kit de herramientas de ingeniería rápida
    • solidez-despliegue-guardia
    • rastreador de uso de tokens
    • verificador-de-respaldo-de-billetera
    • verificador-de-seguridad-de-billetera
    • detector-de-secretos-web3
    • cargador-de-configuración-del-espacio de trabajo
  • PyPI

    • seguridad-criptomoneda
    • verificación de canalización de datos
    • escáner-de-riesgo-defi
    • env-cargador-cli
    • auditor-de-seguridad-ética
    • git-config-sincronización
    • solidez-construcción-guardia

La operación se destaca por sus diversas rutas de entrega, que utilizan enlaces posteriores a la instalación, cargas útiles de JavaScript remotas que se ejecutan durante las importaciones de paquetes y scripts build.rs maliciosos dirigidos a los desarrolladores de Sui y Move. Los paquetes se hacen pasar por herramientas aparentemente inofensivas y brindan a los atacantes la capacidad de llegar a una audiencia más amplia.

Se ha descubierto que los paquetes npm ejecutan una carga útil de JavaScript («trap-core.js»), que busca credenciales y secretos de desarrollador, valida las credenciales robadas mediante llamadas API de AWS y GitHub y crea persistencia en el host mediante trabajos cron, servicios systemd, enlaces Git y se mueve a través de la red a través de SSH.

Las cajas Rust, de manera similar, buscan almacenes de claves locales, cifran los datos usando una clave XOR codificada y los exfiltran a GitHub Gists. Los paquetes también destacan por el uso de un construir script («build.rs») para desencadenar la ejecución del código malicioso.

Ciberseguridad

Los paquetes de Python asociados con TrapDoor están diseñados de manera que se ejecuten automáticamente al importarlos. El objetivo principal de los paquetes es descargar JavaScript desde un dominio de páginas GitHub controlado por un atacante («ddjidd564.github[.]io») y ejecútelo usando «node -e».

«Esta técnica permite que el paquete Python delegue la ejecución a una carga útil remota de JavaScript, dando al atacante más flexibilidad después de la publicación», explicó Socket. «Al alojar la carga útil externamente, el atacante puede actualizar el comportamiento sin publicar una nueva versión de PyPI».

Un aspecto inusual de la campaña es la implantación de .cursorrules y CLAUDE.md que contienen instrucciones ocultas para engañar a los asistentes de inteligencia artificial (IA) para que ejecuten un «escaneo de seguridad» que resulta en el descubrimiento y exfiltración de secretos. Esto se logra abriendo solicitudes de extracción (PR) de GitHub en proyectos populares de IA y desarrolladores, incluidos «browser-use/browser-use», «langchain-ai/langchain» y «langflow-ai/langflow».

La actividad de relaciones públicas indica que TrapDoor va más allá de enviar paquetes maliciosos a ecosistemas de código abierto. Socket dijo que el actor de amenazas probablemente esté probando si los archivos de proyectos relacionados con la IA se pueden introducir a través de flujos de trabajo regulares de contribución de código abierto, lo que provocará que las herramientas de codificación de IA analicen esas instrucciones ocultas y las apliquen.

Los hallazgos demuestran una vez más cómo los actores de amenazas se dirigen cada vez más a los flujos de trabajo de los desarrolladores, con el objetivo de robar una amplia gama de información que podría permitir profundizar en los entornos de destino para ataques posteriores.

«TrapDoor muestra cómo los atacantes están combinando la tradicional manipulación tipográfica de paquetes con rutas de ataque más nuevas en el entorno de desarrollador», dijo Socket. «Los nombres de los paquetes están diseñados para que parezcan relevantes para el desarrollo criptográfico, las herramientas de inteligencia artificial, la configuración del entorno local y los flujos de trabajo de seguridad. Luego, el malware utiliza rutas de ejecución específicas del ecosistema: build.rs en Rust, enlaces postinstalación en npm y ejecución en tiempo de importación en Python».

El ataque a la cadena de suministro de Packagist infecta 8 paquetes utilizando malware de Linux alojado en GitHub – CYBERDEFENSA.MX

Una nueva campaña de ataque «coordinada» a la cadena de suministro ha afectado a ocho paquetes en empaquetador incluido código malicioso diseñado para ejecutar un binario de Linux recuperado de una URL de versiones de GitHub.

«Aunque los paquetes afectados eran todos paquetes de Composer, el código malicioso no se agregó a compositor.json», Socket dicho. «En cambio, se insertó en package.json, dirigido a proyectos que incluyen herramientas de compilación de JavaScript junto con código PHP».

Esta «ubicación entre ecosistemas» hace que la actividad se destaque porque los desarrolladores y equipos de seguridad que escanean las dependencias de PHP solo pueden centrarse en los metadatos relacionados con Composer, mientras omiten los ganchos del ciclo de vida de package.json que están incluidos en el paquete. Desde entonces, las versiones maliciosas se han eliminado de Packagist.

Ciberseguridad

Un análisis de los paquetes ha descubierto que sus repositorios ascendentes han sido modificados para incluir un script posterior a la instalación que intenta descargar un binario de Linux desde una URL de versiones de GitHub («github[.]com/parikhpreyash4/systemd-network-helper-aa5c751f»), guárdelo en la carpeta «/tmp/.sshd», cambie sus permisos usando «chmod» para otorgar permisos de ejecución a todos los usuarios y ejecútelo en segundo plano.

Los nombres de los paquetes y la versión afectada asociada se enumeran a continuación:

  • moritz-sauer-13/silverstripe-cms-theme (dev-master)
  • crosiersource/crosierlib-base (dev-master)
  • devdojo/wave (dev-principal)
  • devdojo/génesis (dev-main)
  • katanaui/katana (dev-principal)
  • elitedevsquad/sidecar-laravel (3.x-dev)
  • r2luna/cerebro (dev-principal)
  • baskarcm/tzi-chat-ui (dev-principal)

La investigación de Socket encontró referencias a la misma carga útil en 777 archivos en GitHub, lo que sugiere que podría ser parte de una campaña más amplia. en al menos dos instanciasse agregó a un flujo de trabajo de GitHub. Sin embargo, actualmente no se sabe cuántos de estos coinciden con distintos compromisos, bifurcaciones, artefactos de paquetes duplicados o referencias almacenadas en caché.

«Esto sugiere que el atacante no confiaba en un único mecanismo de ejecución. En los artefactos del paquete, la carga útil se activaba a través de scripts postinstalación package.json», dijo la firma de seguridad de aplicaciones. «En los archivos de flujo de trabajo, estaba posicionado para ejecutarse durante los trabajos de GitHub Actions».

Ciberseguridad

Es más, la naturaleza exacta de la carga útil descargada de GitHub no está clara, ya que cuenta GitHub asociado con el alojamiento del repositorio ya no está disponible. La elección del nombre «gvfsd-network» para el malware es interesante, ya que se refiere a un demonio del sistema de archivos virtual GNOME (GVfs). responsable para administrar y explorar recursos compartidos de red.

«Incluso sin el binario de segunda etapa, el instalador malicioso es suficiente para justificar el bloqueo», dijo Socket. «Proporciona ejecución remota de código durante la instalación o creación de flujos de trabajo e intenta ocultar su actividad desactivando la verificación TLS, suprimiendo errores y ejecutando un binario descargado en segundo plano».

npm agrega controles de instalación de paquetes y publicación controlados por 2FA contra ataques a la cadena de suministro – CYBERDEFENSA.MX

GitHub ha implementado nuevos controles para npm para mejorar la seguridad de la cadena de suministro de software, brindando a los mantenedores la capacidad de aprobar explícitamente una versión antes de que los paquetes estén disponibles públicamente para su instalación.

La función, denominada publicación por etapas, ahora está disponible de forma generalizada en npm. Exige que un mantenedor humano pase un desafío de autenticación de dos factores (2FA) para aprobar un paquete antes de enviarlo a npmjs.[.]com.

«En lugar de una publicación directa que pone inmediatamente a disposición de los consumidores una versión del paquete, el tarball prediseñado se carga en una cola de espera donde un responsable de mantenimiento debe aprobarlo explícitamente antes de que sea instalable», GitHub dicho.

La subsidiaria propiedad de Microsoft dijo que el cambio garantiza una «prueba de presencia» para cada publicación, incluidas aquellas que provienen de flujos de trabajo CI/CD no interactivos y publicaciones confiables con autenticación OpenID Connect (OIDC).

Antes de usar publicación en escenalos mantenedores de paquetes deben cumplir los siguientes criterios:

  • Tener acceso de publicación al paquete.
  • El paquete ya existe en el registro npm, lo que significa que no se puede preparar un paquete nuevo
  • 2FA está habilitado para la cuenta

Los desarrolladores pueden utilizar el comando «npm stage Publish» desde el directorio raíz del paquete para enviarlo a un área de preparación. Para utilizar este comando, es esencial actualizar a npm CLI 11.15.0 o posterior. Para una protección óptima, GitHub recomienda que la publicación por etapas se combine con publicación confiable utilizando OIDC.

Ciberseguridad

Una segunda actualización centrada en npm se relaciona con la introducción de tres nuevos indicadores de fuente de instalación junto con el indicador existente -allow-git –

  • –allow-file: Controla las instalaciones desde rutas de archivos locales y archivos tar locales
  • –allow-remote: controla las instalaciones desde URL remotas, incluidos archivos tar https
  • –allow-directory: Controla las instalaciones desde directorios locales

Las banderas permiten a los desarrolladores «aplicar el mismo enfoque de lista permitida explícita a cada fuente de instalación que no sea del registro», dijo GitHub.

El desarrollo se produce en medio de un aumento masivo de ataques a la cadena de suministro de software dirigidos a ecosistemas de código abierto en los últimos meses, con un grupo cibercriminal conocido como TeamPCP involucrado en envenenar paquetes populares a una escala sin precedentes a través de un ciclo de compromisos que se perpetúa a sí mismo.

Los errores tipográficos ya no son un problema del usuario. Es un problema de la cadena de suministro – CYBERDEFENSA.MX

Los dominios similares generados por IA ahora están integrados dentro de scripts de terceros que se ejecutan en sus propiedades web. He aquí por qué su pila actual no puede verlos y qué requiere realmente la detección.

Descargue la Guía de expertos de CISO sobre Typosquatting en la era de la IA →

TL;DR

  • Typosquatting ya no es un problema de usuario. Los atacantes ahora incorporan dominios similares dentro de scripts legítimos de terceros. No se requiere una URL mal escrita ni una vulneración del servidor.
  • La IA rompió la economía de la defensa. Los LLM generan miles de variantes de dominio convincentes en minutos; el despliegue completo de la campaña lleva menos de diez años. Las cargas de paquetes maliciosos aumentaron 156% el año pasado. La investigación manual está muerta.
  • Tu pila de seguridad no puede ver esto. Los firewalls, WAF, EDR y CSP no tienen visibilidad de lo que hacen los scripts aprobados una vez que se ejecutan en el navegador.
  • El Ataque a Trust Wallet lo demostró. 8,5 millones de dólares robados en 48 horas a través de una extensión de Chrome troyanizada. No se disparó ninguna alerta, no porque algo fallara, sino porque no había nada mirando.

Esta no es una historia criptográfica

El 24 de diciembre de 2025, los usuarios de Trust Wallet comenzaron a perder dinero. No porque hayan hecho clic en un enlace de phishing. No porque reutilizaron una contraseña débil. No porque hayan hecho nada malo en absoluto.

Un gusano npm autorreplicante llamado Shai-Hulud había pasado meses recopilando credenciales de desarrollador: tokens de GitHub, claves de publicación de npm y credenciales de la API de Chrome Web Store. Esas claves permitieron a los atacantes enviar una versión troyanizada de la extensión Trust Wallet Chrome a través de canales oficiales. La verificación de Chrome pasó.

La extensión maliciosa se ejecutó completamente dentro de los navegadores de los usuarios, capturando silenciosamente frases iniciales y transmitiéndolas a la infraestructura del atacante en un dominio disfrazado de punto final de análisis del propio Trust Wallet. En 48 horas, se habían vaciado 2.500 carteras. Pérdida total: 8,5 millones de dólares. Ningún servidor fue vulnerado. Nunca se disparó ninguna alerta.

Elimine las frases iniciales y lo que queda es esto: un activo confiable entregado por el navegador se modificó silenciosamente para interceptar datos confidenciales del usuario antes de que la aplicación legítima pudiera procesarlos, invisible para los registros del servidor, firewalls, WAF y EDR. No porque esos controles estuvieran mal configurados, sino porque nunca fueron diseñados para observar lo que sucede dentro de una sesión del navegador, ni siquiera una sesión envenenada.

Cambie frases iniciales por datos de tarjetas de pago. Cambie la extensión de Chrome por un píxel de marketing, un widget de soporte o un marco de pruebas A/B. El ataque es idéntico. Una página de pago típica de comercio electrónico ejecuta entre 40 y 60 scripts de terceros. Cada uno es una conexión confiable. Allí podría pasar lo mismo.

Cómo llegó aquí la typosquatting: tres fases

Lo que hace que la Fase 3 sea una evolución genuina no es sólo la sofisticación, sino también la economía. Los LLM pueden generar miles de variaciones de dominio convincentes en minutos. Los ataques homógrafos combinan caracteres latinos, cirílicos y griegos para producir dominios que parecen visualmente idénticos en las barras de direcciones del navegador mientras evaden la detección de distancia de cadena. El registro de dominio, la emisión de SSL y la implementación completa de la campaña ahora demoran menos de diez minutos. Los datos de Sonatype muestran que las cargas de paquetes maliciosos a repositorios de código abierto aumentaron un 156% año tras año, por lo que el volumen por sí solo ha hecho que la investigación manual sea estructuralmente imposible.

Tres ataques que muestran el patrón

La typosquatting apunta a la capa de dominio, el compromiso de paquetes apunta a la cadena de suministro y el abuso del tiempo de ejecución del navegador apunta a lo que hace el código confiable después de ejecutarse.

1. Extensión Trust Wallet para Chrome (diciembre de 2025)

Shai-Hulud recopiló credenciales de desarrollador durante meses antes de lanzar una extensión troyanizada a través de los canales oficiales de Chrome Web Store. La extensión maliciosa capturó frases iniciales y las transmitió a un dominio de análisis similar. 2.500 carteras vaciadas. Se perdieron 8,5 millones de dólares. Tiempo de detección: cero. No existe visibilidad del lado del servidor para la ejecución en tiempo de ejecución del navegador.

2. ataque npm con tiza/depuración (septiembre de 2025)

Un correo electrónico de phishing dirigido a un único responsable del paquete dio a los atacantes acceso a 18 bibliotecas de JavaScript confiablesincluidos chalk y debug, con más de dos mil millones de descargas semanales combinadas. En 16 minutos, se inyectó código malicioso en todos ellos, conectando las API del navegador para interceptar silenciosamente el tráfico de red y las interacciones de billetera. La rápida contención limitó las pérdidas directas a alrededor de 500 dólares. La ventana de exposición no fue la historia. Fueron dos mil millones de descargas.

3. Ataque a la biblioteca Solana Web3.js (diciembre de 2024)

Los atacantes comprometieron una cuenta de acceso de publicación para la biblioteca npm @solana/web3.js a través de una campaña de phishing, luego publicaron versiones maliciosas que contenían una función oculta que interceptaba claves privadas a mitad de la transacción y las exfiltraba a un dominio controlado por el atacante registrado apenas unos días antes del ataque. Cualquier aplicación que se actualizara automáticamente dentro del período de cinco horas enviaba la puerta trasera directamente a sus usuarios. Casi 200.000 dólares se gastaron antes del descubrimiento.

Cómo ocurre el compromiso: la confianza reemplaza al engaño

La ingeniería social clásica necesitaba un ser humano al tanto, alguien que escribiera mal una URL, hiciera clic en un enlace, aprobara un mensaje y confiara en un remitente. El trabajo del atacante era generar confianza en el momento.

La generación actual de ataques se salta ese paso por completo. La confianza ya no se fabrica, se hereda. Su canal de compilación ya confía en npm. Su proveedor ya confía en su CDN. Su navegador ya confía en el proveedor. El atacante no necesita engañar a nadie; sólo necesitan insertarse en cualquier lugar de una cadena de confianza que ya les ha sido otorgada.

Llámelo subversión de la cadena de suministro: el engaño no está dirigido a una persona; está dirigido al gráfico de dependencia.

El punto ciego en su pila de seguridad

Un proveedor de marketing integrado en sus propiedades web hace referencia a una CDN de JavaScript registrada hace seis semanas. SSL válido. Dominio reconocible. Luego, el guión se actualiza silenciosamente.

En su página de pago, el navegador carga silenciosamente el script modificado. Una superposición invisible intercepta las pulsaciones de teclas antes de que lleguen a su aplicación. Los registros de su servidor registran una sesión normal. No hay incendios de alerta.

CSP es el control más citado como defensa. Pero CSP es una lista de invitados, no un monitor de comportamiento. Un script incluido en la lista de permitidos que lee los campos de su formulario de pago y filtra los datos todavía está totalmente permitido, porque el origen es confiable. CSP maneja la conexión. No puede manejar la ejecución.

El comportamiento malicioso en 2026 se difiere al tiempo de ejecución por diseño. Los paquetes de Shai-Hulud permanecieron inactivos durante el escaneo automatizado y solo se activaron bajo condiciones de tiempo de ejecución específicas. El análisis estático no puede detectar cargas útiles cargadas dinámicamente después de que comienza la ejecución.

Lo que realmente requiere la detección

El informe sobre el costo de una vulneración de datos de 2025 de IBM encontró que la vulneración promedio tarda 241 días para identificar. En los ataques a la cadena de suministro en los que el comportamiento malicioso se ejecuta silenciosamente en la memoria del navegador, esa ventana puede ser significativamente más larga, a menos que esté observando el tiempo de ejecución.

La detección requiere observar qué hacen realmente los scripts después de ejecutarse: con qué dominios se comunican, a qué elementos de la página acceden y cómo su comportamiento se desvía de las líneas base establecidas. Se trata de monitoreo del comportamiento en tiempo de ejecución, la única capa de la que carecen actualmente la mayoría de las pilas de seguridad empresarial.

Las características a monitorear para:

  • Exfiltración de datos inesperada: Scripts que leen campos de formulario y transmiten valores a dominios fuera de su lista aprobada
  • Resolución de dominio dinámico: Scripts que llaman a dominios registrados recientemente o que se resuelven de manera diferente a su línea base
  • Deriva conductual: Un script que se comportó normalmente la semana pasada ahora accede a diferentes elementos de la página esta semana.

Detectar un dominio sospechoso en su árbol de dependencia es necesario, pero no suficiente. El problema más difícil es comprender qué hace realmente el script cargado desde ese dominio. La ofuscación generada por IA ahora está diseñada específicamente para derrotar el análisis estático: el código pasa el linting, imita bibliotecas minificadas legítimas y no produce coincidencias de firmas.

Cerrar esa brecha requiere desofuscar el comportamiento en tiempo de ejecución, ejecutar el script en un entorno instrumentado y rastrear su comportamiento real, sin intentar leer su fuente. Eso significa sacar a la luz a qué accede realmente un script: campos de formulario, cookies, puntos finales de la red, independientemente de cuán confusa esté la fuente. Es el enfoque que Reflectiz construyó Desofuscador de IA alrededor, y se detalla en la guía a continuación.

Tu plan de acción

Si no está seguro de por dónde empezar, priorice por exposición: las páginas de pago primero, las páginas de autenticación en segundo lugar y todo lo demás después. He aquí una secuencia práctica:

Esta semana:

  • Audite scripts de terceros para dominios CDN registrados recientemente en su cadena de dependencia
  • Revise los informes de CSP, no solo las infracciones, sino también lo que realmente están haciendo sus orígenes aprobados.
  • Identifique qué páginas manejan datos confidenciales (pago, inicio de sesión, formularios PII) y priorice el monitoreo allí primero.

Este mes:

  • Implementar monitoreo del comportamiento en tiempo de ejecución para páginas de pago y autenticación
  • Establecer líneas de base de comportamiento para todos los scripts de terceros aprobados.
  • Implementar comprobaciones de integridad de subrecursos (SRI) cuando los scripts se autohospedan o se pueden almacenar en caché

Son necesarios un registro de dominio proactivo, un CSP estricto y DMARC aplicado. Cubren el registro de dominio, la entrega de scripts y la suplantación de correo electrónico. Ninguno de ellos cubre lo que sucede después de que un script de proveedor aprobado se modifica silenciosamente. Esa es la brecha que la mayoría de los equipos no ven hasta que es demasiado tarde.

Los controles anteriores le indican qué hacer. Asignarlos a su entorno real, inventario de proveedores y obligaciones de cumplimiento es donde la ejecución se detiene. Reflectiz ha publicado un Guía de expertos CISO con el marco completo: gobernanza de dominio, controles fundamentales, monitoreo del comportamiento en tiempo de ejecución y una hoja de ruta de implementación por fases construida en torno a esa brecha.

Descarga la guía aquí →

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

Las estaciones de trabajo para desarrolladores ahora son parte de la cadena de suministro de software – CYBERDEFENSA.MX

Los atacantes de la cadena de suministro no sólo intentan introducir código malicioso en software confiable. Están intentando robar el acceso que hace posible el software confiable. Recientemente, tres campañas separadas llegaron a npm, PyPI y Docker Hub en un período de 48 horas, y las tres apuntaron a secretos de entornos de desarrollador y canalizaciones de CI/CD, incluidas claves API, credenciales de nube, claves SSH y tokens. Esta es una preocupación constante y se propaga a sí misma, como se ve en ataques como las campañas del «mini Shai Hulud».

Ese patrón debería cambiar la forma en que los equipos de seguridad piensan sobre la cadena de suministro de software.

Tradicionalmente, la seguridad se centraba en sistemas compartidos como repositorios de código fuente, plataformas CI/CD, registros de artefactos, administradores de paquetes y entornos de nube. El objetivo era proteger las cargas de trabajo y los datos de producción. Es absolutamente necesario que nos centremos en estos ámbitos, pero el panorama es incompleto.

La entrega de software moderno comienza antes de que el código llegue a Git. Comienza en la estación de trabajo del desarrollador, donde se escribe el código, se instalan las dependencias, se prueban las credenciales, se solicita a los asistentes de IA, se crean contenedores y comienzan las acciones confiables.

Las estaciones de trabajo de los desarrolladores son una parte real de la cadena de suministro de software. Tratarlos como «simples» puntos finales comunes deja brechas entre la seguridad de los puntos finales, la seguridad de la identidad, la seguridad de las aplicaciones y la gobernanza de la cadena de suministro.

Los ataques a la cadena de suministro se han convertido en operaciones de recolección de credenciales

Los incidentes recientes siguen apuntando a la misma verdad operativa. Los atacantes pueden utilizar paquetes envenenados, imágenes comprometidas, bots de dependencia, flujos de trabajo maliciosos o herramientas de desarrollo vulnerables, pero el objetivo recurrente es el acceso.

Eventos como las campañas TeamPCP y Shai-Hulud muestran cómo los ataques a la cadena de suministro convergen cada vez más en torno al robo de credenciales. En la campaña TeamPCP, los atacantes utilizaron paquetes comprometidos y herramientas de desarrollo para recolectar tokens, credenciales de nube, claves SSH, archivos de configuración npm y variables de entorno.

Shai-Hulud impulsó el mismo patrón aún más, convirtiendo los entornos de desarrolladores infectados en puntos de recopilación de credenciales que expusieron miles de secretos en GitHub, servicios en la nube, registros de paquetes y sistemas internos.

Esto no es sólo una manipulación del software. Se trata de una recopilación de credenciales en puntos en los que los desarrolladores y la automatización ya tienen confianza.

La cadena de suministro queda expuesta cuando los atacantes obtienen acceso a credenciales y contexto que les permiten alterar, publicar, construir, implementar o hacerse pasar por sistemas de software confiables. Los paquetes modificados y publicados en un ataque moderno a la cadena de suministro permanecen activos durante horas, mientras que las herramientas de automatización combinan actualizaciones maliciosas en minutos.

El hilo conductor de muchos de los ataques recientes han sido los secretos, ya sea como vector de acceso inicial o como objetivo de recopilación.

La ruta del atacante ahora pasa por el contexto del lado del desarrollador

La estación de trabajo del desarrollador es valiosa porque concentra el contexto. A menudo contiene repositorios locales, archivos .env, historial de shell, claves SSH, credenciales y configuraciones del administrador de paquetes, scripts de compilación, registros de depuración y sesiones del navegador. Esas piezas se vuelven mucho más peligrosas cuando se ven juntas.

Un token de acceso único puede parecer limitado de forma aislada. Un token que se encuentra junto a un control remoto de Git, un script de implementación, un archivo README, un perfil de nube y una configuración de CI le indica al atacante dónde encaja el token y qué podría desbloquear. En la campaña Shai-Hulud 2.0, por ejemplo, las credenciales de GitHub dominaron las credenciales expuestas y exfiltradas, cada una con potencial acceso de administrador a repositorios y flujos de trabajo de CI.

El compromiso local no es sólo un problema de dispositivo. Puede servir como mapa para el control de fuentes, cuentas en la nube, flujos de trabajo de publicación de paquetes, sistemas CI/CD, API internas e infraestructura adyacente a la producción.

Autoridad de entrega de software de Developer Machines Concentrate

Una computadora portátil estándar para empleados puede exponer datos corporativos. Una estación de trabajo de desarrollador puede exponer la capacidad de cambiar el software. Esa distinción es fundamental al considerar la seguridad de los terminales.

Los desarrolladores suelen necesitar un acceso amplio para realizar su trabajo. Clonan repositorios privados, se autentican en servicios en la nube, publican paquetes, acceden a entornos de prueba e interactúan con múltiples herramientas internas. Sus máquinas se convierten en una intersección funcional de código fuente, credenciales, automatización y autoridad de entrega.

Si bien no todos los desarrolladores tienen acceso a la producción, muchos sí tienen acceso suficiente para influir en los sistemas que eventualmente producirán resultados de producción. Un token de registro puede afectar a los paquetes. Un token de GitHub puede afectar repositorios o flujos de trabajo. Un perfil de nube puede exponer la infraestructura. Una credencial CI/CD puede afectar el comportamiento de la compilación.

A la junta y a los auditores no les importa si un desarrollador almacenó un secreto localmente. En realidad, el riesgo empresarial es que una exposición local proporcione a los atacantes un camino hacia los sistemas que crean, modifican, publican u operan software.

Ese cambio cambia las preguntas que los equipos de seguridad deberían plantearse:

  • ¿Puede identificar qué credenciales se pueden utilizar desde las estaciones de trabajo de los desarrolladores?
  • ¿Puede limitar el valor y la vida útil de esas credenciales?
  • ¿Puede detectar material confidencial antes de que ingrese al historial de Git, registros de CI, tickets, artefactos o chat?
  • ¿Puede revocar y rotar el acceso rápidamente cuando sospecha que la estación de trabajo está comprometida?
  • ¿Puedes notar la diferencia entre exposición local de bajo impacto y credenciales con privilegios similares a los de administrador?

Esas preguntas se sitúan entre AppSec, endpoints, identidad, plataforma y seguridad en la nube. Independientemente de cómo decida coordinar su organización, debe comprender cómo se conecta el comportamiento de los desarrolladores con los sistemas de entrega.

La automatización y la inteligencia artificial hacen que la superficie de exposición sea más delgada y rápida

La automatización ha comprimido el tiempo entre el compromiso y el impacto. Los robots de actualización de dependencias pueden abrir y fusionar cambios rápidamente. Los sistemas CI/CD pueden ejecutar flujos de trabajo confiables automáticamente. Los administradores de paquetes pueden ejecutar scripts de instalación. Los agentes de IA y los asistentes de codificación pueden leer archivos, llamar a herramientas, generar comandos, inspeccionar resultados y mover el contexto entre sistemas.

La automatización no es intrínsecamente insegura, pero normalmente cualquier automatización hereda la confianza, especialmente si se presenta en forma de agencia. Si una actualización de dependencia maliciosa parece rutinaria, un flujo de trabajo automatizado puede hacerla avanzar más rápido de lo que un revisor humano puede entender lo que sucedió.

IA en el circuito

El desarrollo asistido por IA añade otro conjunto de puntos de transferencia. Los datos confidenciales pueden aparecer en mensajes, salidas de terminales, llamadas a herramientas, código generado, memoria del agente, registros y configuración local copiados en una sesión de depuración. La cuestión es más amplia que si un proveedor de modelos almacena indicaciones. El problema más importante es que el contexto de desarrollo local ahora fluye a través de sistemas más semiautomatizados.

Los equipos de seguridad deben evaluar el riesgo de la codificación de IA a través de la misma lente que utilizan para el riesgo de la cadena de suministro. Los equipos deben responder: ¿qué fuentes y datos puede leer la herramienta? ¿Qué puede ejecutar? ¿A dónde va la producción? ¿Qué credenciales hay cerca? Y, quizás lo más importante, ¿qué confianza hereda el flujo de trabajo?

Los controles posteriores siguen siendo importantes, pero ya es demasiado tarde por sí solos

El escaneo de repositorios, la protección de sucursales, la política de CI/CD, la firma de artefactos, el análisis de dependencias y los controles de tiempo de ejecución siguen siendo esenciales. Crean puntos de cumplimiento compartidos y ayudan a los equipos a controlar el software a escala.

El problema ahora es el momento oportuno, gracias a la velocidad de los ataques modernos. Los atacantes ahora aprovechan las herramientas impulsadas por IA para explotar todos y cada uno de los secretos a los pocos segundos de ser descubiertos.

Las barandillas reducen la exposición potencial y el radio de explosión. La captura de material confidencial mientras un desarrollador edita un archivo, prepara una confirmación, ejecuta un comando local, instala una dependencia o interactúa con un asistente de inteligencia artificial mantiene el impacto al mínimo.

Los programas maduros distinguen entre acciones que deberían bloquearse, acciones que deberían dar advertencias y acciones que simplemente deberían generar telemetría para una investigación más profunda. El objetivo no es sepultar a los desarrolladores en fricciones.

Trate la estación de trabajo como un límite de la cadena de suministro local

La cadena de suministro de software moderna no comienza cuando se envía código. Comienza donde el código, las credenciales, la automatización y la confianza se unen por primera vez.

Es hora de tratar la estación de trabajo del desarrollador como un límite de la cadena de suministro local. Ese límite incluye el IDE, la terminal, el cliente Git, el administrador de paquetes, las herramientas de contenedor, la CLI en la nube, el sistema de compilación local, las prácticas de manejo de secretos, los asistentes de IA y los agentes de automatización. Es el lugar donde la acción de los desarrolladores individuales se convierte en un riesgo de entrega de software organizacional.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.