Detectar exfiltración de datos y copias a USB con el journal USN

Tras el ransomware, la segunda pregunta más frecuente que oímos en DFIR es «¿salió algo de aquí?». El journal USN es uno de los lugares más baratos para responderla. Registra cada creación, cada renombrado, cada extensión de datos — lo que significa que la exfil por USB, el staging para sync en la nube y el clásico «volcar todo en un temp y zippear» se ven muy distintivos al plotear una timeline.

Este artículo es el playbook para encontrar esos patrones.

Las USB son el modo fácil

Cuando un usuario conecta un volumen removible, Windows le asigna una nueva letra y el sistema de archivos del dispositivo recibe su propio $UsnJrnl si es NTFS. Pero cuando se copian archivos desde el sistema investigado hacia la USB, el journal del volumen origen sigue registrando el lado lectura como una serie de accesos — y, más importante, el journal de destino (si tienes la imagen de la USB) muestra las escrituras.

Lo que típicamente tienes:

• El journal del disco origen — muestra qué se abrió/cerró y los archivos temporales.
• Las hives del registro — SYSTEM\MountedDevices, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 y los events Setup de hardware para identificar qué USB se conectó.
• El journal del volumen de destino, si el dispositivo era NTFS y puedes imagenarlo — ahí es donde se ven los archivos reales.

Primera señal en el origen: un cluster de aperturas de archivos en una ventana ajustada apuntando al árbol de documentos/desktop/downloads del usuario. Las aperturas no siempre producen registros USN, pero los cachés del sistema y los escaneos AV que las siguen suelen producirlos (tocar atributos dispara BasicInfoChange | Close).

Una señal más decisiva llega si el atacante zippea primero: un FileCreate de un .7z, .zip, .rar o un archivo con nombre aleatorio en una ruta temp, seguido de registros DataExtend | Close sostenidos hasta que el archivo alcanza su tamaño final.

El patrón clásico staging-y-luego-copia

Un patrón frecuente, mapeado a T1074 Data Staged en MITRE ATT&CK:

FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
DataExtend | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\customers.csv
DataExtend | Close   ...
…
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3.zip
DataExtend | Close   ...           ← muchos, el archivo crece
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (limpieza)

Tres señales juntas:

• Una ráfaga de FileCreate en un único directorio de staging.
• DataExtend posteriores en un único archivo cuyo tamaño final aproxima la suma de los archivos stageados.
• Un barrido de eliminación del directorio de staging poco después de la creación del archivo.

Filtrar FileCreate en \AppData\Local\Temp\, \Public\, \Downloads\ u otras ubicaciones escribibles del árbol del usuario, y buscar clusters en tiempo de >50 archivos en <60 segundos. Así se ve un robo interno o un infostealer en disco.

Staging por sync en la nube

OneDrive, Dropbox, Google Drive — todos mantienen una carpeta local de sync. Cualquier cosa volcada ahí se sube en cuanto el agente la ve. Dos señales:

• RenameNewName en masa hacia la carpeta de sync desde Desktop\, Documents\ o Downloads\. La mitad del rename te dice el padre anterior; el nuevo padre es la carpeta de sync.
• DataExtend | Close en archivos dentro de la carpeta de sync sin FileCreate correspondiente de ninguna app del usuario. El propio agente escribe esos — son descargas — pero los creates son los que quieres para uploads.

Para filtros por nombre, las carpetas de sync canónicas en Windows son \Users\<u>\OneDrive\, \Users\<u>\Dropbox\ y \Users\<u>\Google Drive\. Las herramientas listadas en los recursos insider threat TLP-WHITE de CISA tienen supuestos de baseline similares.

Heurísticas que sí funcionan

Tras varias intervenciones, las heurísticas que tienden a marcar exfil real son:

1. Ráfaga de creates: más de N FileCreate en un solo directorio en T segundos. Calibrable a la baseline. Empezamos con N=50, T=60.
2. Archivo tras la ráfaga: un único FileCreate de un archivo con extensión conocida de archive (.zip, .7z, .rar, .tar.gz) a minutos de una ráfaga de creates, con DataExtend acumulando varios MB.
3. Renombrado masivo cruzando fronteras: registros RenameNewName cuyo nuevo padre es estructuralmente distinto del anterior (Documents → OneDrive, Desktop → Public, etc.). Fácil de expresar como regex sobre las rutas resueltas.
4. Ráfagas fuera de horas: cualquiera de las anteriores fuera del horario laboral de ese usuario. Pareja con los events de logon de Security.evtx para confirmación.

El parser de este sitio expone filtrado por ventana temporal y filtros por razón que hacen 1–3 a un clic cada uno. Para (4), exportar a CSV y pivotar por hora del día.

Lo que no verás

Algunas técnicas de exfil reales producen cero señal USN útil:

• Subida directa desde memoria vía navegador o PowerShell — los datos nunca tocan disco, así que el journal no tiene nada.
• Lectura de un share de red — el origen es el sistema de archivos donde vive el share, a menudo no tuyo.
• Captura de pantalla como exfil — produce solo la creación de uno o dos archivos de imagen.
• Impresión — solo deja actividad en \Windows\System32\spool\PRINTERS\, que es su propio artefacto forense, no realmente un asunto USN.

Para una perspectiva de modelo de amenaza más completa, la página Exfiltration de MITRE ATT&CK lista cada técnica y dónde deja residuo. USN cubre directamente quizá un tercio; el resto necesita logs de eventos, capturas de red o historial del navegador.

Ejemplo trabajado

El tipo de CSV que exportarías de una intervención real para demostrar exfil:

Esa timeline es prueba aplastante. Sin el journal, habría que reconstruirla desde el registro, Prefetch y shadow copies — cinco veces más trabajo, la mitad de confianza.