SleeperGem utiliza tres paquetes maliciosos de RubyGems para atacar las máquinas de los desarrolladores – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han señalado un nuevo ataque a la cadena de suministro de software con nombre en código SleeperGem dirigido al ecosistema Ruby después de que se publicaran tres gemas maliciosas en RubyGems con el objetivo final de servir cargas útiles adicionales.

Las gemas rebeldes se enumeran a continuación:

«Cada lanzamiento malicioso es un cargador», StepSecurity dicho en un análisis. «Obtiene una segunda etapa de un host Forgejo controlado por un atacante, verifica si se está ejecutando en un sistema de compilación y lo omite si lo está, y en una máquina de desarrollo coloca un demonio nativo e instala la persistencia».

Ciberseguridad

Un aspecto del ataque que se destaca de inmediato es que «git_credential_manager» se hace pasar por el administrador oficial de credenciales Git de Microsoft, mientras que los otros dos habían estado inactivos durante años antes de recibir las actualizaciones maliciosas. «Dendreo» se actualizó por última vez el 24 de octubre de 2020 y «fastlane-plugin-run_tests_firebase_testlab» permaneció inactivo desde el 9 de marzo de 2019, antes de las nuevas versiones.

Otro rasgo definitorio de la actividad es que los lanzamientos se publicaron directamente en el registro sin ningún compromiso o etiqueta coincidente en los proyectos fuente.

Curiosamente, «git_credential_manager» ha sido agregado como una dependencia de cinco paquetes, incluidos «Dendreo» y «fastlane-plugin-run_tests_firebase_testlab», lo que permite efectivamente que la carga maliciosa se propague a los usuarios existentes de los paquetes.

  • dendreo
  • fastlane-plugin-run_tests_firebase_testlab
  • holguraHtmlToMarkdown
  • seo_optimizador
  • métodos_rápidos_array

Todos los paquetes antes mencionados, a excepción de «fastlane-plugin-run_tests_firebase_testlab», se mantienen en la misma cuenta («LR-DEV«). El hecho de que la gema pertenece a un mantenedor diferente («habitación rosa«) indica que es probable que más de una cuenta haya sido comprometida para enviar las versiones no autorizadas a RubyGems.

Una vez instalado, el malware integrado en estos paquetes escanea el sistema infectado en busca de aproximadamente 30 variables de entorno, incluidas las relacionadas con GitHub Actions, GitLab, CircleCI, Travis, Jenkins y Vercel. Si se identifica alguno de ellos, se cierra de inmediato. Se considera que la verificación es un intento intencional de evitar la ejecución en corredores de CI efímeros y garantizar que se ejecute en una máquina de desarrollador.

En el caso de «git_credential_manager», el código malicioso se activa cuando se requiere la biblioteca, lo que provoca que descargue dos cargas útiles desde una instancia pública de Forgejo («git.disroot[.]org/git-ecosystem»): un script de shell («deploy.sh») y un binario nativo que lleva el mismo nombre que la herramienta que disfraza la gema. En Windows, la carga útil recuperada se ejecuta a través de PowerShell.

Mientras que la versión 2.8.2 simplemente prepara las cargas útiles, la versión 2.8.3 de la gema pasa a la siguiente fase del ataque. Esto implica usar el script de instalación para iniciar el binario como un demonio en segundo plano, después de lo cual establece la persistencia usando una entrada cron y como un servicio de usuario systemd y consulta los grupos sudo y wheel.

«Si el usuario puede ejecutar sudo sin contraseña, el script se vuelve a ejecutar como root, y cuando se ejecuta como root coloca una copia raíz setuid del shell del sistema en una ruta elegida para imitar una utilidad de red», dijo StepSecurity.

Se recomienda a los usuarios que hayan instalado cualquiera de las gemas antes mencionadas que traten las máquinas y los secretos asociados como si estuvieran comprometidos. También se recomienda eliminar el demonio eliminado en «~/.local/share/gcm/», borrar los métodos de persistencia, buscar un shell setuid en «/usr/local/sbin/ping6» y rotar todas las credenciales.

«Una cuenta de RubyGems que ha permanecido inactiva durante seis o siete años no parece riesgosa para nadie», Charlie Eriksen, investigador de Aikido Security dicho. «Ese es exactamente el perfil que vale la pena tomar. De ahí proviene el nombre SleeperGem: no es un activo de atacante plantado y de largo plazo, sino una cuenta real y ordinaria que simplemente había quedado inactiva y parecía lo suficientemente inofensiva como para secuestrarla sin que nadie se diera cuenta».

RubyGems como punto muerto de filtración de datos

La divulgación se produce más de dos meses después de que RubyGems detuviera brevemente los registros de cuentas después de que los delincuentes impulsaran docenas de paquetes maliciosos como parte de una campaña coordinada de publicación de spam. Casi al mismo tiempo, los investigadores de Socket señalaron una campaña paralela que inundó el registro con 150 gemas y abusó de ellas como canal de filtración de datos.

Ciberseguridad

A principios de este mes, Mend.io reveló detalles de un ataque a la cadena de suministro de software no documentado que empleó otro conjunto de 14 paquetes RubyGems para almacenar datos de credenciales robadas.

Específicamente, se descubrió que una extensión de navegador maliciosa recopiló credenciales a través de una API accesible localmente, empaquetó la información en archivos .gem válidos completamente dentro del navegador usando JavaScript y API web estándar, y cargó esos paquetes directamente en RubyGems.org usando una clave API de RubyGems codificada.

«El botín incluyó contraseñas de texto plano, claves privadas SSH, credenciales de AWS, frases iniciales de billeteras criptográficas, números de Seguro Social, números de tarjetas de crédito y detalles de cuentas bancarias en 63 elementos de la bóveda», Maciej Mensfeld dicho.

«RubyGems no era el mecanismo de entrega aquí. Era el punto muerto: un dominio confiable y de alto tráfico donde los datos robados permanecían hasta que el atacante regresaba a buscarlos, invisible entre las cargas normales de los desarrolladores».

Los paquetes npm vinculados a Corea del Norte imitan los Polyfills acumulativos para robar secretos de los desarrolladores – CYBERDEFENSA.MX

Los actores de amenazas con vínculos con Corea del Norte han sido vinculados a un nuevo conjunto de paquetes npm maliciosos que se hacen pasar por herramientas Rollup polyfill para facilitar el acceso remoto y el robo de datos.

Según JFrog, los paquetes «rollup-packages-polyfill-core» y «rollup-runtime-polyfill-core» imitan el legítimo «nodo-polyfill-del-complemento acumulativo«proyecto, hasta la descripción, los metadatos del repositorio y la forma del paquete.

«Los paquetes similares se ubican en el mismo espacio de nombres de rollup, polyfill, núcleo y nodo, lo que puede parecer plausible durante una revisión rápida de dependencia», JFrog dicho en un informe técnico de la campaña.

La campaña también involucra otros cuatro paquetes, todos los cuales han sido eliminados del registro npm:

  • ficha peculiar
  • reaccionar-icono-svgs
  • complemento-rollup-polyfill-connect
  • flujo de análisis rápido

Lo que es digno de mención aquí es que «rollup-packages-polyfill-core» instala y carga «swift-parse-stream», mientras que «rollup-runtime-polyfill-core» instala y «quirky-token». De manera similar, se ha descubierto que «react-icon-svgs» instala «rollup-plugin-polyfill-connect» como segunda etapa.

Ciberseguridad

«Los paquetes de la segunda etapa son utilidades SVG casi idénticas que obtienen un objeto JSON de JSONKeeper y evalúan el campo del modelo», dijo la compañía de ciberseguridad. «Esta estructura en capas, junto con los nombres parecidos, los metadatos de apariencia legítima, la ejecución oculta en el momento de la instalación, las comprobaciones del entorno y las cargas útiles de robo de credenciales/acceso remoto, es similar a campañas anteriores de npm vinculadas a Lazarus de Corea del Norte».

Vale la pena enfatizar aquí que esta no es la primera vez que los actores de amenazas norcoreanos cargan paquetes npm que se hacen pasar por herramientas Rollup Polyfill. En abril de 2026, Panther detalló una campaña sostenida de npm que implicó la publicación de 108 paquetes npm maliciosos que abarcan 261 versiones para entregar BeaverTail y OtterCookie, dos conocidas familias de malware vinculadas a Contagious Interview. Entre esos paquetes se encontraba «rollup-plugin-polyfill-route», que se publicó el 20 de marzo de 2026.

El punto de partida del ataque es un comando de instalación npm codificado en Base64 para «swift-parse-stream» (o «quirky-token») que está oculto dentro de «rollup-packages-polyfill-core» (o «rollup-runtime-polyfill-core»). Los dos paquetes de la segunda etapa están disfrazados de utilidades de desinfección de SVG, mientras acceden a una URL de JSON Keeper para recuperar y ejecutar un malware de JavaScript.

El código JavaScript ejecuta comprobaciones para evitar la ejecución en entornos de desarrollo en la nube, entornos sandbox, tiempos de ejecución sin servidor e infraestructura de análisis. Pasada esta puerta, el malware instala las dependencias necesarias y llega a un servidor externo («216.126.236[.]244») para recuperar una carga útil de JavaScript cifrada.

Luego, la carga útil descifrada actúa como un cargador de secuencias de comandos adicionales responsables de permitir el acceso remoto al host comprometido para admitir sesiones de terminal interactivas, ejecución de comandos, captura de pantalla, terminación de procesos, movimiento del mouse solo para Windows, clics, desplazamiento, pulsaciones de teclado y teclas de acceso rápido usando el paquete «@nut-tree-fork/nut-js», así como robar datos de navegadores web y billeteras de criptomonedas, recopilar archivos que coincidan con extensiones específicas y capturar periódicamente el contenido del portapapeles.

Las características se superponen con las de OtterCookie, y el uso de «@nut-tree-fork/nut-js» para el control remoto del mouse y el teclado también se observa en un paquete llamado «express-session-js» que fue detallado por SafeDep en abril de 2026. Se ha descubierto que el componente recopilador de archivos busca específicamente el historial del editor asociado con Microsoft Visual Studio Code, Windsurf y Cursor, junto con configuraciones de herramientas de inteligencia artificial y desarrolladores, como AWS, Microsoft Azure, Google Gemini, Anthropic Claude, Foundry, SSH y Z shell (Zsh).

«Los complementos acumulativos se cargan comúnmente desde archivos de configuración locales, estaciones de trabajo de desarrolladores y trabajos de CI», dijo JFrog. «Estos entornos a menudo tienen acceso a activos confidenciales como código fuente, tokens npm, credenciales de Git, claves de nube, claves SSH, datos del navegador y secretos de proyectos».

«La carga útil también es más amplia que un simple descargador. Una vez que se ejecutan las etapas posteriores, el atacante obtiene capacidades de recopilación y control. Esto hace que la carga útil sea relevante para las estaciones de trabajo de los desarrolladores y las máquinas de construcción, donde las claves API, las claves SSH, el material de la billetera, las credenciales de la nube y los secretos del proyecto a menudo están presentes».

Ciberseguridad

La divulgación coincide con el descubrimiento de múltiples ataques a la cadena de suministro de software por parte de Checkmarx, SafeDep y el investigador de seguridad de AWS, Chi Tran, destinados a envenenar repositorios de paquetes de código abierto y robar datos valiosos.

  • Un grupo de al menos ocho horquillas «pirograma» troyanizadas publicado por un actor de amenazas que opera bajo múltiples identidades entre noviembre de 2025 y junio de 2026, incluida una puerta trasera oculta que les otorga control remoto total sobre cualquier servidor que ejecute el paquete PyPI infectado mediante la ejecución de código Python arbitrario o comandos de shell enviados por el atacante. Los resultados de la ejecución del comando se filtran a través de Telegram. Checkmarx ha denominado a la actividad Operación Fantasma de la Marina.
  • un grupo de paquetes de 30 npm imitando las herramientas de Polymarket y las bibliotecas de matemáticas generales publicadas por cuentas de mantenimiento de 10 npm que apuntaban a los desarrolladores de DeFi para entregar un ladrón de información de JavaScript que lee bóvedas de billeteras criptográficas, credenciales del navegador, claves SSH, credenciales de AWS, tokens npm, configuraciones de Docker, historial de shell y bases de datos del administrador de contraseñas.
  • un grupo de paquetes de 25 npm publicado bajo el alcance @marketfront por una cuenta npm llamada «marketfront» que contiene un recolector de credenciales posterior a la instalación que lee 20 archivos secretos y de credenciales, incluidos ~/.ssh, ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json, ~/.npmrc, ~/.netrc, ~/.pgpass, ~/.git-credentials, ~/.env y shell historial y extrae los datos.
  • Un paquete de Python llamado «alertas-de-seguridad-sdk» que afirma ser una herramienta de monitoreo de violaciones de datos pero alberga un código para iniciar una puerta trasera que sondea periódicamente un servidor externo («142.93.211[.]30:5000») para comandos y filtra claves privadas SSH, credenciales de AWS, tokens Docker/npm/PyPI/git, archivos .env y bases de datos de credenciales del navegador al mismo servidor.
  • un grupo de paquetes de 15 npm publicado por un único actor de amenazas que opera bajo alcances de 13 npm que activa una carga útil de JavaScript posterior a la instalación responsable de descargar y ejecutar un binario ELF compilado por Rust alojado en GitHub, que luego recopila una amplia gama de datos de billeteras de criptomonedas, navegadores web y otras aplicaciones, incluidos tokens de proveedores de nube, claves SSH, sesiones de plataformas de mensajería, configuraciones de clientes de bases de datos y credenciales de desarrollador.
  • Un paquete npm llamado «tiempo de ejecución de eventos» que escribe en cuclillas «eventos» y genera condicionalmente un ladrón de billeteras de criptomonedas, filtra datos de reconocimiento del host a través de Slack y Telegram, abre un canal de comando bidireccional de Slack y lee fragmentos de configuración y carga útil de un contrato inteligente de Ethereum utilizado como solucionador de entrega muerta. La lógica maliciosa se activa solo cuando el ID del evento es «eventId0».
  • Un paquete npm llamado «o3formas» que roba las credenciales del proveedor de servicios en la nube, escanea los secretos de los desarrolladores y los entornos CI/CD, realiza un reconocimiento de la red interna y exfiltra los datos a un punto final de Cloudflare Workers controlado por el atacante. «El atacante dividió el ataque en un paquete publicado en el registro deliberadamente benigno y una subdependencia *-utils fijada en GitHub que lleva tanto los ganchos de instalación como el malware real», dijo Tran. «Esta estructura está diseñada específicamente para derrotar el script estático y del ciclo de vida escaneo en el que se basan la mayoría de las herramientas del lado del registro y del lado CI».

Se recomienda a los usuarios que hayan instalado cualquiera de los paquetes antes mencionados que los eliminen de sus estaciones de trabajo, asuman compromisos y roten las credenciales, bloqueen los canales de salida maliciosos y habiliten el escaneo de dependencias en las canalizaciones de CI/CD para marcar paquetes sospechosos o recién publicados.

Google fija el 30 de septiembre como fecha límite para la verificación de desarrolladores de Android en cuatro países – CYBERDEFENSA.MX

Google ha fijado el 30 de septiembre de 2026 como el día en que comenzará a aplicar Verificación de desarrollador de Android en los primeros cuatro países, y las tiendas de aplicaciones de los principales fabricantes de dispositivos están presentes desde el principio.

En esa fecha, los teléfonos Android certificados en Brasil, Indonesia, Singapur y Tailandia bloquearán las instalaciones normales de aplicaciones cuyos desarrolladores no hayan registrado una identidad con Google, ya sea que la aplicación provenga de Google Play o de las tiendas administradas por Samsung, Xiaomi, OPPO, vivo, Honor y Transsion.

Los dispositivos certificados son los que se envían con los servicios de Google y Play Protect, que, según el recuento de F-Droid, representa más del 95 por ciento de los dispositivos Android fuera de China.

La mayoría de los usuarios no se darán cuenta, que es el punto. Las aplicaciones de desarrolladores verificados siguen instalándose como antes. La fricción recae en aplicaciones de desarrolladores que Google no ha verificado, y es más difícil en los canales independientes y de código abierto, basados ​​en que no necesitan el permiso de Google para enviar.

Ciberseguridad

Los desarrolladores que distribuyen a través de esas tiendas deben verificar y registrarse antes de la fecha límite. Google dice que las aplicaciones que no lo hagan no estarán disponibles para una nueva instalación en dispositivos certificados en los cuatro países.

Lo que cambia el 30 de septiembre

La verificación se ejecuta en el dispositivo. Google está impulsando una nueva servicio del sistemael Verificador de desarrolladores de Android, para teléfonos con Android 8 y versiones posteriores a partir de junio de 2026, y confirma que una aplicación está registrada para un desarrollador verificado antes de que se instale.

Después del 30 de septiembre, en los cuatro mercados de lanzamiento, una aplicación no registrada no se instalará mediante la ruta normal. Todavía se puede instalar a través de Android Debug Bridge (ADB) o mediante el flujo avanzado, la ruta deliberadamente de alta fricción que Google construyó a principios de este año. Esa ruta hace que el usuario active el modo de desarrollador, reinicie, espere 24 horas y se vuelva a autenticar antes de descargar una aplicación no verificada, y se globaliza en agosto.

El registro se abrió para todos los desarrolladores en marzo y Google dice que ya cubre casi todas las instalaciones en Google Play y una gran mayoría de las que se realizan fuera de él.

Para registrarse, un desarrollador proporciona a Google un nombre legal, una dirección y datos de contacto, es posible que deba cargar una identificación gubernamental y demuestra la propiedad de cada aplicación enviando un APK firmado con su clave privada.

Google también está agregando API para registro masivo y verificación de nombres de paquetes, con delegación de OAuth para que una tienda de terceros pueda ejecutar partes del proceso para los desarrolladores. Las dos interfaces, una API de estado de ID de desarrollador de Android y una API de consola de desarrollador de Android, llegarán en julio.

Un carril separado para cuentas gratuitas de distribución limitada ingresa al acceso anticipado en julio y se lanza a nivel mundial en agosto; permite a estudiantes y aficionados compartir aplicaciones con hasta 20 dispositivos, sin identificación gubernamental ni tarifa. La cuenta de desarrollador completa estándar conlleva una tarifa única de $25.

Por qué el campo del código abierto está luchando contra ello

El caso de Google es el malware. Dice que las fuentes descargadas contienen mucha más cantidad que Google Play, y que las estafas funcionan cada vez más convenciendo a la víctima para que instale un APK malicioso en el acto.

Un control de identidad y una espera de 24 horas están destinados a romper con eso. Google dice que eligió los cuatro países de lanzamiento porque se ven muy afectados por estafas de aplicaciones, a menudo por parte de infractores reincidentes.

Ciberseguridad

El rechazo ha sido fuerte desde que se anunció el programa en agosto de 2025. F-Droid, el repositorio de aplicaciones de software libre, dice que el requisito pondría fin a su proyectoporque crea y firma aplicaciones de muchos colaboradores seudónimos que no le darán a Google una identidad legal.

A Mantener Android abierto Una campaña respaldada por más de 70 organizaciones en 23 países ha pedido a Google que elimine las comprobaciones de identificación de las aplicaciones enviadas fuera de Play. Las concesiones de Google, el flujo avanzado y las cuentas de 20 dispositivos responden a la queja de que se estaba eliminando la descarga lateral. No tocan el problema más profundo: una sola empresa se sentaría en el camino de instalación de casi todos los dispositivos Android fuera de China y decidiría quién obtiene el camino fluido.

Quedan abiertas tres preguntas antes del lanzamiento global en 2027: si Google detalla un proceso de apelación para los desarrolladores que marca por error, qué mantiene en el registro de identidad y durante cuánto tiempo, y si ofrece alguna ruta para repositorios como F-Droid que no pueden cumplir con el control de propiedad por aplicación sin cambiar su funcionamiento.

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».

Consola Nx comprometida 18.95.0 dirigida a desarrolladores de código VS con ladrón de credenciales – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han detectado una versión comprometida de la extensión de la consola Nx que se publicó en el mercado de Microsoft Visual Studio Code (VS Code).

La extensión en cuestión es rwl.angular-consola (versión 18.95.0), una interfaz de usuario y complemento popular para editores de código como VS Code, Cursor y JetBrains. La extensión VS Code tiene más de 2,2 millones de instalaciones. La versión Open VSX no se ha visto afectada por el incidente.

«A los pocos segundos de que un desarrollador abriera cualquier espacio de trabajo, la extensión comprometida buscó y ejecutó silenciosamente una carga útil ofuscada de 498 KB de una confirmación huérfana oculta dentro del repositorio oficial de GitHub nrwl/nx», dijo el investigador de StepSecurity Ashish Kurmi. dicho.

La carga útil es una «herramienta de envenenamiento de la cadena de suministro y ladrón de credenciales de varias etapas» que recopila secretos de los desarrolladores y los filtra a través de HTTPS, la API de GitHub y el túnel DNS. También instala una puerta trasera de Python en sistemas macOS que abusa de la API de búsqueda de GitHub como un solucionador muerto para recibir más comandos.

En un aviso emitido el lunes, los mantenedores de la extensión dicho La causa raíz se remonta a uno de sus desarrolladores, cuya máquina se vio comprometida en un incidente de seguridad reciente que filtró sus credenciales de GitHub. Aunque no se reveló la naturaleza del «incidente» anterior, las credenciales del desarrollador han sido revocadas temporalmente.

Ciberseguridad

Se dice que se ha abusado del acceso proporcionado por las credenciales para enviar un compromiso huérfano y sin firmar a nrwl/nx, que introduce el malware ladrón. La acción maliciosa se activa tan pronto como un desarrollador abre cualquier espacio de trabajo en VS Code, lo que lleva a la instalación del tiempo de ejecución Bun JavaScript para ejecutar una carga útil «index.js» ofuscada.

El malware ejecuta comprobaciones para evitar infectar máquinas probablemente ubicadas en las zonas horarias de Rusia/CEI y se lanza como un proceso en segundo plano independiente para iniciar el flujo de trabajo de recolección de credenciales, lo que le permite recuperar secretos de las bóvedas de 1Password y las configuraciones de Anthropic Claude Code, y secretos asociados con npm, GitHub y Amazon Web Services (AWS).

«Una capacidad que se destaca: la carga útil contiene integración completa de Sigstore, incluida la emisión de certificados Fulcio y la generación de procedencia SLSA», dijo StepSecurity. «Combinado con tokens npm OIDC robados, esto significa que el atacante podría publicar paquetes npm posteriores con certificaciones de procedencia válidas y firmadas criptográficamente, haciendo que los paquetes maliciosos parezcan compilaciones legítimas y verificadas».

El equipo de Nx también reconoció que «algunos usuarios se vieron comprometidos» como resultado de esta infracción. Además de instar a los usuarios a actualizar a 18.100.0 o posterior, los mantenedores han publicado los siguientes indicadores de compromiso:

  • La versión 18.95.0 de Nx Console se instaló durante el período de exposición entre el 18 de mayo de 2026, a las 2:36 p. m. CEST y a las 2:47 p. m. CEST.
  • Presencia de archivos como ~/.local/share/kitty/cat.py, ~/Library/LaunchAgents/com.user.kitty-monitor.plist, /var/tmp/.gh_update_state o /tmp/kitty-*.
  • Presencia de cualquiera de los siguientes procesos en ejecución: un proceso de Python que ejecuta cat.py y un proceso con __DAEMONIZED=1 en su entorno.

Se recomienda a los usuarios afectados que finalicen los procesos antes mencionados, eliminen los artefactos en el disco y roten todas las credenciales accesibles desde la máquina afectada, incluidos tokens, secretos y claves SSH.

Este desarrollo marca la segunda vez que se ataca al ecosistema Nx en un año. En agosto de 2025, se lanzaron varios paquetes npm. infectado por un ladrón de credenciales como parte de una campaña de ataque a la cadena de suministro llamada s1ngularity. A diferencia de la iteración anterior, el último ataque tiene como objetivo la extensión VS Code.

Ciberseguridad

Paquetes npm maliciosos en abundancia

Los hallazgos coinciden con el descubrimiento de varios paquetes maliciosos en los repositorios de código abierto.

  • iceberg-javascript, supabase-javascript, auth-javascript, microsoft-applicationinsights-common y ms-graph-types: Cinco paquetes npm que contienen un binario ELF oculto que bloquea las sesiones de Claude Code para robar credenciales de desarrollador.
  • contratos de mediodía: un paquete npm que se hace pasar por un SDK de contrato inteligente de Noon Protocol para extraer claves SSH, claves privadas de billetera criptográfica, credenciales de AWS, secretos de Kubernetes, todos los archivos .env, historial de shell, tokens Docker/Git/npm y rutas de almacenamiento de billetera del navegador.
  • martinez-polígono-recorte-tonyuna bifurcación troyanizada de martinez-polygon-clipping que usa un gancho postinstalación para descargar un troyano de acceso remoto (RAT) de Windows empaquetado con PyInstaller de 17 MB que usa Telegram para comando y control (C2) para ejecución remota de shell, captura de pantalla, carga/descarga de archivos y ejecución arbitraria de Python.
  • servicio-tg-común: un paquete npm que contiene funcionalidad para hacerse cargo de la cuenta de Telegram de una víctima mientras se hace pasar por «servicio común de Telegram para aplicaciones NestJS».
  • exiosos: un paquete npm que incluye un ladrón de cookies de sesión ChatGPT y OpenAI dirigido a navegadores web como Google Chrome, Microsoft Edge y Brave.
  • k8s-pod-checker, dev-env-setup y node-perf-utils: tres paquetes npm parte del clúster kube-health-tools que instala un servicio proxy de modelo de lenguaje grande (LLM) en la máquina de la víctima, lo que permite al atacante enrutar el tráfico LLM a través del servidor comprometido
  • A campaña coordinada de recolección de credenciales orquestado por un actor de amenazas de habla indonesia que utiliza un conjunto de paquetes de 38 npm que aprovecha la confusión de dependencias como una forma de engañar a los canales de CI/CD para resolver paquetes públicos maliciosos antes que los privados legítimos asociados con Apple, Google y Alibaba, entre otros.
  • Una campaña inusual en la que siete paquetes npm bajo el @ organización del equipo hd Se ha descubierto que actúan como escenario de las configuraciones utilizadas por una plataforma china de apuestas deportivas y transmisión pirata llamada Douqiu para determinar los servidores backend a los que conectarse.
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.

Puerta trasera ladrona encontrada en 3 versiones de Node-IPC dirigidas a secretos de desarrolladores – CYBERDEFENSA.MX

Los investigadores de ciberseguridad están haciendo sonar la alarma sobre lo que se ha descrito como «actividad maliciosa» en las versiones recientemente publicadas de node-ipc.

De acuerdo a Enchufe y PasoSeguridadse han creado tres versiones diferentes del paquete npm confirmado tan malicioso –

  • nodo-ipc@9.1.6
  • nodo-ipc@9.2.3
  • nodo-ipc@12.0.1

«Los primeros análisis indican que node-ipc@9.1.6, node-ipc@9.2.3 y node-ipc@12.0.1 contienen comportamientos de ladrón/puerta trasera ofuscados», dijo Socket.

Ciberseguridad

«El malware parece tomar huellas dactilares del entorno del host, enumerar y leer archivos locales, comprimir y fragmentar los datos recopilados, envolver la carga útil en un sobre criptográfico e intentar la filtración a través de un punto final de red seleccionado mediante lógica de direcciones/DNS».

StepSecurity dijo que la carga útil muy ofuscada se activa cuando se requiere el paquete en tiempo de ejecución e intenta filtrar un amplio conjunto de secretos de desarrollador y de la nube a un servidor externo de comando y control (C2).

Esto incluye 90 categorías de credenciales, incluidos Amazon Web Services, Google Cloud, Microsoft Azure, claves SSH, tokens de Kubernetes, configuraciones de GitHub CLI, configuraciones de Claude AI y Kiro IDE, estado de Terraform, contraseñas de bases de datos, historial de shell y más. Luego, los datos recopilados se comprimen en un archivo GZIP y se transmiten al archivo «sh.azurestaticprovider».[.]dominio «net».

Las tres versiones fueron publicadas por una cuenta llamada «atiertant», que no tiene conexión con el autor original del paquete, «riaevangelist». Aunque «atiertant» aparece en la lista de mantenedores, la cuenta no tiene un historial de publicación anterior en relación con el paquete node-ipc. La actualización anterior del paquete fue en agosto de 2024.

El hecho de que el paquete inactivo de alta descarga se haya visto comprometido después de un intervalo de 21 meses indica que las credenciales «atiertant» fueron comprometidas recientemente o que la cuenta se agregó específicamente como mantenedor para publicar las versiones maliciosas.

Lo notable de la actividad es que no depende de ningún enlace del ciclo de vida de npm, como scripts de preinstalación, instalación o postinstalación, sino que agrega la carga útil maliciosa como una expresión de función invocada inmediatamente (IFE) hasta el final de «node-ipc.cjs». Esto, a su vez, hace que el malware se active incondicionalmente en cada requisito (‘nodo-ipc’).

La rareza no termina ahí, ya que la carga útil realiza una verificación de huellas dactilares SHA-256 y la compara con un hash codificado ensamblado a partir de ocho fragmentos de tabla ofuscados incrustados en el código, antes de continuar con la enumeración del sistema y la recolección integral de credenciales.

«Esto significa que 12.0.1 es completamente inerte en cualquier máquina cuya ruta del módulo principal no alcance el valor objetivo», dijo el investigador de StepSecurity Sai Likhith. «El atacante sabe exactamente qué proyecto o desarrollador está siendo atacado y precalcula el hash de su punto de entrada antes de publicarlo. Las versiones 9.x no tienen esta puerta y ejecutarán la carga útil completa en cualquier sistema que las cargue».

El malware también incorpora un segundo canal de exfiltración además de emitir un HTTPS POST al dominio falso de Azure que contiene los datos robados comprimidos. Esto implica codificar fragmentos del archivo como un registro DNS TXT después de anular el solucionador de DNS del sistema con Google Public DNS para eludir los controles de seguridad locales basados ​​en DNS.

Ciberseguridad

«Primero resuelve sh.azurestaticprovider.net usando 1.1.1.1 (primario) o 8.8.8.8 (alternativo) para obtener la IP C2», dijo StepSecurity. «Luego redirecciona el solucionador directamente a la IP C2 para todas las consultas de exfiltración».

«El sumidero de DNS directo a C2 es una técnica anti-detección notable. Debido a que las consultas de exfiltración nunca tocan los solucionadores de DNS públicos, no hay actividad bt.node.js observable en los registros de DNS públicos. Las organizaciones que dependen únicamente del registro de DNS a través de solucionadores corporativos no verían este tráfico».

Esta no es la primera vez que el paquete npm incorpora una funcionalidad maliciosa. En marzo de 2022, el responsable del paquete introdujo deliberadamente capacidad destructiva en las versiones 10.1.1 y 10.1.2 sobrescribiendo archivos en sistemas ubicados en Rusia o Bielorrusia como forma de protesta tras la invasión militar rusa de Ucrania.

Dos versiones posteriores, 11.0.0 y 11.1.0, incluyeron la dependencia «peacenotwar», que también fue publicada por el mismo mantenedor como una «protesta no violenta contra la agresión de Rusia».

«El último incidente parece involucrar una republicación sospechosa o reintroducción de código malicioso en versiones de un paquete conocido, en lugar de un intento de typosquatting», dijo Socket.

Se recomienda a los usuarios eliminar las versiones comprometidas de node-ipc y reinstalar una versión limpia conocida (9.2.1 y 12.0.0), asumir el compromiso y rotar las credenciales y secretos, auditar la actividad de publicación de npm para cualquier paquete accesible con los tokens rotados y revisar los registros de ejecución del flujo de trabajo para detectar actividades sospechosas, auditar los registros de la nube para verificar si las identidades de IAM cuyas credenciales estaban disponibles durante la ventana comprometida realizaron acciones no autorizadas y bloquear el tráfico de salida al dominio C2.

La campaña GlassWorm utiliza Zig Dropper para infectar múltiples IDE de desarrolladores – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han señalado otra evolución más de la actual gusano de cristal campaña, que emplea un nuevo cuentagotas Zig que está diseñado para infectar sigilosamente todos los entornos de desarrollo integrados (IDE) en la máquina de un desarrollador.

La técnica ha sido descubierta en una extensión Open VSX llamada «specstudio.code-wakatime-actividad-rastreador«, que se hace pasar por WakaTime, una herramienta popular que mide el tiempo que los programadores pasan dentro de su IDE. La extensión ya no está disponible para descargar.

«La extensión […] envía un binario nativo compilado por Zig junto con su código JavaScript», dijo el investigador de Aikido Security, Ilyas Makari. dicho en un análisis publicado esta semana.

Ciberseguridad

«Esta no es la primera vez que GlassWorm recurre al uso código compilado nativo en extensiones. Sin embargo, en lugar de utilizar el binario como carga útil directamente, se utiliza como una dirección indirecta sigilosa para el conocido dropper GlassWorm, que ahora infecta secretamente todos los demás IDE que puede encontrar en su sistema».

La extensión Microsoft Visual Studio Code (VS Code) recientemente identificada es casi una réplica de WakaTime, salvo por un cambio introducido en una función llamada «activate()». La extensión instala un binario llamado «win.node» en sistemas Windows y «mac.node», un binario Mach-O universal si el sistema ejecuta Apple macOS.

Estos complementos nativos de Node.js son bibliotecas compartidas compiladas que están escritas en Zig y se cargan directamente en el tiempo de ejecución de Node y se ejecutan fuera del entorno limitado de JavaScript con acceso completo a nivel del sistema operativo.

Una vez cargado, el objetivo principal del binario es encontrar todos los IDE del sistema que admitan extensiones de VS Code. Esto incluye Microsoft VS Code y VS Code Insiders, así como bifurcaciones como VSCodium, Positron y una serie de herramientas de codificación impulsadas por inteligencia artificial (IA) como Cursor y Windsurf.

Luego, el binario descarga una extensión maliciosa de VS Code (.VSIX) desde un sitio controlado por el atacante. cuenta GitHub. La extensión, llamada «floktokbok.autoimport», se hace pasar por «esteoteatos.autoimport,» una extensión legítima con más de 5 millones de instalaciones en el Visual Studio Marketplace oficial.

Ciberseguridad

En el paso final, el archivo .VSIX descargado se escribe en una ruta temporal y se instala silenciosamente en cada IDE mediante el instalador CLI de cada editor. La extensión VS Code de segunda etapa actúa como un gotero que evita la ejecución en sistemas rusos, se comunica con la cadena de bloques de Solana para buscar el servidor de comando y control (C2), extrae datos confidenciales e instala un troyano de acceso remoto (RAT), que finalmente implementa una extensión de Google Chrome para robar información.

Se recomienda a los usuarios que hayan instalado «specstudio.code-wakatime-activity-tracker» o «floktokbok.autoimport» que asuman un compromiso y roten todos los secretos.

Cómo LiteLLM convirtió las máquinas de los desarrolladores en bóvedas de credenciales para los atacantes – CYBERDEFENSA.MX

La parte más activa de la infraestructura empresarial de la empresa es la estación de trabajo del desarrollador. Esa computadora portátil es donde se crean, prueban, almacenan en caché, copian y reutilizan las credenciales en servicios, bots, herramientas de compilación y, ahora, agentes de IA locales.

En marzo de 2026, el actor de amenazas TeamPCP demostró lo valiosas que son las máquinas de desarrollo. Su ataque a la cadena de suministro contra LiteLLM, una popular biblioteca de desarrollo de inteligencia artificial descargada millones de veces al día, convirtió los puntos finales de los desarrolladores en operaciones sistemáticas de recolección de credenciales. El malware solo necesitaba acceso a los secretos de texto sin formato que ya se encontraban en el disco.

El ataque LiteLLM: un estudio de caso sobre el compromiso de los terminales de los desarrolladores

El ataque fue sencillo en ejecución pero devastador en alcance. TeamPCP comprometió los paquetes LiteLLM versiones 1.82.7 y 1.82.8 en PyPI, inyectando malware de robo de información que se activaba cuando los desarrolladores instalaban o actualizaban el paquete. El malware recopiló sistemáticamente claves SSH, credenciales de nube para AWS, Azure y GCP, configuraciones de Docker y otros datos confidenciales de las máquinas de los desarrolladores.

PyPI eliminó los paquetes maliciosos a las pocas horas de su detección, pero la ventana de daño fue significativa. El análisis de GitGuardian encontró que se configuraron 1.705 paquetes PyPIpara extraer automáticamente las versiones comprometidas de LiteLLM como dependencias. Paquetes populares como dspy (5 millones de descargas mensuales), opik (3 millones) y crawl4ai (1,4 millones) habrían desencadenado la ejecución de malware durante la instalación. El efecto cascada significó que las organizaciones que nunca usaron LiteLLM directamente aún podrían verse comprometidas a través de dependencias transitivas.

Por qué las máquinas de desarrollo son objetivos atractivos

Este patrón de ataque no es nuevo; es simplemente más visible. El Campañas de Shai-Hulud demostró tácticas similares a escala. Cuando GitGuardian analizó 6.943 máquinas de desarrollador comprometidas a partir de ese incidente, los investigadores encontraron 33.185 secretos únicos, de los cuales al menos 3.760 aún eran válidos. Más sorprendente: cada secreto activo apareció en aproximadamente ocho ubicaciones diferentes en la misma máquina, y el 59% de los sistemas comprometidos eran ejecutadores de CI/CD en lugar de computadoras portátiles personales.

Los adversarios ahora entran en la cadena de herramientas a través de dependencias comprometidas, complementos maliciosos o actualizaciones envenenadas. Una vez allí, recopilan datos del entorno local con el mismo enfoque sistemático que utilizan los equipos de seguridad para buscar vulnerabilidades, excepto que buscan credenciales almacenadas en archivos .env, perfiles de shell, historial de terminal, configuraciones IDE, tokens almacenados en caché, artefactos de compilación y almacenes de memoria de agentes de IA.

Los secretos viven en todas partes en texto plano

El malware LiteLLM tuvo éxito porque las máquinas de los desarrolladores son puntos de concentración densos para las credenciales de texto sin formato. Los secretos terminan en árboles de fuentes, archivos de configuración locales, resultados de depuración, comandos de terminal copiados, variables de entorno y scripts temporales. Se acumulan en archivos .env que se suponía que eran solo locales pero que se convirtieron en una parte permanente del código base. La comodidad se convierte en residuo, que a su vez se convierte en oportunidad.

Los desarrolladores ejecutan agentes, servidores MCP locales, herramientas CLI, extensiones IDE, canalizaciones de compilación y flujos de trabajo de recuperación, todos los cuales requieren credenciales. Esas credenciales se distribuyen a través de rutas predecibles donde el malware sabe buscar: ~/.aws/credentials, ~/.config/gh/config.yml, archivos .env del proyecto, historial de shell y directorios de configuración del agente.

Protección de los puntos finales de los desarrolladores a escala

Es importante crear una protección continua en todos los puntos finales del desarrollador donde se acumulan las credenciales. GitGuardian aborda esto extendiendo la seguridad de los secretos más allá de los repositorios de código hasta la propia máquina del desarrollador.

El ataque LiteLLM demostró lo que sucede cuando las credenciales se acumulan en texto sin formato en los puntos finales de los desarrolladores. Esto es lo que puede hacer para reducir esa exposición.

Comprenda su exposición

Comience con la visibilidad. Trate la estación de trabajo como el entorno principal para escanear secretos, no como una ocurrencia tardía. Utilice ggshield para escanear repositorios locales en busca de credenciales que se filtraron en el código o persisten en el historial de Git. Analice las rutas del sistema de archivos donde se acumulan secretos fuera de Git: espacios de trabajo de proyectos, archivos de puntos, resultados de compilación y carpetas de agentes donde las herramientas locales de IA generan registros, cachés y almacenes de «memoria».

ggshield detecta un secreto en un archivo específico desde una ruta

No asuma que las variables de entorno son seguras sólo porque no están en archivos. Los perfiles de Shell, las configuraciones IDE y los artefactos generados a menudo persisten en los valores del entorno en el disco de forma indefinida. Escanee estas ubicaciones de la misma manera que escanea los repositorios.

Agregue ganchos de confirmación previa de ggshield para dejar de crear nuevas fugas en las confirmaciones mientras limpia las antiguas. Esto convierte la detección secreta en una barrera de seguridad predeterminada que detecta los errores antes de que se conviertan en incidentes.

Comando de confirmación previa de ggshield que detecta un secreto

Mover secretos a bóvedas

La detección sin remediación es sólo ruido. Cuando se filtra una credencial, la remediación generalmente requiere la coordinación entre varios equipos: la seguridad identifica la exposición, la infraestructura es propietaria del servicio, es posible que el desarrollador original haya abandonado la empresa y los equipos de producto se preocupan por las interrupciones en la producción. Sin una propiedad clara y una automatización del flujo de trabajo, la remediación se convierte en un proceso manual al que se le quita prioridad.

La solución trata los secretos como identidades administradas con propiedad definida, políticas de ciclo de vida y rutas de reparación automatizadas. Mueva las credenciales a una infraestructura de bóveda centralizada donde los equipos de seguridad puedan aplicar programas de rotación, políticas de acceso y monitoreo de uso. Integre la gestión de incidentes con sus sistemas de emisión de tickets existentes para que la solución se produzca en contexto en lugar de requerir un cambio constante de herramientas.

GitGuardian Analytics que muestra el estado de los secretos que se están monitoreando

Trate a los agentes de IA como riesgos de credenciales

Las herramientas agentes pueden leer archivos, ejecutar comandos y mover datos. Con los agentes estilo OpenClaw, la «memoria» son literalmente archivos en el disco (SOUL.md, MEMORY.md) almacenados en ubicaciones predecibles. Nunca pegue credenciales en los chats de los agentes, nunca les enseñe secretos a los agentes «para más tarde» y escanee de forma rutinaria los archivos de memoria de los agentes como almacenes de datos confidenciales.

Eliminar clases enteras de secretos

La forma más rápida de reducir la proliferación de secretos es eliminar la necesidad de categorías enteras de secretos compartidos. En el lado humano, adopte WebAuthn (claves de acceso) para reemplazar las contraseñas. En cuanto a la carga de trabajo, migre a la federación OIDC, para que las canalizaciones dejen de depender de las claves almacenadas en la nube y los secretos de las cuentas de servicio.

Comience con las rutas de mayor riesgo donde las credenciales filtradas perjudican más y luego amplíe. Mueva el acceso de desarrollador a claves de acceso y migre flujos de trabajo de CI/CD a autenticación basada en OIDC.

Utilice credenciales efímeras

Si aún no puede eliminar los secretos, hágalos de corta duración y reemplácelos automáticamente. Utilice SPIFFE para emitir documentos de identidad criptográficos (SVID) que rotan automáticamente en lugar de depender de claves API estáticas.

Comience con claves de nube, tokens de implementación y credenciales de servicio de larga duración que los desarrolladores conservan localmente para su comodidad. Cambie a tokens de corta duración, rotación automática y patrones de identidad de cargas de trabajo. Cada migración es un secreto menos duradero que puede ser robado y convertido en arma.

El objetivo es reducir el valor que un atacante puede extraer de cualquier punto de apoyo exitoso en una máquina de desarrollador.

Honeytokens como sistemas de alerta temprana

Los Honeytokens brindan protección provisional. Coloque credenciales señuelo en ubicaciones a las que los atacantes apuntan sistemáticamente: directorios de inicio de desarrolladores, rutas de configuración comunes y almacenes de memoria de agentes. Cuando se recolectan y validan, estos tokens generan alertas inmediatas, comprimiendo el tiempo de detección de «descubrir daños semanas después» a «detectar ataques mientras se desarrollan». Este no es el estado final, pero cambia la ventana de respuesta mientras continúa la limpieza sistemática.

Los puntos finales de desarrollador ahora son parte de su infraestructura crítica. Se encuentran en la intersección del privilegio, la confianza y la ejecución. El incidente de LiteLLM demostró que los adversarios entienden esto mejor que la mayoría de los programas de seguridad. Las organizaciones que traten las máquinas de desarrollo con la misma disciplina de gobernanza que ya se aplica a los sistemas de producción serán las que sobrevivan al próximo compromiso de la cadena de suministro.

¿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.

La implementación de la verificación de desarrolladores de Android comienza antes de la aplicación de la ley en septiembre – CYBERDEFENSA.MX

Google dijo el lunes que está implementando oficialmente la verificación de desarrollador de Android para todos los desarrolladores para combatir el problema de los malos actores que distribuyen aplicaciones dañinas mientras «se esconden detrás del anonimato».

El desarrollo se produce antes de un mandato de verificación planificado que entrará en vigor en Brasil, Indonesia, Singapur y Tailandia en septiembre, antes de expandirse a nivel mundial el próximo año.

Como parte de este esfuerzo, Google exige a los desarrolladores de aplicaciones que distribuyen aplicaciones fuera de Google Play que creen una cuenta en la Consola de desarrollador de Android para confirmar su identidad. Aquellos que distribuyen aplicaciones a través del mercado oficial de aplicaciones de Android y han verificado su identidad pueden «ya estar configurados», dijo el gigante tecnológico.

Ciberseguridad

«Para la gran mayoría de los usuarios, la experiencia de instalar aplicaciones seguirá siendo exactamente la misma», dijo Matthew Forsythe, director de gestión de productos para Android App Safety. dicho. «Solo cuando un usuario intenta instalar una aplicación no registrada necesitará ADB o flujo avanzado, lo que nos ayuda a mantener segura a la comunidad en general y al mismo tiempo preserva la flexibilidad para nuestros usuarios avanzados».

Los desarrolladores de Android Studio pueden esperar ver el estado de registro de su aplicación directamente desde el entorno de desarrollo integrado (IDE) en los próximos dos meses cuando generen un App Bundle o APK firmado.

Los desarrolladores que hayan completado los requisitos de verificación de desarrollador de Play Console registrarán automáticamente sus aplicaciones de Play elegibles. Si no se puede registrar una aplicación, se solicita a los desarrolladores que sigan un proceso de reclamo de aplicación manual.

Como se anunció hace un par de semanas, los usuarios avanzados siempre tienen la opción de habilitar la descarga de archivos APK no registrados a través de un flujo avanzado que requiere un paso de autenticación para confirmar que están dando este paso por su propia voluntad y un período de espera único de 24 horas para disuadir a los estafadores.

«Este flujo es un proceso único para usuarios avanzados, pero fue diseñado cuidadosamente para evitar que aquellos que se encuentran en medio de un intento de estafa sean coaccionados por tácticas de alta presión para instalar software malicioso», dijo Forsythe.

Ciberseguridad

El desarrollo llega como lo ha hecho Apple. revisado su Acuerdo de Licencia del Programa de Desarrolladores para hacer cumplir las reglas de privacidad con respecto al acceso de dispositivos portátiles de terceros a actividades y notificaciones en vivo.

Apple señaló explícitamente que terceros «no pueden usar la información de reenvío para publicidad, elaboración de perfiles, modelos de entrenamiento o monitoreo de ubicación», y agregó que «no pueden difundir la información de reenvío a ninguna otra aplicación ni a ningún otro dispositivo además de su accesorio de destino autorizado».

La sección recién agregada también enfatizó que los desarrolladores no pueden almacenar de forma remota ninguna información de reenvío en un servicio en la nube, realizar modificaciones que cambien «materialmente» el significado del contenido o descifrar los datos en cualquier otro lugar que no sea el propio accesorio.