Un nuevo kit de exploits para dispositivos Apple iOS diseñado para robar datos confidenciales está siendo utilizado por múltiples actores de amenazas desde al menos noviembre de 2025, según informes de Grupo de inteligencia sobre amenazas de Google (GTIG), iVerificary Estar atento.

Según GTIG, múltiples proveedores de vigilancia comercial y presuntos actores patrocinados por el estado han utilizado el kit de explotación de cadena completa, cuyo nombre en código Espada oscuraen distintas campañas dirigidas a Arabia Saudita, Turquía, Malasia y Ucrania.

El descubrimiento de DarkSword lo convierte en el segundo kit de exploits para iOS, después de Coruña, descubierto en el lapso de un mes. El kit está diseñado para iPhones que ejecutan versiones de iOS entre iOS 18.4 y 18.7, y se dice que fue implementado por un presunto grupo de espionaje ruso llamado UNC6353 en ataques dirigidos a usuarios ucranianos.

Vale la pena señalar que UNC6353 también se ha relacionado con el uso de Coruna en ataques dirigidos a ucranianos mediante la inyección del marco JavaScript en sitios web comprometidos.

«DarkSword tiene como objetivo extraer un amplio conjunto de información personal, incluidas credenciales del dispositivo y apunta específicamente a una gran cantidad de aplicaciones de billeteras criptográficas, insinuando un actor de amenazas con motivación financiera», dijo Lookout. «En particular, DarkSword parece adoptar un enfoque de ‘atacar y huir’ al recopilar y exfiltrar los datos específicos del dispositivo en segundos o como máximo minutos, seguido de la limpieza».

Las cadenas de exploits como Coruna y DarkSword están diseñadas para facilitar el acceso completo al dispositivo de la víctima con poca o ninguna interacción por parte del usuario. Los hallazgos muestran una vez más que existe un mercado de segunda mano para exploits que permite a grupos de amenazas con recursos limitados y objetivos no necesariamente alineados con el ciberespionaje adquirir «exploits de primera línea» y utilizarlos para infectar dispositivos móviles.

«El uso de DarkSword y Coruña por parte de una variedad de actores demuestra el riesgo continuo de proliferación de exploits entre actores de diferentes geografías y motivaciones», dijo GTIG.

La cadena de exploits vinculada al kit recién descubierto utiliza seis vulnerabilidades diferentes para implementar tres cargas útiles, de las cuales CVE-2026-20700, CVE-2025-43529 y CVE-2025-14174 fueron explotadas como de día cero, antes de que Apple las parcheara:

• CVE-2025-31277 – Vulnerabilidad de corrupción de memoria en JavaScriptCore (parcheada en la versión 18.6)
• CVE-2026-20700 – Omisión del código de autenticación de puntero (PAC) en modo usuario en dyld (parcheado en la versión 26.3)
• CVE-2025-43529 – Vulnerabilidad de corrupción de memoria en JavaScriptCore (parcheada en las versiones 18.7.3 y 26.2)
• CVE-2025-14174 – Vulnerabilidad de corrupción de memoria en ANGLE (parcheada en las versiones 18.7.3 y 26.2)
• CVE-2025-43510 – Vulnerabilidad de gestión de memoria en el kernel de iOS (Parchado en las versiones 18.7.2 y 26.1)
• CVE-2025-43520 – Vulnerabilidad de corrupción de memoria en el kernel de iOS (parcheado en las versiones 18.7.2 y 26.1)

Lookout dijo que descubrió DarkSword después de un análisis de la infraestructura maliciosa asociada con UNC6353, identificando que uno de los dominios comprometidos albergaba un elemento iFrame malicioso que es responsable de cargar un JavaScript en los dispositivos que visitan el sitio y determinar si el objetivo debe ser enrutado a la cadena de exploits de iOS. Actualmente se desconoce el método exacto mediante el cual se infectan los sitios web.

Lo que hizo que esto fuera notable fue que JavaScript buscaba específicamente dispositivos iOS con versiones entre 18.4 y 18.6.2, a diferencia de Coruña, que apuntaba a versiones anteriores de iOS desde 13.0 hasta 17.2.1.

«DarkSword es una cadena completa de exploits y un ladrón de información escrito en JavaScript», explicó Lookout. «Aprovecha múltiples vulnerabilidades para establecer una ejecución de código privilegiada para acceder a información confidencial y extraerla del dispositivo».

Como es el caso de Coruña, la cadena de ataque comienza cuando un usuario visita a través de Safari una página web que incrusta el iFrame que contiene JavaScript. Una vez lanzado, DarkSword es capaz de romper los límites del entorno limitado de WebContent (también conocido como proceso de renderizado de Safari) y aprovechar WebGPU para inyectar en reproducción multimediaun demonio del sistema introducido por Apple para manejar funciones de reproducción multimedia.

Esto, a su vez, permite que el malware minero de datos, conocido como GHOSTBLADE, obtenga acceso a procesos privilegiados y partes restringidas del sistema de archivos. Después de una escalada de privilegios exitosa, se utiliza un módulo orquestador para cargar componentes adicionales que están diseñados para recopilar datos confidenciales, así como también inyectar una carga útil de exfiltración en Springboard para desviar la información preparada a un servidor externo a través de HTTP(S).

Esto incluye correos electrónicos, archivos de iCloud Drive, contactos, mensajes SMS, historial de navegación de Safari y cookies, billetera de criptomonedas y datos de intercambio, nombres de usuario, contraseñas, fotos, historial de llamadas, configuración y contraseñas de Wi-Fi WiFi, historial de ubicaciones, calendario, información celular y SIM, lista de aplicaciones instaladas, datos de aplicaciones de Apple como Notas y Salud, e historiales de mensajes de aplicaciones como Telegram y WhatsApp.

iVerify, en su propio análisis de DarkSword, dijo que la cadena de exploits convierte en arma las vulnerabilidades JavaScriptCore JIT en el proceso de renderizado de Safari (CVE-2025-31277 o CVE-2025-43529) basado en la versión de iOS para lograr la ejecución remota de código a través de CVE-2026-20700, y luego escapar del sandbox a través del proceso de GPU aprovechando CVE-2025-14174. y CVE-2025-43510.

En la etapa final, se aprovecha una falla de escalada de privilegios del kernel (CVE-2025-43520) para obtener capacidades arbitrarias de lectura/escritura y llamadas a funciones arbitrarias dentro de mediaplaybackd y, en última instancia, ejecutar el código JavaScript inyectado.

«Este malware es muy sofisticado y parece ser una plataforma diseñada profesionalmente que permite un rápido desarrollo de módulos mediante el acceso a un lenguaje de programación de alto nivel», dijo Lookout. «Este paso adicional muestra un esfuerzo significativo puesto en el desarrollo de este malware pensando en la mantenibilidad, el desarrollo a largo plazo y la extensibilidad».

Se ha descubierto que un análisis más detallado de los archivos JavaScript utilizados en DarkSword contiene referencias a las versiones 17.4.1 y 17.5.1 de iOS, lo que indica que el kit fue portado desde una versión anterior dirigida a versiones anteriores del sistema operativo.

Otro aspecto que distingue a DarkSword de otros programas espía es que no está diseñado para vigilancia persistente ni recopilación de datos. En otras palabras, una vez que se completa la filtración de datos, el malware toma medidas para limpiar los archivos preparados y sale. El objetivo final, señaló Lookout, es minimizar el tiempo de permanencia y filtrar los datos que identifica lo más rápido posible.

Se sabe muy poco sobre UNC6353, aparte de su uso de Coruña y DarkSword a través de ataques de abrevadero en sitios web ucranianos comprometidos. Esto indica que el grupo de hackers probablemente esté bien financiado para proteger cadenas de exploits de iOS de alta calidad que probablemente estén desarrolladas para vigilancia comercial. Se considera que UNC6353 es un actor de amenazas técnicamente menos sofisticado que opera con motivos alineados con los requisitos de inteligencia rusos.

«Dado que tanto Coruña como DarkSword tienen capacidades para el robo de criptomonedas y la recopilación de inteligencia, debemos considerar la posibilidad de que UNC6353 sea un grupo privado respaldado por Rusia o un actor criminal de amenazas», dijo Lookout.

«La total falta de ofuscación en el código DarkSword, la falta de ofuscación en el HTML para los iframes y el hecho de que DarkSword File Receiver esté diseñado de manera tan simple y obviamente tenga un nombre nos llevan a creer que UNC6353 puede no tener acceso a recursos de ingeniería sólidos o, alternativamente, no está preocupado por tomar las medidas OPSEC apropiadas».

El uso de DarkSword también se ha relacionado con otros dos actores de amenazas:

• UNC6748que se dirigió a usuarios de Arabia Saudita en noviembre de 2025 utilizando un sitio web con temática de Snapchat, snapshare[.]chat, que aprovechó la cadena de exploits para entregar GHOSTKNIFE, una puerta trasera de JavaScript capaz de robar información.
• Actividad asociada con un proveedor turco de vigilancia comercial Defensa PARS que utilizó DarkSword en noviembre de 2025 para entregar GHOSTSABER, una puerta trasera de JavaScript que se comunica con un servidor externo para facilitar la enumeración de dispositivos y cuentas, el listado de archivos, la filtración de datos y la ejecución de código JavaScript arbitrario.

Google dijo que el uso observado de DarkSword según UNC6353 en diciembre de 2025 solo admitía versiones de iOS de 18.4 a 18.6, mientras que el atribuido a UNC6748 y PARS Defense también apuntaba a dispositivos iOS que ejecutaban la versión 18.7.

«Por segunda vez en un mes, los actores de amenazas han empleado ataques de pozo de agua para atacar a los usuarios de iPhone», dijo iVerify. «En particular, ninguno de estos ataques fue dirigido individualmente. Los ataques combinados ahora probablemente afecten a cientos de millones de dispositivos sin parches que ejecutan versiones de iOS de 13 a 18.6.2».

«En ambos casos, las herramientas fueron descubiertas debido a importantes fallos de seguridad operativa (OPSEC) y a un descuido en el despliegue de las capacidades ofensivas de iOS. Estos acontecimientos recientes suscitan varias preguntas clave: ¿Qué tan grande y bien equipado está el mercado para los exploits de días 0 y n de iOS para dispositivos iOS? ¿Qué tan accesibles son capacidades tan poderosas para actores con motivación financiera?»

Los equipos de seguridad han pasado años creando controles de identidad y acceso para usuarios humanos y cuentas de servicio. Pero una nueva categoría de actor ha entrado silenciosamente en la mayoría de los entornos empresariales y opera completamente fuera de esos controles.

Claude Code, el agente de codificación de IA de Anthropic, ahora se ejecuta en organizaciones de ingeniería a escala. Lee archivos, ejecuta comandos de shell, llama a API externas y se conecta a integraciones de terceros llamadas servidores MCP. Hace todo esto de forma autónoma, con todos los permisos del desarrollador que lo lanzó, en la máquina local del desarrollador, antes de que cualquier herramienta de seguridad de capa de red pueda verlo. No deja ningún rastro de auditoría para cuya captura se construyó la infraestructura de seguridad existente.

Este tutorial cubre Ceros, una capa de confianza de IA creada por Más allá de la identidad que se encuentra directamente en la máquina del desarrollador junto con Claude Code y proporciona visibilidad en tiempo real, aplicación de políticas en tiempo de ejecución y un seguimiento de auditoría criptográfica de cada acción que realiza el agente.

El problema: Claude Code opera fuera de los controles de seguridad existentes

Antes de analizar el producto, es útil comprender por qué las herramientas existentes no pueden abordar este problema.

La mayoría de las herramientas de seguridad empresarial se encuentran en el borde de la red o en la puerta de enlace API. Estas herramientas ven el tráfico después de que sale de la máquina. Para cuando un SIEM ingiere un evento o un monitor de red señala tráfico inusual, Claude Code ya ha actuado: el archivo ya ha sido leído, el comando de shell ya se ha ejecutado y los datos ya se han movido.

El perfil de comportamiento de Claude Code agrava significativamente este problema. Vive de la tierra, utilizando herramientas y permisos que ya están en la máquina del desarrollador en lugar de traer los suyos propios. Se comunica a través de llamadas de modelos externos que parecen tráfico normal. Ejecuta secuencias complejas de acciones que ningún ser humano programó explícitamente. Y se ejecuta con todos los permisos heredados de quien lo lanzó, incluido el acceso a credenciales, sistemas de producción y datos confidenciales que los desarrolladores tienen en sus máquinas.

El resultado es una brecha que las herramientas de la capa de red estructuralmente no pueden cerrar: todo lo que Claude Code hace en la máquina local, antes de que cualquier solicitud abandone el dispositivo. Ahí es donde opera Ceros.

Primeros pasos: dos comandos, treinta segundos

Ceros está diseñado para que la instalación no interrumpa el flujo de trabajo del desarrollador. La configuración requiere dos comandos:

curl -fsSL https://agent.beyondidentity.com/install.sh | bash

ceros claude

El primer comando instala la CLI. El segundo lanza Claude Code a través de Ceros. Se abre una ventana del navegador, solicita una dirección de correo electrónico y envía un código de verificación de seis dígitos. Después de ingresar el código, Claude Code se inicia y funciona exactamente como antes. Desde la perspectiva del desarrollador, nada ha cambiado.

Para implementaciones en toda la organización, los administradores pueden configurar Ceros para que se solicite a los desarrolladores que se inscriban automáticamente cuando inicien Claude Code. La seguridad se vuelve invisible para el desarrollador, que es la única forma en que la seguridad se adopta a escala.

Una vez inscrito, antes de que Claude Code genere un único token, Ceros captura el contexto completo del dispositivo, incluido el sistema operativo, la versión del kernel, el estado de cifrado del disco, el estado de arranque seguro y el estado de protección del endpoint, todo en menos de 250 milisegundos. Captura la ascendencia completa del proceso de cómo se invocó Claude Code, con hashes binarios de cada ejecutable en la cadena. Y vincula la sesión a una identidad humana verificada a través de la plataforma de Beyond Identity, firmada con una clave criptográfica vinculada al hardware.

La consola: vea lo que Claude Code ha estado haciendo realmente

Después de registrar un dispositivo y ejecutar Claude Code normalmente durante unos días, navegar a la consola de administración de Ceros revela algo que la mayoría de los equipos de seguridad nunca antes habían visto: un registro completo de lo que Claude Code ha estado haciendo realmente en su entorno.

La vista de conversaciones muestra cada sesión entre un desarrollador y Claude Code en todos los dispositivos registrados, enumerados por usuario, dispositivo y marca de tiempo. Al hacer clic en cualquier conversación se muestra el intercambio completo entre el desarrollador y el agente. Pero entre las indicaciones y las respuestas, algo más es visible: llamadas a herramientas.

Cuando un desarrollador le pregunta a Claude Code algo tan simple como «¿qué archivos hay en mi directorio?», el LLM no simplemente sabe la respuesta. Le indica al agente que ejecute una herramienta en la máquina local, en este caso bash ls -la. Ese comando de shell se ejecuta en el dispositivo del desarrollador con los permisos del desarrollador. Una pregunta casual desencadena una ejecución real en una máquina real.

La vista Conversaciones muestra cada una de estas invocaciones de herramientas en cada sesión. Para la mayoría de los equipos de seguridad, esta es la primera vez que ven estos datos.

La vista Herramientas tiene dos pestañas. La pestaña Definiciones muestra todas las herramientas disponibles para Claude Code en el entorno inscrito, incluidas herramientas integradas como Bash, ReadFile, WriteFile, Edit y SearchWeb, así como todos los servidores MCP que los desarrolladores han conectado a sus agentes. Cada entrada incluye el esquema completo de la herramienta: las instrucciones dadas al LLM sobre lo que hace la herramienta y cómo invocarla.

La pestaña Llamadas muestra lo que realmente se ejecutó. No sólo lo que existe, sino lo que se invocó, con qué argumentos y lo que se devolvió. Los equipos de seguridad pueden profundizar en cualquier llamada de herramienta individual y ver el comando exacto que se ejecutó, los argumentos pasados ​​y el resultado completo que se obtuvo.

La vista del servidor MCP Es donde muchos equipos de seguridad tienen su momento de descubrimiento más significativo. Los servidores MCP son la forma en que Claude Code se conecta a herramientas y servicios externos, incluidas bases de datos, Slack, correo electrónico, API internas e infraestructura de producción. Los desarrolladores los agregan de manera casual, pensando en la productividad más que en la seguridad. Cada uno es una ruta de acceso a datos que nadie revisó.

El panel de Ceros muestra cada servidor MCP conectado a Claude Code en todos los dispositivos registrados, cuándo se vio por primera vez, en qué dispositivos aparece y si ha sido aprobado. Para la mayoría de las organizaciones, la brecha entre lo que los equipos de seguridad asumieron que estaba conectado y lo que realmente está conectado es significativa.

Políticas: Aplicación de controles en el código Claude en tiempo de ejecución

La visibilidad sin gobernanza pone de manifiesto el riesgo, pero no lo previene. La sección de Políticas es donde Ceros pasa de la observabilidad a la aplicación, y donde la historia del cumplimiento se vuelve concreta.

Políticas en Ceros se evalúan en tiempo de ejecución, antes de que se ejecute la acción. Esta distinción es importante para el cumplimiento: el control opera en el momento de la acción, no reconstruido después del hecho.

Lista de permitidos del servidor MCP es la política de mayor impacto que la mayoría de las organizaciones escriben primero. Los administradores definen una lista de servidores MCP aprobados y configuran el valor predeterminado para bloquear todo lo demás. A partir de ese momento, cualquier instancia de Claude Code que intente conectarse a un servidor MCP no aprobado se bloquea antes de que se establezca la conexión y el intento se registra.

Políticas a nivel de herramienta Permitir a los administradores controlar qué herramientas Claude Code puede invocar y bajo qué condiciones. Una política puede bloquear completamente la herramienta Bash para equipos que no necesitan acceso de shell por parte de sus agentes. Puede permitir lecturas de archivos dentro del directorio del proyecto mientras bloquea lecturas en rutas confidenciales como ~/.ssh/ o /etc/. El motor de políticas evalúa no sólo qué herramienta se está utilizando sino también qué argumentos se están pasando, lo cual es la diferencia entre una política útil y un teatro de políticas.

Requisitos de postura del dispositivo sesiones de Gate Claude Code sobre el estado de seguridad de la máquina. Una política puede requerir que se habilite el cifrado de disco y que se ejecute la protección de endpoints antes de que se permita iniciar una sesión. Ceros reevalúa continuamente la postura del dispositivo durante toda la sesión, no solo al iniciar sesión. Si la protección de endpoints está deshabilitada mientras Claude Code está activo, Ceros lo ve y actúa en consecuencia según la política.

El registro de actividad: evidencia lista para auditoría

El Registro de actividad es donde Ceros se vuelve directamente relevante para los equipos de cumplimiento. Cada entrada no es simplemente un registro; es una instantánea forense del entorno en el momento exacto en que se invocó el Código Claude.

Una única entrada de registro contiene la postura de seguridad completa del dispositivo en ese momento, la ascendencia completa del proceso que muestra cada proceso en la cadena que invocó Claude Code, firmas binarias de cada ejecutable en esa ascendencia, la identidad del usuario a nivel de sistema operativo vinculada a un humano verificado y cada acción que Claude Code realizó durante la sesión.

Esto es importante para el cumplimiento porque los auditores exigen cada vez más pruebas de que los registros son inmutables. Los archivos de registro estándar que los administradores pueden editar no cumplen este requisito. Ceros firma cada entrada con una clave criptográfica vinculada al hardware antes de salir de la máquina. El registro no se puede modificar después del hecho.

Para los marcos que requieren registros de auditoría a prueba de manipulaciones, incluidos CC8.1 de SOC 2, AU-9 de FedRAMP, requisitos de control de auditoría de HIPAA y Requisito 10 de PCI-DSS v4.0, este es el artefacto de evidencia específico que satisface el control. Cuando un auditor solicita evidencia de monitoreo y controles de acceso a agentes de IA, la respuesta es una exportación desde el panel de Ceros que cubre todo el período de auditoría, firmada criptográficamente, con atribución de usuario y contexto del dispositivo en cada entrada.

Implementación de MCP administrada: estandarización de las herramientas de Claude Code en toda la organización

Para las organizaciones que desean estandarizar las herramientas disponibles para Claude Code en lugar de bloquear únicamente las no aprobadas, Ceros proporciona implementación de MCP administrada desde la consola de administración.

Los administradores pueden enviar servidores MCP aprobados a la instancia de Claude Code de cada desarrollador desde una única interfaz, sin necesidad de ninguna configuración del desarrollador. El servidor MCP aparece automáticamente en el agente del desarrollador en el próximo lanzamiento.

Combinado con la lista de permitidos del servidor MCP, esto crea un modelo de gobierno completo: los administradores definen qué se requiere, qué se permite y qué se bloquea. Los desarrolladores trabajan dentro de ese ámbito sin fricciones.

El panel: postura de riesgo de IA agente en toda la organización

Lo que viene es El tablerouna vista única de la postura de riesgo de la IA en toda su organización inscrita. Mientras que las vistas a nivel de sesión le indican lo que hizo el agente de un desarrollador, el Panel le informa lo que está sucediendo en toda la flota: cuántos dispositivos están aprovisionados, inscritos y ejecutando activamente Claude Code, con señalización automática cuando las brechas de adopción indican que los agentes se están ejecutando fuera de la ruta de inscripción de Ceros y fuera de sus controles. Inscribirse para recibir una notificación cuando se envíe The Dashboard.

Conclusión

La brecha de seguridad que crea Claude Code no está en el borde de la red. Es en la máquina del desarrollador, donde opera el agente antes de que cualquier herramienta de seguridad existente pueda verlo. Ceros cierra esa brecha viviendo donde vive el agente, capturando todo antes de que se ejecute y produciendo evidencia firmada criptográficamente sobre la cual los equipos de seguridad y cumplimiento pueden actuar.

Para los equipos de seguridad cuyas organizaciones han implementado Claude Code y están comenzando a considerar lo que eso significa para su postura y controles de auditoría, el punto de partida es la visibilidad. No se puede gobernar lo que no se puede ver y, hasta ahora, no ha habido ninguna herramienta que pueda mostrar lo que Claude Code estaba haciendo realmente.

Ceros ya está disponible y comenzar es gratis. Los equipos de seguridad pueden registrar un dispositivo y ver la actividad de su Código Claude por primera vez en más allá de la identidad.ai.

Ceros está desarrollado por Beyond Identity, que cumple con SOC 2/FedRAMP y se puede implementar como SaaS en la nube, autohospedado o totalmente aislado en las instalaciones.

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) ha instado a las agencias gubernamentales a aplicar parches para dos fallas de seguridad que afectan Suite de colaboración Synacor Zimbra (ZCS) y Microsoft Office SharePointafirmando que han sido explotados activamente en la naturaleza.

Las vulnerabilidades en cuestión son las siguientes:

• CVE-2025-66376 (Puntuación CVSS: 7,2): una vulnerabilidad de secuencias de comandos entre sitios almacenadas en la interfaz de usuario clásica de ZCS, donde los atacantes podrían abusar de las directivas @import de hojas de estilo en cascada (CSS) en un mensaje de correo electrónico HTML. (Corregido en las versiones 10.0.18 y 10.1.13 en noviembre 2025)
• CVE-2026-20963 (Puntuación CVSS: 8,8): una vulnerabilidad de deserialización de datos no confiables en Microsoft Office SharePoint que permite a un atacante no autorizado ejecutar código a través de una red. (Fijado en enero 2026)

Actualmente no hay informes públicos que hagan referencia a la explotación de las fallas antes mencionadas, quién puede estar aprovechándolas y la escala de dichos esfuerzos. A la luz de la explotación activa, se recomienda a las agencias del Poder Ejecutivo Civil Federal (FCEB) que apliquen parches para CVE-2025-66376 antes del 1 de abril de 2026 y para CVE-2026-20963 antes del 23 de marzo de 2026.

La divulgación se produce cuando Amazon reveló que los actores de amenazas asociados con el ransomware Interlock han explotado una falla de seguridad de máxima gravedad que afecta el software de administración de firewall de Cisco (CVE-2026-20131, puntuación CVSS: 10.0) desde el 26 de enero de 2026, más de un mes antes de que se divulgara públicamente.

«Históricamente, Interlock se ha dirigido a sectores específicos donde la interrupción operativa crea la máxima presión para el pago», dijo Amazon. Estos sectores incluyen educación, ingeniería, arquitectura, construcción, manufactura, industria, atención médica y entidades gubernamentales.

El ataque destaca una vez más un patrón persistente de actores de amenazas que apuntan a dispositivos de red perimetrales de diferentes proveedores, incluidos Cisco, Fortinet, Ivanti y otros, para obtener acceso inicial a las redes de destino. El hecho de que CVE-2026-20131 se haya convertido en un arma de día cero muestra que los atacantes están invirtiendo tiempo y recursos para encontrar fallas previamente desconocidas que podrían otorgarles un acceso elevado.

Amazon Threat Intelligence advierte sobre una campaña activa de ransomware Interlock que explota una falla de seguridad crítica recientemente revelada en el software Cisco Secure Firewall Management Center (FMC).

La vulnerabilidad en cuestión es CVE-2026-20131 (puntuación CVSS: 10.0), un caso de deserialización insegura de un flujo de bytes Java proporcionado por el usuario, que podría permitir a un atacante remoto no autenticado eludir la autenticación y ejecutar código Java arbitrario como root en un dispositivo afectado.

Según datos obtenidos del gigante tecnológico loco red mundial de sensoresse dice que la falla de seguridad fue explotada como día cero desde el 26 de enero de 2026, más de un mes antes de que Cisco la revelara públicamente.

«Esto no era simplemente otro exploit de vulnerabilidad; Interlock tenía un día cero en sus manos, lo que les daba una semana de ventaja para comprometer a las organizaciones antes de que los defensores supieran siquiera mirar. Al hacer este descubrimiento, compartimos nuestros hallazgos con Cisco para ayudar a respaldar su investigación y proteger a los clientes», dijo CJ Moses, director de seguridad de la información (CISO) de Amazon Integrated Security, en un informe compartido con The Hacker News.

El descubrimiento, dijo Amazon, fue posible gracias a un error de seguridad operativa por parte del actor de amenazas que expuso el conjunto de herramientas operativas de su grupo de cibercrimen a través de un servidor de infraestructura mal configurado, ofreciendo información sobre su cadena de ataque de múltiples etapas, troyanos de acceso remoto personalizados, scripts de reconocimiento y técnicas de evasión.

La cadena de ataque implica el envío de solicitudes HTTP diseñadas a una ruta específica en el software afectado con el objetivo de ejecutar código Java arbitrario, después de lo cual el sistema comprometido emite una solicitud HTTP PUT a un servidor externo para confirmar la explotación exitosa. Una vez que se completa este paso, los comandos se envían para recuperar un binario ELF de un servidor remoto, que aloja otras herramientas vinculadas a Interlock.

La lista de herramientas identificadas es la siguiente:

• Un script de reconocimiento de PowerShell que se utiliza para la enumeración sistemática del entorno de Windows, que recopila detalles sobre el sistema operativo y el hardware, los servicios en ejecución, el software instalado, la configuración de almacenamiento, el inventario de máquinas virtuales Hyper-V, los listados de archivos de usuario en los directorios de escritorio, documentos y descargas, los artefactos del navegador de Chrome, Edge, Firefox, Internet Explorer y el navegador 360, conexiones de red activas y eventos de autenticación RDP de los registros de eventos de Windows.
• Troyanos de acceso remoto personalizados escritos en JavaScript y Java para comando y control, acceso interactivo al shell, ejecución de comandos arbitrarios, transferencia de archivos bidireccional y capacidad de proxy SOCKS5. También admite mecanismos de autoactualización y autoeliminación para reemplazar o eliminar el artefacto sin tener que reinfectar la máquina y desafiar la investigación forense.
• Un script Bash para configurar servidores Linux como servidores proxy inversos HTTP para ocultar los verdaderos orígenes del atacante. El guión cumple falla2banuna herramienta de prevención de intrusiones de Linux de código abierto, y compila y genera una instancia de HAProxy que escucha en el puerto 80 y reenvía todo el tráfico HTTP entrante a una dirección IP de destino codificada. Además, el script de lavado de infraestructura ejecuta una rutina de borrado de registros como una tarea cron cada cinco minutos para eliminar y purgar agresivamente el contenido de los archivos *.log y suprimir el historial del shell al desarmar la variable HISTFILE.
• Un shell web residente en memoria para inspeccionar solicitudes entrantes en busca de parámetros especialmente diseñados que contengan cargas útiles de comandos cifradas, que luego se descifran y ejecutan.
• Una baliza de red liviana para llamar a la infraestructura controlada por un atacante que probablemente valide la ejecución exitosa del código o confirme la accesibilidad del puerto de la red luego de la explotación inicial.
• ConnectWise ScreenConnect para acceso remoto persistente y para servir como vía alternativa en caso de que se detecten y eliminen otros puntos de apoyo.
• Volatility Framework, un marco forense de memoria de código abierto

Los enlaces a Interlock surgen de indicadores técnicos y operativos «convergentes», incluida la nota de rescate integrada y el portal de negociación TOR. La evidencia muestra que el actor de amenazas probablemente esté operativo durante la zona horaria UTC+3.

A la luz de la explotación activa de la falla, se recomienda a los usuarios que apliquen parches lo antes posible, realicen evaluaciones de seguridad para identificar posibles compromisos, revisen las implementaciones de ScreenConnect en busca de instalaciones no autorizadas e implementen estrategias de defensa en profundidad.

«La verdadera historia aquí no se trata solo de una vulnerabilidad o un grupo de ransomware, sino del desafío fundamental que los exploits de día cero plantean para cada modelo de seguridad», dijo Moses. «Cuando los atacantes explotan las vulnerabilidades antes de que existan los parches, ni siquiera los programas de parcheo más diligentes pueden protegerte en esa ventana crítica».

«Esta es precisamente la razón por la que la defensa en profundidad es esencial: los controles de seguridad en capas brindan protección cuando un solo control falla o aún no se ha implementado. La aplicación rápida de parches sigue siendo fundamental en la gestión de vulnerabilidades, pero la defensa en profundidad ayuda a las organizaciones a no estar indefensas durante el período entre el exploit y el parche».

La divulgación se produce cuando Google reveló que los actores del ransomware están cambiando sus tácticas en respuesta a la disminución de las tasas de pago, apuntando a las vulnerabilidades en VPN y firewalls comunes para el acceso inicial y apoyándose menos en herramientas externas y más en las capacidades integradas de Windows.

También se ha descubierto que múltiples grupos de amenazas, tanto los propios operadores de ransomware como los intermediarios de acceso inicial, emplean tácticas de publicidad maliciosa y/o optimización de motores de búsqueda (SEO) para distribuir cargas útiles de malware para el acceso inicial. Otras técnicas comúnmente observadas incluyen el uso de credenciales comprometidas, puertas traseras o software de escritorio remoto legítimo para establecer un punto de apoyo, así como confiar en herramientas integradas y ya instaladas para reconocimiento, escalada de privilegios y movimiento lateral.

«Si bien anticipamos que el ransomware seguirá siendo una de las amenazas más dominantes a nivel mundial, la reducción de las ganancias puede hacer que algunos actores de amenazas busquen otros métodos de monetización», dijo Google. «Esto podría manifestarse como un aumento de las operaciones de extorsión por robo de datos, el uso de tácticas de extorsión más agresivas o el uso oportunista de acceso a los entornos de las víctimas para mecanismos secundarios de monetización, como el uso de infraestructura comprometida para enviar mensajes de phishing».

Los investigadores de ciberseguridad han advertido sobre los riesgos que plantean los dispositivos IP KVM (teclado, vídeo, ratón sobre protocolo de Internet) de bajo coste, que pueden otorgar a los atacantes un amplio control sobre los hosts comprometidos.

Las nueve vulnerabilidades, descubiertas por eclipsioabarcan cuatro productos diferentes: GL-iNet Comet RM-1, Angeet/Yeeso ES3 KVM, Sipeed NanoKVM y JetKVM. Los más graves permiten que actores no autenticados obtengan acceso de root o ejecuten código malicioso.

«Los temas comunes son condenatorios: falta de validación de firma de firmware, falta de protección de fuerza bruta, controles de acceso rotos e interfaces de depuración expuestas», investigadores Paul Asadoorian y Reynaldo Vasquez García. dicho en un análisis.

Dado que los dispositivos IP KVM permiten el acceso remoto al teclado, la salida de video y la entrada del mouse de la máquina de destino a nivel BIOS/UEFI, la explotación exitosa de las vulnerabilidades en estos productos puede exponer los sistemas a posibles riesgos de adquisición, socavando los controles de seguridad implementados. La lista de deficiencias es la siguiente:

• CVE-2026-32290 (Puntuación CVSS: 4,2) – Una verificación insuficiente de la autenticidad del firmware en GL-iNet Comet KVM (se está planificando una solución)
• CVE-2026-32291 (Puntuación CVSS: 7,6) – Una vulnerabilidad de acceso raíz al receptor-transmisor asíncrono universal (UART) en GL-iNet Comet KVM (se está planificando una solución)
• CVE-2026-32292 (Puntuación CVSS: 5,3) – Una vulnerabilidad de protección de fuerza bruta insuficiente en GL-iNet Comet KVM (corregido en la versión 1.8.1 BETA)
• CVE-2026-32293 (Puntuación CVSS: 3.1) – Un aprovisionamiento inicial inseguro a través de una vulnerabilidad de conexión a la nube no autenticada en GL-iNet Comet KVM (corregido en la versión 1.8.1 BETA)
• CVE-2026-32294 (Puntuación CVSS: 6.7) – Una vulnerabilidad de verificación de actualización insuficiente en JetKVM (corregido en la versión 0.5.4)
• CVE-2026-32295 (Puntuación CVSS: 7.3) – Una vulnerabilidad de limitación de velocidad insuficiente en JetKVM (corregido en la versión 0.5.4)
• CVE-2026-32296 (Puntuación CVSS: 5.4) – Una vulnerabilidad de exposición del punto final de configuración en Sipeed NanoKVM (corregido en NanoKVM versión 2.3.1 y NanoKVM Pro versión 1.2.4)
• CVE-2026-32297 (Puntuación CVSS: 9,8) – Autenticación faltante para una vulnerabilidad de función crítica en Angeet ES3 KVM que conduce a la ejecución de código arbitrario (no hay solución disponible)
• CVE-2026-32298 (Puntuación CVSS: 8,8) – Una vulnerabilidad de inyección de comandos del sistema operativo en Angeet ES3 KVM que conduce a la ejecución de comandos arbitrarios (no hay solución disponible)

«Estos no son días cero exóticos que requieren meses de ingeniería inversa», señalaron los investigadores. «Estos son controles de seguridad fundamentales que cualquier dispositivo en red debe implementar. Validación de entrada. Autenticación. Verificación criptográfica. Limitación de velocidad. Estamos viendo la misma clase de fallas que afectaron a los primeros dispositivos IoT hace una década, pero ahora en una clase de dispositivo que proporciona el equivalente de acceso físico a todo lo que se conecta».

Un adversario puede utilizar estos problemas como arma para inyectar pulsaciones de teclas, arrancar desde medios extraíbles para evitar el cifrado del disco o las protecciones de arranque seguro, eludir las pantallas de bloqueo y los sistemas de acceso y, lo que es más importante, permanecer sin ser detectado por el software de seguridad instalado en el nivel del sistema operativo.

Esta no es la primera vez que se revelan vulnerabilidades en dispositivos IP KVM. En julio de 2025, el proveedor ruso de ciberseguridad Positive Technologies señaló cinco defectos en conmutadores ATEN International (CVE-2025-3710, CVE-2025-3711, CVE-2025-3712, CVE-2025-3713 y CVE-2025-3714) que podrían allanar el camino para la denegación de servicio o la ejecución remota de código.

Es más, los trabajadores de TI norcoreanos que residen en países como China han utilizado conmutadores KVM IP como PiKVM o TinyPilot para conectarse de forma remota a computadoras portátiles proporcionadas por la empresa alojadas en granjas de computadoras portátiles.

Como mitigaciones, se recomienda aplicar la autenticación multifactor (MFA) cuando sea compatible, aislar los dispositivos KVM en una VLAN de administración dedicada, restringir el acceso a Internet, usar herramientas como Shodan para verificar la exposición externa, monitorear el tráfico de red inesperado hacia/desde los dispositivos y mantener el firmware actualizado.

«Un KVM comprometido no es como un dispositivo IoT comprometido ubicado en su red. Es un canal directo y silencioso hacia cada máquina que controla», dijo Eclypsium. «Un atacante que compromete el KVM puede ocultar herramientas y puertas traseras en el propio dispositivo, reinfectando constantemente los sistemas host incluso después de la reparación».

«Dado que algunas actualizaciones de firmware carecen de verificación de firma en la mayoría de estos dispositivos, un atacante de la cadena de suministro podría alterar el firmware en el momento de la distribución y hacer que persista indefinidamente».

Cuando una carga útil de Magecart se esconde dentro de los datos EXIF ​​de un favicon de terceros cargado dinámicamente, ningún escáner de repositorio la detectará, porque el código malicioso nunca toca su repositorio. A medida que los equipos adoptan Claude Code Security para el análisis estático, este es el límite técnico exacto donde se detiene el escaneo del código de IA y comienza la ejecución del tiempo de ejecución del lado del cliente.

Está disponible un análisis detallado de dónde se detiene Claude Code Security y qué cubre el monitoreo del tiempo de ejecución. aquí.

A Desnatador de carro mágico descubierto recientemente en la naturaleza utilizaba una cadena de carga de tres etapas para ocultar su carga útil dentro de los metadatos EXIF ​​de un favicon: nunca tocaba el código fuente del comerciante, nunca aparecía en un repositorio y se ejecutaba completamente en el navegador del comprador al momento de pagar. El ataque plantea una pregunta que vale la pena precisar: ¿qué categoría de herramienta se supone que debe detectar esto?

Magecart vive fuera de su código base

Los ataques al estilo Magecart rara vez se refieren a vulnerabilidades clásicas en su propio código fuente. Son infiltraciones en la cadena de suministro. El JavaScript malicioso generalmente llega a través de activos de terceros comprometidos: administradores de etiquetas, widgets de pago/pago, herramientas de análisis, scripts alojados en CDN e imágenes que se cargan en el navegador en tiempo de ejecución. La organización víctima no escribió ese código, no lo revisa en las relaciones públicas y, a menudo, ni siquiera existe en su repositorio.

Eso significa que una herramienta de análisis estático basada en repositorio, como Claude Code Security, está limitada por diseño en este escenario, porque solo puede analizar lo que hay en el repositorio o lo que usted le proporciona explícitamente. Cualquier skimmer que viva únicamente en recursos de terceros modificados o archivos binarios cargados dinámicamente en producción nunca entra en su campo de visión. Eso no es un error en el producto; es una discrepancia en el alcance.

El flujo de ataque: cómo se esconde el skimmer

Aquí está el cargador inicial que se ve en los sitios web comprometidos:

Este código auxiliar carga dinámicamente un script desde lo que parece ser una URL CDN legítima de Shopify. Luego, el script cargado construye la URL maliciosa real utilizando matrices de índice ofuscadas:

Una vez decodificado, esto apunta a //b4dfa5[.]xyz/favicon.ico. Lo que sucede a continuación es donde la técnica se vuelve interesante: el script recupera el favicon como datos binarios, analiza los metadatos EXIF ​​para extraer una cadena maliciosa y la ejecuta a través de la nueva Función(): la carga útil se encuentra dentro de los metadatos de la imagen, por lo que es invisible para cualquier cosa que no esté observando el navegador en tiempo de ejecución.

La exfiltración final llama a POST los datos de pago robados de forma silenciosa a un servidor controlado por el atacante:

La cadena tiene cuatro propiedades que son importantes para la discusión sobre herramientas que sigue: el cargador inicial parece una inclusión benigna de terceros; la carga útil está oculta en metadatos de imágenes binarias; la exfiltración ocurre directamente desde el navegador del comprador; y nada de esto requiere tocar el código fuente del propio comerciante.

Lo que Claude Code Security puede y no puede ver

Claude Code Security está diseñado para escanear bases de código, rastrear flujos de datos y sugerir soluciones para vulnerabilidades en el código que usted o sus equipos escriben. Eso lo hace útil para proteger aplicaciones propias, pero también define sus puntos ciegos para esta clase de ataque.

En este escenario, no tiene visibilidad práctica del código malicioso que solo se inyecta en scripts hospedados por terceros, CDN o administradores de etiquetas que nunca se almacenan en sus repositorios. Tampoco puede interrogar cargas útiles ocultas en activos binarios como favicons o imágenes que no forman parte de su árbol de origen. No puede evaluar el riesgo o la reputación activa de los dominios controlados por atacantes que solo aparecen en tiempo de ejecución, y la detección en tiempo real de solicitudes de red anómalas del lado del navegador durante el pago también está fuera de su alcance.

Donde podría contribuir (aunque no como control principal) sería en los casos en que su propio código contenga lógica dinámica de inyección de scripts, un patrón que una herramienta de análisis de código puede marcar como riesgoso. Y si el código propio codifica puntos finales de exfiltración sospechosos o utiliza una lógica de recopilación de datos insegura, el análisis estático puede resaltar esos flujos para su revisión.

Las cuatro filas superiores son las que más importan en un escenario de Magecart, y Claude Code Security no tiene visibilidad en tiempo de ejecución de ninguna de ellas.

Los dos últimos representan una amenaza fundamentalmente diferente: un desarrollador escribe accidentalmente código de apariencia maliciosa en su propio repositorio.

Magecart es un vector, no toda la superficie de ataque

La técnica de esteganografía de favicon anterior es sofisticada, pero es un ejemplo de un patrón más amplio. Los ataques a la cadena de suministro web llegan a través de varios mecanismos distintos, cada uno con la misma característica definitoria: la actividad maliciosa ocurre en tiempo de ejecución, en el navegador, a través de activos que el comerciante no creó. Vea cómo el JavaScript polimórfico generado por IA está aumentando las apuestas →

Algunos otros que vale la pena nombrar:

Inyección maliciosa de iframe. Un widget de terceros comprometido superpone silenciosamente un formulario de pago legítimo con un iframe controlado por un atacante. El usuario ve la página real, pero sus pulsaciones de teclas se envían al atacante. Nada en el repositorio del comerciante cambia.

Abuso del rastreador de píxeles. Los píxeles de análisis y publicidad, casi universales en los sitios de comercio electrónico, se cargan desde CDN externos. Cuando esas CDN se ven comprometidas o se viola el propio proveedor de píxeles, el código de seguimiento que se ejecuta en cada página se convierte en un canal de exfiltración. El código del comerciante todavía llama al mismo punto final de apariencia legítima que siempre llamó.

Recolección de credenciales basada en DOM. Un script cargado a través de un administrador de etiquetas escucha silenciosamente los eventos de los campos de formulario en las páginas de inicio de sesión o de pago, capturando datos antes de enviarlos. El ataque reside completamente en el controlador de eventos registrado en tiempo de ejecución, no en nada que un escáner estático pueda ver.

Cada uno de estos sigue la misma lógica que el caso Magecart: la amenaza vive fuera del repositorio, se ejecuta en un contexto que el análisis estático no puede observar y apunta a la brecha entre lo que usted envió y lo que realmente se ejecuta en los navegadores de sus usuarios. Puedes encontrar el desglose completo de cómo cada vector se asigna a la cobertura de herramientas, y cómo se ve un programa de defensa en profundidad en todos ellos, en la guía vinculada a continuación.

Por qué la supervisión del tiempo de ejecución es fundamental (pero no el único control)

Para amenazas a la cadena de suministro web Al igual que esta campaña de Magecart, el monitoreo continuo de lo que realmente se ejecuta en los navegadores de los usuarios es la capa principal con visibilidad directa del ataque a medida que ocurre. Las plataformas de monitoreo del tiempo de ejecución del lado del cliente responden a un par de preguntas que las herramientas estáticas no pueden responder: «¿Qué código se está ejecutando en los navegadores de mis usuarios en este momento y qué está haciendo?»

Al mismo tiempo, la supervisión del tiempo de ejecución es sólo una parte del panorama. Funciona mejor como parte de una estrategia de defensa en profundidad. El análisis estático y la gobernanza de la cadena de suministro reducen la superficie de ataque, mientras que el monitoreo del tiempo de ejecución detecta lo que se escapa y lo que queda completamente fuera de sus repositorios.

Replantear la «prueba»: categoría, no capacidad

Evaluar una herramienta centrada en repositorios como Claude Code Security contra un ataque en tiempo de ejecución es un error de categoría, no una falla del producto. Es como esperar que un detector de humo apague un incendio. Es la herramienta equivocada para ese trabajo, pero es la ideal para lo que fue diseñada para hacer. Para un edificio a prueba de incendios, necesita detectores de humo y extintores, y para un sitio web seguro, necesita Claude Code Security y monitoreo del tiempo de ejecución en su pila. Para Magecart y ataques similares de skimming del lado del cliente, necesita esa ventana de ejecución en el navegador. El escaneo de repositorios estáticos, por sí solo, simplemente no ve dónde viven realmente estos ataques.

Si está asignando herramientas a clases de amenazas a nivel CISO, hemos elaborado una breve guía sobre cómo la seguridad del código y el monitoreo del tiempo de ejecución encajan en toda la gama de vectores de la cadena de suministro web y dónde cada uno deja de ser útil.

Guía del CISO sobre seguridad del código Claude →

A los equipos de seguridad de hoy no les faltan herramientas ni datos. Están abrumados por ambos.

Sin embargo, dentro de los terabytes de alertas, exposiciones y configuraciones erróneas, los equipos de seguridad todavía tienen dificultades para comprender el contexto:

P: ¿Qué exposiciones, configuraciones erróneas y vulnerabilidades se encadenan para crear rutas de ataque viables hacia las joyas de la corona?

Incluso los equipos de seguridad más maduros no pueden responder tan fácilmente.

El problema no son las herramientas. Es que las herramientas no se comunican entre sí.

Este es precisamente el problema para el que se diseñó el marco Cybersecurity Mesh Architecture (CSMA) de Gartner, y es lo que Seguridad de malla ha puesto en funcionamiento la primera plataforma CSMA especialmente diseñada del mundo.

En este artículo, veremos qué es CSMA y cómo funciona Mesh CSMA:

• Descubre rutas de ataque hacia las joyas de la corona.
• Prioridades basadas en amenazas activas
• Elimina sistemáticamente las rutas de ataque.

¿Qué es CSMA y por qué es importante ahora?

Antes de sumergirnos en la plataforma, aclaremos qué es CSMA.

CSMAtal como lo define Gartner, es una capa de seguridad distribuida y componible que conecta su pila existente, brindándole la unificación del contexto de una plataforma sobre sus mejores herramientas. Con CSMA, el riesgo se puede entender de manera integral y no en silos.

El problema: las herramientas aisladas pierden la historia del ataque

Todos hemos visto hallazgos como estos en paneles separados:

• Un desarrollador ha instalado un asistente de codificación de IA de aspecto legítimo de VS Code Marketplace
• Esa extensión ha sido marcada como potencialmente troyanizada, pero la alerta se encuentra en una herramienta, desconectada de cualquier otra cosa.
• La estación de trabajo del desarrollador tiene largos tiempos de espera de sesión y no se aplica ninguna política de aislamiento de dispositivos.
• Las credenciales del desarrollador tienen amplio acceso a una cuenta de producción de AWS.
• Esa cuenta de AWS tiene acceso directo y sin restricciones a una base de datos RDS de producción que almacena la PII del cliente.

De forma aislada, cada señal parece manejable: un indicador de política de mercado aquí, una configuración incorrecta del tiempo de espera de sesión allí. Los equipos de seguridad los ven, los registran y les quitan prioridad. Ninguno de ellos parece P1 por sí solo.

Pero unidos, cuentan una historia muy diferente: una ruta de ataque clara y de múltiples saltos desde la estación de trabajo de un desarrollador directamente a los datos más confidenciales de sus clientes. No se ha producido ninguna brecha, pero el camino está abierto, es viable y está a la espera.

Si se añade inteligencia sobre amenazas, el riesgo se vuelve aún más difícil de ignorar: los actores de amenazas se dirigen activamente a los entornos de desarrollo y a los puntos de entrada de la cadena de suministro como su punto de apoyo preferido en la infraestructura de producción. ¿Encadenó sus herramientas marcadas por separado? Se corresponde casi exactamente con su libro de jugadas.

Exposición a amenazas en vivo en malla

Esta es una exposición a una amenaza viva. No es una brecha, sino una ruta explotable que existe en su entorno en este momento, invisible porque ninguna herramienta puede verla toda a la vez.

Eso es exactamente para lo que se creó Mesh CSMA. Al unificar el contexto en toda su pila, Mesh muestra estas rutas de ataque entre dominios antes de que sean explotadas, para que su equipo pueda romper la cadena antes de que un atacante la recorra.

Cómo funciona CSMA en malla

Mesh CSMA convierte señales fragmentadas en historias de amenazas significativas entre dominios. Para que los equipos de seguridad puedan centrarse en lo que importa.

Así es como funciona Mesh.

Paso 1: Conéctese: sin agentes, sin quitar y reemplazar

Mesh comienza integrándose con su pila existente: todas las herramientas, lagos de datos e infraestructura. (¿Con qué se integra Mesh? Ver Más de 150 integraciones aquí.

Integraciones de malla

Paso 2: Ver – The Mesh Context Graph™

A continuación, Mesh descubre automáticamente su Joyas de la Corona: bases de datos de producción, repositorios de datos de clientes, sistemas financieros, infraestructura de firma de código y ancla todo el modelo de riesgo en torno a ellos.

Este es el principio fundamental que hace que Mesh sea diferente: el riesgo se entiende en relación con lo que realmente importa para el negocio, no en relación con las alertas más ruidosas.

A partir de ahí, Mesh construye el Gráfico de contexto de malla™ – un gráfico centrado en la identidad y que se actualiza continuamente de cada entidad en su entorno: usuarios, máquinas, cargas de trabajo, servicios, almacenes de datos y las relaciones entre ellos.

A diferencia de los inventarios de activos, que le indican lo que existe, Mesh Context Graph™ le informa como todo se conecta. Mapea rutas de acceso, relaciones de confianza, cadenas de derechos y exposición de la red en un único modelo unificado, todo rastreado hasta sus Joyas de la Corona.

Gráfico de contexto de malla

Paso 3: Evaluar: descubrimiento de rutas de ataque viables

Aquí es donde Mesh se diferencia de las herramientas tradicionales de gestión de exposición.

Las plataformas CTEM y los escáneres de vulnerabilidades muestran CVE y configuraciones erróneas. Pero una vulnerabilidad CVSS 9.8 en un activo aislado con acceso a Internet sin acceso a nada sensible es un riesgo muy diferente a una mala configuración de CVSS 5.5 en una cuenta de servicio que tiene acceso directo a su base de datos de producción. Mesh entiende la diferencia.

La plataforma correlaciona los hallazgos entre dominios (configuraciones erróneas de la postura en la nube, extralimitación de los derechos de identidad, puntos ciegos de detección, vulnerabilidades sin parches) y los rastrea en el gráfico de contexto para determinar qué combinaciones crean cadenas de ataques viables de múltiples saltos hacia Crown Jewels. Luego, prioriza basándose en inteligencia sobre amenazas en vivo.

El resultado: una lista clasificada y procesable de rutas completas de ataque entre dominios, cada una de las cuales muestra:

• Punto de entrada: cómo un atacante obtendría acceso inicial
• Cadena de pivote: cada salto intermedio a través del entorno
• Objetivo: a qué joya de la corona se puede acceder
• ¿Por qué es viable?: las configuraciones erróneas específicas, las rutas de acceso o las brechas de detección que lo permiten
• Contexto de amenaza: si actores de amenazas activos conocidos están explotando esto actualmente

Exposiciones de la joya de la corona de malla

Con Mesh, puede hacer clic en cada exposición a amenazas en vivo y visualizar la ruta de ataque, convirtiendo señales aisladas en una hoja de ruta significativa para la solución de riesgos.

Visualización de la ruta de ataque de malla

Paso 4: Eliminar – Rompiendo la cadena

Descubrir rutas de ataque es solo la mitad del valor. La malla los cierra.

Para cada ruta de ataque identificada, Mesh genera acciones de remediación específicas y priorizadas asignadas a las herramientas existentes que ya están en su pila. En lugar de una guía genérica como «parchear este CVE», Mesh le indica: revocar este enlace de rol específico, aplicar MFA en esta cuenta de servicio, actualizar esta política CSPM, aislar esta carga de trabajo.

Fundamentalmente, Mesh organiza la corrección en todos los dominios: una única ruta de ataque puede requerir una solución en su herramienta CSPM, un cambio en su plataforma IGA y una actualización de políticas en su solución ZTNA. Mesh coordina esas acciones sin obligar a su equipo a cambiar manualmente de contexto entre consolas.

Paso 5: Defender: validación continua y cobertura de brechas de detección

La malla no se limita a la postura. También valida continuamente su capa de detección, identificando puntos ciegos donde las técnicas de ataque tendrían éxito pero no generarían alertas.

Esto cierra el círculo entre prevención y detección. Los equipos de seguridad pueden ver no sólo donde pueden ir los atacantes pero donde pasarían desapercibidos si lo intentaran. Las brechas de detección surgen junto con las brechas de postura dentro del mismo modelo de riesgo unificado, lo que permite una priorización que refleja el verdadero riesgo comercial.

Mesh reevalúa continuamente el entorno a medida que cambia la infraestructura, se incorporan nuevas herramientas y se actualiza la inteligencia sobre amenazas. El mapa de ruta de ataque nunca es una instantánea de un momento determinado: es un modelo en vivo.

Cronología de la investigación automática de malla

¿Qué lo diferencia de SIEM, XDR o CTEM?

SIEM y XDR detectar amenazas después de que se generan las señales. Se basan en eventos que ya sucedieron y requieren ajustes importantes para reducir los falsos positivos. No modelan rutas de ataque de manera proactiva.

Plataformas CTEM priorizan las vulnerabilidades en función de las puntuaciones de explotabilidad, pero la mayoría opera dentro de un único dominio (nube, punto final, identidad) y luchan por modelar cómo se encadenan los riesgos de diferentes dominios.

Grandes proveedores de plataformas lograr la unificación del contexto, pero a costa de la dependencia de un proveedor y el reemplazo forzoso de herramientas especializadas.

Mesh adopta un enfoque diferente. Alineándose precisamente con lo que Gartner imaginó para CSMA, Mesh unifica el contexto en todas las herramientas, lagos de datos e infraestructura existentes, lo que permite la eliminación continua de la exposición sin necesidad de extraer nada.

¿Para quién está diseñado Mesh?

Mesh CSMA está diseñado para equipos de seguridad que ya han invertido en las mejores herramientas y ahora están lidiando con las consecuencias de la seguridad fragmentada:

• Docenas de paneles, contexto cero
• Datos de seguridad inconexos, que generan ruido en lugar de información
• Correlación manual, conectando los puntos entre herramientas.

La plataforma cerró recientemente una Serie A de 12 millones de dólares liderada por Lobby Capital con la participación de Bright Pixel Capital y S1 (SentinelOne) Ventures.

Su próximo paso: obtenga más información sobre Mesh CSMA

Las herramientas de seguridad muestran riesgos aislados. Mesh muestra rutas de ataque hacia las Joyas de la Corona y las elimina.

¿Quiere ver exposiciones a amenazas en vivo en su entorno? Prueba Mesh gratis durante 7 días.

O regístrese para el seminario web en vivo: ¿Quién puede alcanzar las joyas de su corona? Modelado de rutas de ataque con Mesh CSMA para ver a Mesh identificar rutas de ataque reales en vivo.

Apple lanzó el martes su primera ronda de Mejoras de seguridad en segundo plano para abordar una falla de seguridad en WebKit que afecta a iOS, iPadOS y macOS.

La vulnerabilidad, rastreada como CVE-2026-20643 (Puntuación CVSS: N/A), se ha descrito como un problema de origen cruzado en la API de navegación de WebKit que podría aprovecharse para eludir la política del mismo origen al procesar contenido web creado con fines malintencionados.

La falla afecta a iOS 26.3.1, iPadOS 26.3.1, macOS 26.3.1 y macOS 26.3.2. Se solucionó con una validación de entrada mejorada en iOS 26.3.1 (a), iPadOS 26.3.1 (a), macOS 26.3.1 (a) y macOS 26.3.2 (a). Al investigador de seguridad Thomas Espach se le atribuye el mérito de descubrir e informar la deficiencia.

Manzana notas que las mejoras de seguridad en segundo plano están destinadas a ofrecer versiones de seguridad ligeras para componentes como el navegador Safari, la pila de marco WebKit y otras bibliotecas del sistema a través de parches de seguridad más pequeños y continuos en lugar de publicarlos como parte de actualizaciones de software más grandes.

La función es compatible y está habilitada para versiones futuras a partir de iOS 26.1, iPadOS 26.1 y macOS 26. En los casos en que se descubran problemas de compatibilidad, las mejoras pueden eliminarse temporalmente y luego mejorarse en una actualización de software posterior, agrega Apple.

Los usuarios pueden controlar las mejoras de seguridad en segundo plano a través del menú Privacidad y seguridad en la aplicación Configuración. Para garantizar que se instalen automáticamente, se recomienda mantener activada la opción «Instalar automáticamente».

Vale la pena señalar que si los usuarios optan por desactivar esta configuración, tendrán que esperar hasta que las mejoras se incluyan en la próxima actualización de software. Visto desde esa perspectiva, la función es análoga a Rapid Security Response, que introducido en iOS 16 como una forma de instalar actualizaciones de seguridad menores.

«Si se aplicó una mejora de seguridad en segundo plano y elige eliminarla, su dispositivo vuelve a la actualización de software básica (por ejemplo, iOS 26.3) sin aplicar mejoras de seguridad en segundo plano», señaló Apple en un documento de ayuda.

El desarrollo se produce poco más de un mes después de que Apple publicara correcciones para un día cero explotado activamente que afecta a iOS, iPadOS, macOS Tahoe, tvOS, watchOS y visionOS (CVE-2026-20700, puntuación CVSS: 7,8) y que podría provocar la ejecución de código arbitrario.

La semana pasada, el fabricante de iPhone también amplió los parches para cuatro fallos de seguridad (CVE-2023-43010, CVE-2023-43000, CVE-2023-41974 y CVE-2024-23222) que se utilizaron como parte del kit de exploits Coruña.

Investigadores de ciberseguridad han revelado una falla de seguridad crítica que afecta al demonio telnet GNU InetUtils (telnetd) y que podría ser explotada por un atacante remoto no autenticado para ejecutar código arbitrario con privilegios elevados.

La vulnerabilidad, rastreada como CVE-2026-32746tiene una puntuación CVSS de 9,8 sobre 10,0. Se ha descrito como un caso de escritura fuera de límites en el controlador de subopción Establecer caracteres locales (SLC) de LINEMODE que resulta en un desbordamiento del búfer, lo que en última instancia allana el camino para la ejecución del código.

La empresa israelí de ciberseguridad Dream, que descubrió e informó la falla el 11 de marzo de 2026, dijo que afecta a todas las versiones de la implementación del servicio Telnet hasta la 2.7. Se espera que una solución para la vulnerabilidad esté disponible a más tardar el 1 de abril de 2026.

«Un atacante remoto no autenticado puede aprovechar esto enviando un mensaje especialmente diseñado durante el protocolo de enlace de conexión inicial, antes de que aparezca cualquier mensaje de inicio de sesión», Dream dicho en una alerta. «Una explotación exitosa puede resultar en la ejecución remota de código como root».

«Una única conexión de red al puerto 23 es suficiente para desencadenar la vulnerabilidad. No se requieren credenciales, ninguna interacción del usuario ni una posición especial en la red».

El controlador SLC, según Dream, procesa la negociación de opciones durante el protocolo de enlace Telnet. Pero dado que la falla puede activarse antes de la autenticación, un atacante puede convertirla en un arma inmediatamente después de establecer una conexión enviando mensajes de protocolo especialmente diseñados.

Una explotación exitosa podría comprometer completamente el sistema si telnetd se ejecuta con privilegios de root. Esto, a su vez, podría abrir la puerta a diversas acciones posteriores a la explotación, incluido el despliegue de puertas traseras persistentes, exfiltración de datos y movimiento lateral mediante el uso de hosts comprometidos como puntos de pivote.

«Un atacante no autenticado puede activarlo conectándose al puerto 23 y enviando una subopción SLC diseñada con muchos tripletes». de acuerdo a al investigador de seguridad de Dream, Adiel Sol.

«No es necesario iniciar sesión; el error se detecta durante la negociación de opciones, antes del mensaje de inicio de sesión. El desbordamiento corrompe la memoria y puede convertirse en escrituras arbitrarias. En la práctica, esto puede conducir a la ejecución remota de código. Debido a que telnetd generalmente se ejecuta como root (por ejemplo, bajo inetd o xinetd), un exploit exitoso le daría al atacante control total del sistema».

A falta de una solución, se recomienda desactivar el servicio si no es necesario, ejecutar telnetd sin privilegios de root cuando sea necesario, bloquear el puerto 23 en el perímetro de la red y el nivel del firewall basado en host para restringir el acceso y aislar el acceso a Telnet.

La divulgación se produce casi dos meses después de que se revelara otra falla de seguridad crítica en GNU InetUtils telnetd (CVE-2026-24061, puntuación CVSS: 9,8) que podría aprovecharse para obtener acceso raíz a un sistema de destino. Desde entonces, la vulnerabilidad ha sido objeto de explotación activa en la naturaleza, según la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU.

Investigadores de ciberseguridad han revelado detalles de un nuevo método para extraer datos confidenciales de entornos de ejecución de código de inteligencia artificial (IA) mediante consultas del sistema de nombres de dominio (DNS).

En un informe publicado el lunes, BeyondTrust reveló que el modo sandbox de Amazon Bedrock AgentCore Code Interpreter permite consultas DNS salientes que un atacante puede aprovechar para habilitar shells interactivos y evitar el aislamiento de la red. La emisión, que no tiene un identificador CVE, tiene una puntuación CVSS de 7,5 sobre 10,0.

Intérprete de código de Amazon Bedrock AgentCore es un servicio totalmente administrado que permite a los agentes de IA ejecutar código de forma segura en entornos aislados tipo sandboxde modo que las cargas de trabajo agentes no puedan acceder a sistemas externos. Fue lanzado por Amazon en agosto de 2025.

El hecho de que el servicio permita consultas de DNS a pesar de la configuración de «sin acceso a la red» puede permitir que «los actores de amenazas establezcan canales de comando y control y exfiltración de datos a través de DNS en ciertos escenarios, evitando los controles de aislamiento de red esperados», dijo Kinnaird McQuade, arquitecto jefe de seguridad de BeyondTrust.

En un escenario de ataque experimental, un actor de amenazas puede abusar de este comportamiento para configurar un canal de comunicación bidireccional mediante consultas y respuestas de DNS, obtener un shell inverso interactivo, filtrar información confidencial a través de consultas de DNS si su función de IAM tiene permisos para acceder a recursos de AWS, como depósitos S3 que almacenan esos datos, y ejecutar comandos.

Es más, se puede abusar del mecanismo de comunicación DNS para entregar cargas útiles adicionales que se envían al intérprete de código, lo que hace que sondee el servidor de comando y control (C2) de DNS en busca de comandos almacenados en registros DNS A, los ejecute y devuelva los resultados a través de consultas de subdominio DNS.

Vale la pena señalar que Code Interpreter requiere una función de IAM para acceder a los recursos de AWS. Sin embargo, un simple descuido puede provocar que se asigne una función con privilegios excesivos al servicio, otorgándole amplios permisos para acceder a datos confidenciales.

«Esta investigación demuestra cómo la resolución DNS puede socavar las garantías de aislamiento de la red de los intérpretes de código aislados», dijo BeyondTrust. «Al utilizar este método, los atacantes podrían haber extraído datos confidenciales de los recursos de AWS accesibles a través de la función IAM del intérprete de código, lo que podría causar tiempo de inactividad, violaciones de datos de información confidencial del cliente o infraestructura eliminada».

Tras la divulgación responsable en septiembre de 2025, Amazon determinó que se trataba de una funcionalidad prevista y no de un defecto, e instó a los clientes a utilizar modo VPC en lugar del modo sandbox para un aislamiento completo de la red. El gigante tecnológico también recomienda el uso de un cortafuegos DNS para filtrar el tráfico DNS saliente.

«Para proteger las cargas de trabajo sensibles, los administradores deben inventariar todas las instancias activas de AgentCore Code Interpreter y migrar inmediatamente aquellas que manejan datos críticos del modo Sandbox al modo VPC», dijo Jason Soroko, miembro senior de Sectigo.

«Operar dentro de una VPC proporciona la infraestructura necesaria para un aislamiento sólido de la red, lo que permite a los equipos implementar grupos de seguridad estrictos, ACL de red y firewalls DNS Route53 Resolver para monitorear y bloquear la resolución DNS no autorizada. Finalmente, los equipos de seguridad deben auditar rigurosamente las funciones de IAM adjuntas a estos intérpretes, aplicando estrictamente el principio de privilegio mínimo para restringir el radio de explosión de cualquier posible compromiso».

LangSmith es susceptible a un error de adquisición de cuentas

La divulgación se produce cuando Miggo Security reveló una falla de seguridad de alta gravedad en LangSmith (CVE-2026-25750puntuación CVSS: 8,5) que exponía a los usuarios a un posible robo de tokens y apropiación de cuentas. El problema, que afecta tanto a las implementaciones autohospedadas como a las implementaciones en la nube, se solucionó en la versión 0.12.71 de LangSmith, lanzada en diciembre de 2025.

La deficiencia se ha caracterizado como un caso de inyección de parámetros de URL derivada de una falta de validación en el parámetro baseUrl, lo que permite a un atacante robar el token de portador, la ID de usuario y la ID del espacio de trabajo de un usuario que ha iniciado sesión y transmitidos a un servidor bajo su control mediante técnicas de ingeniería social, como engañar a la víctima para que haga clic en un enlace especialmente diseñado como el siguiente:

• Nube – smith.langchain[.]es/studio/?baseUrl=https://attacker-server.com
• Autohospedado – /studio/?baseUrl=https://attacker-server.com

La explotación exitosa de la vulnerabilidad podría permitir a un atacante obtener acceso no autorizado al historial de seguimiento de la IA, así como exponer consultas SQL internas, registros de clientes de CRM o código fuente propietario mediante la revisión de llamadas a herramientas.

«Un usuario de LangSmith que haya iniciado sesión podría verse comprometido simplemente accediendo a un sitio controlado por un atacante o haciendo clic en un enlace malicioso», afirman los investigadores de Miggo, Liad Eliyahu y Eliana Vuijsje. dicho.

«Esta vulnerabilidad es un recordatorio de que las plataformas de observabilidad de IA son ahora una infraestructura crítica. Como estas herramientas priorizan la flexibilidad de los desarrolladores, a menudo pasan por alto sin darse cuenta las barreras de seguridad. Este riesgo se agrava porque, al igual que el software ‘tradicional’, los agentes de IA tienen acceso profundo a fuentes de datos internas y servicios de terceros».

Defectos de deserialización de pepinillos inseguros en SGLang

También se han señalado vulnerabilidades de seguridad en SGLang, un popular marco de código abierto para servir modelos de lenguaje grandes y modelos de IA multimodal, que, si se explotan con éxito, podrían desencadenar una deserialización insegura de pickle, lo que podría resultar en la ejecución remota de código.

Las vulnerabilidades, descubiertas por el investigador de seguridad de Orca, Igor Stepansky, siguen sin parchearse al momento de escribir este artículo. Una breve descripción de las fallas es la siguiente:

• CVE-2026-3059 (Puntuación CVSS: 9,8): una vulnerabilidad de ejecución remota de código no autenticado a través del broker ZeroMQ (también conocido como ZMQ), que deserializa datos que no son de confianza utilizando pickle.loads() sin autenticación. Afecta al módulo de generación multimodal de SGLang.
• CVE-2026-3060 (Puntuación CVSS: 9,8): una vulnerabilidad de ejecución remota de código no autenticado a través del módulo de desagregación, que deserializa datos que no son de confianza utilizando pickle.loads() sin autenticación. Afecta al sistema de desagregación paralela del codificador SGLang.
• CVE-2026-3989 (Puntuación CVSS: 7,8): el uso de una función pickle.load() insegura sin validación y deserialización adecuada en «replay_request_dump.py» de SGLang, que puede explotarse proporcionando un archivo pickle malicioso.

«Los dos primeros permiten la ejecución remota de código no autenticado contra cualquier implementación de SGLang que exponga sus características de generación o desagregación multimodal a la red», Stepansky dicho. «El tercero implica una deserialización insegura en una utilidad de reproducción de volcado de memoria».

En un aviso coordinado, el Centro de Coordinación CERT (CERT/CC) dijo que SGLang es vulnerable a CVE-2026-3059 cuando el sistema de generación multimodal está habilitado, y a CVE-2026-3060 cuando el sistema de desagregación paralela del codificador está habilitado.

«Si se cumple cualquiera de las condiciones y un atacante conoce el puerto TCP en el que el corredor ZMQ está escuchando y puede enviar solicitudes al servidor, puede explotar la vulnerabilidad enviando un archivo pickle malicioso al corredor, que luego lo deserializará», CERT/CC dicho.

Se recomienda a los usuarios de SGLang restringir el acceso a las interfaces del servicio y asegurarse de que no estén expuestos a redes que no sean de confianza. También se recomienda implementar controles de acceso y segmentación de red adecuados para evitar la interacción no autorizada con los puntos finales de ZeroMQ.

Si bien no hay evidencia de que estas vulnerabilidades hayan sido explotadas en la naturaleza, es crucial monitorear conexiones TCP entrantes inesperadas al puerto del corredor ZeroMQ, procesos secundarios inesperados generados por el proceso SGLang Python, creación de archivos en ubicaciones inusuales por el proceso SGLang y conexiones salientes del proceso SGLang a destinos inesperados.