11 November 2014

DJ Forensics: Analysis of Sound Mixer Artifacts

In many forensics examinations, including those of civil and criminal nature, there is an art to finding remnants of previously installed applications. Fearing detection, or assuming that an examination is forthcoming, many suspects attempt to remove unauthorized or suspicious applications from a system. Such attempts are usually unsuccessful and result only in additional hours of processing for forensics. But even with a clean uninstall there are traces left within the Windows registry that note such a program was installed.

The most popular of these is the Windows Shim Cache (a/k/a Application Compatibility Database, a/k/a AppCompatCache), a resource that can be used to catalog applications not natively compiled for newer Windows. It's also a resource that works great for finding APT-related malware running on a system, but not so much legitimate applications.

For a few months I've been playing with another repository of applications: the Windows Sound Mixer. Whenever an application requests the use of the Windows audio drivers, Windows will automatically register this application in the registry. This information is stored so that Windows can create per-application sound settings:

This was a resource I dismissed for a year. It existed only in Windows Vista and newer, it didn't catch any of the malware I threw at it, and wasn't relevant to any of the Incident Response work I do**. Its importance came to me when working some cases that came mixed in with many of my intrusion cases where I had to examine the systems owned by various hackers. One in particular involved tracking the use of alternative web browsers and discovering that the Sound Mixer had catalogued the use, and location, of Tor Browser launched from a TrueCrypt volume. Clear as day, the path even noted that it was a TrueCrypt volume based upon the Windows device name:


I learned that the registry keys were useful for such cases, but there has been no prior public discussion of the forensic use of this data.

** After some testing ideas from Michael Zeberlein, I determined that many RATs with audio capturing abilities do get flagged by the Sound Mixer. However, many only do so when the adversary actively engages that feature. This was tested with SpyGate and DarkComet.

Windows collects this data in the user's NTUSER.DAT registry hive as:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\LowRegistry\Audio\PolicyConfig\PropertyStore

From this key are a series of sub-keys, one for each individual application stored. What we are really concerned about is the "(Default)" (REG_SZ) value stored for each sub-key. An example of this value is:

{}.{e64c029e-480d-424c-a775-2fd663e1442f}|\Device\HarddiskVolume2\Program Files\VideoLAN\VLC\vlc.exe%b{00000000-0000-0000-0000-000000000000}

This value stores the path of the program, the sound device registered, and other assorted data:

  • {}.{e64c029e-480d-424c-a775-2fd663e1442f}
  • \Device\HarddiskVolume2\Program Files\VideoLAN\VLC\vlc.exe
  • %b
  • {00000000-0000-0000-0000-000000000000}

The first value corresponds to the output audio device for which the application can access. The second is the path to the application, followed by an unknown delimiter and finally a GUID referencing any audio input devices (microphones) used by the application.

Referencing Output Devices

For the vast majority of applications, the GUID for the output device will be for the generic "Speakers" device. These values can be correlated to multiple places in the registry. The easiest way would be to search the user's output devices in HKEY_CURRENT_USER\Software\Microsoft\Speech\AudioOutput\TokenEnums\MMAudioOut, however these values only contain values for current hardware, and those that the user has access to.

Instead, we reference the system list of rendering devices stored at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render. Each sub-key under this key is a GUID that corresponds to the devices we see noted in the Sound Mixer list. For each GUID there is a sub-key named Properties with a constant value of "{a45c254e-df1c-4efd-8020-67d146a850e0},2" (PKEY_AudioEndPoint_Interface) that contains the device name.

This is a very long-about way of saying to retrieve the value from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\<GUID>\FxProperties\{a45c254e-df1c-4efd-8020-67d146a850e0},2 to get the device name. For example:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\{e64c029e-480d-424c-a775-2fd663e1442f}\Properties\{a45c254e-df1c-4efd-8020-67d146a850e0},2 = Speakers

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\{bfb5623f-3f3c-4245-803f-d4bae95d0016}\Properties\{a45c254e-df1c-4efd-8020-67d146a850e0},2 = H243H  (A monitor with speakers)

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\{799503ed-68e3-4293-9905-8a6bc8823094}\Properties{a45c254e-df1c-4efd-8020-67d146a850e0},2 = E320i-A0   (A TV that was previously hooked up)

Again, there are forensic implications that can be determined from this. At one point there was an E320i-A0 TV hooked up. I can grab the modification times from the registry keys to determine an approximate time range for that (new applications stored after the device was installed) and also to determine when the device was removed (new applications stored later that don't reference it). This information can show the portability of the system, such as when a laptop is connected to a docking station.

Referencing Input Devices

Obtaining the input device is performed the same way as retrieving the output device. Instead of a Render device, we'll obtain the Capture device. However, for my test systems, there were two sets of Microphone and Line-In devices, but some of the Sound Mixer applications contained input GUIDs that weren't found in the registry. Further analysis showed that all of these applications were created on the same day, when I had reinstalled Windows on a new system, suggesting that they were related to GUIDs from my old hardware.

These sub-keys contain the same structure as the output devices and can be parsed the same way.

The majority of retrieved applications will have an input GUID of '{00000000-0000-0000-0000-000000000000}' to note that the application did not have any input devices associated with it.

Bringing It All Together

Based on this data, we can extract the application list, obtain the last modified time for each key, and correlate the audio device to get a listing like this:

Date,Output Device,Volume,Input Device,Application
2013-09-04,21:03:32,Speakers,N/A,N/A,\Device\HarddiskVolume2\Program Files (x86)\Fiddler2\Fiddler.exe
2013-09-06,19:54:48,Speakers,N/A,N/A,\Device\HarddiskVolume2\Program Files (x86)\Hopper Disassembler\Hopper.exe
2013-09-18,21:22:27,Speakers,128,N/A,\Device\HarddiskVolume2\Program Files (x86)\Steam\SteamApps\common\Gunpoint\Gunpoint.exe
2013-11-23,23:24:57,Speakers,128,N/A,\Device\HarddiskVolume2\Program Files (x86)\Vuze\Azureus.exe
2013-12-27,20:41:55,Speakers,128,N/A,\Device\HarddiskVolume2\Program Files (x86)\Folder Size\FolderSize.exe
2014-01-21,21:42:24,Speakers,128,N/A,\Device\HarddiskVolume2\Program Files\Oracle\VirtualBox\VirtualBox.exe
2014-01-21,23:34:42,Speakers,N/A,N/A,\Device\HarddiskVolume2\Program Files (x86)\sqlitebrowser_200_b1_win\SQLite Database Browser 2.0 b1.exe
2014-01-25,19:57:25,Speakers,128,N/A,\Device\HarddiskVolume2\Program Files (x86)\Course Vector\minerva\minerva.exe
2014-02-17,02:43:10,Speakers,40,N/A,\Device\HarddiskVolume2\Users\Brian\Desktop\Tor Browser\Browser\firefox.exe

Returning back to the application data, the rest of the information holds minor value to us. The vast majority of applications will also store the volume information as a sub-key, although some will not. This volume information is stored in a static GUID sub-key of "{219ED5A0-9CBF-4F3A-B927-37C9E5C5F14F}" in a value named "3".

The value of "3" (REG_BINARY) contains a large set of binary data, but only one single byte refers to the audio setting, highlighted in yellow below.

04 00 00 00 00 00 00 00 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00

This value ranges from 0-255, with the default 0x80 referring to the median volume of 128. There is additional significance that can be read into this value, especially if a subject chooses to keep certain applications at a very low volume.


  • There is no apparent correlation between the application sub-key name and any other data in the registry. This key name may be randomly generated.
  • The GUID sub-key under each application is "{219ED5A0-9CBF-4F3A-B927-37C9E5C5F14F}". There is no documentation on this GUID except that it is unique to this family of data.
  • The application registry values of "4" and "5" all contain unknown binary data that were identical in all applications on the test systems. The usage of these keys is unknown.
  • Every system will have at least one application named "#" that will always have an input device. The purpose of this application is unknown.

Scripts for Analysis:

I've written two scripts to acquire this information. One uses the Python _winreg library to acquire the information from the active, live system. The other uses the Python-Registry library to acquire the information from a set of registry files.

Both scripts are located on GitHub for download.  Note that because the application subkeys appear randomly generated, the output from each should be piped to `sort` to see the applications in chronological order.

Example usage:

E:\Development\SoundMixer>SoundMixer_Hive.py -s reg\SOFTWARE -n reg\NTUSER.DAT
2014-05-28,02:31:00,Speakers,N/A,N/A,\Device\HarddiskVolume1\Program Files (x86)\Google\Chrome\Application\chrome.exe
2014-11-07,15:46:18,Speakers,128,N/A,\Device\HarddiskVolume1\Program Files (x86)\VideoLAN\VLC\vlc.exe

Harlan Carvey has also updated his RegRipper application with new plugins based upon this information, so you can immediately test the data in your analysis process.


  1. Brian,

    Thanks for sharing this! Great stuff. It's this kind of sharing that allows for further research and validation.

  2. Thanks Harlan, and thank you for the plugins. I've updated the post to reflect this. More people will definitely be able to test this out and see if it helps them in their examinations now.

  3. Very cool read! Also something I would have never learned about otherwise. I'm definitely going to start checking this blog regularly.

  4. very nice post