Bad parenting — forensics value of parent-child process statistics
Let’s assume you know what the “process” means in Windows OS. If not sure, I would definitely recommend the sample chapter from Windows Internals book, named “Processes, Threads, and Jobs”. You can download it for free from Microsoft and after working over 20 years with OS Internals, I have never found anything even close in terms of quality and details.
If you know the basics, we can quickly wrap up the most important facts:
1. Your Windows OS has an information about each process present in the system.
2. Except for OS initialization and smss.exe, each process is created by some other process, called usually the parent.
3. Child process inherits (by default) some parent process parameters such as affinity, priorities, security context etc.
4. Each process keeps an information about hist parent in the designated field within Process Execution Block.
5. Windows CAN (please enable it for your own good!) record and store the information (including parent details) about each process created. You can achieve it through Process Tracking feature or with Sysmon, free tool from Microsoft, allowing you to collect more information. “Collecting more” may sound exciting, but please remember it will also mean “analyzing more” at some point.
If we have the process tracking enabled and we can reach for the log and list the processes history, we also have invaluable help when it comes to the incident response. In the first scenario, we can identify all non-standard processes being launched, for example by comparing the data extracted from a log to a list of processes from the healthy computer with similar OS, hardware, and software configuration. Everything unusual will clearly stick out, does not matter if it is msfvenom, spying malware, or custom-written ransomware. Such analysis may be a great first step, but has one important weakness: it will never show you attacks made with built-in, legitimate Windows tools. And for many hackers, such attacks are the most tempting and beautiful ones. Especially if they may stay under the radar as no unusual binary is being involved. Grab the system context with cmd launched from utilman, run malicious script through cmd configured as a service, execute PowerShell from Acrobat Reader. It may happen and happens. And you will not detect it by looking just for unusual binaries.
Of course, we can use some advanced, machine learning, cloud, magic, whatever, based solutions, but these are not free, you need to deploy them before the attack happen and no one will tell you the full truth about how they work inside. Is great to have it, but let’s focus on the data your Windows provides out of the box.
And here comes the idea, how to expand your analytics powers. Not only compare your binaries to the list of the well-know ones, but also try to use other facts you already have collected in your security logs, especially the information about the parent. If we have process tracking enabled (does not matter if built-in or Sysmon based), every single event has the data you need. You should be aware that the amount of data about parent-child pairs will be significantly higher than single-dimension binaries list. This is the price for the power you have got. The most reasonable way of analysis would rely on cleaning the list of pairs and removing each “typical” pair, present in your systems when not under attack.
Before I provide you the ready-to-use script doing all the hard work for you, I would like to stress on couple of factors to consider:
1. Please enable process tracking. NOW. It costs you nothing and may start working the moment you press the final Enter. You have three possible ways, any of the following is enough:
a. Use auditpol /set /category:”Detailed Tracking” /success:enable from the elevated commandline. Be aware that the change will not be reflected in secpol.msc, as described in KB2573113
b. Use secpol.msc, go to Local Policies, then Audit Policy and enable the “Process tracking” / Success option.
c. Use GPO to spread process tracking settings through your environment
2. You can verify your settings by using auditpol /get /subcategory:”Process Creation” from the elevated commandline.
3. Please centralize the audit log. Just send its copy to some other computer. This topic is not within the scope of the current article and it is well-covered in many other places. Basically, centralization protects you from erasing the useful information you have just gathered. And believe me — this is one of the first things hackers will do to cover their tracks. Additionally, you can perform multi-machine queries and correlate the data if you have your logs from multiple computers in one place. Make sure you keep your centralized audit data long enough.
4. There is a chance the bad guy manipulated the information about the parent process. It is possible unfortunately, and may make investigators quite unhappy. The only good news is very rarely used in real attacks and usually involves its own processes/binaries which can be detected.
5. If you compare your collected data with others, make sure you are using a “healthy” computer as a reference. Comparing one infected machine to another one, also infected will not give you any reasonable value. The best option is to collect the data before an attack happen. Store it aside, collect new data every couple of weeks and have handy if anything bad happens. If you had your process tracking enabled, the good moment for an initial analysis is now.
6. After you enable process tracking (does not matter if the built-in or Sysmon one) you should check how long is the audit trail you keep. If the log size is too small, the oldest events will be overwritten to provide some space for fresh ones. Open your log, jump to the oldest event you have and decide if it is old enough. I have seen some logs with trails as short as two minutes which of course will not provide you real help if you realize you were attacked couple of hours after the incident. If you think you collect the right data and need to keep it for a longer time — just increase the log size. Be aware the time may significantly change if you configure new events to be collected, so verify it again couple of days after the change. If you have the log centralization properly configured (see 3, above) it would greatly help when it comes to the trail length as well.
7. When it comes to the real investigation, start with a simple list of processes first. Maybe something can be spotted. If not, you can follow the idea I have described here. Correlation parent-child may be more informative, but at the same time it is more complex when it comes to the manual detection of anomalies.
And here comes the script, I have promised you: https://github.com/gtworek/PSBits/blob/master/DFIR/GetParentChild.ps1
Good luck!