Of Corona, Buggy Audio Drivers and Industrial Espionage

The Situation

Last year, the CISO of a customer sent me a laptop for analysis. The reason was that he feared the company could have been victim of industrial espionage. Starting in spring 2020, the IT help desk got several employee laptops with full hard drives, caused by a huge amount of audio recordings. The audio files contained recordings even of highly sensitive telephone conferences. An automated scan on all employee computers for such audio recordings showed that about 300 devices were affected.

The Analysis

So I started analyzing the laptop. At first a dead analysis: I scanned the filesystem for known malware and dug into file creation/modification timelines, and so on. But I could not find any hint for any kind of malware or tampering on the system.

Afterwards, I started with a live analysis: I turned on the laptop, started procmon and other tools, located the audio recordings on the file system and waited for new recordings to show up. But nothing happened – until I opened the Windows audio settings dialog. Immediately, two new .wav files got created and grew in size, as long as I kept the audio settings dialog opened.

A closer look at the API calls logged by procmon showed this:

13:20:22 AUDIODG.EXE RegOpenKey    HKLM\SOFTWARE\Fortemedia                       SUCCESS
13:20:22 AUDIODG.EXE RegQueryValue HKLM\SOFTWARE\Fortemedia\DebugFunction         NAME NOT FOUND
13:20:22 AUDIODG.EXE RegCloseKey   HKLM\SOFTWARE\Fortemedia                       SUCCESS
13:20:22 AUDIODG.EXE WriteFile     C:\Windows\Temp\sam_mic_2020_7_27-13_20_22.wav SUCCESS

We see that the AUDIODG process, the Windows process responsible for audio drivers, accessed a non-existing registry value with name DebugFunction, just before creating a new .wav file.

I simply created a DWORD32-value DebugFunction with the data “0” and tried again: Now, opening the audio settings dialog did not result in a new audio recording. When I set the content to “1”, the audio settings dialog would cause a new recording again.

The Reason

The reason for this behavior seems to be an incorrect usage of the Windows API call RegQueryValue in the audio drive. If the registry value exists, the value gets written to a buffer and the function returns ERROR_SUCCESS; if the registry value does not exist, it returns ERROR_FILE_NOT_FOUND and leaves undefined data in the buffer. If a program does not check the return value of the API call for success or failure, the program works with this bogus data.

The audio driver used on this laptop obviously does not check the return value of the RegQueryValue call and therefore seems to default to a debug mode, which causes the audio driver to write recordings to disk as soon as some program accesses the microphone.

The Corona Effect

All this trouble with full hard drives was indirectly caused by the Corona pandemic. Until 2019 the customer never experienced this issue, although the audio driver was the same. However, starting in early spring of 2020, the customer sent the employees home. Work from home now was the new standard mode of operation and people needed to communicate. They did this using softphones on their laptops. Before Corona they worked on-site and used desk phones.

Summary

The customer was not target of advanced industrial espionage. Quite the contrary, it was a simple bug in the audio driver causing a lot of trouble. The changed user behavior during the Corona pandemic just made the buggy audio driver obvious.

Some details:

Affected audio driver: Realtek High Definition Audrio Driver 6.0.1.8045
Audio recording location: C:\Windows\Temp\sam_mic_<date>.wav and C:\Windows\Temp\sam_ref_<date>.wav
Workaround: Create the registry value HKLM\SOFTWARE\Fortemedia\DebugFunction as DWORD32 with content 0.
Fix: Update the driver.