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.