Process monitoring/Process cmd line monitoring – data sources

Posted on by

One of the most popular way of hunting is looking at the processes that have been executed on a specific system, or a set of them.

There are many data sources that can be useful in analysis of executed processes, so after being inspired by this interesting Twitter thread I tried to put together a quick & dirty list of logs/ideas listed there + some more. If you have any other ideas please let me know. Thank you.

  • Windows
    • 4688 with no cmd line arguments
    • 4688 with cmd line arguments
    • 4688 with cmd line arguments & name of the parent process (newer Windows systems)
    • Sysmon / 1
    • EDR logs
    • AV logs
    • Local Proxy logs
    • Local IDS logs (CIDS)
    • DCOM Logs
    • WMI Logs
    • there are also some ‘indirect’ logs that may indicate some process ran at some stage in the past (most of these listed below include PID, process name) e.g.:
      • service creation / start logs
      • powershell logs
      • WER logs
      • Application error logs
      • Application hung logs
      • App Locker logs
      • Restart Manager logs
      • Diagnostics-Performance logs
      • Firewall logs
      • System/change time logs
      • System Logon events logs
      • Forensic artifacts (if e.g. EDR picks them up — see this excellent reference by @harrisonamj: https://blog.1234n6.com/2018/10/available-artifacts-evidence-of.html …), etc.
      • etc.
  • Linux
    • auditd (see this reference)
      • EXECVE
      • USER_CMD
      • BPRM_FCAPS
      • SYSCALL
      • ANOM_EXEC
    • content of .bash_history retrieved as a snapshot on regular basis
  • OSX
    • xnumon logs (anyone actually using it?)
    • content of .bash_history retrieved as a snapshot on regular basis

Noise in the logs:

Unfortunately, there is a lot of noise; I have written about it many times before: Enterprise solutions, especially asset inventory tools create a crazy number of processes that:

  • contaminate the logs and make our jobs much harder, because they use the very same techniques as described in MITRE; just for good reasons
  • clutter the logs by adding huge volumes of events with lots of additional data that we don’t want to parse through, but we have to (performance hit is visible; every new system is a noise multiplier)

Lookup tables, white lists of any sorts, regexes by host, by process name, by PID, by user name, by SID, by tokens, etc. are all good, but… these are nice gates for someone to exploit it. All they have to do is to name their malicious processes like a well-known processes.

It’s a cat and mouse game, but we could really do much better without this non-sense in logs…

Dear vendors, could you please reduce your 3rd-party tools dependencies?

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.