Los investigadores han descubierto un segundo caso de presuntos piratas informáticos rusos que reutilizaron exploits de iOS que se cree que fueron creados originalmente en nombre del gobierno de los EE. UU., lo que señala lo que dicen que son varias tendencias premonitorias.

iVerificar, Estar atento y Google colaboraron en la investigación publicada el miércoles, una continuación de revelaciones anteriores sobre un kit de explotación similar, Coruña. Si bien el segundo kit, denominado DarkSword, también estaba dirigido a usuarios en Ucrania, la escala es significativa: iVerify estimó que hasta 270 millones de usuarios de iPhone podrían ser susceptibles, mientras que Lookout le dijo a CyberScoop que aproximadamente el 15% de todos los dispositivos iOS actualmente en uso ejecutan iOS 18 o versiones anteriores y podrían ser vulnerables al kit de explotación.

La investigación revela una serie de nuevos detalles, así como patrones interesantes:

• Mientras que los piratas informáticos rusos y chinos utilizaron Coruña con fines de lucro, hay indicios de que DarkSword podría servir tanto para fines financieros como de vigilancia, y/o podría usarse para infligir daño.
• Lookout observó que alguien utilizó un modelo de lenguaje grande para personalizar tanto Coruña como DarkSword.
• El descubrimiento de DarkSword refuerza las preocupaciones anteriores sobre un mercado secundario de exploits, dijeron Lookout e iVerify.
• DarkSword es la segunda campaña «masiva» de iOS descubierta este mes, siendo la primera conocida Coruña.
• Ambos kits sugieren que los ciberataques están migrando hacia los teléfonos móviles, ya que representan una mayor porción del tráfico de Internet, dijo a CyberScoop Rocky Cole, cofundador y director de operaciones de iVerify.
• Google también descubrió que DarkSword se utilizó contra objetivos en Arabia Saudita, Turquía y Malasia.

DarkSword puede filtrar contraseñas guardadas, billeteras criptográficas, mensajes de texto y más, según descubrieron los investigadores. Los atacantes están aprovechando el kit de explotación comprometiendo primero el WebKit de Apple y luego usando WebGPU como punto de pivote para escapar de la zona de pruebas, según Justin Albrecht, director global de inteligencia de amenazas móviles de Lookout.

Lo que no está tan claro es quién, exactamente, está detrás del kit de exploits, además de los vínculos con Rusia. Cole dijo que DarkSword está alojado en la misma infraestructura de comando y control que Coruña, pero es un kit completamente separado creado por personas completamente diferentes. Google ha atribuido las campañas a un grupo al que rastrea como UNC6353, al que describe como un grupo de espionaje respaldado por Rusia, así como UNC6748 y el proveedor turco de vigilancia comercial PARS Defense.

Los motivos de los atacantes también son un poco opacos, mezclando lo que parecen ser tanto espionaje como objetivos financieros. Albrecht señaló que hay un precedente para esto: los grupos de amenazas rusos han atacado las criptomonedas en Ucrania antes, en particular con Infamous Chisel, un kit de explotación de Android implementado por Sandworm.

«Probablemente estén bien financiados y bien conectados, pero se ha confirmado que están robando criptomonedas. Definitivamente hay una motivación financiera», dijo Albrecht a CyberScoop. «Ahora, creo que la gran pregunta es, dependiendo de quién sea el grupo, ¿la motivación financiera en esto es simplemente hacer daño a los ucranianos o es robar criptomonedas?»

Rusia ha estado bajo duras sanciones durante mucho tiempo y está empezando a tener problemas presupuestarios debido a la guerra en curso en Ucrania, señaló. «¿Por qué no empezar a financiar sus operaciones con fondos robados? No estaría fuera de la norma, aunque sería un cambio potencial en sus TTP para las APT rusas en general», dijo Albrecht.

El kit podría ser útil para alguien que intente hacer un análisis de “patrones de vida”, dijo Cole, y por lo tanto útil para fines de vigilancia e inteligencia.

Dijo que un proveedor comercial de software espía podría haber fabricado el kit sin ningún público objetivo en mente, de ahí su calidad de “navaja suiza”. La principal preocupación para Cole es que aparentemente hay un mercado creciente para este tipo de herramientas, y la gente puede sentirse adormecida con una falsa sensación de seguridad acerca de que los iPhone no son vulnerables.

A pesar de la sofisticación de los exploits en sí, los actores de amenazas detrás de DarkSword pueden no tener mucha experiencia, dijo Albrecht. Ninguno de los códigos JavaScript o HTML estaba ofuscado de ninguna manera, y el componente del lado del servidor estaba etiquetado como “Receptor de archivos Dark Sword”, una seguridad operativa deficiente para un actor de amenazas ruso experimentado.

“Yo esperaría que sus experimentados actores de amenazas rusos, sus APT29 del mundo, tuvieran mejores OPSEC”, dijo Albrecht.

Uno de los hallazgos más inusuales de la investigación es la clara presencia de código generado por modelos de lenguaje de gran tamaño. El componente del lado del servidor de DarkSword, por ejemplo, incluye signos reveladores de código generado por IA, completo con notas detalladas y comentarios característicos del resultado LLM. Es un desarrollo que efectivamente reduce la barrera de entrada para el despliegue de exploits móviles avanzados, incluso entre actores patrocinados por el estado, dijo Albrecht.

Los tres equipos de investigación han estado en contacto con Apple sobre los hallazgos, según Albrecht, y es probable que Google haya estado en contacto más cercano desde que comenzaron a investigar la amenaza a fines de 2025. En su blog, Google dijo que informó a Apple de las vulnerabilidades utilizadas en DarkSword a fines de 2025, y que todas las vulnerabilidades fueron reparadas con el lanzamiento de iOS 26.3, aunque la mayoría fueron parcheadas antes.

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.

Una falla de seguridad de alta gravedad que afecta las instalaciones predeterminadas de las versiones 24.04 y posteriores de Ubuntu Desktop podría aprovecharse para escalar privilegios al nivel raíz.

Seguimiento como CVE-2026-3888 (Puntuación CVSS: 7,8), el problema podría permitir a un atacante tomar el control de un sistema vulnerable.

«Esta falla (CVE-2026-3888) permite a un atacante local sin privilegios escalar privilegios a acceso raíz completo mediante la interacción de dos componentes estándar del sistema: snap-confine y systemd-tmpfiles», informó la Unidad de Investigación de Amenazas de Qualys (TRU) dicho. «Si bien el exploit requiere una ventana de tiempo específica (10 a 30 días), el impacto resultante es un compromiso total del sistema host».

El problema, señaló Qualys, surge de la interacción no intencionada de snap-confine, que administra los entornos de ejecución para aplicaciones instantáneas mediante la creación de un entorno limitado, y systemd-tmpfiles, que limpia automáticamente archivos y directorios temporales (por ejemplo,/tmp, /run y /var/tmp) más antiguos que un umbral definido.

La vulnerabilidad ha sido parcheada en las siguientes versiones:

• Ubuntu 24.04 LTS: versiones snapd anteriores a 2.73+ubuntu24.04.1
• Ubuntu 25.10 LTS: versiones snapd anteriores a 2.73+ubuntu25.10.1
• Ubuntu 26.04 LTS (Dev): versiones snapd anteriores a 2.74.1+ubuntu26.04.1
• Snapd ascendente: versiones anteriores a 2.75

El ataque requiere privilegios bajos y ninguna interacción del usuario, aunque la complejidad del ataque es alta debido al mecanismo de retardo en la cadena de explotación.

«En las configuraciones predeterminadas, systemd-tmpfiles está programado para eliminar datos obsoletos en /tmp», dijo Qualys. «Un atacante puede aprovechar esto manipulando el momento de estos ciclos de limpieza».

El ataque se desarrolla de la siguiente manera:

• El atacante debe esperar a que el demonio de limpieza del sistema elimine un directorio crítico (/tmp/.snap) requerido por snap-confine. El período predeterminado es de 30 días en Ubuntu 24.04 y de 10 días en versiones posteriores.
• Una vez eliminado, el atacante recrea el directorio con cargas útiles maliciosas.
• Durante la siguiente inicialización de la zona de pruebas, ajuste el ajuste unir montajes estos archivos como raíz, lo que permite la ejecución de código arbitrario dentro del contexto privilegiado.

Además, Qualys dijo que descubrió una falla en la condición de carrera en el paquete uutils coreutils que permite a un atacante local sin privilegios reemplazar entradas de directorio con enlaces simbólicos (también conocidos como enlaces simbólicos) durante ejecuciones cron de propiedad raíz.

«La explotación exitosa podría conducir a la eliminación arbitraria de archivos como raíz o a una mayor escalada de privilegios al apuntar a directorios de espacio aislado», dijo la compañía de ciberseguridad. «La vulnerabilidad se informó y mitigó antes del lanzamiento público de Ubuntu 25.10. El comando rm predeterminado en Ubuntu 25.10 se revirtió a GNU coreutils para mitigar este riesgo de inmediato. Desde entonces, se han aplicado correcciones iniciales al repositorio de uutils».

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.

El gobierno de Estados Unidos no debería ceñirse rígidamente a las designaciones tradicionales sobre qué agencia toma la iniciativa en la interacción con sectores de infraestructura críticos, dijo el martes el director interino de la Agencia de Seguridad de Infraestructura y Ciberseguridad.

Las designaciones de agencias de gestión de riesgos sectoriales han determinado durante mucho tiempo qué agencia está a la vanguardia de los esfuerzos gubernamentales para proteger cada uno de los 16 sectores de infraestructura crítica, siendo CISA responsable de ocho de ellos.

«Cuando analizamos la estructura de nuestra agencia de gestión de riesgos del sector, eso es importante por muchas razones. Es menos importante cumplir con eso estrictamente y decir 'CISA es la Agencia de Gestión de Riesgos del Sector para las telecomunicaciones'», dijo Nick Andersen de CISA en un evento organizado por el Instituto McCrary de la Universidad de Auburn.

Más bien, al responder a incidentes cibernéticos o emprender otros compromisos con el sector privado, la pregunta debería ser quién tiene la mejor relación con un determinado sector.

«Es posible que tengamos algunos propietarios-operadores dentro de un determinado sector de infraestructura crítica y tal vez la persona de la que estén mejor posicionados para recibir recursos seamos nosotros, o tal vez sea [Department of] Energía, o tal vez sea la EPA, o tal vez sea el FBI o la NSA, etc., etc.», dijo. «Simplemente tenemos que sentirnos cómodos quitándonos esas anteojeras y diciendo: 'No necesariamente necesito estar a cargo todo el tiempo, sin importar quién sea'. Sólo necesito asegurarme de que este propietario-operador tenga el mejor socio preparado para liderar ese compromiso'”.

El objetivo es evitar otra “situación en Guam”, en la que “todo el mundo corría hacia Guam durante los últimos años como niños persiguiendo un balón de fútbol”, dijo Andersen. Guam fue escenario de ataques a infraestructuras críticas contra bases militares estadounidenses que Microsoft atribuyó al grupo de hackers chino Volt Typhoon en 2023.

Un ataque al sector de las telecomunicaciones por parte de otro grupo “Typhoon”, Salt Typhoon, generó dudas sobre si CISA tiene las manos demasiado ocupadas con todas sus responsabilidades como agencia de gestión de riesgos del sector. El presidente de Seguridad Nacional de la Cámara de Representantes, Andrew Garbarino, RN.Y., planteó preocupaciones el año pasado sobre cómo CISA manejó su papel de agencia de gestión de riesgos sectoriales para el sector de las telecomunicaciones después de que se descubriera la campaña del tifón de sal.

El director nacional cibernético, Sean Cairncross, dijo el martes que la administración Trump no aspira a reclutar al sector privado para realizar operaciones cibernéticas ofensivas, sino a ayudar al gobierno manteniéndolo al tanto de las amenazas que enfrenta.

La estrategia cibernética nacional recientemente publicada habla de incentivar a las empresas para que interrumpan las redes de los adversarios.

«No me refiero al sector privado, la industria o las empresas que participan en una campaña ciberofensiva», dijo Cairncross en un evento organizado por el Instituto McCrary de la Universidad de Auburn. “A lo que me refiero es a las capacidades técnicas, la capacidad de nuestro sector privado para iluminar el campo de batalla a partir de lo que están viendo, para informar y compartir información para que el gobierno de los EE.UU. [U.S. government] puedo responder para adelantarme a las cosas”.

La idea de permitir a las empresas estadounidenses emprender campañas disruptivas u ofensivas contra piratas informáticos malintencionados, o al menos ayudar en las operaciones ofensivas del gobierno estadounidense, ha vuelto a ganar fuerza en algunos círculos republicanos en los últimos años. Algunas empresas han mostrado interés en hacerlo, especialmente si se cambian las leyes para hacerlo más viable.

Esa tendencia coincide con los crecientes llamados de los funcionarios de la administración Trump (y ahora con la publicación de la estrategia de ciberseguridad) para pasar a la ofensiva contra los piratas informáticos, aunque Cairncross enfatizó nuevamente que el pilar de la estrategia para “dar forma al comportamiento del adversario” no se trata solo de llevar a cabo campañas ciberofensivas, sino de utilizar otros mecanismos gubernamentales para presionar a los piratas informáticos, ya sean legales o diplomáticos.

El gobierno puede dar forma al «cálculo de riesgo» «de una manera más ágil» con la ayuda del sector privado, dijo.

Hay una enorme capacidad por parte del sector privado, y ahora tenemos una lanza del gobierno de Estados Unidos… estamos buscando una asociación real”, dijo Cairncross.

Una forma en la que el gobierno estadounidense ha tratado de llevar la lucha a los ciberadversarios son las “operaciones conjuntas secuenciadas” del FBI, utilizadas para degradar sus capacidades. En el mismo evento, el jefe de la división cibernética de la oficina dijo que el sector privado también era clave para esas operaciones.

“Cada una de las operaciones conjuntas secuenciadas que lleva a cabo el FBI para eliminar esa capacidad de la que hablé (de los rusos, de los chinos, de los iraníes y otros) ocurre porque una víctima se presentó y se comprometió con el FBI”, dijo Brett Leatherman.

“Una conclusión para todos aquí es '¿Cuál es su plan de acción en caso de una infracción para involucrar a su oficina local del FBI?'”, preguntó. «Yo diría que hay muy poca responsabilidad al hacerlo, y estamos felices de tener conversaciones con sus abogados externos o internos, pero hay mucho que ganar al hacerlo».

Un tribunal federal de apelaciones suspendió temporalmente una orden de un juez de California que habría impedido a Perplexity AI utilizar un agente de compras impulsado por inteligencia artificial en Amazon, mientras el caso avanza en una disputa sobre quién controla la actividad automatizada dentro de las cuentas de los clientes.

El Tribunal de Apelaciones del Noveno Circuito de EE. UU. concedió el lunes a Perplexity una suspensión administrativa, suspendiendo la orden judicial mientras el tribunal considera la solicitud de la compañía de una pausa más prolongada durante su apelación. La orden del tribunal inferior debía entrar en vigor en unos días.

Amazon demandó a Perplexity en noviembre, alegando que el navegador Comet de la startup y el agente de inteligencia artificial asociado accedieron a partes protegidas con contraseña de las cuentas de los clientes de Amazon sin la autorización de Amazon, incluso cuando los usuarios permitieron que la herramienta actuara en su nombre. Amazon también acusó a Perplexity de disfrazar la actividad automatizada como navegación humana y de ignorar las repetidas demandas para que se detuviera.

La jueza de distrito estadounidense Maxine Chesney en San Francisco aceptó la solicitud de Amazon de una orden judicial preliminar el 9 de marzo. Escribió que era probable que Amazon tuviera éxito en las demandas bajo la Ley federal de abuso y fraude informático y la Ley integral de fraude y acceso a datos informáticos de California. Chesney dijo que Amazon había proporcionado pruebas sólidas de que Perplexity accedió a las cuentas «con el permiso del usuario de Amazon pero sin la autorización de Amazon».

La orden de Chesney requería que Perplexity prohibiera a Comet acceder o intentar acceder a las cuentas de usuario de Amazon y eliminar las cuentas de Amazon y los datos de los clientes que recopilaba. Chesney también citó la evidencia de Amazon sobre los costos de respuesta, incluido el tiempo de los empleados dedicado a desarrollar herramientas para bloquear Comet y detectar accesos futuros, y escribió que la compañía incurrió en una cantidad superior al umbral utilizado a menudo para respaldar las reclamaciones de fraude informático.

Perplexity argumenta que la actividad es legal porque los usuarios autorizaron al agente de IA a realizar compras y navegar por el sitio en su nombre. Al buscar una pausa, la compañía dijo que bloquear su producto en uno de los sitios de compras más grandes de Internet causaría un «daño devastador» a la empresa y a los consumidores.

Un portavoz de Perplexity dijo a CyberScoop el martes que la compañía continuaría luchando por «el derecho de las personas a elegir su propia IA». Amazon se negó a hacer comentarios.

El caso subraya los problemas con las herramientas de inteligencia artificial «agentes» que pasan de responder preguntas a iniciar transacciones. Se está pidiendo a los tribunales que comparen el permiso del usuario con la autorización de la plataforma y que decidan si los representantes automatizados deben seguir las reglas de la plataforma diseñadas para limitar los bots no divulgados en áreas sensibles de la cuenta.