Beyond good ol’ Run key, Part 95

December 2, 2018 in Anti-Forensics, Autostart (Persistence)

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).

Share this :)

Comments are closed.