I stumbled upon this persistence mechanism by chance and its nature is similar to the many I have covered before – the preset applications that are executed when a certain event happens. This time I was checking the Bluetooth Stack applications on a laptop and discovered it could be easily configured to run arbitrary programs. We can assume that many other similar Bluetooth configuration utilities developed by other companies offer similar capabilities.

I don’t know how many people use Bluetooth on their PC laptops nowadays, but as long as the Bluetooth stack is installed, radio is enabled and applications are installed – the specific events should trigger the execution of preset applications…

There are at least two places I found where one could add persistent malware to the Bluetooth configuration settings.

The first one is under the SMART tab in General Options:

Despite efforts I didn’t manage to trigger it, but I don’t have many Bluetooth devices at hand. Perhaps someone will be able to run a QC on this one.

The setting is located inside the Registry under the following location:

• HKCU\Software\Toshiba\BluetoothStack\
  V1.0\Mng\IasStartAplPath= EXE Path

The second, is not just one, but it’s actually a group of individual settings assigned to each connection – here is an example of properties of such one connection where I added the c:\windows\system32\notepad.exe to execute anytime the connection is established:

This one works for sure and it was easy to test it.

The location of these settings is as follows:

• HKCU\Software\Toshiba\BluetoothStack\
  V1.0\EZC\DATA\1001\SCORIGINAL
  APPEXECUTE=hex:01
  APPFILEPATHBYTECNT=dword:<Path Length in bytes>
  APPFILEPATH=hex:<Path expressed as a sequence of hexadecimal numbers>
  APPFILEPATH2=EXE Path represented as a string
  PSM=dword:0000000f
  SECURITY=dword:00000001

The key DATA\1001\SCORIGINAL changes to DATA\1002\SCORIGINAL for the second connection and increases for subsequent connections. This is how it looks like inside the Registry:

It’s pretty simple, but it’s also not very convincing – I don’t think we should expect a flood of malware using it. Still, worth documenting.

The best persistence mechanisms are these that are well documented. They work perfectly and are often compatible with many versions of Windows. Here’s a story of one.

According to Microsoft’s page, the OffloadModExpo function offloads modular exponentiation from a CSP to a hardware accelerator.

We don’t really care too much what it means other than it has something to do with the crypto**, and that the function is exported by a plug-in-like DLL that is loaded from the path specified in the following location:

HKLM\Software\Microsoft\Cryptography\
Offload\ExpoOffload = DLL Path

Yup. It’s that simple.

Add the key, add the DLL. It doesn’t even need to export the OffloadModExpo function.

The only question remaining is when.

The answer is – pretty much all the time.

The library is loaded by either dssenh.dll, or rsaenh.dll and these libraries provide crypto services to pretty much any possible software running on Windows. At some stage it’s loaded by svchost.exe, iexplore.exe (f.ex. when you visit https:// page), mscorsvw.exe, taskhostw.exe, sdiagnhost.exe and other processes.

Here’s an example log from promcon immediately after I added the .reg file that installs a rogue DLL (soon after more processes pick it up):

and the debug view log confirming the loading:

**Bonus:

Last, but not least – the very same thing was described in 2000 as a vulnerability; apparently the DLL will receive all the private keys used by the Crypto API 🙂