Category Archives: Forensic Analysis

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.

Turning the MAX_PATH length to 11

Posted on by

In my recent post I described how NTFS Sparse files could be used to make life of reversers, forensic investigators, and sandbox developers a bit more difficult. There are  more way to to make their life more miserable and here I describe another potential one.

Every once in a while I re-read the Naming Files, Paths, and Namespaces article on Microsoft page. I do it because I don’t remember all the gory details and I know that this page is updated every once in a while so sometimes you can find some new content there.

New content == new ideas.

While the change I refer to is not very very new, it is very interesting especially from the reversers’ and sandbox developers’ perspective:

Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters.

[…]

Tip Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD). The key’s value will be cached by the system (per process) after the first call to an affected Win32 file or directory function (list follows). The registry key will not be reloaded during the lifetime of the process. In order for all apps on the system to recognize the value of the key, a reboot might be required because some processes may have started before the key was set.

The registry key can also be controlled via Group Policy at Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths.

This is very interesting.

If there is no limitation, malware could abuse it relying on the fact limitations apply to all software that is not aware of this change.

For instance, if sandbox is copying files from the sandbox to external world, using a script/program that runs inside the sandbox, and does not use the extended-length path’s prefix \\?\ when it accesses files it will fail to copy files out as it won’t ‘see’ them (they are too deep). Notably, the very same limitation applies to the old trick where the known device name is used as a file name and such file (e.g. c:\con) can only be accessed via that extended-length path’s prefix.

But are all sandbox developers aware of this? (unless they use external access to the sandbox disk using e.g. their own NTFS parser)

And as for reversers… if the tool they use to browse the system, open the file don’t use the extended-length path’s prefix they will find themselves unable to browse/open files inside these deeply nested folders.

And if you are a forensic investigator, there is yet another Registry key to learn about:

HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
LongPathsEnabled

So, not entirely new (the c:\con trick is at least 10 years old), but perhaps new to you.