$LogFile: recuperar evidencias de archivos borrados

TL;DR. En $LogFile, un borrado suele verse como un DeleteIndexEntry* (el nombre desaparece de la carpeta padre) seguido de un DeallocateFileRecordSegment (se libera el registro FILE). Esos registros —más la creación del archivo, si sigue en el diario— te dan el nombre, la carpeta padre, la entrada de la MFT y el número de secuencia, las marcas de tiempo de $FILE_NAME y los tamaños, a menudo los últimos valores de $STANDARD_INFORMATION, a veces los data runs y, en archivos diminutos, el contenido. El diario no te da la hora del borrado; lo máximo que obtienes es «en ese momento o después de la última marca de tiempo conocida». Los archivos enviados a la Papelera de reciclaje son renombrados, no borrados.

Los archivos efímeros son los favoritos del atacante: descargar, descomprimir, ejecutar, borrar. Cuando llegas a adquirir el disco, el registro FILE ya se ha reutilizado, el slack de $I30 se ha sobrescrito y el diario USN dice FILE_DELETE con un nombre y nada más. $LogFile todavía puede conservar la estructura del archivo tal como NTFS la vio por última vez, durante los últimos minutos u horas.

Qué escribe un borrado en el diario

Paso	Operación	Qué contienen los bytes
El nombre se elimina de la carpeta	`DeleteIndexEntryRoot` o `DeleteIndexEntryAllocation`	La entrada de índice eliminada: referencia del archivo (entrada + secuencia) y un `$FILE_NAME` embebido con la referencia del padre, el nombre, las cuatro marcas de tiempo, el tamaño asignado y real, y los flags
Se libera el registro FILE	`DeallocateFileRecordSegment`	Entrada afectada; la parte undo permite a NTFS restaurar el registro
Se borra el bit del bitmap de la MFT	`ClearBitsInNonresidentBitMap`	Qué entrada de la MFT quedó libre
Se liberan los clústeres	`ClearBitsInNonresidentBitMap` sobre `$Bitmap`	Qué clústeres quedaron libres (archivos no residentes)

Cuál de las dos partes, redo o undo, contiene la entrada de índice eliminada es uno de los detalles que cada analizador resuelve a su manera; el analizador en el navegador prueba ambas. Las operaciones en sí se tratan en las operaciones redo/undo del $LogFile de NTFS.

Qué puedes reconstruir

Nombre y ubicación. A partir de la entrada de índice, aunque la creación ya no esté en el diario. El padre es una referencia MFT; resuélvela con el $MFT del mismo volumen o verás [MFT #n] para las carpetas desconocidas.

Identidad. Entrada de la MFT y número de secuencia. Cuando una entrada se reutiliza, NTFS incrementa su número de secuencia (como señala el readme de LogFileParser a propósito de su historial de nombres), así que entrada + secuencia distingue el archivo borrado de lo que ocupe hoy esa entrada.

Marcas de tiempo. Las de $FILE_NAME de la entrada de índice y, si el diario aún conserva registros anteriores de esa entrada, los últimos valores de $STANDARD_INFORMATION. Ninguna de ellas es la hora del borrado.

Tamaños. Tamaño asignado y real del $FILE_NAME de la entrada de índice. Tómalos con cautela: los tamaños de $FILE_NAME en las entradas de directorio no siempre están actualizados.

Data runs. Si la creación del archivo (InitializeFileRecordSegment, CreateAttribute) y los UpdateMappingPairs posteriores siguen en el diario, se pueden reconstruir sus runs de clústeres. LogFileParser lo implementa y documenta la recuperación de archivos borrados fragmentados cuyo registro FILE se había sobrescrito, siempre que los clústeres no se hayan reutilizado.

Contenido (solo archivos pequeños). Un archivo lo bastante pequeño para ser residente guarda su contenido dentro del registro FILE. Si la imagen del registro o el CreateAttribute de su $DATA sobreviven en el diario, el contenido también. Es cuestión de suerte: el autor de LogFileParser señala que en Windows moderno los cambios posteriores en datos residentes suelen registrar solo que hubo un cambio, no los bytes nuevos.

Hora del borrado: qué puedes afirmar y qué no

Los registros del diario no llevan reloj. Para un borrado, la mejor cota que da el diario por sí solo es «en el momento de la marca de tiempo más reciente conocida para ese archivo, o después», normalmente su último valor de modificación/cambio de $SI. El analizador en el navegador etiqueta esos eventos como «última hora conocida — borrado en ese momento o después».

Para obtener una hora real, correlaciona con:

el registro FILE_DELETE del diario USN para la misma referencia de archivo (analizador del diario USN);
un evento cercano del diario que sí lleve hora (ordenando por LSN);
eventos de Security o Sysmon sobre la actividad de procesos en ese intervalo (analizador EVTX).

Papelera de reciclaje: un movimiento, no un borrado

Borrar desde el Explorador sin Mayús mueve el archivo a $Recycle.Bin\<SID>\ con un nombre $R… y crea el archivo $I… correspondiente con la ruta original y la hora del borrado. En $LogFile esto aparece como un renombrado/movimiento hacia $Recycle.Bin más la creación del archivo $I, no como una liberación. La liberación real solo llega al vaciar la papelera. El archivo $I es pequeño y residente, así que su contenido también puede aparecer en el diario; analízalo como corresponde con el analizador de la Papelera de reciclaje.

Ejemplo práctico (muestra sintética)

En la muestra del analizador (sintética, equipo ficticio FIN-WKS-07):

LSN	Evento	Detalle
117494	Creación	`\Users\svc_backup\Desktop\creds.txt`, creación `$FN` 10:38:10.5119430
117577	Datos residentes escritos	Primeros bytes del archivo (una nota de credenciales falsa marcada SYNTHETIC)
117610	Cambio de `$SI`	Modificación / cambio / acceso → 10:38:27.7024018
117804	Borrado	Misma entrada; hora «última conocida — borrado en ese momento o después» 10:38:27.7024018

Entre la creación y el borrado, el diario muestra además un .lnk creado en Recent, una pista para el analizador LNK. En un caso real buscarías ahora el registro USN FILE_DELETE para fechar el borrado, y el contenido en cualquier otra copia (copias de seguridad, sincronización en la nube, memoria: analizador de RAM).

La misma muestra incluye también un borrado inocente: \Windows\Temp\~DF3A1B7C2E.TMP, creado y borrado en menos de un minuto. Los archivos temporales se crean y destruyen constantemente; la marca de borrado es una ayuda para el triaje, no un hallazgo.

Dónde falla

Retención. Un borrado de ayer en un volumen de sistema casi seguro que ya no está. Consulta hasta dónde llega el $LogFile.
Agrupación. Un borrado cuya creación quedó fuera del diario aporta menos datos; un analizador que agrupa por proximidad (como hace ahora el analizador en el navegador) puede asociar registros vecinos por error. Revisa los registros en bruto.
Entradas reutilizadas. Resolver rutas con un $MFT obtenido más tarde puede dar el nombre del nuevo ocupante de una entrada o de su padre. Compara los números de secuencia; el analizador en el navegador todavía no los comprueba al resolver rutas desde el $MFT.
Validación. El analizador en el navegador solo se ha validado con diarios sintéticos; confirma los borrados relevantes con LogFileParser o NTFS Log Tracker (comparativa).

Preguntas frecuentes

¿Puede el $LogFile mostrar archivos borrados?

Sí, si el borrado es lo bastante reciente como para seguir en el diario circular. La eliminación de la entrada de índice y la liberación del registro FILE contienen el nombre del archivo, la carpeta padre, la entrada de la MFT y el número de secuencia, las marcas de tiempo de $FILE_NAME y los tamaños.

¿Puedo recuperar el contenido de un archivo borrado desde el $LogFile?

Rara vez, y solo en archivos residentes pequeños cuyo contenido aparece en una imagen de registro FILE o en una creación de atributo que siga en el diario. En archivos más grandes, el diario puede conservar data runs que apuntan a clústeres, lo que ayuda al carving si esos clústeres no se reutilizaron.