Looking at the compact.exe program today I noticed that it had a few extra command line arguments (I never heard of) available, including /exe, xpress4k, xpress8k, xpress16k and lzx. Quick google research led me to this excellent post by Yogesh Khatri and this informative discussion on the Microsoft page.

After testing it on win10, I confirmed some forensics tools struggle with processing of such compressed files. It immediately occurred to me that the very same problem will apply to any sandbox, or other security solution that tries to bypass the native NTFS driver of OS and read the files directly from the logical or physical drive (this also includes solutions that read file systems from the guest VM images from the host level: some sandboxes do).

As such, if these solutions don’t process such compressed files properly, a malware could simply use compression to make it harder for anyone to extract samples from the system, in a similar fashion like the other NTFS feature I discussed previously. Of course, bypassing it is easy as one has to use built-in OS APIs to copy files to other locations, but this may affect the workflow of the sandbox process (especially these that try to be non-intrusive and only observe what’s happening inside the sandbox).

To test run:

compact /c /f /exe:<compression> <filename>

where compression is one of these:

• xpress4k
• xpress8k
• xpress16k
• lzx

Last, but not least. The compact.exe is using DeviceIoControl API to set the compression of the files. Some coders already duplicated the compact.exe functionality in AutoIt.

This is a little nifty trick for detecting virtualization environments. At least, some of them.

Anytime you restore the snapshot of your virtual machine your guest OS environment will usually run some initialization tasks first. If we talk about VMWare these tasks will be ran by the vmtoolsd.exe process (of course, assuming you have the VMware Tools installed).

Some of the tasks this process performs include clipboard initialization, often placing whatever is in the clipboard on the host inside the clipboard belonging to the guest OS. And this activity is a bad ‘opsec’ of the guest software.

By checking what process recently modified the clipboard we have a good chance of determining that the program is running inside the virtual machine. All you have to do is to call GetClipboardOwner API to determine the window that is the owner of the clipboard at the time of calling, and from there, the process name via e.g. GetWindowThreadProcessId. Yup, it’s that simple. While it may not work all the time, it is just yet another way of testing the environment.

If you want to check how and if it works on your VM snapshots you can use this little program: ClipboardOwnerDebug.exe [external link warning].

This is what I see on my win7 vm snapshot after I revert to its last state and run the ClipboardOwnerDebug.exe program:

Notably, I didn’t drag&drop/copy paste the ClipboardOwnerDebug.exe file to VM, I actually copied it via a network share to ensure my clipboard doesn’t change during this test; and, even if I did just CTRL+C (copy) the file on the host and CTRL+V (paste) it on the guest the result would be very similar anyway. The vmtoolsd.exe process just gets involved all the time.

The malware doesn’t need to rely on the first call to the GetClipboardOwner API. It could stall for a bit observing changes to the clipboard owner windows and testing if at any point there is a reference to a well-known virtualization process. Anytime the context of copying to clipboard changes between the host and the guest OS (very often when you do manual reversing), the clipboard window ownership will change, even if just temporarily.

The below is an example of the clipboard ownership changing during a simple VM session where things are copied to clipboard a few time, both on the host and on the guest and the context of the the clipboard changes. The context switch means that when the guest gets the mouse/keyboard focus, the changes to host clipboard are immediately reflected by the appearance of the vmtoolsd.exe process on the list: