Esta entrada va a ser un repaso del funcionamiento del LastAccessUpdate de los archivos a cuenta de que me lo he encontrado al revisar un registro. El valor en concreto es el que establece si debe actualizarse el atributo Last Access Time del sistema de archivos.
La descripción de la clave y valor del registro la he encontrado en:
http://msdn.microsoft.com/en-us/library/ee377058%28v=bts.10%29.aspx

NTFSDisableLastAccessUpdate

Key:	HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
Value:	NTFSDisableLastAccessUpdate
Data Type:	REG_DWORD
Range:	0 – 1
Default value:	0
Recommended value:	1
Value exists by default?	No, needs to be added.

Me parece muy importante destacar que el valor por defecto es 0 en XP pero 1 en Vista/7.

Parece que este valor ha generado mucha discusión en los foros ya que se afirma en muchos de ellos que el S.O. no actualiza el valor de LastAccessUpdate como debiera.

Creo que la confusión puede deberse en muchos casos al hecho de que ese valor no se actualiza de forma instantanea siempre que se accede a un archivo o directorio: la actualización depende de si el acceso es de solo lectura o no. Si es éste el caso no se actualiza de forma inmediata precisamente para evitar que todas las operaciones se conviertan en accesos de escritura, degradando el rendimiento del sistema.

Donde sí se actualiza es en memoria y se vuelca ese valor si se modifica otro atributo del archivo o si desaparece la referencia de la memoria. El retraso máximo que el sistema acepta para actualizar el valor es de una hora por lo que si leemos un archivo a las 14:00 y de nuevo a las 14:50 el sistema no lo actualiza. Si volvemos a leerlo a las 15:01 sí se actualiza el valor en disco para reflejar las 15:01.

El otro lugar donde se almacena el  LastAccessUpdate de un archivo es en el índice del directorio. En este caso el sistema solo actualiza el valor cuando detecta que la diferencia entre el valor en el índice y el almacenado en memoria difieren en más de una hora, lo que ocurre cuando se elimina la referencia al mismo. También cuando se modifica otro de los atributos del archivo se actualiza el LastAccessUpdate con el valor que estaba en memoria. (Fuente: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_behavior.mspx?mfr=true)

Como digo puede que se deba a esto pero no lo he comprobado personalmente.

Un ejemplo de malware que modifica este valor:
W32/Virut.n.gen!D4F31486AF8E
(http://www.mcafee.com/threat-intelligence/malware/default.aspx?id=317086)

NTFS $MFT slack

Hal Pomeranz ha publicado en SANS Computer Forensics un artículo muy interesante sobre la posibilidad de recuperar datos del slack de las entradas de la MFT.
Se trata de la información que queda residente en la entrada de la MFT en el atributo $DATA cuando ésta pasa de ser residente a no residente.
Para la comprobación se sugiere en el artículo probar con una extensión de datos del archivo inferior a 700 bytes de forma que sea residente y posteriormente ampliar su tamaño para comprobar los datos residuales que quedan en la entrada de la MFT.
Referencia: Resident $DATA Residue in NTFS MFT Entries

NTFS INDX Buffers

Acaban de publicar en el blog de Mandiant la cuarta entrega dedicada a los NTFS Index Buffers:
The Internal Structures of an INDX Attribute.

Se trata de una descripción de la estructura y comportamiento de los B+Tree que ayuda a entender este concepto. Es un buen complemento para entender el follón de ese tipo de estructura que se añade a las lecturas:

• El libro de Brian Carrier: File System Forensic Analysis
• La herramienta INDXparse de Willi Ballenthin: INDXparse.
• Del blog de SANS Computer Forensics el artículo de Chad Tilbury: NTFS $I30 Index Attributes: Evidence of Deleted and Overwritten Files
• La herramienta wisp de TZWorks.