You are browsing the archive for Malware Analysis.

Turning the MAX_PATH length to 11

May 6, 2018 in Anti-*, Forensic Analysis, Malware Analysis, Sandboxing

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:


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

NTFS Sparse files – another possible quick anti- trick

April 25, 2018 in Anti-*, Anti-Forensics, Malware Analysis, Random ideas, Sandboxing

A number of tricks that cause trouble to sandboxes, as well as malware analysts leverage less known features of NTFS (note: less known to programmers and perhaps reversers than to forensic experts). NTFS is rich in features and malware successfully abused these in the past, and… still does nowadays e.g. storing the code and data inside the Alternate Data Streams, Extended Attributes, toying around with Unicode character set by using RTLO (Right To Left Override) or homographic attacks to hide or obfuscate file names.

What about Sparse files?

The way it works is that one can create a normal file using e.g. CreateFile API then use the FSCTL_SET_SPARSE control code to make this file grow in a perceived size very quickly. The change is instant as the system allocates a chain of clusters for such file inside the $MFT and does so in a smart way without actually using physical clusters that it would normally fill in with data (zeroes). So large these files can become that copying them outside of lab/sandbox will cause a lot of trouble, and who knows, in some cases may even DoS the whole lab device or network.

There is also one more trick that can be done here (while it doesn’t require using sparse files per se it is certainly easier to deliver it with this specific feature being enabled): a slightly more complex malware could artificially generate a new payload – a large PE file (and creating it in a sparse mode would be the fastest way to do so).  It would then fill it in with a modified PE header/sections data and sections placed in the vast space of a new file yet in a way that the file can be still executed. There are some constraints against maximum size and available memory of course. Again, it will be impossible to copy such file outside the lab/sandbox w/o either compressing it or shrinking it somehow. It may also be harder to dump its memory and post-process/analyze it efficiently (note that if these artificially created PE sections are large enough malware could fill it in memory with a lot of random data so the memory dump would contain some ‘data’ – imagine how long would it take to generate strings from it).

And last but not least – such trickery may affect forensic evidence processing – such files would be certainly harder to extract. I don’t know what techniques forensics software can use to ensure extraction of sparse files is done efficiently (and how forensic software deals with it today), but well… using sparse files for the output could be probably a good idea? Also, how to browse such files efficiently? Some special mode that removes zeroes from the output and shows ‘islands’ of data? Some food for thought.

No PoCs as it is just a random thought.