Category Archives: Anti-*

Sysmon and an accidental anti-disassembling trick

Posted on by

This is one of these cases where you don’t plan for the outcome, yet you stumble upon something interesting, and then you just… describe it.

When you launch IDA and then load the sysmon.exe into it, you will see the following dialog box:

Okay…, so…. for some reason, IDA is recognizing the sysmon.exe binary as having an additional resources apart from the 32-, or 64-bit binary code. One that is associated with SNES.

Err… Que?

If you ever opened a .NET binary in IDA you are familiar with the program reaction to these types of binaries. It immediately shows you various, very specific ways to process (disassemble) the file. And not only the ‘traditional’ MZ/PE executable (including MZ DOS Executable which is just a basic Stub), but also the .NET binary that IDA can parse and show to you:

If you are familiar with this view, then the reason for the SNES detection becomes pretty apparent.  It is very much the same reason that makes IDA include an additional item for .NET binaries.

When IDA opens a file it runs all the Loader Plugins. They are responsible for a quick&dirty detection of the binary image. Every time any of them returns a ‘I know this file format’ value, the IDA will add the returned string to the list of available modules that can process this data block (that’s because code and data have no meaning, until you apply file format constraints to the data block, and only then will recognize certain data blocks as code or data).

And if any of these is chosen by the reverser, the plug-in will be activated to process the data in a way the specific loader envisions…

In a case of sysmon.exe, it doesn’t really make sense to load the SNES loader, but… well… why don’t we try?

Let’s be honest. It’s a complete non-sense.

Yup, in a case of sysmon, it’s obvious it doesn’t have the SNES data inside it., We can consider it a loader bug/feature, and… we can immediately think of simple ways to abuse it…

While many IDA loaders are pretty strict about the image file format they expect, there is a way to trigger them all, or at least, some of them. Before you get too excited though, you need to understand that we can’t create a polyglot file that will cater for the expectations of all them, or most of them, but well… you can certainly try to make some of them work…

In other words, one could craft a file that will end up with the IDA showing more items on the preliminary Disassemble dialog box than expected.

How do we go about it?

Let’s start with a quick analysis of the SNES Sound File plugin which is the smallest possible (file size-wise) on my install; analysis of its code shows that creating any file of a size at least 0x10200 and with a header as below:

… will allow us to create dummy files that will be recognized by IDA as SNES music modules.

The hypothesis is then as follows: for each Loader module, there exist a minimalistic file that can act as a dummy that will be interpreted by IDA as a file of a specific format.

And a hypothesis #2: in some cases, we will be able to create PE executables (32- or 64-bit) that will include data crafted in a way as to trigger recognition functions of additional IDA Loader modules in a file; same way as sysmon does accidentally.

Thanks Sysmon!

While it won’t stop more advanced reversers, it will certainly add to the confusion of Trudys (the archetype of a n00b reverser created by @hacks4pancakes), and any automated systems that involve IDA for batch processing…

Last, but not least – yes, it is lame, but… the more the anti-* the more interesting it is to enter this field. Isn’t?

Trivial Anti-BlueTeam trick for 32-bit systems

Posted on by

I love evasion tricks of any sort. Sometimes they can be very elaborate, and sometimes… incredibly trivial, almost stupid really. Such is the trick I am describing below. It works on 32-bit Windows only, and that’s because it relies on a folder structure that is (exclusively) present on 64-bit systems.

If we look at logs from various process monitoring tools we can notice that they omit a very important info. They don’t tell us what is the architecture of the logging system. Unless it is somehow self-evident (e.g. ‘bitness’ is a part of a host naming convention) there is no way to tell whether the process is executed on a 32- or 64- box.

These 3 folders are present on 64-bit systems only:

  • c:\windows\syswow64\
  • c:\windows\sysnative\
  • c:\Program Files (x86)\

Nothing (apart from access rights) stops us from re-creating them on a 32-bit system.

Imagine seeing the following paths in the logs indicating that calc.exe or iexplore.exe was launched on a system:

  • c:\windows\syswow64\calc.exe – from a 64-bit system
  • c:\windows\syswow64\calc.exe – from a 32-bit system
  • c:\windows\sysnative\calc.exe – from a 64-bit system
  • c:\windows\sysnative\calc.exe – from a 32-bit system
  • c:\Program Files (x86)\Internet Explorer\iexplore.exe – from a 64-bit system
  • c:\Program Files (x86)\Internet Explorer\iexplore.exe – from a 32-bit system

For all logs from 32-bit systems it’s obvious that they are fake.
How can you tell the difference though if your logs don’t tell you the architecture of the system where they come from?

This opens up a lot of opportunities for an impersonation.

Threat hunting efforts that rely on full paths for analysis purposes (whitelisting, LFO, etc.) could be easily fooled to accidentally exclude, or include bad processes that are executed from locations that pretend to be ’64-bit legitimate’.
And since most of the orgs are mixed 32/64 environments, the logs from all systems will be inevitably clustered together, and detection rules will be applied to them as a whole.

Admittedly, a malicious svchost.exe executed from c:\windows\syswow64\svchost.exe is definitely less suspicious than one starting from %APPDATA%:

Now, could this be a bad process?

  • c:\Program Files (x86)\Windows Defender\MpCmdRun.exe