You are browsing the archive for Batch Analysis.

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

October 21, 2018 in Anti-*, Batch Analysis, Sandboxing

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.

Possible anti-sandbox trick using SetSystemTimeAdjustment API

October 21, 2018 in Anti-*, Batch Analysis, Sandboxing

Update

Just to expand on the forensic side of things – the time adjustment value, if changed, does not survive the reboot; i.e the adjustment value is not stored anywhere (e.g. in Registry).

Old post

Today I was browsing some of my archives and (re-)discovered a program written by my ex-coworker before Tue Feb 10 20:20:38 2004 (thx PE compilation time ;). The program was written with QA test automation in mind, but when I ran it today on my win7 VM I realized that the very same trick could be used to affect the inner working of the sandbox systems, or even disturb some reversing work…

The program is simple; it allows the user to modify the ‘adjustment’ value for the Windows Clock.

What does it mean?

Googling around I found this post that explains the inner workings of this mechanism better than I could ever do myself. The magic API is called SetSystemTimeAdjustment; it’s good to know that it internally calls NtSetSystemInformation with a SystemTimeAdjustmentInformation parameter. Sandbox programmers please take a notice.

As per the MSDN article:

The GetSystemTimeAdjustment and SetSystemTimeAdjustment functions support algorithms that synchronize the time-of-day clock, reported via GetSystemTime and GetLocalTime, with another time source using a periodic time adjustment.

Okay, enough theory.

After I ran the program and adjusted the ‘adjustment’ (pun intended) setting to the ‘max’ my clock went completely crazy:

(btw. this is tested and recorded on win7; win10 clock is such a ‘paradigm shift’ in the user interface that I can’t even begin to describe my despair…)

Running timeout 10 command suddenly doesn’t work as it should. It exits immediately or almost instantly and shows some funny values on the screen (kinda integer overflow ;). Same goes for timeout 100, 1000, 10000…

Interestingly, running ping 127.0.0.1 doesn’t cause any issues.

And this is because timeout is using a _time API function that is being checked every 100 ms. If we adjust the clock to run faster the _time function will produce the result that is immediately much higher than expected under normal circumstances (so, delta between the start value and next value is big enough o satisfy the exit condition); as a result, the timeout program will quit. Ping is using a call to Sleep (1000) API in a loop (between the pings, the number of which is default 3 and can be changed by the -n command line argument), and that’s why it is not affected.

So, the conclusion can be that if any program ran by a sandbox on the test system is relying on a difference between two sequential values returned by any of the time function relying on the adjustment (GetSystemTime , GetLocalTime, _time, etc.) – it will be affected. Sandboxes that don’t run any ‘worker’ programs on the guest system can sleep well, but… don’t they all run auto clickers (for GUI programs) these days? And these must rely on some delays/time functions. Hmm… As usual, a subject for a further research. I also wonder if changing the settings will affect existing software and potentially introduce some interesting race conditions or at least DoS. The good news is that use of this API requires admin privileges,