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

This is a short post to cover a ‘new feature’ of Windows 10 that some users complain about online.

When you use this ugly system for a while, and at some time need to restart it, you may notice that sometimes applications that are running prior to restart are re-launched after you log on.

A good example is Regedit. If you open it, restart the system, the application will be re-launched after the reboot.

How does the Windows 10 know which processes to re-launch after the reboot?

Prior to restart the system populates the RunOnce key adding a list of items in a form of:

• HKCU\SOFTWARE\Microsoft\
  Windows\CurrentVersion\
  RunOnce\Application Restart #N
  =<Application Path>

where N is a number (the code is inside the winsrvext.dll).

So, if you come across entries like this, at least we can guess where they come from.

Now, how does the OS actually know which programs to restart?

If you ever used OSX you may be familiar with the a cool feature of re-opening currently opened applications after the reboot. Could that be that Windows 10 is following this path? Turns out that the truth is far more boring. This is actually not a Mac OSX-like feature at all. The OS simply grabs a list of programs that called the RegisterApplicationRestart API during their run-time, and only these will be added to the RunOnce key.

Last, but not least, I have no idea why Regedit calls this API at all…

btw. I am getting old, I covered it in the past here, although in a different context.