El malware apunta a herramientas de inteligencia artificial en entornos de desarrollo de software

El malware dirigido a los asistentes de codificación de IA y a los flujos de trabajo automatizados de los desarrolladores de software se está extendiendo a más entornos con más capacidades, lo que coloca a los defensores en una desventaja cada vez mayor.

Una variedad de malware denominada Sandworm_Mode, primero descubierto por zócalo en febrero, representa una amenaza creciente para el desarrollo de software. Según un CrowdStrike informeel gusano autopropagante puede propagarse a través de repositorios de código con una detección mínima, lo que genera alarmas sobre las cadenas de suministro de software.

Las capacidades del malware son amplias, pero no especialmente únicas en comparación con la serie de gusanos de la cadena de suministro conocidos como Shai-Hulud y, más recientemente, Mini Shai-Hulud.

«Esta es la nueva tendencia», dijo a CyberScoop Adam Meyers, vicepresidente senior de operaciones contra adversarios de CrowdStrike. «Esto es algo que estamos viendo cada vez más. Es la nueva moda en este momento».

Sandworm_Mode apunta y roba datos confidenciales, incluidas credenciales, claves y secretos que desbloquean rutas a servicios y dependencias adicionales en toda la cadena de herramientas de IA. Esto incluye asistentes de inteligencia artificial, proveedores de nube, claves API para nueve proveedores principales de LLM, canalizaciones de CI/CD y sistemas automatizados que crean, prueban y publican código.

Estas acciones se combinan con decenas de miles de otros comandos que ocurren diariamente en cualquier entorno dotado de herramientas de desarrollo de IA.

«Tratar de encontrar la señal de que algo malicioso está sucediendo es muy difícil porque hay mucho ruido ahí afuera», dijo Meyers.

El gusano también se controla, estableciendo retrasos de varios días para separar el acceso inicial de la actividad maliciosa posterior, creando una brecha en las ventanas de telemetría de las víctimas, lo que hace que sea aún más difícil para los defensores detectar y atribuir la cadena de infección adecuadamente.

«Los agentes de IA están derribando todas estas diferentes dependencias continuamente a lo largo del día», dijo Meyers. «Cuando miras hacia abajo desde la perspectiva del equipo de operaciones de seguridad, simplemente ves a todos derribando estas dependencias, y estas dependencias se desempaquetan y ejecutan automáticamente, por lo que se vuelve muy, muy ruidoso tratar de encontrar que algo malo está sucediendo».

El malware cubre aún más sus huellas con una racha un poco mezquina, al destruir automáticamente los entornos comprometidos si no puede propagarse o lograr sus objetivos.

«Está bien pensado y desarrollado, por lo que alguien dedicó algún tiempo a cuidar y alimentar a esta cosa», dijo Meyer.

A pesar de la revisión de cuatro meses de Sandworm_Mode por parte de CrowdStrike, la empresa de ciberseguridad aún no tiene una idea firme de su intención, pero Meyers dijo que está diseñado para lograr una posición sólida, lo que podría permitir un acceso a largo plazo.

CrowdStrike no ha determinado quién es el responsable del malware, pero Meyers dijo que no cree que TeamPCP, un grupo de amenazas que ha arrasado con el software de código abierto este año, esté involucrado.

«Podría ser un actor de amenazas de un Estado-nación, o podría ser un actor de delitos electrónicos que busca utilizar esto para luego vender el acceso a otras organizaciones», dijo. «No sabemos realmente cuál es la intención».

Tampoco está claro el estado de Sandworm_Mode y si permanece activo. CrowdStrike dijo que continúa observando paquetes maliciosos de la cadena de suministro activos recientemente que siguen patrones similares pero técnicamente divergentes.

En última instancia, “el mundo ha cambiado”, dijo Meyers, y agregó que muchos atacantes están siguiendo caminos similares en la cadena de herramientas de la IA, lo que requiere que los defensores y cazadores de amenazas presten mayor atención a este floreciente modo de agresión.

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

TuxBot v3 Evolution muestra signos de desarrollo de botnets de IoT asistido por LLM – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de un marco de botnet de Internet de las cosas (IoT) no informado anteriormente denominado TuxBot v3 Evolución que muestra signos de haber sido desarrollado con la ayuda de un modelo de lenguaje grande (LLM), aunque con resultados no tan exitosos.

«Si bien la IA cumplió con su solicitud de generar código de botnet, incluyó un descargo de responsabilidad de seguridad que el desarrollador no eliminó antes del envío», Unidad 42 de Palo Alto Networks dicho. «Aunque el LLM claramente ayudó en la construcción de la botnet, varias funciones en las muestras analizadas no funcionaron correctamente».

La compañía de ciberseguridad dijo que una revisión manual del código habría resuelto estos errores y que es posible que existan iteraciones más pulidas del malware.

El marco de la botnet consta de varios componentes: un agente bot basado en C que realiza compilaciones cruzadas para múltiples arquitecturas (por ejemplo, ARM, MIPS, MIPSEL, MIPS64, x86_64, PowerPC y RISC-V), un servidor de comando y control (C2) basado en Go con un panel de alquiler de DDoS, una máquina virtual de exploits personalizada, una infraestructura de prueba basada en Docker y un sistema de compilación automatizado.

El agente bot está diseñado para forzar el acceso Telnet a dispositivos específicos con un conjunto de 1496 pares de credenciales, así como para incorporar código de explotación dirigido a más de 30 familias de dispositivos IoT que utilizan vulnerabilidades conocidas. Se comunica con el servidor C2 a través de un canal TCP cifrado, mientras recurre a un algoritmo de generación de dominio (DGA) SHA512, un protocolo de chismes de igual a igual (P2P) con comandos firmados por Ed25519, Internet Relay Chat (IRC), consultas DNS TXT y sondeo HTTP como mecanismo alternativo.

Ciberseguridad

El linaje del marco modular se remonta a tres botnets diferentes, como Mirai, AISURU y Wuhan, además de trasladar parcialmente algunas de sus funciones del código abierto. Kit de herramientas MHDDoS Python DDoS. Al menos una muestra del malware fue subido a la plataforma VirusTotal el 20 de enero de 2026, lo que indica que existe desde hace más de seis meses. La evidencia sugiere que el trabajo en la botnet comenzó un año antes, cuando el autor clonó el repositorio MHDDoS de GitHub.

«Según la descripción del marco, el desarrollador de TuxBot construyó lo que llamaron una plataforma de marco C2 de nivel profesional con un panel de administración multiusuario, implementación automatizada y capacidades de ataque modular», dijeron los investigadores Chris Navarrete, Asher Davila y Doel Santos.

El componente del servidor C2 basado en Go utiliza tres puertos TCP diferentes para las conexiones entrantes:

  • Puerto TCP 1999 (o 31337), que se utiliza para manejar el envío de comandos cifrados a los bots conectados
  • Puerto TCP 2222, que presenta un shell interactivo para operadores a través de SSH
  • Puerto TCP 9999, que utiliza una interfaz JSON para acceso programático

Una vez lanzada, la botnet sigue una secuencia de inicialización predefinida para realizar una serie de acciones:

  • Carga de la dirección C2 desde una arquitectura de varios niveles con un canal principal y cinco mecanismos alternativos
  • Configurar protecciones anti-depuración y anti-VM que verifican la ejecución de herramientas de análisis
  • Ocultar su nombre de proceso
  • Instalando persistencia
  • Lanzar varios submódulos para montar ataques DDoS, finalizar procesos competitivos, establecer canales C2 a través de IRC, HTTP, DNS y P2P, ejecutar escáneres para Telnet, SSH, HTTP y Android Debug Bridge (ADB), generar un proxy SOCKS5 y ejecutar un marcador de posición de minería de criptomonedas.

El escáner HTTP dedicado, en particular, puede gestionar hasta 128 conexiones simultáneas en cualquier momento dado, funcionando con el objetivo de descubrir interfaces web vulnerables. La persistencia, por otro lado, se logra mediante un servicio systemd, entradas cron y un proceso de vigilancia para garantizar que TuxBot permanezca operativo en la máquina comprometida.

Ciberseguridad

«Varios archivos contienen razonamientos de cadena de pensamiento de LLM sin procesar, dejados palabra por palabra en los comentarios», dijo Unit42. «Estos comentarios son el razonamiento interno del LLM mientras trabajaba en las tareas de transferencia. Este razonamiento se completa con autointerrupciones, decisiones y referencias al ‘usuario’ (es decir, el desarrollador que solicitó el LLM)».

Aunque TuxBot v3 Evolution es una botnet en desarrollo, las funciones de trabajo principales, junto con su dependencia de la IA, indican una integración acelerada de características, al mismo tiempo que permiten que lo que parece ser un solo desarrollador cree un conjunto de herramientas multifacético con múltiples canales C2, una máquina virtual de exploit personalizada y un panel de alquiler de DDoS basado en Go.

«La infraestructura compartida con Kaitori v3.9 y las herramientas AISURU coloca al operador TuxBot dentro del ecosistema Keksec», concluyó la Unidad 42. «Este grupo es conocido por ejecutar múltiples variantes de botnet IoT en paralelo. TuxBot parece ser otra variante en esa cartera. Es una que apunta a ir más allá de la bifurcación Mirai habitual con su C2 cifrado, su DGA y un sistema de explotación modular, aunque ese sistema aún no funciona en la versión que recuperamos».

La divulgación se produce tras la aparición de otras dos botnets llamadas RustDuck y AryStinger, que se han dirigido a enrutadores, cámaras IP, dispositivos Android y servidores mal protegidos para incorporarlos a una red creada para prestar servicios en línea fuera de línea y realizar reconocimientos.

Cómo la obsesión por la velocidad del desarrollo de software permitió la cruzada del caos del TeamPCP

TeamPCP está arrasando con el software de código abierto.

En menos de cuatro meses, el actor de amenazas comprometió e inyectó código malicioso en más de 1.000 paquetes de software. Esta extraordinaria oleada ha transformado la forma en que los desarrolladores y mantenedores de software distribuyen y administran su código, ya que sus dependencias y repositorios se han convertido en uno de los vectores de ataque más efectivos y frecuentes este año.

Si bien ha habido una serie de exploits técnicos, el mayor ataque de TeamPCP ha sido el desarraigo de la confianza, demostrando repetidamente que la mayoría de las organizaciones no verifican que el código que ingieren en sus sistemas sea legítimo, abusando de una fe casi ciega en la que depende gran parte de la industria de desarrollo de software para impulsar la economía moderna de hoy.

Comenzando con Trivy en febrero, los ataques de TeamPCP han sacudido esa confianza muchas veces.

La escala de los ataques de TeamPCP radica en parte en los sistemas automatizados que las empresas utilizan para implementar código, como los canales de CI/CD. También está aprovechando las nuevas brechas de seguridad creadas por la creciente dependencia de los desarrolladores de la IA. Sin embargo, con un esfuerzo relativamente bajo y tácticas poco originales, TeamPCP está destruyendo marcos de código abierto y sistemas subyacentes a niveles que la comunidad tecnológica rara vez ha tenido en cuenta.

«Los desarrolladores no hacían un gran trabajo analizando la seguridad de sus dependencias de código abierto antes, pero ahora con la IA, en algunos casos prácticamente no hay ningún ser humano en el circuito ni ningún tipo de control de cordura sobre lo que están haciendo estas herramientas», dijo a CyberScoop Feross Aboukhadijeh, fundador y director ejecutivo de Socket.

«Hay agentes que instalan paquetes que no han sido examinados», dijo. «Cuando un atacante ingresa, el impacto es aún mayor porque hay menos controles y contrapesos para evitar que afecte a todos».

TeamPCP no ha identificado un nuevo problema ni ha demostrado nada novedoso. El quid de estos ataques gira en torno a un tema central: las vulnerabilidades defensivas que toda la industria del software conoce desde hace años. Los investigadores y desarrolladores saben que el modelo de confianza del código abierto no funciona y es susceptible de sabotaje. Sin embargo, la industria del software no ha solucionado este problema.

«La velocidad y la escala de estos ataques es lo que los hace más notables, no necesariamente la metodología detrás de ellos, porque en esencia se trata de explotar la confianza de terceros que tenemos», dijo Kimberly Goody, gerente senior de Google Threat Intelligence Group.

Los paquetes de software suelen estar sujetos a una supervisión de seguridad intensiva para comprobar si hay vulnerabilidades y actualizaciones envenenadas antes de lanzarlos a entornos activos.

Sin embargo, la verdadera vulnerabilidad destacada por TeamPCP se encuentra más arriba en la cadena de mando con las organizaciones o individuos que publican estos paquetes en el mercado en general, según Nathaniel Quist, gerente de inteligencia de amenazas en la nube de Palo Alto Networks.

«Es su responsabilidad asegurar sus credenciales y no proporcionar un punto de partida para desencadenar un evento en la cadena de suministro», dijo. «Todo lo que interactúa con esa zona o la cruza debe ser altamente monitoreado y controlado para garantizar que un compromiso pueda contenerse rápida y fácilmente».

La motivación del TeamPCP

TeamPCP, como cualquier cibercriminal prolífico, ha captado una gran atención por parte de los cazadores de amenazas desde que surgió a finales de 2025. Google atribuye la actividad a un operador principal.

La compañía dijo que rastreó las conexiones de direcciones IP residenciales y móviles de TeamPCP hasta Sudáfrica, lo que indica que el operador principal estuvo ubicado allí durante al menos algunos de sus ataques.

«No creemos que exista un grupo central establecido, al menos no todavía, y que gran parte de esto ha sido realizado por un individuo», dijo Goody. Google se negó a nombrar al operador principal ni a confirmar que conoce la verdadera identidad de la persona.

Palo Alto Networks dijo que el administrador central de TeamPCP utiliza el identificador «ResoluteXBF» en múltiples plataformas. La firma de ciberseguridad también está rastreando a dos miembros principales adicionales: «diencracked» y «Shinigami».

Si TeamPCP está dirigido principalmente por una sola persona, las fuerzas del orden tienen una rara oportunidad de lograr un impacto duradero con un solo arresto.

TeamPCP ha colaborado con otros ciberdelincuentes, pero la mayoría de esas asociaciones duraron poco y terminaron en una disputa pública o no lograron despegar de manera significativa, dijo Goody.

Los investigadores han vinculado a TeamPCP con equipos de extorsión, foros de la web oscura y afiliados, incluidos Lapsus$, ShinyHunters, Vect, DragonForce, BreachForums y «HasanBroker». TeamPCP enumeró alrededor de 4.000 repositorios de códigos privados en un foro de la web oscura con un precio inicial de 95.000 dólares.

Las acciones hasta la fecha, incluido el comportamiento impredecible, indican motivaciones más allá del beneficio financiero y un “claro deseo de notoriedad”, dijo Goody. «Parece que les gusta crear el caos».

Quist llega a la misma conclusión de su investigación de meses, señalando que alienta a otros ciberdelincuentes a participar en la acción, ofreciendo en un momento recompensas financieras por el mayor ataque a la cadena de suministro de software.

TeamPCP no está involucrado en pagos de extorsión, dijo. «Estos actores están más interesados ​​en la credibilidad callejera clandestina que están ganando» y en «causar tanto daño y caos como sea posible».

Las víctimas abundan, pero la exposición es limitada

TeamPCP ha sido notablemente ruidoso, inyectando de manera oportunista malware en software de código abierto con el fin de robar credenciales para entornos Kubernetes, Amazon Web Services, Microsoft Azure, Google Cloud y muchos otros servicios conectados.

La lista de víctimas reclamadas por el grupo es asombrosa: Checkmarx, Bitwarden, LiteLLM, Telnyx, Mercor AI, PyTorch Lightning, AntV, SAP, GitHub, TanStack, UiPath, MistralAI, Microsoft DurableTask, Red Hat y Nx Console.

La colección completa de paquetes comprometidos o envenenados por TeamPCP hasta la fecha representa aproximadamente 500 millones de descargas semanales combinadas, según Quist.

Si bien la amplitud del posible compromiso posterior que surge de esas descargas es sustancial, muchos puntos finales infectados con esos paquetes plagados de malware no están expuestos a Internet y son menos susceptibles a los ataques, agregó.

«No creo que vaya a haber un número muy grande de víctimas», dijo Quist. «Habrá muchas personas que podrían verse comprometidas y tener paquetes potencialmente vulnerables en su entorno, pero eso no significa necesariamente que estén en una posición explotable».

Si bien estos incidentes han acaparado los titulares, TeamPCP no ha acumulado pagos tan grandes como otros ciberdelincuentes. Sin embargo, el impacto reputacional más amplio que ha provocado es enorme.

TeamPCP ha reclamado públicamente más de 10.000 víctimas y alrededor de 90.000 dólares en extorsiones, según Quist.

«Puede que no estén ganando mucho dinero, pero están causando un gran impacto», dijo Goody. «Sus campañas han sido muy disruptivas».

Cómo el modelo operativo de TeamPCP apunta al desarrollo

La lista de víctimas de TeamPCP ha crecido a medida que sus repositorios de código abierto secuestrados en npm, PyPI, GitHub y otras herramientas de desarrollo subcontratadas que se incorporan al código ascendente que se ejecuta en entornos de producción.

Las computadoras portátiles de los desarrolladores y otros puntos finales asignados para instalar, construir y publicar software contienen ampliamente claves y acceso al código fuente que crean objetivos de cadena de suministro increíblemente valiosos para los atacantes, explicó Amitai Cohen, jefe del equipo de inteligencia de vectores de ataque en Wiz, durante una presentación en junio sobre TeamPCP en SleuthCon en Arlington, Virginia.

El grupo se dirige a los corredores de CI, que son sistemas automatizados que crean, prueban y publican código. TeamPCP inyecta malware en los repositorios de código que mantienen estos corredores. Cuando otros desarrolladores introducen ese código en sus propios sistemas, sin saberlo, descargan el malware junto con él.

Algunos de estos artefactos, incluidas las bibliotecas de Python, los registros npm y las acciones de GitHub, son descargados casi de inmediato por miles o millones de desarrolladores que han configurado sus ejecutores para que obtengan consistentemente la última versión, según Cohen. «Nosotros, como industria de la seguridad, les hemos enseñado que eso es lo correcto. Quiere utilizar la última versión porque quiere estar protegido contra vulnerabilidades y, obviamente, quiere beneficiarse de todas las funciones más recientes».

Ese instinto es exactamente lo que explota TeamPCP. Al comprometer el flujo de trabajo de CI/CD de una empresa, el grupo obtiene acceso a todos los usuarios intermedios que extraen automáticamente ese código infectado. “Esto es lo que permite [TeamPCP] «Para aprovechar el acceso inicial a algún paciente cero, alguna empresa que tenía una vulnerabilidad en su flujo de trabajo de CI/CD, para obtener acceso a sus usuarios intermedios», dijo Cohen. «Así es como funciona la cadena de suministro de software. Todo tiene dependencias sobre dependencias sobre dependencias”.

Algunos de los paquetes comprometidos por TeamPCP estuvieron activos durante casi 13 horas, pero los profesionales de la seguridad han respondido identificando ataques de inyección de código mucho más rápido ahora, retirando algunos repositorios comprometidos en 15 minutos, dijo Ben Read, director de inteligencia estratégica de Wiz.

Las operaciones del grupo de amenaza siguen siendo de alto ritmo. TeamPCP infecta nuevos paquetes de software casi a diario, valida los compromisos y captura datos confidenciales en 24 horas, según los investigadores de Wiz.

El grupo de amenazas ha evolucionado constantemente sus tácticas, desarrollando cargas útiles en JavaScript y Python mientras se propaga desde archivos locales a interfaces de programación de aplicaciones de Kubernetes y kits de desarrollo de software incluidos. Más recientemente, ha estado robando credenciales mediante protocolos personalizados.

Las ambiciones del grupo se han expandido más allá de sus propios ataques. TeamPCP también es responsable de una pieza de malware autorreplicante conocida como Mini Shai-Hulud, que infectó cientos de paquetes de software en registros de código abierto en ataques consecutivos el mes pasado. Un afiliado de TeamPCP publicó el código fuente completo del malware en GitHub el mes pasado y alentó a otros ciberdelincuentes a utilizarlo para sus propias campañas.

«TeamPCP busca volumen. No discriminan, no necesariamente intentan ser sigilosos o maximizar el retorno de la inversión. Buscan una estrategia que incluya todo lo anterior», dijo Read durante la presentación de Sleuthcon.

Las brechas defensivas crean aperturas para el ataque

La ola de ataques de TeamPCP también ha puesto de relieve lo difícil que es para las organizaciones revocar secretos comprometidos. Múltiples víctimas han experimentado infecciones recurrentes, a veces siendo víctimas de TeamPCP tres veces en un mes, porque no rotaron los secretos correctamente, dijo Cohen.

En esencia, estos ataques resaltan una compensación directa que las organizaciones aceptan cuando actualizan el software rápidamente para corregir vulnerabilidades, pero aprenden que hacerlo demasiado rápido podría exponerlas a registros ilegítimos que contienen malware.

TeamPCP se ha centrado en lo que Aboukhadijeh describe como un “bien público”, registros de código abierto que nunca fueron perfectos pero que eran ampliamente confiables y rara vez se convertían en un punto de entrada para ataques a la cadena de suministro.

La instalación rápida de software de código abierto es una de las cosas más peligrosas que una organización puede hacer en este momento, dijo, y agregó que hay aproximadamente una posibilidad entre 10 de que cualquier paquete instalado por una organización pueda desencadenar un ataque activo.

TeamPCP ha comprometido escáneres de seguridad, administradores de contraseñas, herramientas de automatización, software de visualización de datos e infraestructura CI/CD en varios entornos.

Y ha obtenido un tesoro de credenciales y otros datos confidenciales de las víctimas.

Investigadores como Cohen en Wiz, que han estado siguiendo esta ola de ataques desde el principio, se están acercando a un punto de ruptura.

«Esto también es demasiado duro para nosotros. Estamos muy cansados. Estoy seguro de que mucha gente que trabaja en este espacio problemático está muy cansada y se ha vuelto insostenible», dijo Cohen.

«No se puede seguir existiendo en un mundo en el que te despiertas cada mañana y algún paquete súper prevalente está comprometido y todo el mundo va a utilizarlo como si nada», añadió. «Necesitamos empezar a tomar esto un poco más en serio».

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

Microsoft confirma RoguePlanet Defender Zero-Day y dice que el parche está en desarrollo – CYBERDEFENSA.MX

Microsoft ha revelado formalmente que está trabajando para lanzar un parche para abordar un Defender de día cero con nombre en código RoguePlanet.

A la vulnerabilidad ahora se le ha asignado el identificador CVE. CVE-2026-50656 (Puntuación CVSS: 7,8), y el gigante tecnológico lo describe como una falla de escalada de privilegios.

«Microsoft es consciente de una elevación de privilegios en el motor de protección contra malware de Microsoft en Microsoft Defender, denominado públicamente ‘RoguePlanet’», dijo la compañía. «Estamos trabajando para proporcionar una actualización de seguridad de alta calidad que aborde esta vulnerabilidad».

El desarrollo se produce casi una semana después de que un investigador de seguridad llamado Chaotic Eclipse (también conocido como Nightmare-Eclipse) publicara RoguePlanet, calificando el exploit como un caso de condición de carrera que otorga a los atacantes un shell con privilegios a nivel de SISTEMA.

Ciberseguridad

«El exploit es una condición de carrera, por lo que es una cuestión de éxito o fracaso», señaló el investigador. «He logrado obtener una tasa de éxito del 100 % en algunas máquinas, mientras que en otras tenía dificultades para funcionar».

En una actualización compartida el martes, el investigador agregado: «Olvidé agregar una cosa, sorprendentemente, el PoC para RoguePlanet funciona independientemente de si la protección en tiempo real está activada o no, lo cual es gracioso. Creo que incluso funciona en el caso del modo pasivo, pero no estoy realmente seguro, no lo he probado».

Microsoft le dijo a The Hacker News la semana pasada que está al tanto de la vulnerabilidad reportada y que está «investigando activamente la validez y potencial aplicabilidad de estas afirmaciones».

RoguePlanet es la cuarta vulnerabilidad de Defender revelada por Chaotic Eclipse después de BlueHammer (CVE-2026-33825), UnDefend (CVE-2026-45498) y RedSun (CVE-2026-41091), todas las cuales desde entonces han sido parcheadas por Microsoft.

El ataque de desarrollo de GitHub con un solo clic permite a los atacantes robar tokens completos de OAuth de GitHub – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado un ataque con un solo clic a través de Microsoft Visual Studio Code (VS Code) que permite robar el token de GitHub de un usuario.

«Con solo hacer clic en un enlace, es posible que un atacante robe un token de GitHub que puede leer y escribir en sus repositorios, incluidos los privados», dijo el investigador de seguridad Ammar Askar. dicho.

GitHub admite una función llamada GitHub.dev que corre como un editor de código fuente ligero basado en web en la zona de pruebas del navegador web iniciando un entorno VS Code. Permite a los usuarios enviar solicitudes de extracción y realizar confirmaciones.

Ciberseguridad

«Esta funcionalidad se logra mediante la PUBLICACIÓN de github.com a través de un token OAuth en github.dev que le permite interactuar con GitHub en su nombre», dijo Askar. «El token no tiene como alcance el repositorio particular con el que interactuó, lo que significa que tiene acceso completo a todos los demás repositorios a los que tiene acceso».

En pocas palabras, la vulnerabilidad permite a los atacantes instalar extensiones maliciosas de VS Code que roban tokens GitHub OAuth cuando se pasan a GitHub.dev mediante la explotación de un mecanismo de paso de mensajes entre la ventana principal de VS Code y vistas web. Las vistas web se utilizan para representar vistas previas de Markdown o editar cuadernos de Jupyter.

Específicamente, el exploit ejecuta JavaScript malicioso dentro de una vista web que no es de confianza para simular pulsaciones de teclas (también conocidas como eventos de pulsación de teclas) en la ventana principal del editor, abre la paleta de comandos activando «Ctrl+Shift+P» e instala una extensión controlada por el atacante que extrae el token GitHub OAuth enviado a GitHub.dev y consulta la API de GitHub para enumerar todos los repositorios privados a los que puede acceder la víctima.

Vale la pena señalar que el enfoque también aprovecha una característica de VS Code llamada extensiones de espacio de trabajo local que permite instalar una extensión directamente sin presentar ningún adicional mensaje de diálogo de confianza siempre y cuando esté ubicado en la carpeta «.vscode/extensions» dentro de ese espacio de trabajo, evitando efectivamente la verificación de confianza del editor.

Ciberseguridad

«Sin embargo, esto es sólo un pequeño inconveniente, una de las cosas que las extensiones pueden hacer como parte de su paquete.json es contribuir con combinaciones de teclas adicionales a VS Code», explicó el investigador. «Dado que podemos activar combinaciones de teclas de manera confiable, podemos simplemente agregar una combinación de teclas para cualquier comando de VS Code que queramos, como instalar una extensión y omitir la verificación del editor confiable».

El investigador también señaló que GitHub era notificado de la vulnerabilidad el 2 de junio de 2026, una hora después de la cual los detalles del problema se hicieron públicos, citando a Microsoft manejo de Errores relacionados con VS Code en el pasado. Al momento de escribir este artículo, Microsoft reconoció la vulnerabilidad y señaló que está trabajando en una solución.

«Para aclarar, este problema no afecta a VS Code Desktop», dijo Alexandru Dima, gerente de ingeniería de software asociado de Microsoft.

RAMPART y Clarity de código abierto de Microsoft para proteger a los agentes de IA durante el desarrollo – CYBERDEFENSA.MX

Microsoft ha presentado dos nuevas herramientas de código abierto llamadas MURALLA y Claridad para ayudar a los desarrolladores a probar mejor la seguridad de los agentes de inteligencia artificial (IA).

MURALLAabreviatura de Risk Assessment and Measurement Platform for Agentic Red Teaming, funciona como un marco de pruebas de seguridad nativo de Pytest para escribir y ejecutar pruebas de seguridad para agentes de IA, que cubren problemas adversarios y benignos, así como varias categorías de daños.

Los usuarios pueden escribir casos de prueba para atacar o sondear a un agente de IA para explorar posibles violaciones de seguridad, como inyecciones cruzadas, donde datos no confiables llegan a un sistema de IA indirectamente a través de una fuente de datos (por ejemplo, correo electrónico, archivo o página web) procesada por este, o regresiones de comportamiento no intencionadas y exfiltración de datos.

RAMPART luego evalúa el resultado de esas pruebas e informa los resultados. Todo lo que necesita es un adaptador que conecte un agente al conjunto de pruebas. La herramienta se basa en PyRIT (abreviatura de Python Risk Identification Tool), que Microsoft lanzó hace más de dos años como una forma de probar sistemas de inteligencia artificial.

Claridadpor otro lado, ha sido descrito por el gigante tecnológico como una «caja de resonancia estructurada» para ayudar a los desarrolladores a llegar al enfoque correcto incluso antes de escribir una sola línea de código. Es un «socio de pensamiento de IA que retrocede», guiándolos a través de la aclaración de problemas, la exploración de soluciones, el análisis de fallas y el seguimiento de decisiones.

Ciberseguridad

Al hacer públicas estas herramientas, Microsoft dijo que la idea es abordar por qué ciertas decisiones se incorporan en una etapa temprana del desarrollo de software para que cualquier problema potencial (por ejemplo, el acceso de un agente a una herramienta) se aborde mucho antes de que se construya el sistema.

«Queríamos brindarles a los gerentes de producto e ingenieros una manera de poner a prueba sus suposiciones al inicio de un proyecto, cuando cambiar de rumbo es barato y la conversación correcta puede ahorrar meses de retrabajo». Ram Shankar Siva Kumarun Data Cowboy y fundador del AI Red Team de Microsoft, dicho en un blog compartido con The Hacker News.

Microsoft señaló que una motivación secundaria detrás de invertir en estas herramientas es hacer que los incidentes sean reproducibles y las mitigaciones verificables y escalar los aprendizajes de los ejercicios de equipos rojos convirtiéndolos en activos de ingeniería ejecutables.

«Mientras que PyRIT se optimiza para el descubrimiento de cajas negras por parte de los investigadores de seguridad después de que se construye el sistema, RAMPART se construye para los ingenieros a medida que se construye el sistema», agregó Siva Kumar. «La claridad ayuda a los equipos a aclarar la intención del diseño y capturar las suposiciones. Juntos, estos enfoques hacen que la seguridad de la IA pase de una revisión única a un conjunto de artefactos vivos que los desarrolladores pueden utilizar durante todo el ciclo de vida».

El ataque a la herramienta de desarrollo de software axios amenaza con compromisos generalizados

Un hacker entregó brevemente malware esta semana a través de un popular proyecto de código abierto para desarrolladores de software que tiene aproximadamente 100 millones de descargas semanales, lo que aumenta la posibilidad de que los compromisos se propaguen ampliamente a través de un ataque a la cadena de suministro.

Axios es una biblioteca cliente de JavaScript que se utiliza en solicitudes web. El atacante desconocido secuestró la cuenta npm (npm es un administrador de paquetes para JavaScript) del principal mantenedor de axios y luego publicó versiones maliciosas de axios con troyanos de acceso remoto en npm. Eso sucedió el domingo por la noche hasta el lunes por la mañana, empresa de ciberseguridad. Cazadora dijo, antes de que se sacaran las versiones envenenadas.

Aikidootra empresa de seguridad, lo calificó como «uno de los ataques a la cadena de suministro de npm más impactantes jamás registrados». Los investigadores de un gran número de empresas cibernéticas han hecho sonar las alarmas sobre el ataque, entre ellas Paso de seguridad, Enchufe, Laboratorios Endor y otros.

Según Step Security, las versiones maliciosas “axios@1.14.1” y “axios@0.30.4” inyectan una nueva dependencia de software, Plain-crypto-js@4.2.1, que actúa como cargador del malware. Está dirigido a dispositivos MacOS, Windows y Linux.

Pero, aunque los investigadores lo describen como malware, señalan que «no hay líneas de código malicioso dentro del propio axios». Más bien, el software simplemente funciona según lo diseñado o rediseñado.

“Ambas versiones envenenadas inyectan una dependencia falsa… nunca importada a ninguna parte de la fuente de axios, cuyo único propósito es ejecutar un [post installation] script que implementa un troyano de acceso remoto multiplataforma”, escribió Ashish Kurmi, director de tecnología y fundador de Step Security.

Feross Aboukhadijeh, director ejecutivo y fundador de Socket, calificó la situación como “un compromiso vivo” con un amplio radio potencial de explosión.

«Este es un software malicioso instalador de la cadena de suministro de libros de texto», Aboukhadijeh escribió el lunes X por la nochey agrega sobre las versiones maliciosas que «Cada instalación de npm que extrae la última versión está potencialmente comprometida en este momento».

El paquete de software introducido por las versiones maliciosas de axios tiene cargas útiles integradas que evaden los métodos estáticos de análisis de ciberseguridad y confunden a los revisores humanos, y elimina y cambia el nombre de los artefactos para destruir la evidencia forense.

Aboukhadijeh dio consejos contundentes a cualquiera que haya descargado o usado axios al menos durante la semana pasada.

«Si usa axios, fije su versión inmediatamente y audite sus archivos de bloqueo», escribió. «No actualice».

Kurmi describió el ataque como de “precisión”, y señaló que la dependencia maliciosa se realizó con menos de 24 horas de anticipación y que ambas versiones maliciosas fueron envenenadas en la misma hora.

Dado el período de tiempo durante el cual las versiones maliciosas de axios estuvieron en línea, eso podría traducirse en aproximadamente 600.000 descargas, dijo Joshua Wright, miembro de la facultad del Instituto SANS y director técnico senior de Counter Hack Innovations.

«Esa es una gran cantidad de compromisos, y tan pronto como se instala el software, se eliminan las credenciales de acceso, por lo que ahora los actores de amenazas podrían recurrir a AWS y a otros paquetes de GitHub a través de claves de GitHub eliminadas, y esa es la parte que es realmente difícil de articular», dijo a CyberScoop, advirtiendo que las consecuencias podrían extenderse durante semanas. «Vamos a ver más y más historias sobre personas que se dan cuenta de que han sido violadas, ya que hoy están tratando de descubrir cuál es el impacto de eso».

El ataque sigue de cerca a otros casos de segmentación orientada al desarrollador.

Escrito por Tim Starks y Derek B. Johnson