Path: blob/master/Guided Investigation - Process-Alerts.ipynb
3249 views
Alert Investigation - Windows Process Alerts
Data Sources Used:
Log Analytics/Microsoft Sentinel
SecurityAlert
SecurityEvent
Threat Intelligence Providers (Optional)
VirusTotal (https://www.virustotal.com/)
XForce (https://www.ibm.com/security/xforce)
This notebook is intended for triage and investigation of security alerts related to process execution. It is specifically targeted at alerts triggered by suspicious process activity on Windows hosts.
Table of Contents
- 1 Hunting Hypothesis
- 2 Notebook Initialization
- 3 Get List of Alerts
- 4 Choose Alert to Investigate
- 5 Extract properties and entities from Alert
- 6 Entity Graph
- 7 Related Alerts
- 8 Get Process Tree
- 9 Other Processes on Host - Clustering
- 10 Base64 Decode and Check for IOCs
- 11 Threat Intelligence Lookup
- 12 Alert command line - Occurrence on other hosts in workspace
- 13 Host Logons
- 14 Failed Logons
- 15 Appendices
- 16 Configuration
Hunting Hypothesis
Our broad initial hunting hypothesis is that a we have received an alert/indicators involving windows process name which is suspected to be malicious, we will need to hunt from a range of different positions to validate or disprove this hypothesis.
Before you start hunting please run the cells in Setup at the bottom of this Notebook.
Notebook initialization
The next cell:
Checks for the correct Python version
Checks versions and optionally installs required packages
Imports the required packages into the notebook
Sets a number of configuration options.
This should complete without errors. If you encounter errors or warnings look at the following two notebooks:
If you are running in the Microsoft Sentinel Notebooks environment (Azure Notebooks or Azure ML) you can run live versions of these notebooks:
You may also need to do some additional configuration to successfully use functions such as Threat Intelligence service lookup and Geo IP lookup. There are more details about this in the ConfiguringNotebookEnvironment notebook and in these documents:
Get WorkspaceId and Authenticate to Log Analytics
Use the following syntax if you are authenticating using an Azure Active Directory AppId and Secret:
instead of
Note: you may occasionally see a JavaScript error displayed at the end of the authentication - you can safely ignore this.
On successful authentication you should see a popup schema button. To find your Workspace Id go to Log Analytics. Look at the workspace properties to find the ID.
Get List of Alerts
We are using an alert as the starting point for this investigation, specify a time range to search for alerts. Once this is set run the following cell to retrieve any alerts in that time window. You can change the time range and re-run the queries until you find the alerts that you want to investigate.
Choose Alert to Investigate
To focus the investigation select an alert from a list of retrieved alerts.
As you select an alert, the main properties will be shown below the list.
Use the filter box to narrow down your search to any substring in the AlertName.
Extract properties and entities from Alert
In order to pivot to data related to the selected security alert we need to identify key data points in the selected alert. This section extracts the alert information and entities into a SecurityAlert object allowing us to query the properties more reliably.
Properties in this object will be used to automatically provide parameters for queries and UI elements. Subsequent queries will use properties like the host name and derived properties such as the OS family (Linux or Windows) to adapt the query. Query time selectors like the one above will also default to an origin time that matches the alert selected.
The alert view below shows all of the main properties of the alert plus the extended property dictionary (if any) and JSON representations of the Entity.
Entity Graph
Depending on the type of alert there may be one or more entities attached as properties. Entities are key indicators that we can pivot on during our investigation, such as Host, Account, IpAddress, Process, etc. - essentially the 'nouns' of security investigation. Entities are often related to other entities - for example a process will usually have a related file entity (the process image) and an Account entity (the context in which the process was running). Endpoint alerts typically always have a host entity (which could be a physical or virtual machine). In order to more effectively understand the links between related entities we can plot them as a graph.
Related Alerts
For certain entities in the alert we can search for other alerts that have that entity in common. Currently this pivot supports alerts with the same Host, Account or Process.
Notes:
Some alert types do not include all of these entity types.
The original alert will be included in the "Related Alerts" set if it occurs within the query time boundary set below.
In order to more effectively identify related alerts the query time boundaries can be adjusted to encompass a longer time frame.
Show these related alerts on a graph
To see the how these alerts relate to our original alert, and how these new alerts relate to each other we can graph them.
Browse List of Related Alerts
Once we have understood how these alerts related to each other, we can view the details of each new, related alert.
Get Process Tree
If the alert has a process entity this section tries to retrieve the entire process tree to which that process belongs.
Notes:
The alert must have a process entity
Only processes started within the query time boundary will be included
Ancestor and descented processes are retrieved to two levels (i.e. the parent and grandparent of the alert process plus any child and grandchild processes).
Sibling processes are the processes that share the same parent as the alert process
This can be a long-running query, especially if a wide time window is used! Caveat Emptor!
The source (alert) process is shown in red.
What's shown for each process:
Each process line is indented according to its position in the tree hierarchy
Top line fields:
[relationship to source process:lev# - where # is the hops away from the source process]
Process creation date-time (UTC)
Process Image path
PID - Process Id
SubjSess - the session Id of the process spawning the new process
TargSess - the new session Id if the process is launched in another context/session. If 0/0x0 then the process is launched in the same session as its parent
Second line fields:
Process command line
Account - name of the account context in which the process is running
Process Time Line
As well as seeing the processes involved in a tree we want to see the chronology of this process execution. This shows each process in the process tree on a time line view. If a large number of processes are involved in this process tree it may take some time to display this time line graphic.
Other Processes on Host - Clustering
Sometimes you don't have a source process from which to build our investigation. Other times it's just useful to see what other process activity is occurring on the host. This section retrieves all processes on the host within the time bounds set in the query times widget.
If you want to view the raw details of this process data display the processes_on_host dataframe.
In order to more effectively analyze this process data we can cluster processes into distinct process clusters. To do this we process the raw event list output to extract a few features that render strings (such as commandline)into numerical values. The default below uses the following features:
commandLineTokensFull - this is a count of common delimiters in the commandline (given by this regex r'[\s-\/.,"'|&:;%$()]'). The aim of this is to capture the commandline structure while ignoring variations on what is essentially the same pattern (e.g. temporary path GUIDs, target IP or host names, etc.)
pathScore - this sums the ordinal (character) value of each character in the path (so /bin/bash and /bin/bosh would have similar scores).
isSystemSession - 1 if this is a root/system session, 0 if anything else.
Then we run a clustering algorithm (DBScan in this case) on the process list. The result groups similar (noisy) processes together and leaves unique process patterns as single-member clusters.
Clustered Processes
Variability in Command Lines and Process Names
In this section we display a number of charts highlighting the variability of command lines and processes paths associated with each process.
The top chart shows the variability of command line content for a given process name. The wider the box, the more instances were found with different command line structure. For certain processes such as cmd.exe or powershell.exe a wide variability in command lines could be expected, however with other processes this could be considered abnormal.
Note, the 'structure' in this case is measured by the number of tokens or delimiters in the command line and does not look at content differences. This is done so that commonly varying instances of the same command line are grouped together.
For example updatepatch host1.mydom.com and updatepatch host2.mydom.com will be grouped together.
The second graph shows processes by variation in the full path associated with the process. This does compare content so c:\windows\system32\net.exe and e:\windows\system32\net.exe are treated as distinct. You would normally not expect to see any variability in this chart unless you have multiple copies of the same name executable or an executable is trying masquerade as another well-known binary.
Time Line of clustered processes data vs. original data
Base64 Decode and Check for IOCs
This section looks for Indicators of Compromise (IoC) within the data sets passed to it.
The first section looks at the command line for the process related to our original alert (if any). It also looks for Base64 encoded strings within the data - this is a common way of hiding attacker intent. It attempts to decode any strings that look like Base64. Additionally, if the Base64 decode operation returns any items that look like a Base64 encoded string or file, a gzipped binary sequence, a zipped or tar archive, it will attempt to extract the contents before searching for potentially interesting items.
IoCs in the entire data set
If we have a process tree or other elements that contain command lines we also want to attempt to extract IoCs from these data sets.
If any Base64 encoded strings, decode and search for IoCs in the results.
For simple strings the Base64 decoded output is straightforward. However it is not uncommon to see nested encodings therefore we want to try to extract and decode these nested elements as well.
Threat Intelligence Lookup
Now that we have identified a number of IoCs we want to check to see if they are associated with known mallicious activity. To do this we will query three different Threat Intelligence providers to see if we get results.
We will be using:
VirusTotal https://www.virustotal.com/.
Alienware OTX https://otx.alienvault.com/
IBM X-Force https://exchange.xforce.ibmcloud.com/
If you do not have an API key for any of these providers simply remove their name from the providers list in our lookup_iocs command.
Alert command line - Occurrence on other hosts in workspace
Understanding where else a command line is being run in an environment can give us a good idea of the scope of a security incident, or help us determine whether activity is malicious or expected.
To get a sense of whether the alert process is something that is occuring on other hosts, run this section.
If at this point you wish to investigate a particular host in detail you can use the cells below or you can switch to our Host Investigation Notebooks that provide a deep dive capability for Windows and Linux hosts.
Host Logons
This section retrieves the logon events on the host in the alert.
You may want to use the query times to search over a broader range than the default.
If you wish to investigate a specific host in detail you can use the cells below or switch to our Account investigation notebook.
Alert Logon Account
This returns the account associated with the alert being investigated.
All Host Logons
Since the number of logon events may be large and, in the case of system logons, very repetitive, we use clustering to try to identity logons with unique characteristics.
In this case we use the numeric score of the account name and the logon type (i.e. interactive, service, etc.). The results of the clustered logons are shown below along with a more detailed, readable printout of the logon event information. The data here will vary depending on whether this is a Windows or Linux host.
Highest and lowest number of logon types by Account
Failed Logons
Failed logons can provide a valuable source of data for investigation so we also want to look at failed logons during the period of our investigation.
Appendices
Available DataFrames
Saving Data to CSV
To save the contents of a pandas DataFrame to an CSV use the following syntax
Saving Data to Excel
To save the contents of a pandas DataFrame to an Excel spreadsheet use the following syntax
Configuration
msticpyconfig.yaml configuration File
You can configure primary and secondary TI providers and any required parameters in the msticpyconfig.yaml file. This is read from the current directory or you can set an environment variable (MSTICPYCONFIG) pointing to its location.
To configure this file see the ConfigureNotebookEnvironment notebook