I read about the key logging of the driver at modzero, and that it's apparently making all my keystrokes available. How much am I exposed by this, and can I reduce my exposure?

  • And this is why I prefer using Windows' built-in drivers whenever possible, instead of third-party garbage that at best puts an unnecessary icon in the system tray (waste of resources) and at worst puts me at risk like here. Commented May 11, 2017 at 21:41
  • @AndréBorie Windows built-in drivers, and even the kernel, are neither more, nor less, vulnerable than third-party drivers. Check out CVE-2015-2454-(kernel-mode driver), CVE-2016-0133-(USB Mass Storage Class driver), and I lost count of the CVEs for theGraphics Device Interface in Windows. For example CVE-2016-3396. For some people, that unnecessary icon can be very important, while for other people, using a windowed GUI is wasted resources.
    – user135823
    Commented May 11, 2017 at 23:08

3 Answers 3


Risk: There is no additional "attack surface" created by this issue. In other words, provided an uninfected machine, you are no more vulnerable to attack. The real risk here is that if your machine is/was previously compromised, an attacker could more easily (than having to install their own keylogger) capture your keystrokes and possibly keystroke history (since last logon) via the log file. Many AV products would detect the installation of a keystroke logger, but since the signed driver already includes it, it could be overlooked (although that said I would expect any reputable security software provider to soon be listing affected drivers as dangerous anyway). The only other consideration as pointed out by Modzero, if you happen to be backing up the public user folder anywhere, backups could also include copies of the log file (again IMHO an unlikely real-world scenario).

Mitigation: We tested it and found that even if MicTray.log is 0 bytes (as is a common occurrence as reported on the internets and my observation), it can only be deleted/renamed if MicTray[64].exe is killed.

As we had about 40 machines affected, we created the following batch file to push out and mitigate the issue. It renames all files to include an underscore and therefore prevent them from being run normally. This allows reversal if required. The only casualty of this workaround is the lack of the relevant system tray and associated functionality (which IMHO is rarely used anyway).

taskkill /IM MicTray.exe
taskkill /IM MicTray64.exe
ren c:\users\public\MicTray.log MicTray.log_
ren c:\windows\system32\MicTray.exe MicTray.exe_
ren c:\windows\system32\MicTray64.exe MicTray64.exe_

The simplest way is to see if you can delete the file (delete it in safe mode if you can't) and then recreate it as a text file, and make it read only.

This will stop the process writing to the file, seemingly without any other issues.

As more information is discovered about this I'm sure there'll either be a updated driver without this flaw, or another better workaround but this is something you can implement immediately.

Please note, this flaw is only a problem if someone already has access to your system, obviously having all keystrokes logged is bad, but it still requires someone to read these keystrokes to gain any information and as far as we can tell so far, this file isn't shared anywhere other than on the local machine.


The keylogger is there and works even if the output is not put in the MicTray.log file. You can see the keyloger in action using DbgView program from SysInternals auite. In my case Windows 10 updated the driver and removed the MicTray.exe only to install another funny program called flow.exe that is trying to internet (to youtube.com?) I relly have no idea why a sound driver would need to connect to internet, other than illegally broadcast sound of what I type as a poor replacement for the keylogger that can't be there anymore.

You must log in to answer this question.