Extracting data from disk images with a damaged file system

He may not, as unvalued persons do, Carve for himself (W. Shakespeare)

When investigating an infrastructure that has been subjected to encryption, there is regularly a need to extract data from disk images where the file system is significantly damaged.

In such cases, it is far from always possible to extract MFT data, OS logs, or user artifacts in a state suitable for processing by classical tools. This gives rise to the need to employ carving — the recovery or reconstruction of damaged files. In a number of cases, available commercial tools that implement this technique produce decent results, but on the whole they have a fairly limited scope of application.

In the case of carving Windows OS event log events, the “forget about BinXML” technique has proven itself well: full decoding of the content of the fields of a single event requires templates stored in the chunk header, which for understandable reasons may simply be absent. Without even attempting to search for such templates, it is possible to compose a textual description of a single event in which dates stored in standard locations, event codes, and several other service fields are unambiguously identified, as well as byte sequences containing data for substitution into templates, decoded “as text” (with service BinXML sequences stripped out).

As a result, this technique makes it possible to obtain substantially more data than when attempting to recover EVTX chunks: having the date, the EventID event code, and the log type stored as text, one can understand what is being referred to (screenshot 1).

A similar approach can also be applied to “live” systems where attackers have attempted to delete data in order to conceal traces of their movements.

🔎 To search for residual data of the MFT table, in addition to recovering individual records of the standard format, in a number of cases the technique of searching for individual attributes works well: as a rule, attributes of type 0x30, that is, $FILE_NAME, are of value, containing four timestamps, the file name, and its size (screenshot 2). In certain cases, such individual attributes even for a “live” system make it possible to discover, for example, in the paging file (pagefile.sys), traces of the presence of malicious files that are absent from other artifacts. Such results can also be obtained by searching for USN records containing one timestamp and the name of a file with which some FS operations were performed (screenshot 3).

💽 To search for executable files in a disk image, the tactic of searching for the PE header with subsequent estimation of the file size from the combined size of the sections works well. With a slight complication of the algorithm, it is possible to implement a more precise approach: determining the entropy of the final fragments of the file with a successive reduction of the fragment size until an empirically determined threshold value is crossed “from the bottom up,” while observing padding, in a number of cases makes it possible to obtain executable files that match by hash. However, even “roughly hewn” executable files of malware or their fragments are perfectly detected using YARA rules (screenshots 4, 5).

📁 To recover registry files, it is possible to use a search by header with determination of the file size from the HiveBinsDataSize field: this approximation in a number of cases makes it possible to obtain a set of files suitable for processing by classical tools. A characteristic feature in this case is the presence in the header of the modification date and the file type (primary/log), as well as the file name in UTF-16 with a size of 64 bytes. Despite the fact that for some files potentially interesting from a forensics standpoint (UsrClass.dat), the path structure does not allow determining the original location of the file with sufficient accuracy, in most cases the available information is quite sufficient.

Finally, the technique of searching a disk image for readable text fragments associated with identified attacker tooling has proven itself excellently: in a number of cases it makes it possible to recover command lines and logs of the tools used, including passwords, account names, and similar “pleasant little things” (screenshot 6).

#yara #dfir #ir #windows
@ptescalator