Códigos de razón USN — leer entre bits

Si pasas tiempo en forense de Windows, el bitmask de razón USN acaba siendo memoria muscular. Es un campo de 32 bits que NTFS coloca en cada registro del journal para resumir qué acaba de cambiar en un fichero. Los bits no te cuentan todo — son aditivos, no exclusivos — pero leídos juntos dan un cuadro notablemente preciso del ciclo de vida.

Los bits

Flag	Hex	Lo que significa en la práctica
`DataOverwrite`	`0x00000001`	Se sobrescribió una región del flujo de datos principal
`DataExtend`	`0x00000002`	El flujo de datos principal creció
`DataTruncation`	`0x00000004`	El flujo de datos principal se encogió
`NamedDataOverwrite` / `Extend` / `Truncation`	`0x10` / `0x20` / `0x40`	Igual, pero sobre un flujo alternativo
`FileCreate`	`0x00000100`	Se creó un nuevo fichero o directorio
`FileDelete`	`0x00000200`	El fichero salió del espacio de nombres
`EaChange`	`0x00000400`	Atributos extendidos modificados
`SecurityChange`	`0x00000800`	ACL/propietario modificados
`RenameOldName`	`0x00001000`	Mitad «antes» de un renombrado
`RenameNewName`	`0x00002000`	Mitad «después» de un renombrado
`IndexableChange`	`0x00004000`	Flag indexable conmutado
`BasicInfoChange`	`0x00008000`	Marcas temporales, atributos o compresión cambiaron
`HardLinkChange`	`0x00010000`	Hard link añadido o retirado
`CompressionChange`	`0x00020000`	Compresión NTFS conmutada
`EncryptionChange`	`0x00040000`	Estado EFS cambió
`ObjectIdChange`	`0x00080000`	Object ID asignado o limpiado
`ReparsePointChange`	`0x00100000`	Reparse point cambiado
`StreamChange`	`0x00200000`	Flujo alternativo añadido/renombrado/borrado
`Close`	`0x80000000`	El handle que produjo el cambio se ha cerrado

Close es especial: NTFS agrupa operaciones sucesivas sobre un mismo handle y solo emite el registro final con Close cuando el handle desaparece. Si ves un registro sin Close, estás viendo al sistema purgando estado intermedio — útil, pero el registro con Close es el resumen autoritativo.

Patrones que verás en la naturaleza

Unos pocos patrones aparecen tanto que conviene reconocerlos al instante:

Fichero nuevo escrito por una app. FileCreate | DataExtend → DataExtend | Close → BasicInfoChange | Close. El último es el fichero recibiendo su mtime al cerrar.
Renombrado entre directorios. Dos registros sobre el mismo FileReferenceNumber: RenameOldName | Close y luego RenameNewName | Close. La referencia padre difiere entre ambos — así reconstruyes el movimiento.
Guardar-renombrar atómico. Muchos editores escriben a un fichero temporal y lo renombran sobre el destino. Ves FileCreate en el tmp, FileDelete | Close en el original, y RenameNewName | Close en el tmp.
Ransomware cifrar-renombrar. Registros DataOverwrite cubriendo megabytes, seguidos de RenameNewName | Close con la nueva extensión. La cantidad y cadencia de los DataOverwrite suelen ser donde primero detectas una muestra en disco.
Cuarentena antivirus. FileDelete | Close inmediatamente después de un FileCreate reciente, todo bajo la misma entrada MFT. El journal te da la prueba de que el AV tocó el fichero incluso después de que el fichero haya desaparecido.

Lo que los bits no te dirán

El bitmask de razón habla del fichero, no del actor. No hay usuario, ni PID, ni línea de comandos. Combina el journal con Security.evtx (4663 acceso a objeto) o con Microsoft-Windows-Sysmon/Operational para atar un actor a cada operación. El USN te da el cuándo y el qué; otros logs dan el quién.

Receta práctica de lectura

Cuando abres un journal parseado:

Filtra FileCreate para ver qué es genuinamente nuevo en la ventana temporal.
Busca RenameNewName para atrapar movimientos y patrones de «guardar como».
Pinta el número de DataExtend en el tiempo — las escrituras masivas (backups, cifrado, staging de exfiltración) saltan a la vista.
Lee primero los registros con Close activo; trata los intermedios como evidencia de apoyo.

La app web de este sitio permite filtrar por cualquier combinación de razones, lo que convierte los pasos 1-3 en un ejercicio de un solo clic.