Beyond good ol’ Run key, Part 97

Posted on by

When I explore new persistence mechanisms, I usually try to focus on a native OS functionality. The main reason for such approach is the omnipresence of these mechanisms – they can be used on most versions of the Windows OS no matter what other software is present.

Every once in a while I do look at other persistence ‘vectors’ tho. Ones that focus on popular applications e.g. Office, Total Commander, popular archivers, email or torrent clients. They are so prevalent that they form a separate ‘cloud’ of apps that can be abused for persistence simply because they are so popular.

Today’s subject is a software that is very unusual – the burning software. 15 years ago everyone was using it. Today it’s really a bit of a remnant of the good old times. I have not burnt a single CD/DVD since 2009-2010. I really can’t recall any instance where I would do so within last 8 years. The cloud, the USB 3.0, and capacity of external drives pretty much rendered media burning obsolete.

Except, according to my quick Twitter quiz question many still use it.

Nero was and still is one of the best media burning applications. While I won’t cover its features in detail I do want to acknowledge its role in shaping the media burning industry – at some stage it was a staple program used by many ‘burners’.

Its popularity, even today, can be used for not-so-nice-reasons.

How?

The simplest way is to drop a fake plug-in inside the following location:

  • c:\Program Files\Common Files\Ahead\AudioPlugins

The plug-in must be a DLL file named with a ‘nx’ prefix, and exporting two functions:

  • NERO_PLUGIN_GetPrimaryAudioObject
  • NERO_PLUGIN_ReadyToFinish

Such plug-in can be then loaded anytime user wants to burn the Audio CD. For testing purposes, the easiest way to ‘trigger’ the execution is by going to Tools, and looking at Plugins Options. All the DLLs, as long as properly named, will load and execute at least their DllMain.

There are more locations that can be potentially abused:

  • HKLM\SOFTWARE\Ahead\Shared\AudioEffects\DXPlugins
  • HKLM\SOFTWARE\Ahead\Nero PhotoSnap Shared\PluginManager\Plugins
  • HKLM\SOFTWARE\Ahead\Nero Mobile\Installer\Signed=<exe>
  • HKLM\SOFTWARE\Ahead\Nero Mobile\Installer\Unsigned=<exe>
  • HKLM\SOFTWARE\Ahead\Nero BurnRights\PathToBurnRights =<exe>
  • HKLM\SOFTWARE\Ahead\InCD\UI\LaunchOnBlankDisc=<exe>
  • HKLM\SOFTWARE\Ahead\Shared\<various registry names can be replaced>

Some of these executable paths could be replaced with others (man in the middle attack). Some can point to new plugins added under respective Nero applications suite.

And Nero is just an example. I think most of the popular applications that thrived in early noughties and survived to this day can be abused in a similar way as long as they offer some options for customization, and support plugins.

Enter Sandbox part 22: CTF – Capturing The … False (Positive Artifacts)

Posted on by

Do these look familiar to you?

  • CTF.Asm.Mutex
  • CTF.AsmListCache.FMP
  • CTF.Compart.Mutex
  • CTF.Layouts.Mutex
  • CTF.LayoutsCache.FMP
  • CTF.LBES.Mutex
  • CTF.TimListCache.FMP
  • CTF.TMD.Mutex
  • MSCTF.Asm.Mutex
  • MSCTF.CheckThreadInptIdle.Event
  • MSCTF.CtfActivated
  • MSCTF.CtfDeactivated
  • MSCTF.CtfMonitorInitialized
  • MSCTF.CtfMonitorInstMutex
  • MSCTF.CtfServerMutex
  • MSCTF.GCompartList
  • MSCTF.MarshalInterface.FileMap
  • MSCTF.SendReceive.Event
  • MSCTF.SendReceiveConection.Event
  • MSCTF.Server
  • MSCTF.Shared
  • MSUIM.Msg.Private
  • MSUIM.Msg.SetFocus
  • MSUIM.Msg.ThreadTerminate
  • MSUIM.Msg.ThreadItemChange
  • MSUIM.Msg.LangBarModal
  • MSUIM.Msg.RpcSendReceive
  • MSUIM.Msg.ThreadMarshal
  • MSUIM.Msg.CheckThreadInputIdel
  • MSUIM.Msg.StubCleanUp
  • MSUIM.Msg.ShowFloating
  • MSUIM.Msg.LBUpdate
  • MSUIM.Msg.MuiMgrDirtyUpdate

Since some of them are just prefixes/infixes, it’s possible that you are used to see their longer versions e.g.:

  • \BaseNamedObjects\CTF.TimListCache.FMP<…>
  • CTF.Asm.MutexDefaultS-1-5-21-<…>
  • \BaseNamedObjects\msctf.server
  • Local\MSCTF.Asm.Mutex<…>

You might have seen them in strings extracted from binaries, or AV write-ups, or sandbox reports. You might have searched the Internet for these as well, and… found many blogs and forums talking about them.

Turns out that all of these are created by MSCTF.dll, a native Windows OS library, that together with ctfmon.exe (and a couple of other libs e.g. msctfime.ime) support Text Services Framework.

Before I continue I must mention that there may be cases where malware samples impersonate legitimate OS services and use similar or even identical names for objects. Exceptions that prove the rules.

For some reason many of these *CTF* artifacts get a lot of people confused over the last years. As I mentioned, many posts can be found online where users ask about the CTF-related artifacts and suspect malicious infection…

There are many reasons for that. Microsoft didn’t do a good job explaining what it is for starters. But in my opinion this is not Microsoft fault. I think that a big part of the blame is on the vendors and researchers. Pretty much every sandbox report and AV write-up got it wrong at the beginning. With time, some of them eventually corrected themselves, but many of such wrong reports still remain online; these reports describe malicious activity of analyzed samples. So, if it is in the report, it must be true right?

What’s worse, these artifacts end up in books as well – authors end up teaching others how to interpret artifacts in an incorrect way. As such, people who read these books and believe them at their face value potentially shoot themselves in a foot.

We all enjoy a bit of a schadenfreude and it is kinda funny to see these being listed in printed materials, or online reports, but there is a more serious angle to that. If you ever include such artifacts in your forensic report, especially in cases where accuracy is of paramount importance, they could compromise your whole case (a.k.a. they can prove you don’t know what you are talking about).

So.. let’s finally put an end to this CTF FP artifact nightmare.

MSTCF is a library that happens to be loaded by many Windows processes. As such, you will find its traces on XP:

Windows 7:

Windows 10 (admittedly less):

If you are a security vendor, if you generate IOCs, sandbox reports, AV write-ups, write white papers, etc. please do whitelist these artifacts from the reports. Please do add QA/QC checks for CTF artifacts in your deliverables. And if you are reverser, make sure you confirm your findings. And don’t let malware trying to re-use these artifacts’ names for malicious purposes fool you.