Category Archives: Sandboxing

An anti-sandbox/anti-reversing trick using the GetClipboardOwner API

Posted on by

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:

State machine on top of another state machine i.e. konami code as a sandbox evasion

Posted on by

The recently discovered bug in libssh (CVE-2018-10933) made me think of a state machine mechanism a bit. Not the particular one causing that specific bug, but the one that is embedded and used by all windows. Many programmers know it as a Windows Procedure – a callback routine executed anytime there is a window message waiting in a queue.

The windows message loop calling the windows procedure is a foundation of the Windows UI; given its omnipresence it has been attacked many times before and many techniques are known e.g. shatter attacks, malicious automation (f.ex. closing dialogs from security products, clickjacking), as well as privilege escalations, and delayed code execution. Some older malware (e.g. Upatre) actively abused it and executed its main code inside the windows routine; more info on the existing anti-emulation techniques within this space can be found in this preso (pdf/slideshare site warning).

So, now that we know the standard windows procedure has been used by malware in the past you may be wondering what this post is about. Well, it’s about another state machine. One that can be built on top of an existing windows message loop. We can probably call it a Konami code, since the idea I am describing is pretty much borrowed from this famous game trick.

Konami code implementation can be a simple state machine that progresses when specific keys are entered by the user (e.g. keys collected in response to WM_CHAR, WM_UNICHAR , WM_KEYDOWN, etc. messages). A program would wait for a keyword to be entered by a user. Notably, for it to work, the keyword should be a relatively popular word to ensure that the state machine is actually reaching its final stage. Things like ‘hello’, ‘thanks’, ‘lol’, or even shortcuts for emojis should do the trick. Even a combo of 10 pastes (10x CTRL+V) could be a good trigger as well. Anyone writing emails, editing report, or posting memes on Slack would trigger these in no time while the sandbox or even reverse engineer will be stuck until they reverse the actual routine to understand what the trigger is. And if none of these work, there is always a way to introduce a timeout after which the main payload code will still execute.

While the original konami code was keyboard-centric, nothing stops a coder from implementing a mouse-centric, or a hybrid approach. For instance, one could wait after N mouse moves to the left top corner are registered before the keyboard konami input code is enabled.

If you are a windows programmer you probably recognize the caveat of the idea described above – in order to intercept the windows messages the window needs to be active – and if it is not, it has to attach itself to capture certain messages system-wide e.g. using SetCapture API for mouse. This is tricky and obviously the best possible way to implement it is by using well-known keylogger techniques…

How to deal with it on a sandbox/reversers’ side? I doubt there is a generic way to detect such trigger in an automated fashion, but luckily malware families don’t change that fast; once such stealth-trigger-happy malware family is discovered and analyzed there is always a way to extract the trigger info in a generic way – either statically, or dynamically. The script to trigger the code can be then deployed for this particular family. Also, just a presence of active keylogging functions is a good indirect indicator as well. And who knows, perhaps in some cases it’s enough and we don’t even need to bother to know the konami code… Oh well, just one of these ideas.