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

Después del ransomware, la segunda pregunta más común de DFIR es alguna variante de "¿se ha ido algo de aquí?". El USN journal es uno de los lugares más baratos para empezar a responderla. Cada copia a USB, cada subida de cloud-sync y cada operación de drop-everything-in-a-temp-folder-then-zip deja una forma reconocible en $J — lo bastante reconocible para que con dos filtros y un pivote por ruta padre normalmente puedas triagear una ventana candidata de exfil en menos de veinte minutos.

Este post es el playbook para encontrar esos patrones, desglosado por canal de exfil.

Las unidades USB dejan el rastro más limpio

Cuando un usuario conecta un volumen extraíble, Windows le asigna una letra de unidad y, si el volumen es NTFS, el dispositivo recibe su propio $UsnJrnl. Los archivos copiados al USB aterrizan en el journal de destino como FileCreate | Close más un flujo de registros DataExtend | Close. Los archivos copiados desde el disco origen dejan un rastro más suave del lado origen: eventos open y close que a menudo producen BasicInfoChange | Close por el escaneo de AV y el caching del sistema de archivos que siguen a la lectura.

Lo que normalmente tienes en un engagement real:

• El journal del disco origen. Muestra lo que se abrió, cualquier archivo temp o archivado creado, y el sweep final de eliminación si el usuario limpió.
• Los hives del registro. SYSTEM\MountedDevices, SYSTEM\CurrentControlSet\Enum\USBSTOR, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 y setupapi.dev.log juntos identifican qué dispositivo físico se conectó y cuándo. Parséalos con el parser de registro.
• El journal del volumen destino, si tienes la imagen USB. Aquí es donde viven las escrituras de archivos reales.

La señal decisiva en el lado origen es el patrón archive-before-copy, porque la mayoría de usuarios con algo que ocultar recurren a 7-Zip o a la compresión integrada del Explorer antes de sacar la unidad por la puerta: un FileCreate de un .7z, .zip, .rar o archivo de nombre aleatorio en una ruta temp, seguido de registros sostenidos DataExtend | Close hasta que el archivo alcanza su tamaño final. La ruta suele ser \Users\<u>\AppData\Local\Temp\, \Users\<u>\Desktop\ o la raíz del perfil de usuario.

Para el lado de identificación USB, cruza los timestamps en el journal contra los eventos Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx de conexión/desconexión — el parser EVTX lo convierte en cosa de unos pocos clics. Empareja con archivos LNK bajo \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ y jump lists para evidencia explícita de usuario-abrió-desde-USB.

El patrón clásico de staging-luego-archivado

Mapea a T1074 Data Staged en MITRE ATT&CK y se ve así en disco:

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 de estos, el archivo crece
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (limpieza)

Tres señales en secuencia:

1. Una ráfaga de FileCreate en un único directorio de staging.
2. Un FileCreate posterior más DataExtend continuo sobre un único archivado, cuyo tamaño final aproxima la suma de los archivos apilados.
3. Un sweep de eliminación del directorio de staging poco después de que el archivado se cierre.

Cada señal por sí sola es ruidosa. Combinadas son diagnósticas. Filtra por FileCreate en \AppData\Local\Temp\, \Users\Public\, \Downloads\ y otras ubicaciones escribibles del árbol de usuario, luego clusteriza por directorio padre y busca >50 creates dentro de 60 segundos. Esa cadencia pilla staging de robo por insider y la mayoría de cargas de infostealer. Saca rutas de build conocidas (node_modules\, target\, Debug\, Release\, obj\, .next\, dist\) del filtro; producen ráfagas de forma idéntica y dominarán tus resultados si no.

Staging de cloud-sync

OneDrive, Dropbox, Google Drive y Box mantienen todos una carpeta de sync local y empujan todo dentro de ella en el momento en que el agente lo recoge. El journal expone dos patrones diagnósticos:

RenameNewName masivo hacia la carpeta de sync. El padre nuevo es \Users\<u>\OneDrive\, \Users\<u>\Dropbox\, \Users\<u>\Google Drive\ o \Users\<u>\Box\; el padre antiguo es Desktop\, Documents\ o Downloads\. La mitad rename preserva la referencia padre original del archivo, lo que significa que puedes probar la procedencia incluso después de que el archivo se haya ido.

DataExtend | Close sobre archivos dentro de la carpeta de sync sin un FileCreate correspondiente de app de usuario. Estas son las escrituras del propio agente — descargas del lado cloud a la copia local. Los creates son lo que quieres para la dirección de subida. Agentes de sync en segundo plano como OneDrive.exe y Dropbox.exe también escriben archivos de log en sus subdirectorios AppData\Local\, lo que te da otra forma de acotar la actividad si la evidencia de rename es escasa.

Menos común pero vale la pena saberlo: algunos operadores scriptean un Copy-Item hacia un junction o symlink que apunta a la carpeta cloud, lo que produce registros ReparsePointChange además del par rename.

BITS, herramientas de subida nativas y exfil living-off-the-land

Un patrón que he visto más a menudo en engagements de ransomware recientes: el operador usa bitsadmin.exe o Start-BitsTransfer de PowerShell para sacar archivos, a veces a almacenamiento cloud controlado por el atacante con certificados válidos. El journal muestra:

• FileCreate de archivos de estado de jobs BITS bajo \ProgramData\Microsoft\Network\Downloader\ (coincidiendo con qmgr.db, qmgr0.dat, qmgr1.dat).
• Para subidas, los archivos origen apilados en \Users\<u>\AppData\Local\Microsoft\BITS\ inmediatamente antes de la transferencia.

Empareja con los IDs de evento Microsoft-Windows-Bits-Client%4Operational.evtx 59 (job creado), 60 (job transferido) y 61 (job completo) — el puente EVTX para exfil BITS es una de las correlaciones más limpias disponibles.

Historia similar para rclone.exe y MEGAsync.exe. Producen firmas predecibles de file-create en sus directorios de app y archivos de log; mira \Users\<u>\AppData\Roaming\rclone\ para la configuración que lista el destino.

Heurísticas que se ganan su sitio

Tras suficientes engagements, las heurísticas que consistentemente marcan exfil real:

Ráfaga de creates. Más de N eventos FileCreate en un único directorio dentro de T segundos. Tunea a baseline; N=50, T=60 es el punto de partida para hosts de escritorio.

Archivado tras ráfaga. Un único FileCreate de un archivo con extensión .zip, .7z, .rar, .tar.gz, .tar.zst o .iso dentro de minutos de una ráfaga de creates, con DataExtend continuo acumulándose a varios MB. El tamaño del archivado coincide aproximadamente con el tamaño acumulado de los archivos apilados.

Rename masivo cruzando límites de directorio. Registros RenameNewName cuya ruta de padre nuevo es estructuralmente distinta de la vieja — Documents\ a OneDrive\, Desktop\ a Users\Public\, Downloads\ a \AppData\Local\Microsoft\BITS\. Fácil de expresar como regex sobre las rutas completas resueltas por MFT.

Ráfagas fuera de horario. Cualquiera de las anteriores fuera del horario laboral normal del usuario. Cruza con logons 4624 de Security.evtx para las fronteras reales de sesión.

Sweep de eliminación tras archivado. Un cluster FileDelete sobre el directorio de staging tras cerrarse el archivado. Esto es el usuario intentando limpiar. La forma del cluster — muchos archivos eliminados en segundos, todos compartiendo un padre — es inusual fuera de flujos dev/build.

El parser de esta página expone filtros de ventana de tiempo y por reason que hacen de la detección de ráfagas y el clustering de rename cosa de un clic cada uno. Para análisis fuera de horario, exporta a CSV y pivota en hora-del-día.

Lo que no verás en $UsnJrnl

Unas pocas técnicas reales de exfiltración no producen señal USN útil:

• Subida directa desde memoria vía un POST del navegador, Invoke-WebRequest -InFile desde una variable, o curl pipeando desde Get-Content. Nada aterriza en disco.
• Lectura desde un recurso compartido de red que el lado origen no posee. El journal en tu host no tiene nada porque el archivo no vivió allí.
• Captura de pantalla como exfil. Solo los archivos de screenshot aterrizan en disco; los datos reales salen vía la imagen renderizada.
• Imprimir. Solo deja actividad en \Windows\System32\spool\PRINTERS\, que es su propio artefacto forense.
• Tunelización DNS o ICMP. Nada toca disco; pivota a capturas de red y evento 3 de Sysmon.

Para estas, pivota a EVTX, conexiones de red Sysmon (evento 3), historial del navegador, SRUM para bytes de red por proceso, dumps de RAM o artefactos PRINTERS spool. La página de táctica de Exfiltración de MITRE ATT&CK lista cada técnica con notas sobre dónde deja residuo realmente.

Un ejemplo trabajado

El tipo de CSV que podrías exportar de un engagement real para demostrar exfil:

Esa timeline es una pistola humeante. Sin el journal la reconstruirías a partir del registro, Prefetch, shadow copies y los propios logs de OneDrive — cinco veces el trabajo, la mitad de la confianza.

Lecturas adicionales

• MITRE ATT&CK — la táctica de Exfiltración y T1074 Data Staged para la taxonomía completa.
• CISA, recursos de insider threat — las asunciones base y umbrales de detección en su playbook están cerca de lo que aguanta en un entorno corporativo real.
• The DFIR Report — múltiples intrusiones de formato largo documentan el patrón exfil-luego-cifrar paso a paso, con evidencia USN en la timeline. Lo más cercano a un corpus público de verdad sobre cómo se ven estos patrones en la práctica.