Acceso Raw a NTFS vs. Defensas EDR Modernas.

DiskBleed es una técnica de acceso bajo nivel a NTFS que permite la recuperación completa de archivos bloqueados por el sistema operativo, incluyendo la base de datos de Active Directory (NTDS.DIT) y las Registry hives (SYSTEM, SAM, SECURITY), crear instantáneas (snapshots) ni generar los patrones de comportamiento que las soluciones EDR modernas suelen marcar como sospechosos.

[!] DESCARGO DE RESPONSABILIDAD [!] El objetivo de esta investigación es comprender como funcionan las técnicas actuales de extracción de credenciales y como desde un punto de vista diferente se pueden eludir las defensas en Windows. No se publicaran artefactos ejecutables ni cadenas de ataque completas.

El bloqueo de archivos en Windows reside dentro del I/O Manager (Gestor de E/S) y el File System Driver (Driver del Sistema de Archivos). Cuando un proceso intenta abrir un archivo, la solicitud viaja por el stack de dispositivos hasta el driver del sistema de archivos, el cual verifica si existe un bloqueo activo y devuelve el error de compartición.

Si se omite ese stack y se accede al dispositivo físico directamente como un objeto de caracteres, el driver del sistema de archivos nunca llega a consultar sus bloqueos. El bloqueo no se evalúa porque nunca se cuestiona.

Introducción

Windows expone sus volúmenes y discos como objetos de dispositivo accesibles a través del Namespace de Dispositivos. Un handle abierto hacia \\.\C: no representa un sistema de archivos; representa el volumen físico subyacente. Leer desde ese handle significa leer sectores en bruto, sin que el driver de NTFS interponga ninguna lógica de bloqueo.

// El driver del sistema de archivos nunca ve esta llamada.
// Para él, estos bytes no existen.

HANDLE hVol = CreateFile("\\\\.\\C:",
                         GENERIC_READ,
                         FILE_SHARE_READ | FILE_SHARE_WRITE,
                         NULL, OPEN_EXISTING, 0, NULL);

// A partir de aquí: ReadFile() opera sobre sectores físicos.
// El bloqueo de NTDS.DIT no existe en este espacio.

Lo que sigue es una operación de parsing: leer el Boot Sector para entender la geometría del volumen, localizar la MFT (Master File Table), iterar a través de sus registros para encontrar los archivos objetivo por nombre y ruta de origen, y extraer su contenido siguiendo los data runs que mapean los clusters del archivo en el disco.

Una vez localizado el registro MFT del archivo objetivo, se busca el atributo $DATA sin nombre (name_length == 0, correspondiente al flujo de datos primario). La extracción varía dependiendo de si el atributo es residente o no residente:

• Atributos Residentes: Si el flag non_resident es 0, todo el contenido del archivo está incrustado dentro del propio registro MFT, inmediatamente después de la cabecera del atributo. Se lee directamente del búfer del registro y se escribe en el archivo de destino. Este caso es típico en archivos muy pequeños (<≈700 bytes).
• Atributos No Residentes y Data Runs: Para archivos grandes como NTDS.DIT (que generalmente oscilan entre cientos de MB y varios GB), el atributo $DATA es no residente. La cabecera NONRESIDENT_ATTR contiene el tamaño real del archivo, el tamaño asignado (redondeado a múltiplos de cluster) y el offset dentro del atributo donde comienza la lista de data runs.

NTFS no almacena necesariamente los datos de un archivo de forma contigua. Los fragmentos del archivo se describen en una lista de data runs: pares de (longitud, offset) que indican qué clusters del disco contienen cada parte del archivo.

El algoritmo de decodificación de data runs recorre la lista hasta encontrar el byte terminador 0x00. Por cada run:

1. Decodifica la longitud en clusters y el offset LCN diferencial.
2. Acumula el offset para obtener el LCN (Logical Cluster Number) absoluto.
3. Lee todos los clusters del fragmento de forma secuencial por sectores.

La escritura en el archivo de destino se realiza en fragmentos (chunks) de 256 clusters (1 MB con clusters de 4 KB) para optimizar el uso de memoria y permitir el procesamiento de archivos altamente fragmentados.

Esta imagen corresponde a la lectura del registro ntds.dit en la MFT; podemos observar el atributo con propiedad no residente y los diferentes data runs que alojan el archivo.

La siguiente imagen corresponde a la lectura del registro SYSTEM en la MFT. Podemos ver los diferentes data runs que alojan el archivo con fsutil.exe, una herramienta propia de Windows.

Por qué las técnicas actuales están “quemadas”.

Las técnicas conocidas para obtener credenciales mediante el manejo de NTDS.DIT en un sistema activo han sido profundamente estudiadas. Precisamente por ello, los EDR modernos las tienen catalogadas como patrones de alta fidelidad:

El patrón común: todas estas técnicas siguen rutas de ejecución predecibles y documentadas. Sus llamadas al sistema son conocidas y sus secuencias de eventos son reconocibles. El EDR no necesita ser “inteligente”; solo tiene que reconocer un patrón que ya ha visto mil veces.

DiskBleed

Para un primer enfoque se desarrolló un artefacto que explota la técnica localmente, se pudieron obtener los archivos NTDS y SYSTEM sin ningún tipo de bloqueo del sistema operativo.

Esta imagen corresponde a la lectura de los registros NTDS y SYSTEM en la MFT. Se observa cómo la herramienta extrae los datos que conforman los archivos.

Para validar las capacidades evasivas frente a un EDR de grado empresarial en un entorno real, se implementó un enfoque de exfiltración basado en una arquitectura cliente-servidor. Para ello, se desarrolló un artefacto capaz de realizar la lectura del disco en bruto (raw) que, actuando como servidor, expone el flujo de datos a través de una interfaz Named Pipe en lugar de utilizar protocolos de red tradicionales propensos a la monitorización.

En el extremo receptor (entorno Linux), se utilizó un artefacto cliente para establecer la conexión hacia el Named Pipe. El flujo de datos se gestiona de la siguiente manera:

FUSE (Filesystem in Userspace): El cliente utiliza FUSE para proyectar el flujo de datos desde la tubería y transformarlo en una imagen de disco virtual en el sistema de archivos local.

Una vez que el dispositivo de bloques virtual está disponible, la estructura de archivos se monta utilizando ntfs-3g. Con el disco montado, el sistema permite la navegación directa a través del árbol de directorios y la extracción selectiva de información, funcionando como si el disco estuviera físicamente conectado a la máquina local.

Permitiendo navegación sin ningún tipo de restricción dentro del sistema de archivos y exfiltración de archivos que están bloqueados desde el espacio de usuario en Windows.

Una mirada al kernel.

El programa cliente abre un handle al dispositivo, lo que crea un _file_object que podemos inspeccionar interceptando el servicio NtReadFile.

El proceso ntds6.exe ha intentado realizar una operación de lectura en un objeto cuyo handle es 0x8C. El puntero de instrucción (rip) se encuentra ahora en el prólogo de la función, lo que nos permite inspeccionar sus argumentos.

La secuencia de ejecución del artefacto interactúa directamente con el sistema de archivos de la siguiente manera:

ntds6.exe → ReadFile (Win32 API) → NtReadFile (Syscall) → Windows Kernel

Esto valida que el breakpoint condicional en el Handle 0x8C detuvo efectivamente el hilo de ejecución justo cuando el artefacto intentaba acceder a los datos.

ntds6.exe no solo tiene el disco abierto, sino que también cuenta con permisos explícitos de lectura (00120089).

La estructura confirma los permisos con los que se abrió el disco:

• ReadAccess : 0x1: El proceso tiene permiso activo para leer los datos del disco.
• SharedRead / SharedWrite : 0x1: El disco permite que otros procesos lo lean o escriban simultáneamente, lo cual es típico en bases de datos activas.

El hecho de que el FileName esté vacío en esta estructura es lo esperado, ya que solo estamos enviando la apertura directa del volumen (\.\C:) y no un handle a un archivo convencional.

Esto es particularmente útil, ya que un driver de minifiltro puede identificar cuándo se está abriendo un archivo. Puede ver de qué archivo se trata, qué proceso realiza la apertura (FltGetRequestorProcessId), los derechos de acceso solicitados, etc. Por ejemplo, un atacante podría crear una shadow copy e intentar copiar el SAM (\\GLOBALROOT\Device\HarddiskVolumeShadowCopyX\Windows\System32\config\SAM), y el minifiltro lo detectaría. Sin embargo, en nuestro caso, solo estamos abriendo el volumen en sí (\\.\C:), por lo que el minifiltro nunca ve aperturas de archivos individuales, solo una lectura bruta sobre el objeto de dispositivo del volumen.

Aquí estamos analizando el _DEVICE_OBJECT (0xffffd40fe45818f0) asociado al _FILE_OBJECT que identificamos en el paso anterior. Esta es la pieza final para entender dónde se encuentra físicamente el archivo que ntds6.exe intenta leer.

La salida revela cómo Windows gestiona el almacenamiento a través de capas:

• Driver Principal: El dispositivo pertenece a \Driver\volmgr (Volume Manager). Este es el driver responsable de gestionar los volúmenes lógicos en Windows.
• UpperDevices: Inmediatamente arriba en el stack se encuentra un objeto para \Driver\volume. Esto indica que las solicitudes de lectura pasan primero por la capa genérica de volumen antes de llegar al gestor de volúmenes.
• FileSystem: El dispositivo está vinculado a \FileSystem\Ntfs. Esto confirma definitivamente que el archivo está almacenado en una partición formatted con NTFS.

Esta vista es esencial para comprender el flujo de datos desde el hardware hasta el sistema de archivos. La imagen muestra el Device Stack (pila de dispositivos) completo para el objeto que hemos estado rastreando.

Jerarquía del Stack:

Lista de drivers que procesan cualquier solicitud de Entrada/Salida (I/O) para este volumen específico:

• \Driver\volmgr (Capa Inferior): El punto de entrada en este stack es el Volume Manager. El nombre del objeto se identifica claramente como HarddiskVolume2. Esta es la partición física o lógica real donde residen los datos.
• \Driver\volume (Capa Intermedia): Actúa como una interfaz de clase de volumen genérica sobre el gestor de volúmenes.
• \Driver\volsnap (Capa Superior): Este es el driver de Volume Shadow Copy (VSS). Su presencia indica que este volumen soporta (o tiene activas) instantáneas de volumen.

Detección.

Se recomienda catalogar como sospechoso todo proceso que obtenga un handle directo al volumen \\C: Esto permite una detección temprana de actividades anómalas, garantizando la continuidad operativa mediante el despliegue de alertas automatizadas o la interrupción preventiva de procesos no autorizados para minimizar la superficie de exposición.

Conclusiones.

Para un adversario, el uso de DiskBleed representa un salto estratégico crítico, ya que permite ejecutar la táctica de Acceso a Credenciales (TA0006) evadiendo la efectividad de los EDR modernos. Al omitir los mecanismos convencionales de control de archivos y acceder directamente a las estructuras del disco para extraer el NTDS.dit, esta técnica evade los File System Minifilter Drivers que los sistemas de seguridad utilizan para monitorear el acceso a datos sensibles. Esto es crítico en una operación ofensiva, ya que no solo garantiza la obtención de secretos para el movimiento lateral y la escalada de privilegios, sino que lo hace de forma invisible para las alertas heurísticas del kernel, dejando a los equipos de respuesta a incidentes sin visibilidad sobre el compromiso total del dominio.

Agradecimientos.

Rilke Petrosky y Carlos Garrido Esta investigación no existiría sin ellos. No solo como referentes técnicos, sino como auténticos guías en todo el proceso. Su disposición para compartir conocimientos de alto nivel, su paciencia en cada sesión de trabajo y su forma de razonar los problemas desde la capa de hardware hacia arriba marcaron el rumbo de toda esta investigación. El conocimiento que aportaron generosamente durante el desarrollo de DiskBleed es la base real sobre la cual se sostiene este paper. Honor a quien honor merece.