An overview of Windows process behavior and why it matters
Nov 02, 2018
This post covers Windows Process Behavior from a very high level. Look for future posts going into much more depth on a variety of topics surrounding Process Behavior and how it can be leveraged to hunt for and detect attackers on your endpoints.
Windows Process Behavior
A technique often used by the Endpoint Detection and Response (EDR) industry is to detect attacker activity based on the behaviors exhibited by processes on your endpoints. All of that sounds pretty fancy, but I want to break it down for you here.
Process behavior simply refers to what a particular program does when it runs on a computer. For example, when you start Microsoft Outlook, your computer launches the Outlook executable, outlook.exe, loads it into memory and begins to execute its instructions. Since every program is different, each one behaves a little differently after it launches.
After Outlook.exe launches, it loads some library files that it needs to carry out its functions. After that you might see it make a network connection to retrieve emails, and read and write files to the hard drive as the user interacts with it. You might also see it launch a child process when a user clicks on an attachment. For example, if a user clicks on a Word Doc attachment, you would see Outlook launch winword.exe.
Each of these activities that we see a process exhibit are referred to as behaviors. Here is a list of common behaviors many EDR products capture (roughly in order of importance):
- Executable Path
- Command Line Arguments
- Network Connections
- Executable Hash
- File Writes
- Module Loads
Most EDR products use these behaviors to detect anomalous or unwanted activity, and some make the raw data available for you to analyze yourself.
This brings into light the concept of process parents, children, grandparents, etc. Collectively, we call this Process Ancestry and spending some time to understand it can be extremely fruitful for threat hunting and detection on endpoints.
If our ultimate goal is to detect threats to our environment, then it pays to understand what normal process behavior looks like. If we understand that, then we’re much more likely to be able to pick out anomalies.
This understanding can be helpful in a couple of ways:
One, it can give you context as you interpret and investigate alerts coming from an EDR product. Despite industry efforts to reduce false positives, they’re still common and it’s up to you to investigate and make a determination as to the veracity and the severity of each alert.
Another, even more pertinent use case, is in Threat Hunting. Starting with an understanding of typical process behavior, you can start to build a list of behaviors that you would not expect to see in your environment and you can begin hunting for those.
A Specific Case
Let’s take winlogon.exe as an example. Click on the link to read more about what it does. Also, take a look at its children in the table below. Note that you don’t see any typical processes that a user would run, like calc.exe, winword.exe or cmd.exe. Based on the description of winlogon.exe, along with some data to back it up, we can deduce that it shouldn't launch programs like these under normal circumstances.
There is a logon bypass technique, called Sticky Keys, that allows a person to access a shell like cmd.exe without logging in, simply by modifying a registry key. Once modified, this allows a user to bring up a command prompt on top of the logon screen simply by pressing the shift key 5 times. This invokes an accessibility feature in Windows that would normally bring up a window offering logon assistance to the user, but in this case brings up a command prompt instead. Note: this is a persistence technique, not an exploit to gain initial access.
When this technique is leveraged by an attacker, you would see winlogon.exe launch a child of cmd.exe, or if you were looking from cmd.exe’s perspective, you’d see winlogon.exe as its parent.
Using a database like Insights to confirm that winlogon.exe launching cmd.exe is either never seen, or exceedingly rare, you can feel confident adding this behavior to your future hunting efforts.
If you’re wondering how to get started actually doing this. Take a look at Sysmon as an endpoint behavior logging tool and take a look at this post I wrote to help get you started. Also, sign up for the mailing list below as there will be more posts on this topic to follow.
Check out our Welcome post for a list of upcoming topics.