Una organización sin fines de lucro francesa inicia un centro global de inteligencia e investigación para las ciberamenazas de la IA

El Foro de Paz de París, una organización francesa sin fines de lucro que ha convocado a líderes mundiales sobre cuestiones de seguridad global, está lanzando un nuevo proyecto para reunir a expertos internacionales para evaluar las amenazas relacionadas con la IA a la infraestructura global de Internet.

La Red Integrada para una IA confiable en el ciberespacio (INTAiC) recurrirá a investigadores y expertos de la sociedad civil del gobierno y el sector privado, analizará las amenazas cibernéticas actuales de la IA desde el campo y creará informes «con visión de futuro» sobre cómo la tecnología afectará a la sociedad y qué pueden hacer las organizaciones para responder.

Uno de los principales objetivos del proyecto es crear una coalición internacional de respuesta rápida entre gobiernos y empresas para abordar las amenazas relacionadas con la IA, similar a los mecanismos de coordinación que existen en otras áreas de la ciberseguridad.

«La fragmentación de la evidencia sobre las amenazas cibernéticas impulsadas por la IA no es incidental, es estructural: quienes defienden las redes y quienes protegen los sistemas de IA han trabajado durante mucho tiempo en esferas separadas», dijo Adrien Abecassis, director de iniciativas políticas del Foro de Paz de París. «Es exactamente por eso que INTAiC es único: está diseñado para convertir esos fragmentos en una lectura comparable de la amenaza, porque este es un desafío que ningún actor puede afrontar solo».

La red ya incluye una serie de empresas y organizaciones destacadas, incluidas Microsoft, Cyber ​​Threat Alliance, Cloud Security Alliance, Orange Cyberdefense y otras.

Según el foro, el trabajo del INTAiC se centrará principalmente en dos líneas de trabajo separadas. Uno es un recurso único y actualizado periódicamente para que los defensores se mantengan actualizados sobre cómo la IA está remodelando las ciberamenazas. El recurso se centra más en las capacidades de los atacantes, las diferentes formas de uso indebido y el impacto en las operaciones de seguridad que en incidentes aislados.

«El resultado es un punto de referencia común, basado en la realidad, que brinda a los formuladores de políticas una medida más clara de la amenaza e identifica los riesgos que más merecen atención colectiva», dijo el Foro en un comunicado.

El segundo flujo de trabajo se centrará en evaluar y prevenir los riesgos cibernéticos asociados con la IA, creando una base de expertos externos independientes que puedan proporcionar evaluaciones neutrales o imparciales de las capacidades cibernéticas del modelo de frontera. Ese trabajo atraerá a gobiernos, instituciones de investigación y organizaciones sin fines de lucro a desarrollar nuevas vías organizativas y de financiación para apoyar ese tipo de investigación.

Si bien el gobierno federal de EE. UU. ha recorrido un largo camino en los últimos años para desarrollar su propia capacidad para probar y estudiar las amenazas cibernéticas de la IA, gran parte del acceso y la experiencia técnica en torno a las capacidades de los modelos de frontera se concentran en las empresas comerciales de IA. En ocasiones, esto ha generado preocupaciones de que las agencias federales dependieran demasiado de las empresas de inteligencia artificial para explicar cómo funciona la tecnología y guiarlas a través de los posibles escenarios de amenaza.

A medida que Anthropic y OpenAI han implementado programas de ciberseguridad defensiva como el Proyecto Glasswing y el programa Trusted Access for Cyber, el acceso a esos modelos ha estado disponible para un grupo más amplio de investigadores y organizaciones.

El Foro de Paz de París tiene la intención de informar al público sobre el trabajo y los logros de INTAiC en París a finales de este año durante la conferencia anual de la organización en noviembre.

Derek B. Johnson

Escrito por Derek B. Johnson

Derek B. Johnson es reportero de CyberScoop, donde su área incluye la ciberseguridad, las elecciones y el gobierno federal. Antes de eso, ha brindado una cobertura galardonada de noticias sobre ciberseguridad en los sectores público y privado para varias publicaciones desde 2017. Derek tiene una licenciatura en periodismo impreso de la Universidad de Hofstra en Nueva York y una maestría en políticas públicas de la Universidad George Mason en Virginia.

Las confirmaciones ‘verificadas’ de GitHub se pueden reescribir en nuevos hashes sin romper las firmas – CYBERDEFENSA.MX

Una nueva investigación muestra que el hash de un compromiso Git firmado no es el nombre único que gran parte del mundo del software supone que es. Dada cualquier confirmación firmada, alguien sin la clave de firma puede crear una segunda confirmación con los mismos archivos, autor y fecha, y una firma válida, GitHub aún marca «Verificado».

Todo lo que un crítico comprobaría coincide. El hash del compromiso no. Esto es importante porque muchos sistemas tratan un hash de confirmación verificado como un nombre único y permanente para su contenido.

Aquí está el fallo concreto: bloquear una confirmación incorrecta mediante su hash, y un atacante puede volver a enviar el mismo contenido bajo un hash nuevo y aún «verificado» que su lista de bloqueo nunca ha visto. La deduplicación, los registros de procedencia y los registros de compilación reproducible que codifican el hash heredan el mismo punto débil.

Un espejo comprometido u hostil puede entregar a los clonadores confirmaciones firmadas válidamente cuyos hashes difieren de los de la forja canónica.

Lo que esto no es es una forma de pasar un código diferente por una verificación de firma. Los archivos son idénticos en cada copia, por lo que un hash que fijó aún obtiene exactamente el contenido que esperaba o falla.

No hay CVE ni avisos de proveedores, y no hay nada que cambiar en su propio repositorio: la falla está en cómo una falsificación decide qué significa «Verificado», y la solución pertenece al lado de la falsificación.

Ciberseguridad

El trabajo proviene de Jacob Ginesinestudiante de doctorado en la Universidad Carnegie Mellon y auditor criptográfico en Cure53. Su artículo de cinco páginas, publicado en arXiv el 2 de julio, viene con un herramienta publica que ejecuta los tres ataques, además de dos repositorios de demostración donde las confirmaciones maltratadas todavía muestran «Verificado» en GitHub.

Debido a que cada confirmación nombra a su padre mediante hash, maltratar una confirmación fuerza nuevos hashes en las confirmaciones que se encuentran encima de ella. La herramienta reescribe esa cadena para mantenerla consistente. Sin embargo, un descendiente firmado pierde su propia insignia en el momento en que cambia su puntero principal. Ginesin llama al efecto «maleabilidad de la cadena hash«.

La causa es la maleabilidad característica. El hash de una confirmación se calcula sobre todo lo que contiene, incluidos los bytes sin procesar de la firma en su encabezado. Muchas firmas se pueden reescribir en una forma diferente pero aún válida, y cambiar esos bytes cambia el hash sin tocar una línea de código.

Las tres rutas cubren todos los esquemas GPG que GitHub verifica, además de S/MIME:

  • Claves ECDSA: voltea la firma con una pieza clásica de álgebra de curva elíptica (convierte el valor s en n – s). Ambas formas son válidas. Esto pasa un compromiso de verificación de git local y obtiene una insignia de GitHub.
  • Claves RSA y EdDSA: agregue un campo adicional ignorado a la sección «sin hash» de la firma, la parte que la firma deliberadamente no cubre. La firma aún se verifica, pero los bytes de la confirmación y su hash cambian. Tanto Local como GitHub lo aceptan.
  • Teclas S/MIME (X.509): reescriba un campo de longitud en la estructura DER de la firma en una forma más larga y no estándar. Una verificación local estricta (a través de gpgsm) lo rechaza, pero GitHub aún lo marca como «Verificado», y la herramienta reproduce ambas cosas.

Las tres rutas comparten un habilitador: GitHub no normaliza una firma antes de verificarla. Sin codificación estricta en S/MIME, sin eliminación de esos campos OpenPGP y los valores ECDSA no canónicos se aceptan tal cual.

Luego, GitHub archiva un registro «Verificado» contra cada hash de confirmación y no lo vuelve a verificar, por lo que una confirmación permanece «Verificada» incluso después de que se revoca su clave de firma. Empuje un original y su gemelo a dos ramas, y la vista de comparación de GitHub los tratará como historias divergentes, una confirmación por delante y otra por detrás, a pesar de archivos idénticos.

Para ser claros: esto no es una colisión de hash. No rompe SHA-1 o SHA-256, y no tiene nada que ver con el cambio de Git a SHA-256. Nadie obliga a dos confirmaciones diferentes a compartir un hash; es al revés, una confirmación que se puede escribir de muchas maneras válidas, cada una con su propio hash.

El movimiento central es antiguo. Bitcoin luchó exactamente igual simetría ECDSA Hace años, cuando cualquiera podía invertir el valor s en la firma de una transacción y cambiar el ID de la transacción sin la clave del propietario. La solución fue aceptar solo el formulario «low-S» y luego sacar las firmas del ID con SegWit.

Las correcciones del artículo riman con eso: canonicalizar la codificación antes de confiar en el hash. Una lección conocida, no una criptografía nueva y exótica.

Ciberseguridad

El documento también conecta esto con los recientes secuestros de etiquetas de GitHub Actions, los ataques tj-actions/changed-files de 2025 y los ataques trivy-action de 2026 (cita este último). Después de eso, el consejo fue simple: fijar un hash de confirmación completo, no una etiqueta móvil. Ese consejo sigue siendo válido.

La fijación detuvo esos ataques y esta investigación no cambia eso. Su punto es más estrecho. En el caso Trivy, las confirmaciones maliciosas se destacaron porque no podían firmarse válidamente. Esta es una advertencia contra confiar demasiado en esa indicación: una firma válida prueba quién firmó una confirmación, pero no hace que el hash de la confirmación sea un nombre único para lo que contiene.

Entonces ¿quién tiene que hacer algo? No el desarrollador que fija una acción o un módulo; un hash fijado aún obtiene el código correcto. El trabajo es para las fraguas. El periódico dice que deberían canonicalizar las firmas antes de confiar en ellas.

Las herramientas que bloquean, deduplican o registran la procedencia mediante hash de confirmación deberían hacer lo mismo, verificando y canonicalizando primero en lugar de confiar en el hash sin formato de un objeto firmado que un atacante puede volver a codificar. No todos los sistemas están igualmente expuestos: los esquemas que también fijan un hash independiente de los archivos recuperados, como las derivaciones de salida fija de Nix, mantienen un respaldo; aquellos que se detienen en un hash de confirmación verificado no lo hacen.

Ginesin dice que informó del problema a GNU y Git en enero y a GitHub en marzo, y que hasta la publicación del artículo, ni Git ni ninguna falsificación lo habían abordado. La solución del lado de la falsificación se comprende bien, y el lugar obvio para comenzar es el caso S/MIME, donde GitHub todavía acepta lo que una estricta verificación local rechaza.

La falla de GhostLock de 15 años permite el escape de raíz y contenedor en la mayoría de las distribuciones de Linux – CYBERDEFENSA.MX

Los investigadores de Nebula Security han revelado GhostLock (CVE-2026-43499), una falla del kernel de Linux de hace 15 años que permite a cualquier usuario que haya iniciado sesión tomar el control total de raíz de una máquina que no ha sido parcheada. El código vulnerable se ha incluido de forma predeterminada en prácticamente todas las distribuciones principales desde 2011. La falla no necesita ningún permiso especial, ni configuraciones inusuales ni red.

Las herramientas DEBULL abusan del flujo de código de dispositivo de Microsoft para apuntar a cuentas M365 – CYBERDEFENSA.MX

Se ha observado una campaña de phishing de código de dispositivo Microsoft 365 que aprovecha señuelos con temas de colaboración para tomar el control de las cuentas de las víctimas entre la última semana de junio de 2026 y principios de julio, según recomendaciones de ZeroBEC.

«La campaña no dependía de una página de contraseña falsa de Microsoft. Utilizó un señuelo malicioso de estilo colaborativo para empujar a los usuarios a la experiencia legítima de inicio de sesión del dispositivo Microsoft, mientras que un agente backend generaba y sondeaba tokens de código de dispositivo del Agente de Autenticación de Microsoft», dijo la compañía de seguridad de correo electrónico en un informe compartido con The Hacker News.

Se evalúa que la actividad comparte superposiciones «fuertes» con una campaña documentada por Microsoft en febrero de 2025 bajo el nombre de Storm-2372, incluido el uso de mensajes o señuelos estilo Teams para engañar a víctimas desprevenidas para que ingresen un código de dispositivo proporcionado por el atacante, junto con sus credenciales, lo que permite efectivamente al actor de amenazas recuperar el token y secuestrar su cuenta.

A pesar de estas similitudes, se evalúa que los actores de amenazas están empleando técnicas de estilo Storm-2372 a través de lo que se ha descrito como una capa de herramientas reutilizable llamada DEBULL.

El phishing de código de dispositivo se refiere a una técnica de robo de identidad en la que los atacantes explotan un mecanismo de autenticación OAuth 2.0 legítimo, específicamente el flujo de concesión de autorización de dispositivo, para evitar la autenticación multifactor (MFA) y obtener acceso persistente a la cuenta sin tener que robar las contraseñas de los usuarios.

A diferencia de los ataques de phishing tradicionales que requieren que los operadores configuren páginas de inicio de sesión falsas de adversario en el medio (AitM), el phishing de código de dispositivo se basa en manipular a un usuario para que complete un mensaje de autenticación real y confiable.

Ciberseguridad

Autenticación de código de dispositivo, por microsoftes un flujo OAuth legítimo diseñado para dispositivos con interfaces limitadas, como televisores inteligentes o impresoras, que no pueden admitir un inicio de sesión interactivo tradicional. En este escenario, al usuario se le presenta un código corto en el dispositivo desde el que intenta iniciar sesión y se le solicita que ingrese ese código en un navegador web en un dispositivo separado para completar la autenticación.

Los actores de amenazas tienen abusado esta separación para insertarse y iniciar el flujo de autenticación. Luego, comparten ese código con el objetivo a través de un señuelo de phishing. Así, cuando el usuario ingresa el código, autoriza la sesión del actor de la amenaza sin su conocimiento, otorgándole acceso a la cuenta.

«El phishing del código del dispositivo no se abre camino», Huntress notas. «Utiliza un flujo de autenticación legítimo para atravesar la puerta principal, sin necesidad de contraseña, sin pasar por MFA y con tokens de sesión entregados directamente al atacante».

Los ataques exitosos de phishing de código de dispositivo pueden facilitar la apropiación total de la cuenta, el robo de información valiosa, el fraude, el compromiso del correo electrónico empresarial (BEC), el movimiento lateral dentro de un entorno comprometido e incluso ataques disruptivos como el ransomware.

«En la mayoría de los ataques de phishing de código de dispositivo actuales, el código se genera dinámicamente cuando un usuario hace clic en el enlace de phishing inicial. Este cambio aparentemente pequeño permite al usuario ver el correo electrónico en cualquier momento para iniciar la cadena de ataque», Proofpoint dicho en un análisis publicado en mayo de 2026. «Estas nuevas implementaciones de las cadenas de ataque de código de dispositivo se pueden comprar a través de ofertas de phishing como servicio (PhaaS), como EvilTokens o Tycoon, o pueden ser creadas y propiedad del actor de amenazas que realiza las campañas».

También se sabe que estas campañas aprovechan el salto de toma de control de cuenta (ATO), una técnica en la que un atacante compromete una cuenta de correo electrónico inicial y luego abusa de ella para enviar enlaces de phishing a un conjunto más amplio de contactos en forma de botón, texto con hipervínculo, incrustado en un documento o código QR. Los enlaces, cuando los visita el destinatario, inician una secuencia de ataque que emplea el proceso de autorización de dispositivos de Microsoft.

ZeroBEC dijo que la campaña que observó implica el uso de pretextos de pago y carpetas compartidas en correos electrónicos de phishing para engañar a las víctimas para que hagan clic en una URL que las lleva a un sitio web de alquiler croata legítimo pero comprometido, que, a su vez, actúa como un orquestador de códigos de dispositivos utilizado para iniciar la cadena de desafío de códigos de dispositivos de Microsoft.

El flujo de trabajo se caracteriza por la presencia de marcadores de desarrollador en idioma turco, aunque las pistas no son suficientes para atribuir definitivamente la procedencia de la campaña. Un análisis más detallado de la infraestructura ha revelado que DEBULL es probablemente una plataforma de phishing como servicio (PhaaS) que utiliza GraphSpy o un flujo de trabajo derivado de GraphSpy para Microsoft 365 y Entra post-explotación.

«Los operadores pueden definir un nombre de página y un slug, editar HTML, CSS y JavaScript directamente y luego elegir cómo se publica el señuelo», dijo ZeroBEC. «Las plantillas integradas incluían una página de autenticación de código de dispositivo de Microsoft 365, una página de devolución de llamada de OAuth y una página de inicio moderna. La plantilla de Microsoft 365 es especialmente importante porque expone el bloque de construcción exacto utilizado por la campaña: una visualización del código de usuario, un comportamiento de copia de código y un vínculo para iniciar sesión en el dispositivo de Microsoft».

«La conclusión más útil es que el arte de identidad al estilo Storm-2372 ahora se está empaquetando en una infraestructura de corredor reutilizable. DEBULL proporciona la capa orientada a la campaña y al operador. GraphSpy o el código derivado de GraphSpy probablemente maneja la capa posterior a la autenticación. El atractivo se puede cambiar sin cambiar la pila de identidades del backend».

La divulgación se produce como lo dijo Cisco Talos. identificado un panel de operador PhaaS con todas las funciones llamado ARToken que comparte infraestructura, contratos API y patrones operativos con la plataforma de phishing de código de dispositivo EvilTokens y está disponible para los afiliados.

Ciberseguridad

«El panel ARToken expone más de 80 puntos finales API para phishing de códigos de dispositivos, persistencia de tokens de actualización primaria (PRT), acceso a correo electrónico, operaciones de compromiso de correo electrónico empresarial (BEC) y exfiltración de SharePoint, todo accesible para los operadores a través de un panel basado en React», dijo Talos.

EvilTokens, como DEBULL, permiten a los atacantes utilizar tokens recolectados como armas para filtrar correos electrónicos, archivos y otros datos confidenciales de cuentas de Microsoft comprometidas, realizar reconocimientos a través de Microsoft Graph API y establecer acceso persistente. Además, incorpora Funciones impulsadas por inteligencia artificial (IA) para automatizar y escalar los flujos de trabajo de BEC, como examinar miles de correos electrónicos recopilados, identificar hilos de correo electrónico relacionados con finanzas y redactar borradores de correos electrónicos de BEC.

ARToken funciona como un conjunto de herramientas completo posterior al compromiso que permite a los operadores aprovechar el token de acceso capturado recuperado luego de una autenticación exitosa del código del dispositivo para mantener el acceso, realizar operaciones de correo electrónico, acceder a OneDrive y SharePoint, y explorar las sesiones de Microsoft 365 de las víctimas fuera del panel utilizando una herramienta dedicada conocida como ARTBrowser.

«Estas características indican que la plataforma es más madura que un simple kit de phishing de código de dispositivo: es un entorno de operaciones BEC completo», dijo el investigador de Talos, Michael Kelley.

El aumento de los ataques de phishing de códigos de dispositivos también ha llevado a otros kits PhaaS como Tycoon 2FA a adoptar la técnica para secuestrar cuentas de Microsoft 365 en sus rebote después de una operación policial, lo que indica un cambio más amplio dentro del panorama de amenazas.

«Los operadores de Tycoon 2FA han reutilizado su kit PhaaS existente como marco de entrega para el phishing de concesión de código de dispositivo OAuth», eSentire anotado en mayo de 2026. «El ataque comienza cuando una víctima hace clic en una URL de seguimiento de clics de Trustifi en un correo electrónico atractivo y culmina cuando la víctima, sin saberlo, otorga tokens OAuth a un dispositivo controlado por el atacante a través del flujo legítimo de inicio de sesión del dispositivo de Microsoft en microsoft.com/devicelogin».

Una falla en la IA del escritor podría permitir que las vistas previas de los agentes filtren tokens de sesión entre los inquilinos

Investigadores de ciberseguridad han revelado detalles de una vulnerabilidad de aislamiento de sesión crítica ahora parcheada en Escritoruna plataforma empresarial de inteligencia artificial (IA) generativa, que podría resultar en un compromiso entre inquilinos.

La vulnerabilidad de un clic ha recibido el nombre en clave Escribir por el equipo de investigación de seguridad de arena.

«Un extraño podría pasar de no tener acceso a hacerse cargo de cualquier organización de Writer AI dentro de empresas líderes en la industria, con nada más que un vínculo», dijo la empresa de ciberseguridad. dicho en un informe compartido con The Hacker News.

Dicho de otra manera, se podría abusar de la deficiencia para hacerse cargo de la cuenta de escritor de una víctima y usarla para acceder a chats privados, documentos y otros datos confidenciales relacionados con agentes, configuraciones, modelos privados, conectores y credenciales de modelos de lenguaje grande (LLM).

Peor aún, se podría abusar de él para tomar el control administrativo dependiendo del papel de la víctima. Un aspecto importante del fallo es que el atacante y la víctima no tienen por qué pertenecer a la misma organización.

Ciberseguridad

Un atacante puede crear un agente en su propia cuenta de Writer y compartir un enlace de vista previa. Eso es todo lo que se necesita para activar la vulnerabilidad, esencialmente haciendo posible secuestrar la cuenta de una víctima que hace clic en el enlace y inicia sesión con su propia sesión.

«Un atacante puede abusar de la zona de pruebas administrada por la IA de Writer para recopilar sesiones que pertenecen a compañías completamente separadas y actuar dentro de cada una de ellas como un usuario real, sin ningún punto de apoyo previo en ninguna parte», dijo Sand Security.

WriteOut también socava el modelo de responsabilidad compartida, ya que rompe las protecciones de aislamiento de los inquilinos al aprovechar la ventaja de Writer. función de vista previa en vivo que permite a los usuarios obtener una vista previa de la aplicación a través de Writer Framework.

Toda la cadena de ataque se desarrolla de la siguiente manera:

  • Un atacante crea un agente con una vista previa en vivo y comparte su enlace de vista previa pública.
  • Cuando un usuario de Writer que ha iniciado sesión abre ese enlace, su navegador adjunta su cookie de sesión de Writer a la solicitud.
  • El proxy de vista previa envía esa cookie al servidor del atacante. salvadera.
  • El código contenido dentro del entorno limitado controlado por el atacante lee el token de sesión reenviado y se filtra.
  • él.
  • El atacante reproduce el token y obtiene el control de la cuenta de escritor de la víctima.

Debido a que un atacante puede indicarle a su agente malicioso prediseñado que ejecute código dentro de la zona de pruebas administrada y controlada, esto hace posible leer la memoria del proceso de la zona de pruebas, recuperar el token de sesión exfiltrado de la víctima y transmitirlo a un servidor que mantienen.

Ciberseguridad

Luego de una divulgación responsable, Writer resolvió el problema impidiendo que la cookie de sesión del usuario se reenvíe por completo a las vistas previas de la zona de pruebas y moviéndolas a un origen aislado.

«El escritor no fue descuidado, había barreras de seguridad. El filtrado del lado de entrada intentó impedir que los usuarios leyeran variables de entorno o enviaran código obviamente malicioso», dijo Sand Security. «El problema es lo que observaron esas comprobaciones: las instrucciones, no el comportamiento en tiempo de ejecución».

«Eludir la barrera de seguridad fue bastante sencillo: en lugar de pegar la carga útil en línea, simplemente le dijimos al agente que buscara y ejecutara un script remoto. La barrera de seguridad vio una solicitud benigna de ‘descargar y ejecutar’, y la lógica de explotación real nunca apareció en el mensaje».

Presuntos piratas informáticos alineados con China explotan las fallas de Roundcube contra las universidades – CYBERDEFENSA.MX

Se ha observado que un grupo de actividad de amenazas presuntamente alineado con China explota el software de correo web Roundcube perteneciente a los departamentos de física e ingeniería de universidades de EE. UU. y Canadá como parte de una nueva campaña.

La actividad implica la explotación de fallas de seguridad críticas ahora parcheadas en la solución de correo electrónico de código abierto, como CVE-2024-42009 (puntaje CVSS: 9.3), para desviar credenciales, seguido de la implementación de un shell web para acceso persistente o una conocida herramienta posterior a la explotación llamada VShell.

Proofpoint está rastreando el grupo de amenazas emergentes bajo el nombre UNK_MassTraction. Se detectó por primera vez en mayo de 2026, centrándose específicamente en administradores y profesores de departamentos con vínculos de seguridad nacional o entidades que estudian astrofísica y física de partículas.

«Los correos electrónicos dirigidos a departamentos universitarios utilizaron remitentes comprometidos, así como dominios abusados ​​y vulnerables a la suplantación de identidad debido a la política laxa de DMARC para enviar los correos electrónicos», escribió la compañía de seguridad empresarial en un informe técnico compartido con The Hacker News, añadiendo que el uso de señuelos genéricos indica una «franja de objetivos más amplia» más allá de su visibilidad.

Si bien la naturaleza del exploit de secuencias de comandos entre sitios (XSS) es tal que solo requiere que el destinatario abra el correo electrónico en el cliente Roundcube para obtener acceso al servidor de correo, se evaluó que los departamentos objetivo fueron seleccionados porque todos ejecutaban versiones de Roundcube susceptibles a fallas de seguridad de N días.

Esto indica que el actor de amenazas probablemente llevó a cabo un reconocimiento preparatorio de estos objetivos para recopilar información sobre sus entornos antes de enviar correos electrónicos de phishing que desencadenan un exploit para CVE-2024-42009 y ejecutan código JavaScript arbitrario en el contexto del navegador web de la víctima.

Ciberseguridad

«Es probable que el actor esté abusando de los servidores Roundcube como punto de pivote para ingresar a las redes objetivo, y los operadores han diseñado deliberadamente su cadena de infección para evitar la detección», dijeron los investigadores de Proofpoint Greg Lesnewich y Mark Kelly.

La carga útil entregada tras la explotación de la falla XSS, cuyo nombre en código es IceCube, está diseñada para desviar información de credenciales almacenada en el navegador junto con autenticación de dos factores (2FA) y cookies. También lleva a cabo su propio reconocimiento para recopilar información sobre el idioma del navegador, el tamaño de la pantalla y los valores de los campos del formulario. tamaño de pantalla y valores de campo de formulario.

La información recopilada se envía a un sistema externo mediante una solicitud HTTP POST. En el siguiente paso, IceCube aprovecha el token CSRF de la sesión para convertir en arma una segunda falla de ejecución remota de código posterior a la autenticación en Roundcube: CVE-2025-49113 (puntuación CVSS: 9,9): con el objetivo de establecerse en el servidor de correo y colocar VShell o un shell web denominado SquareShell en la memoria.

El shell web, implementado mediante un comando de shell de gadget PHP, es accesible de forma remota en el punto final «plugins/newmail_notifier/mail_preview.php» y permite la ejecución de código arbitrario. Sin embargo, si la instalación del shell web falla por algún motivo, la cadena de ataque recurre a un mecanismo alternativo en el que se ejecuta un script de shell a través de la vulnerabilidad Roundcube para finalmente entregar VShell.

Se dice que el método secundario se introdujo en junio de 2026, cuando anteriormente la cadena de ataque simplemente saldría al no implementar SquareShell. El script de shell actúa como conducto para un cargador ELF denominado SNOWLIGHT y se ha utilizado en otras intrusiones orquestadas por adversarios chinos. El uso de SNOWLIGHT y VShell se ha vinculado a un clúster vinculado a China rastreado como UNC5174 en el pasado.

Esto sugiere que el script de shell posiblemente sea compartido por múltiples clústeres de China-nexus a título privado, similar a ShadowPad y otras herramientas. La principal responsabilidad del script es buscar una versión de SNOWLIGHT que sea compatible con la arquitectura del sistema del host y luego ejecutarla.

«IceCube también establece lo que llama ‘desencadenantes diferidos’ para garantizar la continuidad de la cadena de infección», afirmó Proofpoint. «Los activadores diferidos monitorean si el usuario cierra la página o cambia de pestaña, verifica si el mouse sale de la ventana del navegador y secuestra el botón de cerrar sesión».

Ciberseguridad

«Si se toma alguna de esas acciones, IceCube engancha esos eventos y vuelve a intentar la explotación de CVE-2025-49113, y señala al C&C [command-and-control] que el usuario abandonó la sesión de Roundcube.»

Al completar estas acciones o agotar el tiempo de espera, el malware JavaScript destruye las sesiones iniciadas por el usuario y el malware en el servidor, lo que hace que el usuario cierre sesión y borre la evidencia forense asociada con el compromiso del servidor Roundcube.

Escrito en Go, VShell es una herramienta de administración remota que proporciona capacidades posteriores al compromiso similares a Cobalt Strike. Ha sido utilizado por varios adversarios alineados con China en los últimos años.

Este hecho marca la primera vez que un grupo de piratas informáticos chino se vincula a la explotación de las fallas de Roundcube, de las que tradicionalmente han abusado los actores de amenazas patrocinados por el estado de Rusia.

«Si bien el objetivo de esta campaña cautiva la imaginación, es poco probable que UNK_MassTraction resuelva profundas cuestiones de física teórica o la paradoja de Fermi en un futuro próximo», concluyeron los investigadores de Proofpoint.

«UNK_MassTraction mostró un conjunto de herramientas maduro y un uso único de las vulnerabilidades de n días. La campaña es un recordatorio de que la entrega de correo electrónico puede facilitar el compromiso del servidor de correo, y que los operadores chinos continuarán tratándolos como cualquier otro dispositivo de borde, por lo que los defensores deben priorizar la defensa de los servidores de correo de sus redes tan a fondo como lo hacen con sus concentradores VPN y otros nodos de acceso remoto en sus redes».

El presunto grupo de espionaje chino utilizó una cadena de exploits Roundcube para infiltrarse en las universidades

Atacantes alineados con China irrumpieron en las redes de universidades estadounidenses y canadienses para robar datos confidenciales y establecer un acceso persistente a través de webshells y puertas traseras, dijeron el martes los investigadores de amenazas de Proofpoint.

Los ataques motivados por el espionaje se dirigieron a departamentos de física e ingeniería, centrándose en administradores y profesores con vínculos de seguridad nacional u organizaciones que investigan astrofísica y física de partículas.

Proofpoint identificó menos de 10 víctimas universitarias y estima que unas pocas docenas de universidades podrían verse afectadas, dijo a CyberScoop Greg Lesnewich, investigador principal de amenazas de Proofpoint. La compañía observó la campaña por primera vez en mayo y cree que está en curso.

«Existe una alta probabilidad de que muchas víctimas aún no hayan sido informadas de esta actividad», añadió Lesnewich.

Los investigadores rastrearon los ataques hasta un par de vulnerabilidades críticas en Roundcube, un cliente de correo electrónico de código abierto, que fueron explotadas y encadenadas para robar credenciales y obtener acceso a largo plazo.

El grupo de amenazas, que Proofpoint rastrea como UNK_MassTraction, explotó CVE-2024-42009 para ejecutar JavaScript dentro del navegador de la víctima, luego explotado CVE-2025-49113 para hacerse un hueco en el servidor de correo.

El exploit inicial en la cadena solo requiere que la víctima abra un correo electrónico, y los atacantes enviaron a las víctimas una serie de señuelos genéricos para activar el acceso inicial.

Proofpoint atribuye la campaña a un grupo alineado con China porque los atacantes utilizaron una red encubierta conocida utilizada por múltiples grupos de amenazas alineados con China, una cadena de infección que conduce a VShell y dejaron artefactos en idioma chino en los correos electrónicos de phishing.

Los investigadores no han sacado ninguna conclusión sobre por qué los atacantes atacaron las universidades y qué buscan.

«No tenemos datos que sugieran qué fue robado, ya que sólo observamos el intento inicial de entrada de correo electrónico», dijo Lesnewich.

Los aspectos de ingeniería se alinean con las iniciativas estratégicas de China, añadió. Los cazadores de amenazas de Google detectaron recientemente un grupo de espionaje patrocinado por el Estado chino que se metió en los sistemas durante años, robando datos académicos, médicos, militares, de ciberseguridad y de política exterior.

«Los adversarios alineados con China han estado apuntando a otros tipos de dispositivos periféricos, como enrutadores y concentradores VPN, durante años con varios exploits para crear un punto de apoyo en una red objetivo, sin utilizar el correo electrónico para la entrega», dijo Lesnewich. «Esta campaña le da la vuelta a eso, utilizando el correo electrónico para entregar una cadena de exploits para comprometer un servidor de correo, en lugar de usar el correo electrónico para entregar una URL de recolección de credenciales o malware dirigido a un usuario final, no a un servidor».

Matt Kapko

Escrito por Matt Kapko

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

Una falla de KVM de Linux de hace 16 años permite que las máquinas virtuales invitadas escapen al host en sistemas Intel y AMD x86

Se puede activar un error de uso después de la liberación en el hipervisor KVM de Linux desde una máquina virtual invitada para corromper el estado de la página oculta del kernel host que lo ejecuta.

Apodado ‘Januscape‘ y rastreado como CVE-2026-53359la falla se encuentra en el código MMU oculto que KVM comparte tanto en Intel como en AMD. La prueba de concepto pública hace que el anfitrión entre en pánico; El investigador afirma que un exploit separado e inédito convierte el mismo error en la ejecución completa del código host.

investigador de seguridad Hyunwoo Kim (@v4bel) encontró e informó el error. Describió a Januscape como el primer exploit de huésped a host que se puede activar tanto en Intel como en AMD, hasta donde el público sabe. El defecto pasó desapercibido durante aproximadamente 16 años.

Según Kim, el exploit se utilizó como envío de día cero en kvmCTF de Googleel programa de recompensas por vulnerabilidades de KVM controladas que ofrece hasta 250 000 dólares por escapadas completas de invitado a anfitrión.

Cómo funciona

Para ejecutar una máquina virtual, KVM mantiene su propio conjunto privado de tablas de páginas que reflejan el diseño de la memoria del invitado. Cuando necesita una de estas páginas de seguimiento, busca una existente para reutilizarla.

El problema: los comparó solo por la dirección de memoria e ignoró qué tipo de página de seguimiento estaba tomando. Dos tipos diferentes pueden compartir la misma dirección pero realizar trabajos completamente diferentes, por lo que KVM a veces reutiliza el tipo incorrecto.

Ciberseguridad

Esa confusión codifica los registros internos de KVM sobre qué página pertenece y dónde, y una vez que esos registros son incorrectos, algo tiene que ceder.

La mayoría de las veces, el núcleo se da cuenta del desorden y se apaga en el acto para evitar causar daños. Ese bloqueo es lo que desencadena la demostración pública: un invitado puede derribar todo el host, derribando con él a todas las demás máquinas virtuales de esa máquina.

El caso más raro y peor ocurre cuando la página de seguimiento liberada se entrega para otro uso antes de que el kernel se limpie. Luego, la limpieza escribe un valor en la memoria que ya no posee. Un atacante solo controla dónde llega esa escritura, no lo que se escribe, pero incluso ese punto de apoyo limitado se puede convertir en código ejecutable en el host.

La falla se comporta igual en los chips Intel y AMD; sólo el paso final y más difícil de convertirlo en control total requiere un trabajo diferente en cada uno.

¿Quién se ve afectado?

El código vulnerable ha estado presente desde cometer 2032a93d66fa en agosto de 2010 (era del kernel 2.6.36) y fue reparado por cometer 81ccda30b4e8se fusionó con mainline el 19 de junio de 2026.

El ataque requiere dos cosas por parte del huésped: raíz dentro de la VM, una condición común en instancias de nube alquiladas, y virtualización anidada expuesta por el host. Incluso en hosts que ejecutan hardware EPT o NPT de forma predeterminada, la virtualización anidada obliga a KVM a retroceder a través de la MMU oculta heredada, que es donde se encuentra el error.

El exploit no necesita la cooperación de QEMU ni de ningún VMM del espacio de usuario. Es puramente un error de KVM en el kernel.

La preocupación práctica es cualquier entorno x86 que aloje invitados que no sean de confianza y con la virtualización anidada habilitada. Un atacante que alquila una sola instancia de este tipo puede provocar pánico en el host y desactivar todas las demás máquinas virtuales de la misma máquina física.

Kim dijo que el exploit completo retenido ejecuta código como root en el host, lo que expondría a otros invitados en la misma máquina a ese acceso de root. En distribuciones como RHEL, donde /dev/kvm se puede escribir en todo el mundo (0666), Kim notó que el mismo error también podría servir como una escalada de privilegios locales a la raíz, aunque la ruta de invitado a host es el uso de mayor impacto.

Unos meses muy ocupados para un investigador

Januscape es la tercera revelación de Kim sobre un exploit del kernel de Linux en aproximadamente dos meses. En mayo de 2026, reveló Dirty Frag (CVE-2026-43284 / CVE-2026-43500), una cadena de vulnerabilidad de escritura en caché de página que ofrece raíz determinista en la mayoría de las distribuciones principales, extendiendo la misma clase de error que Dirty Pipe y Copy Fail.

En junio publicó SU paisaje (CVE-2026-46316), el primer escape de huésped a host demostrado públicamente en KVM/arm64, que explota una condición de carrera en el controlador de interrupción virtual. Januscape ahora añade el lado x86; el mismo disparador se activa tanto en Intel como en AMD, y el PoC lleva una ruta de código separada para cada proveedor.

Ciberseguridad

Google lanzó kvmCTF en 2024 específicamente porque KVM sustenta tanto a Android como a Google Cloud. Un uso-después libre de paginación oculta KVM x86 independiente (CVE-2026-46113) que involucraba una discrepancia de rmap relacionada pero distinta, se solucionó en mayo de 2026.

Eso hace que dos MMU en la sombra se liberen en la misma ruta de código heredado en dos meses.

Qué hacer

La solución es una adición de una línea a kvm_mmu_get_child_sp(): la condición de reutilización ahora verifica role.word junto con gfn, por lo que una página oculta solo se reutiliza cuando tanto el número de fotograma como el rol coinciden. El mantenedor de KVM Paolo Bonzini escribió el parche.

Versiones estables fijas enviadas el 4 de julio de 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 y 5.10.260. NVD aún no ha asignado una puntuación CVSS; no esperes uno.

Si opera un host KVM x86 que acepta invitados multiinquilino con virtualización anidada, confirme que su kernel incluya la confirmación 81ccda30b4e8. Los backports de distribución pueden contener la solución con un número de versión diferente, así que verifique el registro de cambios del paquete en lugar de confiar solo en uname -r.

Si no puede parchear inmediatamente, deshabilitar la virtualización anidada (kvm_intel.nested=0 o kvm_amd.nested=0) elimina la ruta de ataque para invitados que no son de confianza. Los hosts ARM64 no se ven afectados por Januscape; ITScape (CVE-2026-46316) es un problema separado de KVM/arm64.

La PoC pública demuestra un pánico de host confiable por parte de un invitado con un módulo de kernel cargable y segundos o minutos de carrera. Trate los hosts KVM x86 expuestos con virtualización anidada como objetivos de parches de alta prioridad.

Seis capacidades que separan a los líderes de las soluciones de IA integradas – CYBERDEFENSA.MX

Crear una lista corta para una evaluación del SOC de IA puede resultar complicado. Los proveedores de SIEM, SOAR y AI SOC puro dicen lo mismo. Pero detrás de la misma etiqueta se encuentran productos muy diferentes, desde asistentes de chat integrados en un SIEM heredado hasta plataformas de agentes que ejecutan detección, clasificación, investigación y respuesta en su propia base de datos.

Que una plataforma cambie materialmente los resultados de su equipo es más importante que cómo se llama. Podemos medir eso en tiempo de investigación, volumen de falsos positivos, horas de analista devueltas, costo total de funcionamiento de su SOC y, finalmente, si la arquitectura aguantará dentro de 2 o 3 años a medida que el volumen, la velocidad y la complejidad de los ataques sigan aumentando.

¿Qué es una plataforma AI SOC?

Un AI SOC La plataforma es una plataforma de operaciones de seguridad donde los agentes de IA llevan a cabo el trabajo principal del SOC (detección, clasificación, investigación y respuesta) razonando sobre datos de seguridad correlacionados, bajo supervisión humana. Se diferencia de la IA integrada, que resume las alertas dentro de un SIEM existente mientras que el trabajo subyacente sigue siendo manual.

Los agentes que hacen el trabajo principal son a lo que se refieren los proveedores cuando dicen agente. La distinción puede parecer sutil en una hoja de datos, pero la prueba real se produce durante las pruebas de concepto.

¿Qué hace que un agente AI SOC sea predecible?

La previsibilidad separa la automatización del SOC en la que puede confiar de la automatización que usted cuida, y es una propiedad de los datos más que una propiedad del modelo. Un agente que solo resume las alertas puede trabajar únicamente desde la carga útil de la alerta. Un agente de confianza para cerrar alertas o tomar acciones de respuesta necesita tener mucho más contexto, como la entidad (identidad, recurso, dispositivo/activo) involucrada, cómo ha variado su configuración y cómo se ve lo normal para la entidad y muchos otros factores.

Las plataformas creadas para ese nivel de confianza mantienen un gráfico de conocimiento en tiempo real, un mapa continuamente actualizado de las identidades, recursos, configuraciones y líneas base de comportamiento en un entorno y las relaciones entre ellos, recopilados antes de que se active cualquier alerta. Basado en ese contexto, y junto con la arquitectura del modelo en capas cubierta en la lista de verificación a continuación, un agente arroja veredictos consistentes y respaldados por evidencia. La IA integrada funciona en la dirección opuesta, consultando registros sin procesar después de que llega una alerta, razón por la cual sus conclusiones a menudo no se mantienen bajo escrutinio. La amplitud es igualmente importante. Las plataformas más potentes añaden cobertura de detección para fuentes que nunca instrumentó, ejecutan búsquedas de amenazas continuamente y comienzan a responder mientras el incidente aún se está desarrollando.

Seis capacidades de AI SOC para probar antes de comprar

Cada capacidad a continuación se puede verificar durante una prueba de concepto, en su propio entorno o en vivo en una demostración del proveedor.

  1. Una base de datos correlacionados en tiempo real. Un veredicto de IA es tan bueno como el contexto detrás de él. Pregunte si los datos de identidad, configuración, recursos y línea de base están correlacionados continuamente (el enfoque del gráfico de conocimiento) o se ensamblan a partir de registros sin procesar en el momento de la consulta. La velocidad por sí sola demuestra poco; un motor de consultas rápido también regresa en segundos. En su lugar, elija una identidad al azar y comprenda sus permisos (administrador o no), deriva de configuración y línea base de comportamiento (ubicación normal, IP, ASN, agente de usuario, etc.). Nada de eso se puede falsificar en el momento de la consulta.
  2. Agentes de ciclo de vida completo. Haga que el proveedor recorra un incidente de principio a fin, desde la detección que lo creó hasta la clasificación, la investigación y una acción de respuesta, y observe si el contexto se transmite en cada paso o se vuelve a reunir. Muchas plataformas automatizan la clasificación de nivel 1 y se detienen ahí, lo que acelera la cola de alertas sin acelerar el SOC.
  3. Veredictos auditables y respaldados por evidencia. Solicite ver el rastro de evidencia detrás de un veredicto (cada línea de registro, correlación e inferencia que lo produjo) y confirme que sus analistas pueden reproducir el hallazgo a partir de los mismos datos. Un veredicto que no se puede auditar es una opinión.
  4. Cobertura de detección más allá del SIEM. Los incidentes reales cruzan la nube, SaaS, identidad y código, pero gran parte de esa telemetría nunca llega al SIEM porque su ingesta cuesta demasiado. Enumere las fuentes que su pila deja oscuras, como registros de auditoría de la nube de gran volumen, GitHub y Google Workspace, luego haga que el proveedor muestre una detección activa sobre ellos y una investigación sobre ellos.
  5. Autonomía escenificada con supervisión humana. La autonomía total desde el primer día es una señal de advertencia, al igual que una plataforma que nunca obtiene más que acceso de solo lectura. Investigue cómo se organiza la confianza, qué acciones comienzan como recomendaciones, qué registro de evidencia desbloquea la ejecución automática y dónde una persona aún aprueba. Confirme que puede ajustar esos umbrales por tipo de acción.
  6. Resultados mensurables. Defina los números antes de que comience la prueba de concepto: tasa de falsos positivos y tiempo medio para investigar y responder. Mida los resultados con respecto a su línea de base actual y pregunte a los clientes de referencia qué se movió en su primer trimestre. Si eventualmente desea que el proveedor lo ejecute por usted, confirme que el servicio administrado utilice el mismo producto que operaría su equipo.

Enfoque: Plataforma SOC Agentic de Exaforce

Una plataforma diseñada en torno a estas capacidades es Exaforce, una plataforma AI SOC agente cuyos cuatro Exabots cubren el ciclo de vida completo del SOC. Exabot Detect funciona como su ingeniero de detección de IA, Exabot Triage lleva cada alerta a un veredicto con profundidad de Nivel 3, Exabot Investigate reduce la barrera para que cualquiera pueda cazar amenazas y Exabot Respond coordina acciones a lo largo de la cadena de eliminación, con un humano aprobando cualquier cosa irreversible.

Los cuatro Exabots razonan sobre un plataforma unificada de datos en tiempo real que ingiere y enriquece los registros y la configuración en la nube, SaaS, identidad, punto final y código. Los analistas lo consultan todo en lenguaje sencillo a través de Exabot. La misma plataforma puede sustituir a un SIEM, menos los analizadores, el mantenimiento de tuberías y las contrataciones de expertos en SIEM que normalmente vienen con uno. Salud guardián convirtió a Exaforce en su SIEM y MDR principal. «Ya no escribo consultas. Sólo le pregunto a Exabot», dice Mike Shannon, director de ingeniería de seguridad de Guardant Health.

Los resultados medidos se corresponden con las capacidades anteriores. El corte invisible significa tiempo para investigar en un 95%llevando las investigaciones de horas o días a minutos. Punto de fuerza reemplazó un MSSP que necesitaba ayuda con Exaforce MDR y ahora tiene un tiempo medio de 14 minutos para responder a incidentes P0.

Tiene la opción de ejecutar la plataforma con su equipo interno o hacer que Exaforce la opere por usted a través de su oferta MDR. La arquitectura y los Exabots son idénticos en ambos sentidos; sólo cambia quién los opera.

¿Qué tan cerca está el SOC autónomo?

Ninguna plataforma, incluida Exaforce, hace que el SOC moderno sea un problema resuelto. La lucha es de IA contra IA, y no se ganará en los modelos de frontera sino en los datos sobre los que razonan los agentes. Los agentes basados ​​en datos en tiempo real correlacionados con identidad, activos/dispositivo, recursos afectados y comportamientos de referencia producen veredictos que se pueden predecir, reproducir y auditar, infundiendo confianza en los humanos para aprovechar la IA en el SOC.

Si está iniciando una evaluación, el manual propio de Exaforce, ¿Qué es un SOC de IA?es una lectura fundamental. Luego, coloque las seis capacidades anteriores frente a cada proveedor de su lista corta y solicitar una demostración para ver cómo Exaforce les responde.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

SkillCloak permite que las habilidades maliciosas de los agentes de IA evadan los escáneres estáticos con un embalaje autoextraíble

Los escáneres destinados a detectar «habilidades» complementarias maliciosas para agentes de codificación de IA pueden ser engañados con unos pocos cambios simples que dejan el malware funcionando, según un nuevo estudio de investigadores de la Universidad de Ciencia y Tecnología de Hong Kong.

Su truco más fuerte pasó desapercibido para todos los escáneres probados más del 90% de las veces, y el mismo equipo creó un verificador de tiempo de ejecución que detecta la mayoría de las habilidades encubiertas que los escáneres pasan por alto.

Las habilidades son paquetes pequeños, generalmente un archivo de instrucciones Markdown más algunos scripts, que agentes como Claude Code, OpenAI Codex y OpenClaw cargan para adquirir una nueva capacidad. Debido a que una habilidad es solo un conjunto de archivos, la misma puede ejecutarse en diferentes agentes. Y se ejecuta con el acceso del propio agente: tus archivos, tu terminal, tus contraseñas guardadas.

Uno malo puede robar credenciales, copiar código fuente o instalar una puerta trasera. La mayor parte de lo que un mercado público enumera es subido por extraños con poca investigación.

La principal defensa hasta ahora ha sido el escáner de habilidades, que lee los archivos de una habilidad antes de instalarla y bloquea cualquier cosa que parezca peligrosa. El documento, titulado «Ocultar y detonar,» prueba si eso realmente se sostiene. No es así. Sin embargo, vencer a los escáneres no es nuevo.

Ciberseguridad

Hacker News ha cubierto a investigadores que pasan una habilidad falsa más allá de todos los escáneres a los que se enfrentaron, lo que, según el propio recuento de la empresa, llegó a decenas de miles de agentes. Lo que este artículo añade es una manera de hacerlo sistemáticamente, a escala, y una defensa que aún funciona cuando lo hace.

Cómo se transmiten las habilidades disfrazadas

La herramienta de los investigadores, CAPA DE HABILIDADreescribe una habilidad maliciosa para que parezca limpia y se comporte exactamente igual. Funciona de dos maneras.

El más ligero reescribe los bytes revelados en los que teclea un escáner, utilizando los propios operadores del papel: cambia un carácter por uno parecido de otro alfabeto, o divide un comando marcado en una nueva línea, de modo que el patrón del escáner ya no coincida pero el comando aún se ejecuta.

El paquete más pesado, autoextraíble, mueve toda la carga útil a un directorio que el escáner omite, como .git/, detrás de un decodificador de apariencia inofensiva que reconstruye la habilidad solo cuando el agente la ejecuta. Los escáneres omiten dichos directorios para ahorrar tiempo y evitar falsas alarmas, que es exactamente el punto ciego que explota el truco.

A través de ocho escáneres y 1.613 habilidades maliciosas reales extraídas de ClawHub, un mercado público, el truco de embalaje superó cada uno de los ocho más del 90% de las veces, y superó a la mayoría de ellos más del 99%.

La reescritura más ligera aclaró más del 80% en la mayoría de los escáneres y el 96% en uno. Y el disfraz no le cuesta casi nada al atacante: en Claude Code y OpenAI Codex, las habilidades encubiertas funcionaron tan bien como las originales.

Observar lo que hace una habilidad, no cómo se ve

Dado que la apariencia se puede falsificar, los investigadores proponen comprobar el comportamiento, en una herramienta que llaman HABILIDAD DETONAR. Ejecuta la habilidad en un sandbox y observa lo que hace a nivel del sistema operativo: qué lee, qué escribe, dónde envía datos.

Dos ideas hacen que funcione para los agentes. Realiza un seguimiento de los datos confidenciales por dónde fluyen en lugar de por su apariencia, por lo que base64 o el cifrado no los desvían. Y ejecuta las instrucciones que una habilidad construye sólo en tiempo de ejecución, que es exactamente donde el truco de empaque esconde su carga útil.

En una prueba controlada, el verificador captó el 97% de los ataques mientras marcaba erróneamente el 2% de las habilidades seguras, una tasa de falsas alarmas más baja que los escáneres que vence, y se mantuvo estable cuando las habilidades estaban ocultas. En habilidades maliciosas del mundo real, captó el 87%.

El escáner de Cisco, el más potente probado, fue en sentido contrario: captó el 99% de las habilidades del mundo real antes del encubrimiento y alrededor del 10% después.

El problema es la velocidad, un par de minutos por habilidad frente a los pocos segundos de un escáner, aunque se ejecuta una vez, antes de que la habilidad entre en funcionamiento. El trabajo es una preimpresión y aún no ha sido revisado por pares; Los investigadores han publicado su código.

Ya está sucediendo en la naturaleza

Nada de esto es hipotético. Los mercados públicos ya están llenos de habilidades maliciosas que los escáneres no detienen: Bitdefender encontró Aproximadamente el 17% de las habilidades que verificó en un mercado contenían códigos maliciosos ocultos, y Koi Security contado 341 en una sola campaña a la que llamó ClawHavoc, como informó THN, luego 824 a medida que el mercado crecía.

Algunos utilizan los mismos trucos del periódico. De cinco habilidades evasivas Unidad 42 encontró todavía vive en ClawHub a pesar de su escaneo incorporado, uno, omnicogg, rellenó su README con 22 MB de basura para pasar el límite de tamaño del escáner, el mismo operador de relleno de tamaño que prueba el papel. Dos más entregaron ladrones de contraseñas de Mac y dos secuestraron el asesoramiento financiero del agente para impulsar enlaces de afiliados y manipular el lanzamiento de meme-coins.

La brecha en el tiempo de ejecución también aparece fuera de los mercados de habilidades. Un repositorio de GitHub de aspecto limpio recientemente llevó a Claude Code a abrir un shell inverso en la propia máquina del desarrollador, entregando el control remoto al atacante. El código malicioso nunca estuvo en el repositorio; el script de configuración lo obtuvo en tiempo de ejecución de un registro DNS, por lo que un análisis estático no tenía nada que detectar. El equipo 0DIN de Mozilla rastreado la cadena.

Ciberseguridad

Una falla relacionada afecta las descripciones de las herramientas que los agentes leen a través del Protocolo de contexto del modelo. microsoft prevenido que una descripción envenenada, modificada después de que se aprobó la herramienta, empujó silenciosamente a un agente financiero a filtrar facturas impagas. El mecanismo es diferente, pero la suposición rota es la misma: lo que pasó la revisión es lo que se ejecuta.

Vale la pena señalar claramente algunos límites. Nadie ha atrapado todavía a los atacantes utilizando exactamente estos trucos de embalaje a escala; Los casos del mundo real aquí son evasiones adyacentes, no SKILLCLOAK en sí. El verificador de tiempo de ejecución es un prototipo de investigación, sólido en el laboratorio pero no probado en un mercado real o bajo un atacante que intenta evadirlo activamente. Y cada número de desempeño es propio de los autores, de un artículo que no ha sido revisado por pares. La dirección está bien evidenciada; las cifras específicas merecen la cautela habitual debido al trabajo inicial de un solo grupo.

Ésa es la verdadera lección, y es en ella donde converge una línea de trabajo cada vez mayor. Un escáner juzga una habilidad por su apariencia cuando se envía, pero el comportamiento malicioso solo aparece una vez que se ejecuta la habilidad, una vez que ha pasado el escaneo. Por lo tanto, la decisión de confianza debe pasar de la puerta del mercado a la máquina donde se ejecuta la habilidad.

¿Qué cazar? Las evasiones del periódico dejan señales que un defensor puede buscar, incluso en una habilidad que pasó un escaneo:

  • Archivos grandes o de alta entropía escondidos en directorios que un escáner tiende a omitir, como .git/ o build/.
  • Habilidades que desempaquetan o ensamblan código solo cuando se ejecutan, en lugar de enviarlo a la vista.
  • Los archivos superaban con creces un tamaño razonable, el truco que desliza una habilidad por debajo del límite de tamaño de un escáner.

Ninguno de estos es prueba por sí solo. Son primeras banderas baratas, no un veredicto.

Para los equipos que utilizan agentes de codificación, eso hace que una insignia de «pasó el escaneo» sea un punto de partida, no una garantía. Mantenga el escaneo estático como higiene barata, pero observe lo que hace una habilidad cuando se ejecuta: los archivos que toca, los comandos que ejecuta y adónde envía datos.

El documento también ofrece soluciones provisionales concretas, como aplicar hash a una habilidad cuando se escanea y volver a verificar antes de cada ejecución para detectar cargas útiles que se descomprimen más tarde, y marcar habilidades que envían manchas opacas en carpetas ignoradas o archivos de bloc que superan un límite de tamaño. Ninguno de ellos cierra la brecha por sí solo, lo cual es el punto: la defensa duradera está observando el comportamiento en tiempo de ejecución.

Más allá de eso, instale solo desde una fuente verificada, brinde a los agentes el mínimo acceso que necesiten y no los ejecute en máquinas que contengan secretos que valga la pena robar.