1. Principales Vulnerabilidades y Filtraciones de la semana

2. Bring Your Own EDR: cómo Akamai convirtió el propio antivirus SentinelOne en un caballo de Troya invulnerable

3. De MessageBoxA a rootkit invisible: el manual que todo defensor debería leer aunque no sea programador

💥Microsoft confirma explotación activa de CVE-2026-69836 (CVSS 10.0) en Entra ID, un fallo de deserialización de datos no confiables que permitía ejecución remota de código sin autenticación ni interacción del usuario. Ya está mitigado del lado de Microsoft y no requiere ninguna acción del cliente, pero la compañía no ha revelado quién lo explotó, desde cuándo, ni el alcance real. Llegó junto a otros 21 parches del mismo día, incluyendo hasta seis fallos más con CVSS 10.0 en Azure Arc y Exchange Online (Noticia)

💥Más de 14.500 cámaras Dahua comprometidas en la operación bautizada CameraSwarm, combinando ataques de credenciales con dos fallos de bypass de autenticación ya conocidos y técnicas de relevo P2P; un vector P2P independiente alcanzó 283 cámaras identificadas por número de serie, y 1.923 dispositivos quedaron con una cuenta persistente instalada por el atacante (Noticia)

💥NSA, CISA, FBI, DOE y EPA emiten una alerta conjunta sobre una campaña activa contra PLCs Siemens S7, con actores usando servicios de escaneo en internet y scripts asistidos por IA para localizar sistemas expuestos, desactualizados o mal protegidos (Noticia)

💥Explotan activamente CVE-2026-19478 en GitLab (CVSS 9.4) apenas días después de su divulgación, un fallo de inyección de código que permite a un atacante no autenticado modificar o eliminar proyectos públicos sin necesidad de credenciales ni interacción del usuario. (Noticia)

💥CISA añade a su catálogo KEV la explotación activa de CVE-2026-64849 (CVSS 9.3) en MLflow, la popular plataforma open-source de MLOps con más de 60 millones de descargas mensuales: un SSRF no autenticado en la funcionalidad de webhooks del registro de modelos permite a un atacante hacer que el propio servidor MLflow realice peticiones HTTP hacia endpoints internos, incluidos los metadatos de la nube (AWS, Azure, GCP), robando credenciales y tokens en cuestión de horas tras la divulgación (Noticia)

Bring Your Own EDR: cómo Akamai convirtió el propio antivirus SentinelOne en un caballo de Troya invulnerable

Hay un tipo de investigación de seguridad que resulta especialmente inquietante, no porque explote un fallo exótico, sino porque le da la vuelta a la premisa más básica de la defensa: ¿qué pasa cuando el software en el que confías ciegamente, precisamente porque está ahí para protegerte, se convierte en el arma que te ataca? Eso es lo que Shahak Morag, investigador de Akamai Security Intelligence Group, presentó en DEF CON 34 bajo el nombre "Bring Your Own EDR", y el resultado es una de las demostraciones más completas que se han visto sobre cómo abusar de un EDR comercial de gama alta, en este caso SentinelOne, sin necesidad de un solo exploit de kernel ni un driver vulnerable.

El punto de partida: entender qué protege a un EDR de sí mismo. Desde Windows 8.1, existe un mecanismo llamado Protected Process Light (PPL), que blinda a los procesos críticos del sistema y de seguridad frente a manipulación: bloquea el acceso a memoria desde procesos no protegidos, impide cargar DLLs sin firmar, evita que cualquier usuario pueda matar el proceso, y restringe el acceso a herramientas de depuración. La mayoría de soluciones EDR modernas, incluida SentinelOne, se ejecutan bajo el nivel de protección PsProtectedSignerAntimalware-Light. En teoría, esto las hace intocables para cualquier proceso normal. En la práctica, Akamai encontró la grieta.

El punto de entrada fue, de forma casi irónica, una interfaz pensada para diagnóstico. Analizando el agente de SentinelOne, los investigadores enumeraron sus objetos COM expuestos y encontraron tres procesos con interfaces accesibles: SentinelHelper, SentinelUI y SentinelAgent. Dentro de SentinelHelper apareció un método llamado Dump, que recibe un PID como parámetro y genera un volcado de memoria de ese proceso. Lo probaron contra procesos protegidos, y funcionó. El motivo: el método solo comprobaba si el usuario tenía privilegios de administrador, sin verificar nada más, a pesar de ejecutarse él mismo como proceso protegido (hereda la protección PPL del servicio SentinelHelperService.exe). El resto de funciones de esa misma interfaz sí verificaban que quien llamaba residía dentro del directorio de instalación de SentinelOne. Dump no, porque en teoría solo la usaba un script interno de diagnóstico que corre desde otra ruta. Ese descuido de validación fue la primera grieta: cualquier administrador local podía volcar la memoria de cualquier proceso protegido, incluido el propio SentinelOne, sin exploit ni driver malicioso de por medio.

De volcar memoria a ejecutar código: el verdadero reto técnico. Tener un volcado de memoria no es lo mismo que ejecutar código dentro de un proceso protegido. Akamai partió de una investigación previa (PPLSystem, de @Slowerz) que ya había demostrado cómo extraer secretos COM de procesos volcados para mapear una DLL sin firmar dentro de un proceso PPL, pero con una limitación crítica: ese código nunca llegaba a ejecutarse de verdad, quedaba como "código muerto" en memoria, sin relocalizaciones corregidas ni hilo de ejecución. Cerrar esa brecha les llevó por un camino de depuración bastante fino, resuelto en cinco pasos encadenados:

1. Encontrar la dirección del shellcode en memoria, ya que la primitiva original de PPLSystem solo podía leer direcciones de 32 bits, insuficiente en un entorno de 64 bits, así que recurrieron a volcar el proceso de nuevo y localizar la dirección en la lista de módulos cargados.

2. Resolver la protección del punto de entrada: la primera página que contenía el punto de entrada estaba mapeada como solo lectura en vez de ejecutable, así que tuvieron que llamar a NtProtectVirtualMemory para marcarla como ejecutable tras el mapeo.

3. Recuperar una sección de shellcode "perdida": la herramienta que generaba el shellcode (PE_TO_SHELLCODE) añadía al final del binario el código encargado de corregir relocalizaciones, pero sin registrarlo en la tabla de secciones del PE, así que Windows simplemente no lo mapeaba. Solución: un script en Python que añade esa parte como una sección PE legítima.

4. Conseguir permisos de escritura para las relocalizaciones, marcando todas las secciones del ejecutable como RWX (lectura, escritura y ejecución), ya que el shellcode necesitaba reescribir referencias en la sección .idata, que por defecto no tenía permisos de escritura.

5. Evitar cargar DLLs sin firmar dentro de un proceso PPL: el paso más delicado. Al probar la técnica contra MsMpEng.exe (el propio Microsoft Defender, un proceso protegido), el shellcode fallaba al intentar cargar vcruntime140.dll, no firmada por Microsoft, algo que un proceso PsProtectedSignerAntimalware-Light rechaza automáticamente. La solución fue compilar el ejecutable de forma estática, eliminando esa dependencia externa.

Y esto era solo el principio. La pregunta lógica que se hicieron después fue: ¿y si SentinelOne ni siquiera está instalado en el endpoint objetivo? La respuesta resultó ser inquietantemente sencilla. Basta con conseguir un instalador MSI legítimo de SentinelOne, algo que circula por internet desde hace años, subido por clientes reales. El instalador exige un "token de sitio" para validar la instalación, y ese token resultó estar protegido de forma trivial: mediante Process Monitor, los investigadores descubrieron que el propio instalador crea una DLL temporal con nombre aleatorio durante el proceso, la usa para validar el token, y la borra justo después. Interceptando esa carga con WinDbg, extrajeron y analizaron la lógica: el token es simplemente un JSON codificado en Base64 con dos campos, url y site_key. Construyeron un JSON completamente inventado, con una URL apuntando a localhost y una clave arbitraria, lo codificaron en Base64, y la instalación se completó sin problemas, sin necesidad de ningún servidor real escuchando ni de una licencia válida. El resultado: un agente de SentinelOne que no funciona en absoluto, pero que muestra un tranquilizador estado "SEGURO" en pantalla, dando una falsa sensación de protección a cualquiera que lo mire.

El golpe de gracia: convertir las defensas del EDR en protección para el propio malware. Aquí es donde la investigación da su giro más perverso. SentinelOne incluye una utilidad de gestión local llamada sentinelctl.exe, con un comando unprotect que desactiva todas las protecciones anti-manipulación del agente: bloqueo de manipulación directa de procesos, de modificaciones del sistema de archivos, de cambios de configuración del servicio. Con esas protecciones desactivadas, los investigadores colocaron su malware directamente dentro del propio directorio de instalación de SentinelOne, y después volvieron a activar la protección con el comando protect. El resultado es que el malware queda blindado por partida doble: por los mecanismos PPL de Windows y por el propio sistema anti-manipulación de SentinelOne. Cualquier proceso que intente acceder a esos archivos maliciosos solo obtiene permisos PROCESS_QUERY_LIMITED_INFORMATION, es decir, apenas puede consultar información básica del proceso. El propio EDR se convierte en el guardián de su atacante.

Para rematar, también resolvieron el problema de la telemetría. Consultando la interfaz GetAgentStatusJSON, descubrieron que el agente expone en texto claro la URL del servidor de gestión al que reporta. Modificando el archivo hosts local, sin ningún tipo de monitorización sobre ese archivo, apuntaron esa URL hacia 127.0.0.1, bloqueando toda comunicación con la consola de gestión central sin que el agente deje de mostrarse como activo y protegido de cara al usuario local.

¿Es esto exclusivo de SentinelOne? No del todo. Akamai confirma haber replicado con éxito parcial la técnica contra otros proveedores, usando capacidades de hardlink de Google Project Zero para modificar binarios protegidos del EDR, aunque advierten que en esos casos aún no han confirmado una vía completa de explotación adicional más allá de la desactivación. También citan un precedente relacionado de SafeBreach contra Palo Alto Networks Cortex XDR, que demostró cómo un instalador antiguo podía convertir ese EDR en herramienta ofensiva. El patrón, dicen los investigadores, es más amplio que un solo producto: cuando un software de seguridad opera con los privilegios más altos del sistema por necesidad, cualquier interfaz administrativa mal asegurada dentro de ese software se convierte en un objetivo de máximo valor.

(Investigación completa de Akamai)

De MessageBoxA a rootkit invisible: el manual que todo defensor debería leer aunque no sea programador

"Malware Development Essentials for Operators" es un artículo publicado en f00crew que no introduce ninguna técnica nueva, y eso es precisamente lo que lo hace valioso. Construye una cadena de ataque completa, paso a paso, desde la primera línea de código hasta un rootkit en modo kernel con ocultación de procesos, añadiendo una capa de evasión en cada etapa y midiendo su impacto real contra 72 motores de detección. El resultado es uno de los mejores mapas visuales que existen de cómo los atacantes piensan sobre la detección, no como un obstáculo fijo sino como una función de coste que reducen metódicamente.

Vale la pena leerlo aunque no hagas reversing, porque lo que describe es exactamente el modelo mental que hay detrás de la mayoría de implantes que los equipos de respuesta encuentran en incidentes reales.

El hilo conductor: cada técnica resuelve un problema de visibilidad específico.

Todo empieza con una función tan inocua como MessageBoxA. En su forma normal, esa llamada deja una huella perfectamente visible en la Import Address Table (IAT) del ejecutable: cualquier herramienta de análisis estático, incluida cualquier firma de antivirus, puede abrir el binario y ver exactamente qué funciones importa. El primer paso del artículo resuelve esto cargando las funciones en tiempo de ejecución a través del PEB (Process Environment Block), la estructura que Windows crea en memoria para cada proceso y que contiene la lista de todos los módulos cargados. En vez de declarar una dependencia estática de kernel32.dll, el código camina esa lista a mano, parsea la tabla de exportaciones del PE para encontrar la dirección de la función que necesita, y la llama directamente a través de un puntero. La IAT queda limpia. Sin esa entrada en la tabla de importaciones, el análisis estático no tiene nada a lo que aferrarse.

El siguiente problema a resolver es la IAT de la víctima, no del atacante. Si el malware quiere interceptar llamadas de un proceso legítimo (para ver qué abre, qué escribe, qué conecta), puede sobrescribir las entradas de la IAT de ese proceso con punteros a sus propias funciones. La llamada sale del proceso legítimo, pasa por el hook, y el atacante controla qué llega realmente al sistema.

Process hollowing: el arte de ejecutar código con la identidad de otro.

La técnica del "proceso hueco" merece explicación aparte porque es una de las más usadas en malware real y sigue siendo efectiva. El atacante crea un proceso legítimo (en el ejemplo, GoogleUpdate.exe) en estado suspendido, es decir, existe como proceso en el sistema pero su hilo principal no ha ejecutado ninguna instrucción todavía. Mientras está parado, el atacante borra el código original de la memoria del proceso usando VirtualAllocEx para reservar espacio y WriteProcessMemory para copiar su propio ejecutable, luego actualiza el contexto del hilo (específicamente el registro que apunta a la dirección de entrada del programa, RCX en x64) para que cuando se reanude el proceso, empiece a ejecutar el código malicioso en vez del original. Desde el sistema operativo y desde muchas herramientas de monitorización, lo que se ve es GoogleUpdate.exe ejecutándose. Desde dentro es cualquier cosa que el atacante haya puesto ahí.

El artículo señala honestamente un bug en su propio código de demostración: el área reservada para el contexto del hilo usa sizeof(CTX) donde CTX es un puntero, así que solo reserva 4 u 8 bytes en vez de los cientos que necesita la estructura CONTEXT completa. Esa honestidad es rara en este tipo de material y hace el artículo más útil, no menos: el código de enseñanza no es código de producción, y reconocerlo explícitamente obliga al lector a entender lo que está haciendo, no solo a copiar y pegar.

La inyección de DLL: dos filosofías distintas.

Hay dos formas fundamentalmente distintas de meter una DLL en un proceso ajeno, y el artículo explica bien por qué importa la diferencia. La primera, inyección por ruta, escribe solo el path del fichero en la memoria del proceso objetivo y hace que llame a LoadLibraryA con esa ruta: el cargador legítimo de Windows hace el resto, la DLL aparece en la lista de módulos del proceso, Process Explorer la ve, cualquier EDR que monitorice módulos cargados la ve. La segunda, inyección reflectiva, copia el binario completo de la DLL en memoria y salta directamente a un stub que se auto-carga: procesa sus propias relocalizaciones, resuelve sus propias importaciones, llama a su propio DllMain. El cargador de Windows no participa, y la DLL no aparece en la lista de módulos. La invisibilidad tiene un precio en complejidad, pero es una complejidad asumible.

En cuanto al mecanismo de ejecución, el artículo cubre CreateRemoteThread (el más sencillo, el más vigilado), y NtCreateThreadEx directamente desde ntdll, que saltaba la comprobación de aislamiento de sesión que Microsoft introdujo en Vista. El concepto es el mismo que en la parte de usuario del artículo de SentinelOne que cubrimos antes: bajar un nivel en la pila de llamadas para evitar el punto de vigilancia que está un nivel más arriba.

La progresión de evasión: 27 → 9 → 5 detecciones.

Aquí es donde el artículo pone números a algo que normalmente se queda en lo abstracto. El punto de partida es shellcode de Metasploit inyectado directamente: 27 de 72 motores lo detectan. No por la técnica de inyección, sino porque el shellcode en sí tiene firmas conocidas, cadenas reconocibles, patrones de bytes identificados por las firmas de los motores.

La primera capa que añade el artículo es ofuscación XOR de cadenas: cifra tanto el shellcode como los nombres de funciones como NtCreateThreadEx (que aparecerían en el binario en claro y serían una señal de alerta inmediata para cualquier análisis estático), y los descifra en tiempo de ejecución con la misma clave. Resultado: 9 detecciones. Reducción del 67%.

La segunda capa combina cifrado AES del shellcode con la técnica "Early Bird": el shellcode se descifra en memoria justo antes de ejecutarse, y la ejecución usa APCs (Asynchronous Procedure Calls) encoladas sobre un proceso creado en estado suspendido. El timing es la clave de Early Bird: el APC se ejecuta antes de que el hilo del proceso llegado a su propio punto de entrada, lo que significa antes de que muchos EDR hayan tenido oportunidad de poner sus hooks en el proceso. Fue documentado por Cyberbit en 2018 como una técnica usada por APT33 contra el sector aeroespacial y energético, y el artículo lo reproduce con detalle. Resultado: 5 detecciones de 72.

El artículo es claro en que con técnicas adicionales (stubs de syscall directas, sleep obfuscation para dificultar el análisis dinámico con timeouts cortos, cifrado del payload en disco con clave derivada del entorno de la víctima) llegar a cero detecciones es alcanzable. No lo presenta como un logro sino como una advertencia: el coste de evasión es relativamente bajo para cualquiera con conocimientos básicos de Windows internals.

Lo que persiste incluso en el estado de 5 detecciones son comportamientos, no firmas: creación de procesos en estado suspendido, escritura en memoria de otro proceso seguida de ejecución, encolado de APCs. Estos son los indicadores que los EDR modernos intentan detectar a nivel conductual más que a nivel de firma, y son precisamente los que hay que monitorizar.

El salto al kernel: cuando el atacante ya no tiene árbitro.

La segunda mitad del artículo entra en modo kernel, y el cambio de tono es brusco: en user mode, el sistema operativo actúa como árbitro de todo lo que haces. En kernel mode, tú eres el sistema operativo. Un bug no cierra tu programa, provoca una pantalla azul. La libertad viene acompañada de responsabilidad total.

Para llegar al kernel hace falta un driver firmado, y aquí el artículo toca el punto más políticamente incómodo de esta área: en Windows de 64 bits, Driver Signature Enforcement (DSE) obliga a que todos los drivers estén firmados; si hay Secure Boot activo, solo se cargan drivers firmados con certificados EV de Microsoft. Las tres salidas que lista el artículo son las que se ven en el mundo real: robar certificados de firma (como en el caso del certificado de NVIDIA filtrado en el ataque de Lapsus$), explotar drivers vulnerables legítimamente firmados para deshabilitar DSE desde dentro (BYOVD, la técnica del artículo de Akamai del EDR de SentinelOne), o apuntar a sistemas donde Secure Boot está desactivado.

Una vez en el kernel, el artículo implementa cuatro capacidades que encajan en casi cualquier rootkit real:

La inyección de DLL desde kernel usa PsSetLoadImageNotifyRoutine, un callback oficial y documentado del kernel que se activa cada vez que cualquier imagen (EXE o DLL) se carga en cualquier proceso del sistema. El rootkit espera a detectar kernel32.dll porque sabe que en ese punto el proceso ya puede ejecutar código user-mode, parsea la tabla de exportaciones de kernel32.dll directamente desde ring 0 para encontrar la dirección de LoadLibraryExA, y encola un APC de kernel sobre el hilo del proceso. Los APCs de kernel no requieren estado alertable del hilo: se ejecutan la próxima vez que el IRQL del hilo baja a nivel pasivo, que es casi inmediato. Este es exactamente el mecanismo que usó la familia Sirifef (ZeroAccess) para inyectar su DLL en todos los procesos del sistema.

La ocultación de procesos mediante DKOM (Direct Kernel Object Manipulation) modifica directamente la lista doblemente enlazada ActiveProcessLinks dentro de la estructura EPROCESS del kernel, eliminando el nodo del proceso que se quiere ocultar. Cualquier herramienta que enumere procesos caminando esa lista, que es como funcionan el Administrador de Tareas, tasklist.exe y la mayoría de herramientas forenses, simplemente no encontrará el proceso. El proceso sigue ejecutándose, sus hilos siguen siendo planificados por el scheduler (que usa estructuras completamente distintas), sus handles siguen existiendo. Solo es invisible para la enumeración estándar. El punto crítico que menciona el artículo: los offsets dentro de EPROCESS son específicos de cada build de Windows, son opacos (no documentados oficialmente), y usar offsets incorrectos corrompe memoria del kernel y provoca BSOD inmediato. Además, en Windows de 64 bits, PatchGuard monitoriza periódicamente la integridad de estas estructuras y puede detectar manipulaciones con un retardo de minutos a horas, provocando un BSOD con código CRITICAL_STRUCTURE_CORRUPTION.

La misma lógica DKOM se aplica a la ocultación del propio driver: desvincular la entrada LDR_DATA_TABLE_ENTRY del driver de la lista de módulos cargados del kernel lo hace invisible para lm en WinDbg y para NtQuerySystemInformation(SystemModuleInformation). La diferencia con el proceso es que aquí el artículo sí eleva el IRQL a nivel DPC antes de modificar la lista, para evitar que otro núcleo esté leyendo la misma lista simultáneamente.

El robo de token para escalada de privilegios es la técnica más usada en exploits de kernel: leer el token del proceso SYSTEM (cuyo puntero expone la variable global PsInitialSystemProcess), escribir ese puntero en el campo token de cualquier otro proceso, y ese proceso pasa a ejecutarse como NT AUTHORITY\SYSTEM. Es la misma técnica que ejecuta casi cualquier payload de escalada de privilegios después de explotar un driver vulnerable.

Lo que las defensas ven (y lo que no ven).

El artículo menciona pero no profundiza en dos limitaciones importantes de estas técnicas que son relevantes desde el punto de vista defensivo. La primera es que DKOM oculta un proceso de la enumeración estándar pero no de un análisis forense que escanee directamente la memoria del kernel buscando cabeceras PE, o que compare los procesos visibles con los threads que aparecen en los ready queues del scheduler. Herramientas como Volatility hacen exactamente esto. La segunda es que ObRegisterCallbacks, que el artículo menciona como mecanismo para proteger procesos del rootkit stripping access rights de cualquier handle que intente abrirlos, es el mismo mecanismo que usan los EDR para proteger sus propios procesos, y la competición entre quién registra su callback con mayor "altitud" (prioridad) es una parte real del ecosistema de seguridad de Windows.

Lo que hay que monitorizar en entornos reales a partir de lo que describe este artículo: creación de procesos en estado suspendido seguida de escritura de memoria y encolado de APCs; resolución dinámica de funciones de ntdll (especialmente NtCreateThreadEx y NtAllocateVirtualMemory) en procesos que no deberían hacerlo; carga de drivers no firmados o inesperados; cualquier intento de registrar callbacks de imagen o proceso desde un driver no reconocido; y la aparición de threads sin proceso padre visible en herramientas que miran por debajo de la API estándar.

El artículo cierra con una nota sobre SSDT hooking, la técnica dominante pre-Vista que consistía en reemplazar punteros en la tabla de llamadas al sistema para interceptar toda la enumeración de procesos. PatchGuard la hizo prácticamente inviable en x64, lo que empujó a los rootkits hacia las técnicas que describe el resto del documento: DKOM, callbacks, minifilters. La historia es un buen recordatorio de que las restricciones de seguridad del sistema operativo no eliminan las técnicas de ataque, las desplazan.

(Artículo completo)

Ver historial de Publicaciones