El 6 de julio, dos investigadores publicaron una técnica de inyección de código y la probaron contra cuatro EDR líderes del mercado configurados para detectar, bloquear y remediar. La inyección funcionó en los cuatro. No se creó ninguna alerta. El 22 de septiembre, otro equipo la reprodujo y su EDR tampoco dijo nada. La pregunta útil no es si tu EDR detecta esa técnica concreta. Es qué te queda cuando no salta nada.
Una inyección que nunca escribe en otro proceso
La inyección de código clásica hace siempre lo mismo: reservar memoria dentro de otro proceso y escribir ahí el código. Esas dos operaciones pasan por un puñado de llamadas al sistema que cualquier EDR vigila desde hace más de una década, y sobre las que está escrita buena parte del catálogo de reglas de detección del sector.
Process Parameter Poisoning no escribe. Mete la carga en los parámetros con los que se arranca un proceso nuevo: la línea de comandos, el bloque de variables de entorno y un campo poco documentado de la estructura de arranque, lpReserved, que Windows deposita en el bloque de entorno del proceso (el PEB) bajo una entrada llamada ShellInfo. El proceso nace ya con el material dentro, puesto ahí por el mecanismo normal de creación de procesos, y lo único que queda es desviar la ejecución del hilo hacia esa región.
Hay una frase en el análisis de Flashpoint que explica el silencio mejor que cualquier resumen. Como la técnica no invoca suspensión ni reanudación explícita de hilos, dicen, «las reglas de detección específicas que dependen de esos parámetros no se dispararán». El EDR está mirando la puerta correcta de una casa que tiene otra entrada.
Un catálogo de detecciones es una colección de descripciones de cómo se hizo algo. Cambia el cómo y la descripción deja de encajar. Así funciona cualquier cosa que detecte por comportamiento conocido, la hayas pagado cara o barata.
Lo que dicen las dos publicaciones, y lo que no
La primera es de SensePost, firmada por Max Hirschberger y Ogulcan Ugur, del 6 de julio de 2026. La frase que ha viajado es esta, literal: «La inyección de código funcionó en todos los casos y no se creó ninguna alerta, pese a que los EDR estaban configurados para detectar, bloquear y remediar». Cuatro productos líderes del mercado, dicen. No dicen cuáles, así que nadie puede mirar su consola y concluir que el suyo no estaba.
La segunda es de Flashpoint, del 22 de septiembre, y aquí es donde el titular pierde altura. Probaron la técnica contra «una plataforma EDR de código abierto de uso común» —una sola, y de código abierto—. El EDR no generó ninguna alerta, cierto. Pero en la misma prueba, «el componente XDR bloqueó en la creación inicial del proceso nuevo y en las interacciones COM de la carga de segunda fase». O sea: sí lo paró. Solo después de añadir desenganche de DLL y de crear el proceso sacrificial —el que se arranca solo para hospedar la carga— con la política que impide cargar DLL que no sean de Microsoft —la que, de paso, deja fuera la del propio EDR— los analistas observaron, también en sus palabras, «ningún bloqueo del XDR durante la ejecución y ninguna alerta en la plataforma».
Y los propios investigadores cierran poniendo el freno: «aunque esta prueba de concepto funcionó en pruebas de laboratorio, la técnica tiene múltiples oportunidades de detección y lo más probable es que requiera una combinación de técnicas de evasión adicionales para lograr una tasa de éxito mayor». Eso no es «los EDR no sirven». Es una capa que calla sola y dos evasiones más encima para que callen también las demás.
Hay un matiz que ninguna de las dos publicaciones subraya y que cambia por completo el orden de tus prioridades: esto es post-explotación. Para meter una carga en los parámetros de un proceso hay que estar ya ejecutando código en la máquina. Ninguno de los dos textos presenta la técnica como vía de entrada. Si alguien necesita esquivar tu EDR, es que ya ha pasado por delante de otras tres cosas más baratas de arreglar.
La primitiva no es nueva
Lo cuenta la propia entrada de SensePost, en una nota añadida después de publicar: el investigador X-C3LL les señaló que la misma primitiva ya la había presentado modexp en una entrada de blog hoy borrada. SensePost no da la fecha de aquella entrada, así que no sabemos cuánto tiempo lleva esto dando vueltas; sí sabemos que estaba descrito en público antes de que nadie lo titulara.
Ese es el reloj real con el que se planifica la defensa, y no el de la semana en que algo se hace viral. Lo que envejece es el tiempo que una idea tarda en bajar de una entrada de blog borrada a una herramienta que usa cualquiera: primero la prueba de concepto en C++ de los autores, después su reimplementación en Rust. Si tu plan de seguridad se mueve a golpe de titular, llegarás tarde a lo importante.
Cuatro comprobaciones que puedes pedir esta semana
Las dos publicaciones terminan con recomendaciones de detección. Las hemos juntado y traducido a cuatro preguntas que puedes trasladar tal cual a quien opera tu plataforma:
- 1Entropía de los parámetros de arranque. Flashpoint propone inspeccionar las cadenas de inicialización dentro de las estructuras del proceso buscando entropía anormalmente alta, señal habitual de código ofuscado o binario en crudo. SensePost lo dice desde el otro lado: cuando la entropía de la línea de comandos se acerca a la de un shellcode, o se aleja de la de un valor normal. Corresponde a la técnica T1564.010 de MITRE ATT&CK.
- 2Ejecución fuera de la sección ejecutable normal. En concreto, código ejecutándose dentro de los búferes de parámetros del PEB. Es la señal más específica de las cuatro, porque ahí no tiene por qué ejecutarse nada nunca. Técnica T1055.
- 3La secuencia, no la llamada suelta. SensePost señala el patrón: una llamada que deja ejecutable una región de memoria seguida de una manipulación del contexto del hilo. Y, aparte, la lectura desde otro proceso de la estructura de parámetros a la que apunta el PEB. Por separado, las dos cosas son ruido; juntas y en ese orden, no.
- 4Cambios de permisos de memoria a ejecutable. Auditar cuándo una región pasa a poder ejecutarse revela la preparación de la carga. Es la más ruidosa de las cuatro y la que peor sienta sin contexto; por eso va al final y no al principio.
Ninguna de las cuatro es un botón. Las cuatro son consultas sobre telemetría, y que se puedan hacer depende de tres condiciones que rara vez se revisan al firmar el contrato: que el agente emita esos eventos, que se guarden el tiempo suficiente, y que alguien los consulte.
La pregunta que no sale en la ficha de producto
¿Cuántos días de telemetría en bruto guarda tu consola? Si son siete, las cuatro comprobaciones de arriba no sirven de nada frente a un acceso que empezó hace tres semanas, que es el escenario normal: lo que se investiga rara vez es de hoy. Y si el agente lleva días sin enviar nada, el panel puede seguir diciendo que todo está protegido —lo contamos aquí a partir de lo que enseñó Akamai en DEF CON 34—.
La segunda pregunta es más incómoda: ¿quién escribe la consulta? Una plataforma sin nadie que la mire es un antivirus caro con un panel bonito. Ahí está la diferencia entre comprar un EDR y contratar EDR/MDR gestionado: en el segundo caso hay una persona de guardia que tiene la obligación de buscar lo que no ha saltado. Y si la búsqueda encuentra algo, la respuesta también tiene que estar escrita antes: aislar un equipo es un clic y devolverlo a la red hay que haberlo pensado con calma.
Cuándo no hacer nada con esto
Si en tu empresa todavía hay usuarios con administrador local, el correo no obliga a segundo factor y las copias viven en un recurso compartido que ve todo el mundo, esto no es tu prioridad de octubre. Ni de noviembre. Una técnica de post-explotación importa cuando ya has cerrado por dónde entran, y para entrar nadie está usando inyecciones exóticas: usa la contraseña reutilizada de alguien.
Lo decimos sabiendo de qué lado cobramos. Vendemos EDR/MDR gestionado y consultoría, y un artículo que empieza con «cuatro EDR y ninguna alerta» es la puerta perfecta para venderte un cambio de plataforma. No vamos a hacer eso: cambiar de producto porque un laboratorio esquivó al tuyo es la reacción cara y equivocada. Ninguno detecta todo. El que te prometa lo contrario te está vendiendo algo, y la parte cara del presupuesto debería ir a la retención de telemetría y a la guardia antes que a la licencia.
Lo que no afirmamos
- ✗No hemos reproducido la técnica. Todo lo anterior sale de dos publicaciones públicas, citadas abajo, leídas en su fuente original y no en el resumen de nadie.
- ✗Este resultado no se traslada a tu parque. Un laboratorio no es un endpoint con su política, su antigüedad y su tuning. Y nadie puede decirte si tu producto estaba entre los cuatro, porque SensePost no los nombra.
- ✗No hay CVE ni parche. Esto no es una vulnerabilidad de un producto: es un abuso de un mecanismo normal de Windows. El martes de parches que viene no trae nada que arregle esto.
Fuentes (verificadas el 29 de septiembre de 2026): la prueba contra cuatro EDR líderes del mercado configurados para detectar, bloquear y remediar, el mecanismo sobre la línea de comandos, el bloque de entorno y lpReserved/ShellInfo, las recomendaciones de detección (entropía de la línea de comandos, secuencia de permiso ejecutable más manipulación del contexto del hilo, lectura remota de la estructura de parámetros) y la nota sobre el trabajo previo de modexp, sin fecha, señalado por X-C3LL — SensePost, «Process Parameter Poisoning», 6 de julio de 2026, Max Hirschberger y Ogulcan Ugur; la prueba contra una plataforma EDR de código abierto de uso común, el bloqueo del componente XDR en la creación del proceso y en las interacciones COM, el resultado tras añadir desenganche de DLL y política de bloqueo de DLL no Microsoft, la frase sobre las reglas que dependen de la suspensión y reanudación de hilos, las cuatro vías de detección con sus técnicas MITRE ATT&CK (T1564.010, T1055.003, T1055) y la advertencia sobre las múltiples oportunidades de detección — Flashpoint, «Process Parameter Poisoning: Inside a Novel EDR Evasion Technique», 22 de septiembre de 2026.
¿Cuántos días de telemetría guarda tu consola?
Miramos qué eventos emite de verdad tu agente, cuánto tiempo se guardan y quién puede consultarlos un martes a las tres de la madrugada. Si tu configuración ya aguanta las cuatro comprobaciones de arriba, te lo decimos y ahí se acaba.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN