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

December 25, 2018 in Batch Analysis, Sandboxing

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.

Comments are closed.