Category Archives: Autostart (Persistence)

Beyond good ol’ Run key, Part 96

Posted on by

Today, while browsing through the Registry, I came across this strange set of garbled Registry keys:

  • HKCU\Software\Microsoft\Payment\PaymentApps

Not sure what they are, but when I grepped win10 for DLLs that referenced the parent key name I found the DLL called SEMgrSvc.dll.

The internal name of the DLL is ‘NFC SEManagement Service DLL’. A quick google followed and I found this post. It refers to the `Payments and NFC/SE Manager` service.

Browsing through the code of the DLL I spotted a possible persistence opportunity. I can’t test it as I really don’t know under what circumstances it is being used, but documenting in case someone wants to poke around, or one day it is actually being used:

  • HKLM\Software\Microsoft\SEMgr\Wallet\DllName=<file>

The <file> is loaded via LoadLibraryW when Wallet instance is created, and then the API GetMockWalletCOMInstance exported by the wallet DLL is executed.

If you know how it is being used, please let me know. Thanks.

Beyond good ol’ Run key, Part 95

Posted on by

I recently read ESET research paper on Turla [PDF warning].

While reading it, I came across a description of Turla’s legacy persistence mechanism that requires a presence of The Bat! program on the infected system. While Eset’s paper claims Turla no longer uses this trick, I thought it would be a good idea to include the description of it in this series. Plus I added one more trick as a bonus.

For these who don’t know, The Bat! is a very popular email client. It is actively developed and there are still many users that could be targeted by malware abusing this program’s plug-in framework.

As per the ESET document:

To register as a plugin for The Bat!, the malware was modifying the file %appdata%\The Bat!\Mail\
TBPlugin.INI. This is the legitimate method to register a plugin for The Bat! and some plugins such
as anti-spam plugins also rely on it.

The structure of the TBPlugin.INI is pretty straightforward – it’s a standard Windows .ini file:

...
[Plugins]
Count=<number>
Plugin #1=<file name>
Plugin #2=<file name>
...

The .ini file may include other sections e.g. [Plugin Data], and [AntiSpam].

The default file extension for plugins is .tbp.

The Plug-in is a standard DLL module; to work properly, it needs to export some, or all the APIs listed below:

  • TBP_Initialize
  • TBP_Finalize
  • TBP_GetName – MUST be exported/present for a plug-in to work
  • TBP_GetVersion
  • TBP_GetStatus – MUST be exported/present for a plug-in to work
  • TBP_GetInfo
  • TBP_NeedConfig
  • TBP_Setup
  • TBP_SetConfigData
  • TBP_GetConfigData
  • TBP_NeedCOM
  • TBP_GetSpamScore
  • TBP_FeedSpam
  • TBP_GetMacroList
  • TBP_ExecMacro
  • TBP_SetLibEntryPoints
  • TBP_NeedResave
  • TBP_SetCoreBridge

More information on how to write The Bat! plug-ins (including sample plug-ins) can be found here.

In my tests I managed to execute a test DLL without any of the required APIs exported by my library. When I tried to add my plug-in manually, the program did load the DLL and executed its DllMain routine, but complained about it not being a properly working plug-in:

This is expected behavior. Most of the plug-in frameworks relying on DLLs load them by using a call to a LoadLibrary* API (calls DllMain), and then a sequence of GetProcAddress calls to retrieve plug-in interface pointers (exported APIs).

Such ‘corrupted’ plug-in DLL won’t survive manual configuration changes and updates to the TBPlugin.INI made by the program’s Preferences dialog box, plus will immediately catch attention of the user.

BUT

It still works. It’s a great lolbin opportunity.

Looking at the documentation for developers, as well as checking the Preferences of the program, I noticed that apart from ‘standard’ plug-ins, The Bat! supports another kind of plug-ins: ones that support antivirus function to scan files processed by this e-mail client.

The web site I linked to earlier provides an example of a ClamAV plug-in (the F-Prot plug-in link is broken).

One can add the AV plugin via the Preferences dialog box:

…or by manipulating the content of %appdata%\The Bat!\Mail\AVConfig.INI file directly. This .ini file is ‘dedicated’ to host configuration of the antivirus plugins. Its content looks like this:

...

[Checkers]
Count=<number>
Checker #1=<name>.<path>
Checker #2=<name>.<path>
...

The antivirus plug-ins use a file extension .bav, and need to export some, of all the following APIs:

  • BAV_Initialize
  • BAV_Uninitialize
  • BAV_ComNeeded
  • BAV_GetName
  • BAV_GetVersion
  • BAV_ConfigNeeded
  • BAV_Setup
  • BAV_SetCfgData
  • BAV_GetCfgData
  • BAV_GetStatus – MUST be exported/present for a plug-in to work
  • BAV_MemoryChecking
  • BAV_FileChecking
  • BAV_StreamChecking – MUST be exported/present for a plug-in to work
  • BAV_CheckFile
  • BAV_CureFile
  • BAV_CheckMemory
  • BAV_CureMemory
  • BAV_CheckStream
  • BAV_CureStream
  • BAV_CheckStreamEx – MUST be exported/present for a plug-in to work
  • BAV_CureStreamEx – MUST be exported/present for a plug-in to work

The takeaway is that we have a few more forensic artifact to look at if The Bat! is, or was installed on the analyzed system(s):

  • %appdata%\The Bat!\Mail\TBPlugin.INI file
  • %appdata%\The Bat!\Mail\AVConfig.INI file
  • *.tbp files
  • *.bav files

Why should we look at the .tbp and .bav files as well? A clever attacker could patch existing plug-ins (in a viral way).