Category Archives: Anti-Forensics

Too much % makes Event Viewer drunk

Posted on by

Update:

After I posted it Daniel Bohannon provided a link to his earlier research (March 2018) where he described the very same problem. He has some interesting examples so please have a look!

Old Post:

This is a short post about a funny side effect of using the % sign and how these are being interpreted by Windows Events Log Viewer.

When you use this character as a part of a file name, or as a Registry data the program will assume these % signs are referring to actual parameters and will resolve them into actual strings.

I know it doesn’t make any sense, so let’s do a test.

Name your program %1.exe. Run it. This is what the Viewer will show:

Now try to add this Registry value:

reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run /v Foo /t reg_sz /d test%1%2%3%4%5%6%7%8%9%10%100

The result? Very strange details:

What about naming the program %1%2%3.exe?

Look at the image and the command line. One is: C:\Test\2019-01-27 22:28:29.601{670b5bbc-308d-5c4e-0000-00105f407c03}.exe, and the other “C:\Test\Incorrect function.The system cannot find the file specified.The system cannot find the path specified..exe”.

Only the viewer is fooled, because the actual data is logged properly (although there is an inconsistency in the way %s are doubled in command line) — one just needs to go to Details tab and see what it really shows:

That’s it. Yet another quirky behavior to be aware of.

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