Anti- techniques refresh A.D. 2019

August 3, 2019 in Anti-*

The old-school malware used to detects Reverse Engineering tools by looking for artifacts created by this type of software. The most common artifacts include Process Names, DLL Names, mutexes, files, Registry Entries, Window Classes / Titles. It’s actually really trivial to catch sysinternals tools, Wireshark, OllyDbg, IDA, etc. by using simple Windows API calls that find Window with a specific class/title…

Long, and always growing lists of ‘interesting’ window classes/titles used by these tools have been circulating within a cracking / malware community for many years & are kinda a standard now. So standard, sometimes they include artifacts as old as these created on Windows 9x (e.g. Softice references that are obsolete today).


I’ve been recently thinking of all these well-known tricks and it suddenly hit me that we don’t really hear much about software targeting newer tools on our scene:

It is handy to review these tools from an attacker perspective – we may be able to collect additional data points that can be easily converted into yara sigs, etc.. And of course, this is a new class of old-is-new-again tricks that may be out there and we are just not focusing on finding yet – a.k.a. potentially missing them.

IDA’s QT windows seem to be hard to spot using your standard window enumerations APIs — the drawing routines are all internal to QT and there are no native Window primitives used by the class other than a generic window belonging to class Qt5QWindowIcon. Still, we can query its window text though and if it contains .idb, or _i64 strings (that refer to IDA database file extensions) chances are high that IDA is running.

GHIDRA is Java-based so windows’ classes are related to it e.g. SunAwtDialog or SunAwtFrame. The Window titles will of course reveal references to the program name e.g. Ghidra: <project name>.

PE-Sieve is a command line tool, so there are no windows created, but it can still be spotted by looking at a process list. Any process with a pe-sieve in name should be a red flag.

Detect It Easy (DiE) is written in QT, and same as IDA doesn’t use native window hierarchy (just one class QWidget). Still, its window titles are revealing the name of a program e.g. Detect It Easy 1.01 or Die.

WinDbg with Time Traveling relies heavily on a bunch of DLLs that will be loaded into a target process:

  • ttdloader.dll
  • ttdplm.dll
  • ttdrecord.dll
  • ttdrecordcpu.dll
  • ttdwriter.dll

Detecting presence of any of these should work as a neat anti-debug trick. (note: I have not explored it enough yet, but it would seem that ttdrecordcpu.dll and ttdwriter.dll are always loaded into a debugged process; others are helper libraries & may not be present in a debuggee’s address space; need to run more tests).

XDBG is a great debugger and gaining more and more users as it breaks Olly’s hegemony when it comes to user mode code analysis – it offers a debugger for both 32- and 64-bit programs. And since it was written in QT as well, it kinda suffers from the same detection limitations as other programs I described above. Still, the window class Qt5QWindowIcon and the Window Title x32dbg or 642dbg give it away. Same goes for process names.

Fakenet-NG is a nice local network redirector. When it’s running, a service called WinDivert xxx is in operation, so it’s one way of to detect it. Others may include spotting boilerplate file content that is delivered on monitored ports — if an analyst forgot to edit these, the content returned by a local server is predictable and can be identified as a default FakeNet reply e.g.:

With regards to WireShark, there are tones of ways to detect it. The filenames in default install directory, the Registry entries, NPCAP/WinPCAP driver/service, Window class/title, the file extensions it takes over, etc. Notably, newer versions of Wireshark also use QT, so you can look for a Qt5QWindowIcon class with a title The Wireshark Network Analyzer.

Sysmon and EDRs is a completely different category. If you see them running — need to rely more on Lolbins, and/or other trickery (e.g. common whitelisting points i.e. directories whitelisted by EDRs/analysts often relying on ‘standard’ configs like e.g. SwiftOnSecurity). There is a growing body of knowledge that focuses on bypassing EDRs and it’s just a matter of time that it will become a de facto part of attackers’ toolkit. Bugs, clever bypasses, code patching etc. are on a rise. It’s also a time we create a curated list of artifacts that EDR tools give away: program locations, processes running, Registry keys, services, etc.

For obvious reasons, I am not listing all artifacts, to make it a little bit harder for the bad guys, but these are potential detections capabilities out there and it’s good to keep them in mind. Not only they can help malware to detect defenders tools, but may also be useful for sandbox vendors / SOC analysts to identify sample behavioral traits as well.

I guess, the Cat and Mouse game continues?

Comments are closed.