Dos paquetes joyfill npm comprometidos ejecutan RAT cuando se importan a Node.js – CYBERDEFENSA.MX

Las versiones beta de dos paquetes npm en el espacio de nombres @joyfill se han visto comprometidas para entregar un troyano de acceso remoto (RAT) asociado con el DESARROLLADOR#POPPER familia de programas maliciosos.

La lista de paquetes afectados es la siguiente:

  • @joyfill/layouts@0.1.2-2773.beta.0
  • @joyfill/components@4.0.0-rc24-2773-beta.4

Los dos paquetes «contienen un implante de JavaScript en el momento de la importación que resuelve el código cifrado a través de transacciones de Tron, Aptos y BNB Smart Chain», afirmó Socket. dicho en un análisis.

A diferencia de otros paquetes maliciosos que se activan mediante un enlace de ciclo de vida de npm, el implante entregado como parte de las bibliotecas de JavaScript se ejecuta cuando Node.js carga el punto de entrada del paquete CommonJS.

Vale la pena señalar que el uso de una estructura de resolución de múltiples cadenas de bloques que comprende Tron, Aptos y BNB Smart Chain (BSC) se ha vinculado a un grupo de amenazas rastreado como PolinRider, que se considera relacionado con Contagious Interview.

Ciberseguridad

A principios de este mes, Checkmarx y OpenSourceMalware destacaron un conjunto de paquetes npm maliciosos denominados colectivamente ViteVenom dirigidos al ecosistema de herramientas frontend de Vite utilizando la misma infraestructura de comando y control (C2) basada en blockchain para entregar una RAT con shell inverso, recolección de credenciales, exfiltración de archivos e inyección persistente de puerta trasera.

El implante consta de dos secuencias paralelas de acciones:

  • Una rama en proceso que conduce a una carga útil recuperada de JavaScript de 77 KB con similitudes con la familia de malware DEV#POPPER.
  • Una rama secundaria que inicia un proceso Node.js separado y solicita una carga útil de arranque independiente desde el 23.27.13.[.]43, descifra la respuesta y la evalúa.

Una vez que se carga el paquete, inicia un envío basado en blockchain que obtiene un hash de transacción BSC de la última transacción saliente de una dirección Tron codificada. Si este paso falla, consulta una cuenta de Aptos como alternativa para recuperar la transacción BSC y, a partir de ella, descifra y extrae el código JavaScript y lo ejecuta.

Tanto las sucursales en proceso como las independientes utilizan un conjunto distinto de direcciones de billetera, cuentas y transacciones para Tron, Aptos y BSC. El uso de blockchain también significa que ofrece resiliencia operativa y permite cambiar cargas útiles sin tener que publicar una nueva versión de los paquetes.

La primera carga útil en proceso es un cargador de JavaScript que emplea el método de resolución blockchain para recuperar un malware de segunda etapa llamado «clientCode». El proceso separado, por otro lado, consulta la dirección IP antes mencionada para obtener y ejecutar código JavaScript.

«Esta es una rama de entrega redundante, no una alternativa inofensiva», explicó Socket. «Está separado del proceso de importación de Node.js y puede continuar después de que salga un comando de compilación, prueba o CLI».

La carga útil final «clientCode» está muy ofuscada y funciona como una RAT de Node.js con las siguientes características, al tiempo que evita la ejecución en máquinas de desarrollo, CI o sandbox con los nombres de host github-runner, buildbot, buildkitsandbox y microsoft-standard-WSL2:

  • Cargar archivos al host de carga configurado
  • Recuperar JavaScript adicional
  • Recopile detalles básicos del anfitrión
  • Enviar mensajes de registro de estado
  • Lea los datos del portapapeles a través de PowerShell en Windows, pbpaste en macOS y xclip o xsel en Linux

Se han asociado dos cargas útiles con el proceso separado: el RAT «clientCode» y un ladrón de información de Python que puede recopilar una amplia gama de datos de hosts comprometidos. Se considera una iteración del malware OmniStealer, cuyos detalles fueron destacado por primera vez por eSentire a principios de abril.

Los datos recopilados por el malware se encuentran a continuación:

  • Información sobre el entorno y el anfitrión
  • Datos del Administrador de credenciales de Windows y del Servicio secreto de Linux
  • Datos de los navegadores Chromium y Firefox
  • Almacenamiento de extensiones de navegador para billeteras y administradores de contraseñas
  • credenciales de git
  • Configuración de la CLI de GitHub
  • Registros de escritorio de GitHub
  • Almacenamiento de código de Microsoft Visual Studio

Socket le dijo a The Hacker News que tanto ViteVenom como la última colección de paquetes npm están conectados a la misma operación en curso por parte de actores de amenazas norcoreanos, en lugar de representar campañas separadas.

Ciberseguridad

Según la empresa de seguridad de aplicaciones, se dice que ambas versiones maliciosas fueron publicadas por la misma identidad npm usando Node.js 18.20.0 y npm 10.5.0, con el código presente en el momento del paquete. Dicho esto, actualmente no está claro si esta inyección de código fuente se logró luego de comprometer una estación de trabajo de desarrollador, un repositorio de código fuente, un entorno de CI o credenciales de publicación.

Se recomienda a los desarrolladores que hayan instalado las versiones afectadas que las eliminen de los archivos de bloqueo, cachés, espejos internos, imágenes de compilación y artefactos de implementación, las fijen a una versión verificada y roten las credenciales del proceso Node.js afectado.

«La versión @joyfill/layouts debe ser tratada como capaz de ejecutar código arbitrario en el contexto de cualquier proceso que lo cargue», dijo Socket. «Esto incluye entornos de desarrollo, ejecutores de CI, herramientas de prueba, renderizado del lado del servidor y compilaciones».

«El código final recuperado puede recopilar información del host, establecer un canal de control remoto Socket.IO, ejecutar JavaScript o comandos de shell suministrados, cargar archivos, leer datos del portapapeles y modificar archivos que pertenecen a herramientas de desarrollo».

Tengu Botnet reinicia dispositivos Linux comprometidos cuando los defensores interrumpen su proceso – CYBERDEFENSA.MX

Una nueva botnet derivada de Mirai llamada Tengu puede utilizar el dispositivo de vigilancia de hardware de un dispositivo Linux comprometido para activar un reinicio cuando los defensores finalizan su proceso principal.

Si eso sucede, los otros mecanismos de persistencia de Tengu tendrán otra oportunidad de relanzarlo. Nozomi Networks Labs observó que el gotero llegaba a sus honeypots a través de la fuerza bruta de la credencial Telnet.

Tengu admite 25 métodos distribuidos de denegación de servicio (DDoS). También puede ejecutar un proxy SOCKS5, ejecutar comandos de shell y recopilar datos del sistema y de la red. El malware puede actualizarse y recuperar cargas útiles adicionales de formato ejecutable y vinculable (ELF) o paquete de Android (APK).

Nozomi enumeró ejemplos de arquitectura específica para i386, amd64, MIPS, ARM, PowerPC y m68k. El informe no identifica ningún proveedor o modelo de dispositivo específico. Tampoco nombra ningún operador, recuento de infecciones ni víctimas de DDoS del mundo real. Muestra lo que Tengu puede hacer, no hasta dónde se ha extendido.

Los defensores deberían comenzar eliminando la exposición a Internet de Telnet y otros servicios administrativos innecesarios y reemplazando las credenciales predeterminadas. Nozomi también recomienda actualizar el firmware, segmentar las redes de Internet de las cosas (IoT) y revisar los servicios systemd, los scripts de inicio, los archivos de inicio del shell y las rutas relacionadas con cron antes de devolver al servicio un dispositivo sospechoso.

Ciberseguridad

Laboratorios de redes Nozomi publicó su análisis el 27 de julio de 2026. Nozomi dijo que la persistencia y el código de autodefensa de Tengu lo hicieron destacar entre las muestras derivadas de Mirai que rastrea. «La mayoría de las variantes de Mirai implementan pocas o ninguna de estas capacidades de autodefensa», dijeron los investigadores.

Una vez en ejecución, el bot bifurca un guardián independiente que verifica el proceso principal de malware cada 60 segundos y reinicia el binario instalado si se detiene. También puede crear un servicio systemd falso, agregar scripts init y RC, alterar los archivos de inicio del shell y marcar su binario instalado como inmutable. Hay una rutina de persistencia basada en cron, pero Nozomi dijo que su referencia a /proc/self/exe parece inacabada o rota.

Un segundo mecanismo abusa del mecanismo de vigilancia del hardware del dispositivo. Un trabajador de fondo se hace pasar por [kworker/0:0]vuelve a abrir el dispositivo de vigilancia si está disponible, lo activa con un tiempo de espera de aproximadamente 30 segundos y envía señales de mantenimiento de actividad solo mientras el proceso principal de malware permanece activo. Finalice el proceso y el perro guardián dejará de recibir alimentación, lo que permitirá que el dispositivo se reinicie. Los otros mecanismos de persistencia de Tengu pueden entonces intentar relanzarlo.

Tengu también incluye una lista codificada de utilidades de reinicio y apagado. Sobrescribe sus encabezados ELF con la cadena ELFOOD, lo que puede interferir con los comandos normales que los defensores pueden usar para reiniciar o apagar de forma segura un dispositivo comprometido.

La muestra analizada se configuró para comunicarse con un servidor de comando y control (C2) en 64[.]89.163.8 a través del puerto TCP 9931. El registro, el tráfico de latidos y la salida de comandos se envían en texto sin formato, mientras que los comandos y actualizaciones del servidor utilizan un esquema de cifrado autenticado personalizado similar a ChaCha20/Poly1305.

Tengu también puede obtener un identificador de contenido proporcionado por C2 desde una puerta de enlace del Sistema de archivos interplanetario (IPFS) en el mismo servidor, validar el resultado como ELF o APK y ejecutarlo o instalarlo.

Nozomi evaluó que la ruta APK probablemente apunta a dispositivos mal protegidos Cajas de TV con Android o dispositivos similares, pero no documentaron víctimas confirmadas de Android.

Ciberseguridad

URLhaus grabado de forma independiente 17 URL de malware en 64[.]89.163.8 a partir del 17 de junio de 2026. Los registros incluían un script de shell, varios archivos ELF etiquetados como Mirai y un APK. Las entradas de carga útil más recientes de URLhaus se vieron por primera vez el 7 de julio y las 17 URL estaban fuera de línea el 28 de julio.

URLhaus no identifica los archivos como Tengu. Hasta el 28 de julio, ninguno de los hashes SHA-256 enumerados en su registro de host coincidía con el hash de muestra publicado por Nozomi. Por lo tanto, su telemetría solo confirma alojamiento malicioso relacionado con Mirai en la dirección.

The Hacker News se comunicó con Nozomi Networks para obtener detalles adicionales sobre la escala observada de Tengu, el estado de la infraestructura y el enlace de la muestra, y actualizará la historia con cualquier respuesta.

Ni Nozomi ni URLhaus establecen si se podía acceder al servicio C2 en el puerto 9931 o a la puerta de enlace IPFS en el puerto 8080. El estado de URLhaus se aplica únicamente a las URL de descarga enumeradas. Nozomi tampoco dice si el servidor C2 configurado en 64[.]89.163.8:9931 emitió algún comando.

¿Qué cambia cuando su cadena de suministro de software incluye IA escribiendo su código? – CYBERDEFENSA.MX

La seguridad de la cadena de suministro de software ya era bastante difícil. Luego, la IA se unió al proceso de construcción.

Durante cinco años, la «seguridad de la cadena de suministro de software» significó una pregunta: ¿qué hay en su código? ¿Qué paquetes de código abierto, qué versiones, qué dependencias transitivas de tres capas de profundidad que nadie eligió a propósito?

Utilidades SolarWinds, Log4Shell y XZ Todos enseñaron la misma lección: el riesgo reside menos en el código que escribe un equipo y más en todo lo que lo produce. Shai-Hulud, la campaña de paquetes maliciosos autopropagados que se difundió a través de las cadenas de herramientas de los desarrolladores este año, enseñó al siguiente: saber qué hay en su código todavía es necesario, pero ya no es suficiente.

En los aproximadamente 20 meses transcurridos desde el lanzamiento del Protocolo de contexto modelo, las herramientas, los modelos y la infraestructura de inteligencia artificial que los rodea se han convertido en partes que soportan la carga de cómo se construye, implementa y ejecuta el software. El código lo escriben los agentes. Los paquetes son recogidos por herramientas autónomas que deciden si son necesarios. Las indicaciones se han convertido en una entrada real para la compilación, lo que significa que son una forma real de comprometerla. Nada de esto estaba dentro del alcance cuando se diseñaron la mayoría de los programas de seguridad.

Dónde se movió realmente el riesgo

Es tentador tratar el código generado por IA como simplemente más código, ejecutarlo a través de los mismos escáneres y considerarlo cubierto. Eso malinterpreta hacia dónde se movió el riesgo.

La cuestión de la procedencia que siempre ha definido la seguridad de la cadena de suministro (de dónde viene y si puedo confiar en ella) ahora se aplica al modelo, el agente y las herramientas, no sólo al artefacto. Un asistente de codificación de IA sugiere una dependencia y un desarrollador la acepta sin que el paquete cruce nunca el modelo de amenaza de un humano. Un agente autónomo busca una herramienta a través de MCP para completar una tarea, y esa herramienta busca otra. Un mensaje, elaborado por un atacante y colocado en algún lugar donde el modelo pueda leerlo, dirige lo que se escribe o lo que se introduce.

Validar el código generado por IA antes de confirmarlo es algo que está en juego. El problema más difícil es gobernar a los agentes que escriben y las herramientas que utilizan.

Cómo se ve un programa cuando la IA está dentro de su alcance

A los equipos con los que trabajamos no les faltan hallazgos. Se están ahogando en ellos. Agregar «escanear también la salida de IA» a una cola ya sobrecargada hace que la pila de alertas sea más alta, no que el programa sea más fuerte. Dos cosas cambian cuando la IA está realmente dentro de su alcance.

En primer lugar, el linaje debe extenderse a todo lo que entra en el proceso, incluidos los modelos y agentes. Un enfoque es extender el linaje al propio proceso: rastrear la actividad, la procedencia y los cambios de configuración desde el primer compromiso hasta el tiempo de ejecución, y aplicar el mismo rigor a los modelos y agentes que a cualquier otra dependencia.

En segundo lugar, la priorización debe basarse en la explotabilidad real, no en el volumen. Correlacionar los hallazgos con el contexto del tiempo de ejecución con lo que realmente se puede alcanzar es la diferencia entre una lista de vulnerabilidades y una cadena viable de explotación. Esa diferencia importa más, no menos, una vez que un agente puede generar mil líneas de código plausible antes del almuerzo.

Esta es la brecha que Gartner formalizó en junio cuando publicó el Cuadrante Mágico inaugural para la seguridad de la cadena de suministro de software: el reconocimiento del mercado de que un problema que los equipos han estado defendiendo sin una línea presupuestaria es ahora algo que vale la pena evaluar sistemáticamente.

El 22 de julio, los investigadores de OX organizarán un seminario web: Cómo la IA está remodelando la seguridad de la cadena de suministro tal como la conocemos – recorrer nuevas investigaciones junto con los líderes de seguridad que realizan este trabajo desde adentro. Cubriremos cómo la integración de la IA cambió la superficie de ataque, los hallazgos de la primera mirada sistemática a los servidores MCP en la naturaleza y cómo se ve realmente un programa de seguridad de la cadena de suministro cuando la IA está dentro del alcance en lugar de incorporarse después.

Regístrate aquí. Traiga preguntas difíciles.

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

Cuando la identidad es el camino del ataque – CYBERDEFENSA.MX

Considere una clave de acceso almacenada en caché en una sola máquina con Windows. Llegó allí de la misma manera que lo hacen la mayoría de las credenciales almacenadas en caché: un usuario inició sesión y la clave se almacenó automáticamente. Comportamiento estándar de AWS. Nadie configuró mal nada ni violó una política. Sin embargo, esa única clave, a la que podía acceder fácilmente un atacante de ligas menores, podría haber abierto un camino a alrededor del 98% de las entidades en el entorno de nube de la empresa: casi todas las cargas de trabajo críticas de las que dependía el negocio.

Esta exposición del mundo real se detectó antes de que un atacante pudiera utilizarla. Pero la conclusión es clara: La identidad misma, y ​​cada permiso que conlleva, se ha convertido en la ruta de ataque.

Su entorno se basa en la identidad. Active Directory, proveedores de identidades en la nube, cuentas de servicio, identidades de máquinas y agentes de IA: todos ellos cuentan con permisos que abarcan sistemas y límites de confianza. Una única credencial robada le otorga al atacante una identidad legítima, junto con todos los permisos asociados.

A pesar de esto, la mayoría de los programas de seguridad todavía tratan la identidad como un control perimetral, algo que se debe proteger mediante políticas de autenticación y acceso. Sin embargo, el verdadero riesgo comienza dentro de la puerta principal. Una vez que un atacante tiene un punto de apoyo, la identidad es lo que le permite avanzar, cruzar fronteras y llegar a activos críticos. Porque la identidad no es un perímetro – es una autopista que atraviesa cada capa de su entorno.

En este artículo, veremos cómo las credenciales almacenadas en caché, los permisos excesivos y las asignaciones de roles olvidadas pueden convertirse en rutas de ataque en entornos híbridos, y por qué siguen faltando las herramientas diseñadas para detectarlos.

El camino del ataque pasa por la identidad

La clave de acceso almacenada en caché de ese escenario inicial es sólo un ejemplo de un fenómeno mucho mayor. En entornos híbridos, la identidad

Una membresía de grupo de Active Directory que nadie revisó le brinda a un atacante en un punto final minorista una ruta directa al dominio corporativo. Un rol de SSO de desarrollador aprovisionado para una migración a la nube mantiene sus permisos mucho después de que finaliza el proyecto, lo que brinda a cualquiera que comprometa esa identidad una ruta de cuatro pasos desde el acceso de desarrollador hasta el administrador de producción. Lo que hace que estos ejemplos del mundo real sean tan peligrosos es cómo se conectan. Esa credencial almacenada en caché en el punto final minorista generó una función con privilegios excesivos en Active Directory, lo que generó una carga de trabajo en la nube con una política de administración adjunta. Juntos, los eslabones de este tipo de cadena de exposición de la identidad forman una única ruta de ataque, desde un punto de apoyo inicial hasta un activo crítico.

¿Qué tan frecuente es esto? Palo Alto descubrió que las debilidades de identidad desempeñaban un papel importante en casi el 90% de sus investigaciones de respuesta a incidentes de 2025. Y dada la prevalencia de agentes de IA que asumen cargas de trabajo empresariales, es probable que esas cifras aumenten. SpyCloud Informe de exposición de identidad de 2026 señaló el robo de identidad no humana como una de las categorías de más rápido crecimiento en el mundo criminal clandestino, con un tercio de las credenciales no humanas recuperadas vinculadas a herramientas de inteligencia artificial.

¿Qué sucede cuando una de esas identidades no humanas tiene permisos de nivel de administrador? Considere un equipo de desarrollo que configura un servidor MCP con permisos de alto nivel para que sus herramientas de inteligencia artificial puedan operar en todos los sistemas. El agente de IA que utiliza el servidor MCP hereda esos privilegios como su propia identidad. Una vulnerabilidad en las herramientas de código abierto puede entregar fácilmente a un atacante los permisos que posee el agente. A partir de ahí, el camino va directamente a los recursos de la nube, las bases de datos y la infraestructura de producción. Las credenciales que hacen esto posible son exactamente las que se encuentran circulando por millones en los mercados criminales.

Por qué siguen faltando las herramientas

Claramente, la amenaza de la exposición de la identidad no es nueva. Sin embargo, las herramientas de identidad en las que todavía confían la mayoría de las organizaciones se crearon para resolver problemas específicos de forma aislada y en una era de amenazas diferente.

Las plataformas IGA gestionan el ciclo de vida del usuario: aprovisionamiento, desaprovisionamiento, revisiones de acceso y más. Las soluciones PAM almacenan credenciales privilegiadas y monitorean sesiones. Cada una de estas herramientas hace su trabajo de forma aislada. Pero ninguno de ellos puede mapear cómo las exposiciones de identidad se encadenan entre puntos finales, Active Directory y entornos de nube en una única ruta explotable.

Esta es la razón por la que las tasas de incidentes basados ​​en la identidad siguen aumentando incluso cuando crece el gasto en seguridad. La IBM Índice de inteligencia de amenazas X-Force 2026 descubrió que las credenciales robadas o mal utilizadas representaban el 32% de los incidentes, el segundo vector de acceso inicial más común. Los atacantes actuales realmente no necesitan escribir malware o exploits, simplemente pueden iniciar sesión.

La gran mayoría de estas exposiciones basadas en la identidad se pueden prevenir por completo. De hecho, Palo Alto descubrió que más de El 90% de las infracciones. sus equipos investigados en 2025 se vieron favorecidos por exposiciones que las herramientas existentes deberían haber detectado. Las organizaciones tenían las herramientas y el personal. Sin embargo, las brechas persistieron porque ninguna herramienta tenía visibilidad de cómo las exposiciones de identidad se encadenaban en todos los entornos en rutas de ataque.

Cerrando la brecha

Hasta que los programas de seguridad puedan conectar la identidad, los permisos y los controles de acceso en una visión unificada de cómo se mueve realmente un atacante, la identidad seguirá siendo una de las formas más fáciles de comprometer activos críticos.

Todos los escenarios de este artículo siguen la misma estructura: una credencial, un permiso o una asignación de roles que ninguna herramienta señala como peligrosa crea un camino transitable desde un punto de apoyo de bajo nivel hasta un activo crítico. El camino sólo se vuelve visible cuando la identidad, las políticas de acceso y el contexto del entorno se mapean juntos.

Los programas de seguridad que asignan esas conexiones a través de entornos híbridos pueden cerrar rutas de ataque basadas en identidad antes de que un atacante los encadene. Los programas que siguen tratando la identidad como un problema perimetral seguirán perdiendo terreno frente a los atacantes que ya saben que se trata de una autopista.

Nota: Este artículo fue cuidadosamente escrito y contribuido para nuestra audiencia por Alex GardnerDirector de marketing de productos en XM Cyber

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

Cuando los permisos entre aplicaciones suponen un riesgo – CYBERDEFENSA.MX

El 31 de enero de 2026, los investigadores revelado que Moltbook, una red social creada para agentes de IA, había dejado su base de datos completamente abierta, exponiendo 35.000 direcciones de correo electrónico y 1,5 millones de tokens API de agentes en 770.000 agentes activos.

La parte más preocupante se encontraba dentro de los mensajes privados. Algunas de esas conversaciones contenían credenciales de terceros en texto plano, incluidas claves API de OpenAI compartidas entre agentes, almacenadas en la misma tabla no cifrada que los tokens necesarios para secuestrar al propio agente.

Ésta es la forma de una combinación tóxica: una ruptura de permisos entre dos o más aplicaciones, unida por un agente de IA, una integración o una concesión de OAuth, que ningún propietario de la aplicación jamás autorizó como su propia superficie de riesgo.

Los agentes de Moltbook estaban sentados en ese puente, llevando credenciales para su plataforma anfitriona y para los servicios externos a los que sus usuarios los habían conectado, en un lugar al que ninguno de los propietarios de la plataforma tenía línea de visión. La mayoría de las revisiones de acceso a SaaS todavía examinan una aplicación a la vez, que es el punto ciego que los atacantes están aprendiendo a atacar.

Cómo se forman las combinaciones tóxicas

Las combinaciones tóxicas rara vez son producto de una sola mala decisión. Aparecen cuando un agente de IA, una integración o un servidor MCP unen dos o más aplicaciones a través de concesiones de OAuth, alcances de API o cadenas de uso de herramientas, y cada lado del puente se ve bien por sí solo porque el puente en sí es lo que nadie revisó.

Como ejemplo, imagine que un desarrollador instala un conector MCP para que su IDE pueda publicar fragmentos de código en un canal de Slack a pedido. El administrador de Slack aprueba el bot; el administrador del IDE cierra la sesión de la conexión saliente; Ninguno de los dos firma la relación de confianza entre la edición de fuentes y la mensajería empresarial que existe en el momento en que ambas partes están activas. Se ejecuta en ambas direcciones: las inyecciones rápidas dentro del IDE insertan código confidencial en Slack, y las instrucciones colocadas en Slack regresan al contexto del IDE en la siguiente sesión.

La misma forma aparece dondequiera que un agente de IA une Drive y Salesforce, un bot conecta un repositorio de origen a un canal de equipo o cualquier intermediario hace que dos aplicaciones confíen entre sí a través de una concesión que parece normal en cada una.

Por qué las reseñas de aplicaciones únicas las extrañan

La revisión de acceso convencional rara vez adopta esta forma. Se tensa en el territorio que ha abierto el SaaS moderno: identidades no humanas como cuentas de servicio, bots y agentes de IA sin ningún ser humano detrás de ellos, relaciones de confianza que se forman en tiempo de ejecución en lugar de en el momento de aprovisionamiento, y puentes OAuth y MCP están conectados entre aplicaciones sin que el catálogo de gobernanza lo sepa.

Responder «quién posee este alcance más esos otros dos alcances, y qué pueden lograr esos alcances juntos» se vuelve mucho más difícil una vez que los alcances en cuestión viven en un token que, para empezar, nadie aprovisionó a través de ningún sistema de identidad.

La brecha de telemetría se está ampliando bastante rápido.

Los agentes de IA, los servidores MCP y los conectores de terceros ahora se ubican en dos o tres aplicaciones adyacentes de forma predeterminada, y las identidades no humanas superan en número a las humanas en la mayoría de los entornos SaaS. Informe sobre el estado de la seguridad SaaS 2025 de Cloud Security Alliance encontró que el 56% de las organizaciones ya están preocupadas por el acceso a API con privilegios excesivos en sus integraciones de SaaS a SaaS.

Cosas en las que vale la pena pensar

Cerrar la brecha es en gran medida una cuestión de cambiar el lugar donde se realiza la revisión, desde dentro de cada aplicación hacia entre ellas. Aquí hay algunas cosas en las que vale la pena pensar para abordar este tipo de problema:

Área a revisar Cómo se ve en la práctica
Inventario de identidad no humana Cada agente de IA, bot, servidor MCP e integración de OAuth se encuentran en el mismo registro que una cuenta de usuario, con un propietario y una fecha de revisión.
Subvenciones de alcance entre aplicaciones Un nuevo ámbito de escritura en una identidad que ya tiene ámbitos de lectura en una aplicación diferente se marca antes de la aprobación, no después.
Revisión del puente sobre la creación. Cada conector que une dos sistemas tiene un rastro de revisión que nombra a ambas partes y la relación de confianza entre ellas.
Higiene de tokens de larga duración Los tokens cuya actividad se ha desviado de los alcances que se les otorgaron originalmente son candidatos a revocación, no a renovación.
Monitoreo de deriva en tiempo de ejecución Las anomalías del alcance entre aplicaciones y las identidades que operan en una nueva combinación de aplicaciones son indicios de que se está formando una combinación tóxica.

Estas son disciplinas de procedimiento más que opciones de productos, y funcionan con cualquier herramienta de revisión de acceso disponible. La realidad es que ver estas conexiones a escala es difícil sin una plataforma creada para observar el gráfico de tiempo de ejecución continuamente. La revisión manual no pasa de las primeras docenas de integraciones.

Dónde encajan las plataformas de seguridad dinámicas SaaS

Las plataformas de seguridad dinámicas SaaS automatizan la vista entre aplicaciones que configura la revisión de procedimientos. Mientras que IGA inventaria los roles para los sistemas integrados, la seguridad dinámica de SaaS observa continuamente el gráfico de tiempo de ejecución: qué identidades existen, qué aplicaciones tocan, qué ámbitos viven en qué tokens y qué relaciones de confianza se han conectado después de la última revisión de aprovisionamiento.

El monitoreo debe ejecutarse continuamente, porque los puentes que estas plataformas necesitan detectar se crean a la velocidad de una instalación de MCP o un clic de consentimiento de OAuth.

Reco es un ejemplo de esta categoría. Su plataforma conecta identidades, permisos y flujos de datos en todo el entorno SaaS, por lo que una combinación de ámbitos en Slack, Drive y Salesforce se evalúa como una exposición en lugar de tres aprobaciones separadas.

El primer paso es descubrir cada agente de IA, integración e identidad de OAuth que operan en el entorno, de modo que el inventario del que depende cualquier revisión entre aplicaciones realmente exista. Los agentes que los equipos de seguridad no sabían que estaban allí, o los agentes que silenciosamente obtuvieron nuevas conexiones después de la incorporación inicial, emergen junto a los sancionados.

Inventario de agentes de IA de Reco, que muestra los agentes descubiertos conectados a GitHub.

Una vez que los agentes están inventariados, Knowledge Graph de Reco asigna cada identidad humana y no humana a las aplicaciones a las que llega y los puentes entre ellas. Cuando un servidor MCP conecta un IDE a un canal de mensajería, o un agente de IA conecta un almacén de documentos a un CRM, el gráfico muestra la combinación automáticamente y la marca como un desglose de permisos que ningún propietario de la aplicación autorizó.

Gráfico de conocimiento de Reco, que muestra una combinación tóxica entre Slack y Cursor.

A partir de ahí, Reco detecta el momento en que una integración comienza a comportarse fuera de lo aprobado y revoca el acceso riesgoso antes de que alguien tenga la oportunidad de usarlo. La cadena, más que la aplicación, se convierte en lo que revisas, y ese cambio es lo que hace que las combinaciones tóxicas sean visibles en primer lugar.

La próxima infracción en la mayoría de las organizaciones no se anunciará con un nuevo día cero. Parecerá un agente que hace exactamente lo que se le autorizó a hacer, hasta la exfiltración. Que esto quede atrapado en el momento de la aprobación o escrito en una autopsia depende de si alguien puede ver la cadena completa.

Ver la cadena completa es lo que Plataforma de seguridad dinámica SaaS de Reco fue construido para hacer.

¿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 cadena de muerte queda obsoleta cuando su agente de inteligencia artificial es la amenaza – CYBERDEFENSA.MX

En septiembre de 2025, Antrópico revelado que un actor de amenazas patrocinado por el estado utilizó un agente de codificación de IA para ejecutar una campaña autónoma de ciberespionaje contra 30 objetivos globales. La IA manejó entre el 80 y el 90 % de las operaciones tácticas por sí sola, realizando reconocimientos, escribiendo códigos de explotación e intentando movimientos laterales a la velocidad de la máquina.

Este incidente es preocupante, pero hay un escenario que debería preocupar aún más a los equipos de seguridad: un atacante que no necesita recorrer la cadena de destrucción en absoluto, porque ha comprometido a un agente de IA que ya vive dentro de su entorno. Uno que ya tenga el acceso, los permisos y una razón legítima para moverse por sus sistemas todos los días.

Un marco creado para las amenazas humanas

La cadena de destrucción cibernética tradicional supone que los atacantes deben ganarse cada centímetro de acceso. es un modelo desarrollado por Lockheed Martin en 2011 para describir cómo los adversarios pasan del compromiso inicial a su objetivo final, y ha dado forma a cómo los equipos de seguridad piensan sobre la detección desde entonces.

La lógica es simple: los atacantes deben completar una secuencia de pasos y los defensores pueden interrumpir la cadena en cualquier punto. Cada etapa por la que tiene que pasar un atacante es otra oportunidad para atraparlo.

Una intrusión típica pasa por distintas etapas:

  1. Acceso inicial (explotación de una vulnerabilidad, etc.)
  2. Persistencia sin activar alertas
  3. Reconocimiento para comprender el entorno.
  4. Movimiento lateral para alcanzar datos valiosos
  5. Escalada de privilegios cuando el acceso no es suficiente
  6. Exfiltración evitando controles DLP

Cada etapa crea oportunidades de detección: la seguridad de los terminales puede detectar la carga útil inicial, el monitoreo de la red puede detectar movimientos laterales inusuales, los sistemas de identidad pueden señalar una escalada de privilegios y las correlaciones SIEM pueden vincular comportamientos anómalos en todos los sistemas. Cuantos más pasos dé un atacante, más posibilidades habrá de tropezar con un cable.

Esta es la razón por la que los actores de amenazas avanzadas como LUCR-3 y APT29 invierten mucho en sigilo, pasando semanas viviendo de la tierra y mezclándose con el tráfico normal. Incluso entonces, dejan artefactos: ubicaciones de inicio de sesión inusuales, patrones de acceso extraños, ligeras desviaciones del comportamiento inicial. Estos artefactos son exactamente para lo que están diseñados los sistemas de detección modernos.

El problema aquí, sin embargo, es que los agentes de IA realmente no siguen este manual.

Lo que ya tiene un agente de IA

Los agentes de IA operan de manera fundamentalmente diferente a los usuarios humanos. Funcionan en todos los sistemas, mueven datos entre aplicaciones y se ejecutan continuamente. Si se ve comprometido, un atacante evita toda la cadena de eliminación: el propio agente se convierte en la cadena de eliminación.

Piense en a qué suele tener acceso un agente de IA. Su historial de actividad es un mapa perfecto de qué datos existen y dónde residen. Probablemente extrae de Salesforce, ingresa a Slack, se sincroniza con Google Drive y actualiza ServiceNow como parte de su flujo de trabajo normal. Se le otorgaron amplios permisos durante la implementación, a menudo acceso a nivel de administrador en múltiples aplicaciones, y ya mueve datos entre sistemas como parte de su trabajo.

Un atacante que compromete a ese agente lo hereda todo al instante. Obtienen el mapa, el acceso, los permisos y una razón legítima para mover datos. ¿Cada etapa de la cadena de destrucción que los equipos de seguridad han pasado años aprendiendo a detectar? El agente los omite todos de forma predeterminada.

La amenaza ya se está desarrollando

El Crisis de OpenClaw nos mostró cómo se ve esto en la práctica:

Aproximadamente el 12% de las habilidades en su mercado público eran maliciosas. Una vulnerabilidad crítica de RCE permitió un compromiso con un solo clic. Más de 21.000 casos fueron expuestos públicamente. Pero la parte más aterradora era a qué podía acceder un agente comprometido una vez conectado a Slack y Google Workspace: mensajes, archivos, correos electrónicos y documentos, con memoria persistente entre sesiones.

El principal problema es que las herramientas de seguridad están diseñadas para detectar comportamientos anormales. Cuando un atacante aprovecha el flujo de trabajo existente de un agente de IA, todo parece normal. El agente accede a los sistemas a los que siempre accede, mueve los datos que siempre mueve y opera en los momentos en que siempre opera.

Esta es la brecha de detección a la que se enfrentan los equipos de seguridad.

Cómo Reco cierra la brecha de visibilidad

La defensa contra agentes de IA comprometidos comienza con saber qué agentes están operando en su entorno, a qué se conectan y qué permisos tienen. La mayoría de las organizaciones no tienen un inventario de los agentes de IA que tocan su ecosistema SaaS. Este es exactamente el tipo de problema para el que Reco fue creado.

Descubra todos los agentes de IA en juego

Agentic AI Security de Reco descubre cada agente de IA, función de IA integrada e integración de IA de terceros en su entorno SaaS, incluidas las herramientas de IA en la sombra conectadas sin la aprobación de TI.

Figura 1: Inventario de agentes de IA de Reco, que muestra los agentes descubiertos y sus conexiones con GitHub.

Alcance de acceso al mapa y radio de explosión

Para cada agente, Reco asigna a qué aplicaciones SaaS se conecta, qué permisos tiene y a qué datos puede acceder. recoco Visualización de SaaS a SaaS muestra exactamente cómo los agentes se integran en su ecosistema de aplicaciones, mostrando combinaciones tóxicas en las que los agentes de IA unen sistemas a través de integraciones MCP, OAuth o API, creando desgloses de permisos que ningún propietario de la aplicación autorizaría.

Figura 2: Gráfico de conocimiento de Reco que muestra una combinación tóxica entre Slack y Cursor a través de MCP.

Marcar objetivos y hacer cumplir el privilegio mínimo

Reco identifica qué agentes representan su mayor exposición al evaluar el alcance del permiso, el acceso entre sistemas y la sensibilidad de los datos. Los agentes asociados a riesgos emergentes se etiquetan automáticamente. Desde allí, Reco le ayuda a acceder al tamaño adecuado a través de gobernanza de identidad y accesolimitando directamente lo que un atacante puede hacer si un agente se ve comprometido.

Figura 3: Verificaciones de postura de la IA de Reco con puntuaciones de seguridad y hallazgos de cumplimiento de IAM.

Detectar actividad anómala del agente

recoco motor de detección de amenazas aplica un análisis de comportamiento centrado en la identidad a los agentes de IA de la misma manera que lo hace con las identidades humanas, distinguiendo la automatización normal de las desviaciones sospechosas en tiempo real.

Figura 4: Una alerta de Reco que señala una conexión ChatGPT no autorizada a SharePoint.

Lo que esto significa para su equipo

La cadena de destrucción tradicional suponía que los atacantes tenían que luchar por cada centímetro de acceso. Los agentes de IA cambian por completo esa suposición.

Un agente comprometido puede brindarle a un atacante acceso legítimo, un mapa perfecto del entorno, amplios permisos y cobertura incorporada para el movimiento de datos, sin un solo paso que parezca una intrusión.

Los equipos de seguridad que todavía se centran exclusivamente en detectar el comportamiento de los atacantes humanos se lo perderán. Los atacantes aprovecharán los flujos de trabajo existentes de sus agentes de IA, invisibles en el ruido de las operaciones normales.

Tarde o temprano, un agente de IA en su entorno será el objetivo. La visibilidad es la diferencia entre detectarlo temprano y descubrirlo durante la respuesta al incidente. Reco le brinda esa visibilidad, en todo su ecosistema SaaS, en minutos.

Obtenga más información aquí: Solicite una demostración: comience con Reco.

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