1 or more little secrets of disksnapshot.exe

This native tool is not very well known, but it may be useful in some cases.

The tool seems to be parsing volumes directly, bypassing the Windows APIs — hence, it kinda works like a dir command, but parses the $MFT of volumes directly (but still via API).

The program accepts a number of command line arguments:

DiskSnapshot.exe [options]
        -c write detail data to console
        -i write detail data to console (same as -c)
        -s (deprecated) summary data to console
        -u process large volumes (no limit)
        -j [config] specifies an alternate config file
        -v [volume][path] specifies volume(+path) to process, e.g. "d:" or "d:\foo"
        -d [input-file] print encoded versions of the strings in the input file, for decoding purposes
        -e prints out escalation keywords
        -k calculate checksums for files, used to investigate duplicated on-disk content (c arg required).
        -o [output-file] write detail data to a file

It turns out that the ‘checksum’ is actually a SHA256 algorithm, so running:

disksnapshot -c -k -v c:\test

will list all the files in the c:\test directory, and will calculate the SHA256 of each file.

The other curious command line argument is -e. Running:

disksnapshot -e > escalation_keywords.txt

gives us this list of keywords (on Windows 11 25H2). It turns out that this list is based on the content of c:\WINDOWS\system32\DiskSnapshot.conf file.

There is an undocumented command line argument -z that kinda tries to collect telemetry, but it doesn’t really work. If the call to a function TelIsTelemetryTypeAllowed(2) returns 1 it just exits with a message:

Telemetry run: telemetry is disabled, exiting

Otherwise, it checks if the OS is a retail version (guessing by the function name that is called here), and if it is, it ‘rolls a dice’ and prints the below message:

    curtime = _time64(0);
    _o_srand(curtime);
    rand = ::rand();
    if ( rand != 7 * (rand / 7) )
    {
      v4 = o___acrt_iob_func_0(2u);
      fwprintf(v4, L"Telemetry run: failed the dice roll, exiting\n");
      return 0;
    }

There is a command line argument -j that we can use to change the default config file from c:\WINDOWS\system32\DiskSnapshot.conf file to our own, but I am not sure how to use it. The disksnapshot -j c:\test\test.conf -e command prints out the content of the custom config, but when I tried to apply it to the volume, it somehow didn’t work. I guess I just don’t fully understand the logic behind this tool.

Forensics of the past

Few days ago my buddy and I had a chat about so-called old-school forensics. The one where you often used Encase, and – if you were inclined enough – EnScript scripting.

This convo led me to my old Enscript code that I wrote over 15 years ago.

At that time I worked for a consulting firm that was specializing in analysis of carding-related breaches, and we often saw the very same Threat Actors attacking victims in a hospitality and catering sector all over the place. Thanks to my reverse engineering skills, I ended up doing a lot of malware analysis tasks for the whole team back then + since I was very interested in automation, I ended up developing a very basic and rudimentary triage Enscript script that one could just run immediately after they mounted an image in Encase.

Reviewing that code this week… the code I wrote so many years ago… made my jaw drop.

The stuff my script was looking at, and doing, back then… can be seen as a very early threat hunting exercise focused on a data from a single endpoint. An exercise where the artifacts were extracted in an automated fashion, bookmarked for review, and organized into a hierarchy that was supporting that quick&dirty review process:

The other routine was trying to bookmark a lot of important Registry entries associated with vital forensic information, so one could just walk through them and identify/extract information that could make it into a report + highlight a lot of other Registry entries that could help finding that anecdotal smoking gun (f.ex. many recent folders):

The code also includes a list of known malware/hacking file names, multiple persistence mechanisms, and a few other tricks…

I don’t think it ever became a ‘One click to solve the case’ type of solution, but it definitely helped me to structure and systematize my approach to case analysis…

And I guess… ‘what’s old, is new again’. Every once in a while.