Category Archives: Anti-Forensics

Sysmon doing lines, part 3

Posted on by

Update

This issue was fixed by Mark Russinovich on 2018-07-06; that was pretty quick!

Old

Sysmon is an easy target, because it’s easily downloadable and everyone can poke around in its code or toy around with the system and see what sysmon logs. It’s obviously not fair – if other EDR code was that easily available I am pretty sure we would see a cascade of ‘funny stuff’ in these products as well.

Anyway…

In my older post I presented a simple technique that may fool parsers and their state machines into ‘thinking’ they are parsing correct records while in fact they are processing data some malicious software meticulously crafted for them. This is not necessarily sysmon’s problem, but who would read that old post if there was no clickbait value in the title, right?

Back to sysmon and poking around… once you start looking at it you can quickly discover that it can be run in a so-called debug mode – all we have to do is provide an undocumented command line switch ‘-t’ when we install it. When I first discovered it I got really excited, only to immediately get a bucket of cold water thrown by the Twitter post by @mattifestation who figured it out in… Jan 2018.

It’s a really cool feature.

When you run ‘sysmon -t -i’ the program will start throwing a lot messages to the console and some of them will eventually trigger your interest. Especially if you ‘help’ them a bit to appear 🙂

So… what we see in this error message is a very crucial information.

The sysmon had to truncate a very long command line which I have provided to a test process. It was so long that it had to be trimmed.

A-ha… but how long?

Well, it turns out sysmon doesn’t like command line longer than 0x2000 characters – i.e. this a number of wide characters it can swallow, before trimming down the rest.

Now this 0x2000 (Wide characters) is actually 16384 bytes only.

I was curious where the 0x2000 came from, because after reading various versions of MSDN pages about CreateProcess I know very well that the lpCommandLine argument can be much longer; as per the MSDN:

The maximum length of this string is 32,768 characters,
including the Unicode terminating null character.

So… this is an interesting discrepancy.

I have a hypothesis (and I am totally guessing it) that the sysmon author used the arbitrary limit imposed on cmd.exe command line arguments.

Such discrepancy is a nice gift and we can of course abuse it.

Since we can’t pass the command line arguments that are longer than 0x2000 characters to cmd.exe let’s try to use powershell instead.

If you run ‘powershell <0x2000 spaces> calc’ you will spawn Windows Calculator.

What will you see in the logs?

This:

And if you export it to TXT or XML you will get this:

So… using long command line arguments provided to executables that can work with such madness (e.g. powershell) can help to evade sysmon logs…

If you want to test it, grab this .exe.

Enter Sandbox – part 16: The symbols, the ApiSetSchema, and other possible future evasions

Posted on by

It’s been a while since I wrote about Sandboxes and I thought I will revive the series by listing a couple of ideas that I believe may be still under the radar of both sandbox solution creators, and reverse engineers.

Symbols

When we analyze Windows native OS libraries one of the most useful features we have at hand is leveraging debugging symbols. IDA, windbg, and many other reversing tools can use these symbols very efficiently – with symbols in place we can see names of internal functions, variables, and this code/data enrichment provides us with an invaluable context that speeds up the analysis.

Now, since the tools can use it, there is nothing that could stop malware from… doing the same.

Imagine the possibilities!

Instead of relying on export/import tables, a clever malware that leverages symbols could make calls to internal functions, or find ways to hook code deep inside the functions that are typically monitored (at least on the userland level). Symbols could also help to detect caves i.e. areas of code/data that are rarely used, and allow malware to overwrite them and persist in a much stealthier way than usual. There is a lot of potential for surgical modification of code to launch the payload code using the EPO (Entry Point Obscuring) technique.

Note that while there could be a need to download these PDB files directly on the infected system, nothing stops malware from sending copies of the DLLs from the system to its server first, decompiling / disassembling them on a remote server.  The malware could then craft the payload using hardcoded offsets obtained via symbols to deliver the required functionality. A side effect of such trickery would be that such crafted payloads would not run on sandboxes, and manual analysis would typically fail unless the file was analyzed on the exactly same system (meaning: with the same versions of libraries as existing on the victim’s system); obviously, ASLR needs to be taken into account for all offsets and calls. Another caveat is that such approach would require constant monitoring of Windows Update service; if files are replaced, the code would need to be updated to the most up to date version that works with the new libraries.

Leveraging functions of ApiSetSchema libraries

Now that we have not only kernel32.dll, but also KernelBase.dll, and the whole api-ms-*.dll zoo, it is possible to call these wrapper functions instead of the pure exports from kernel32.dll, advapi32.dll, etc..

Leveraging internal/undocumented functions

These can be either located via symbols, or via ApiSetSchema libraries; a quick browsing through internal functions referenced by kernel32.dll reveals a lot of interesting possibilities e.g.:

  • PrivCopyFileExW – undocumented function that allows to copy files
  • A couple of exported Internal functions that can be potentially used as callbacks (to run shellcodes, payload code, etc.)
    • Internal_EnumCalendarInfo
    • Internal_EnumDateFormats
    • Internal_EnumLanguageGroupLocales
    • Internal_EnumSystemCodePages
    • Internal_EnumSystemLanguageGroups
    • Internal_EnumSystemLocales
    • Internal_EnumTimeFormats
    • Internal_EnumUILanguages
  • A couple of exported Internal functions that can be used to access both the Registry and the File System bypassing documented APIs:
    • RegCreateKeyExInternalA
    • RegCreateKeyExInternalW
    • RegDeleteKeyExInternalA
    • RegDeleteKeyExInternalW
    • RegOpenKeyExInternalA
    • RegOpenKeyExInternalW
    • ReplaceFileExInternal

There is certainly more.

New technologies (well, sometimes not that new)

While it doesn’t really rely on symbols, it does fit the topic of the article – there is a class of APIs that are not commonly used yet, but certainly will be heavily utilized in the future:  I am talking about enclave functions; as per MS:

An enclave is an isolated region of code and data within the address space for an application. Only code that runs within the enclave can access data within the same enclave.

Example functions:

So, you got yourself yet another API set for both code injection and protection.

I am obviously not the first one to highlight it; a paper from 2015 (3 years ago!) by Alex Ionescu covers the topic and lists a number of possible issues enclaves bring to the world of security solutions including AV, EDR, and perhaps memory acquisition tools.