Process monitoring/Process cmd line monitoring – data sources

October 27, 2018 in Mitre Att&ck

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: …), 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?

Comments are closed.