Microsoft Sentinel and Sysmon 4 Blue Teamers
Recently, there have been massive cyberattacks against cloud providers and on-premises environments, the most recent of which is the attack and exploitation of vulnerabilities against Exchange servers – The HAFNIUM. This post focus on Microsoft Sentinel and Sysmon 4 Blue Teamers
Recent attacks require us to increase attention alongside tools to provide us with advanced visibility and investigative options. The recent attack on Exchange servers has shown that the richer information we have, the more advanced investigation we can achieve.
Event Viewer alone cannot provide us with the relevant information. We must expand how we collect logs and if it is advanced event log management or PowerShell advanced logging and others.
We saw how PowerShell advanced logging could provide us with the helpful information in the recent blog post. This blog post shows how Sysmon can offer more capabilities to incident response with Microsoft Sentinel.
Sysmon, in a nutshell
Sysinternal System Monitor (Sysmon) is a Windows system service, and device driver that remains resident across system reboots to monitor and log system activity to the Windows event log once installed on a system. It provides detailed information about process creations, network connections, and changes to file creation time.
By collecting the events generated using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network.
More about Sysmon – Windows Sysinternals | Microsoft Docs
What are the Capabilities of Sysmon? In a nutshell, readable and helpful process information. You can get valuable details that are not found in the raw Windows log, but most significantly, these fields, for example:
- Process id
- Parent process-id
- File image names
- Hash of file image
- Process command line
- Parent process command line
Sysmon installs as a device driver and service. Its key advantage is that it takes log entries from multiple log sources, correlates the information, and places the resulting entries into one folder in the Event Viewer.
For example, this particular command line should trigger some suspicions. Using cmd.exe to run another command, then redirecting the output to a strangely named file, is the stuff of some C2. It’s a way to create a shell using specific services.
Sysmon Highlights
- Sysmon includes the ability to filter events before they are written to the Event Log.
- You can build (or download) configuration files.
- They make it easier to deploy a preset configuration and filter captured events.
- You can log network events from processes named “specific.exe” or locate them in C:\Temp, drivers not signed by Microsoft, etc.
- It’s up to you to determine how much data you want to include.
- Sysmon configuration file
- install: sysmon -i -accepteula c:\SysmonConfig.xml
- update: sysmon -c c:\SysmonConfig.XML
- use Psexec or PowerShell during an IR
- Each event is specified using its tag
- To see all tags, dump the entire configuration schema:
- sysmon -s
- on the match can be “include” or “exclude.”
- Include and exclude refer to filter effect
Sysmon Event ID Numbers
Install Sysmon
The first thing is to install Sysmon on relevant servers, such as Domain Controllers, Exchange servers, and Application servers, whether on a VM on Azure, any cloud provider, or any other supported server. Once Sysmon is installed, we can configure Microsoft Sentinel to collect information from the relevant servers.
The way to achieve Sysmon with Microsoft Sentinel is straightforward and can be done by the following actions.
- Download Sysmon and install it on the relevant servers
- Make sure the Sysmon services are up and running and write logs to the event viewer.
- Make sure to update the configuration of an installed Sysmon with the command: Sysmon64.exe -c c:\Windows\sysmonconfig.XML
TIP: Download the Sysmon config file from here and monitor additional apps and exe
Sysmon Configuration
Connecting servers to Microsoft Sentinel occurs via dedicated agents (non-Azure Windows Machine). We need to install the Agent together with the workspace ID and its primary key on the server-side.
The agent can be downloaded via the Security Event connector if you’re working with the Security Event.
TIP: It’s recommended to work with common Security Events alongside the Sysmon
Sysmon Queries
Once Sysmon is installed and configured on the Windows servers and configured on the Microsoft Sentinel, we can run queries for Sysmon. The query can be run with the commands below:
Check basic Sysmon event.
Event
| where Source == “Microsoft-Windows-Sysmon”
Check for important events.
Event
| where Source == “Microsoft-Windows-Sysmon”
| where EventID in (11, 12, 17)
| project TimeGenerated, Computer, EventID, RenderedDescription
You might notice that not all information is available right away in the form of columns. Instead, the real important data is stored inside the two columns “ParameterXml” and “EventData”:
KQL queries can parse those columns via the query below:
Event
| where Source == “Microsoft-Windows-Sysmon”
| extend RenderedDescription = tostring(split(RenderedDescription, “:”)[0])
| extend EventData = parse_xml(EventData).DataItem.EventData.Data
| mv-expand bagexpansion=array EventData
| evaluate bag_unpack(EventData)
| extend Key=tostring([‘@Name’]), Value=[‘#text’]
| evaluate pivot(Key, any(Value), TimeGenerated, Source, EventLog, Computer, EventLevel, EventLevelName, EventID, UserName, RenderedDescription, MG, ManagementGroupName, Type, _ResourceId)
| parse RuleName with * ‘technique_id=’ TechniqueId ‘,’ * ‘technique_name=’ TechniqueName
| order by TimeGenerated desc
Sysmon IR
Sysmon Events
- The service logs events immediately.
- The driver installs as a boot-start driver to capture activity from early in the boot process.
- Sysmon does not replace your existing event logs.
Important events for Incident Response
- Event ID 11: FileCreate – Useful for monitoring autostart locations and available places malware drops during initial infection.
- Event ID 12: RegistryEvent – Useful for monitoring changes to Registry autostart locations or specific malware registry modifications.
- Event ID 17: PipeEvent – Malware usually uses named pipes for inter-process communication.
The Events – 4688
- Sysmon events can detect new EXEs and DLLs.
- Can detect ransomware such as Petya or Wannacry, which used SMB to spread.
- Log event is produced every time an EXE loads as a new process.
- Known EXE and compare each 4688 against that list and identify new actions, like Petya’s EXEs, that run on your network.
- The only problem with using 4688 is it’s based on the EXE name and includes the path.
- What happens if the attacker uses a name similar to that of a known file
- Sysmon event ID 1 is logged simultaneously as 4688, but it also provides the EXE hash.
- If an attacker replaces a known EXE, the hash will change.
- Comparison against known hashes will fail, and detecting a new EXE executing for the first time in your environment.
- Logs process creation with a complete command line for both current and parent processes
- Records the hash of process image files using SHA1, MD5 or SHA256
- Includes a process GUID in process create events to allow for correlation of events even when Windows reuses process IDs
- Optionally logs network connections, including each connection’s source process, IP addresses, port numbers, hostnames, and port names.
Use Cases
The primary use cases with Sysmon hunting:
- Productivity App (e.g., Word, Excel, PowerPoint, Outlook) launches cmd.exe or powershell.exe
- Abnormal parent of svchost.exe
- Whoami.exe running
- net.exe use
- Webshell
- Data exfiltration
- Mimikatz
- Process injection
Sysmon Simulation
You can simulate to check how the Sysmon event logs are working with many tools, and with this example, I’m using the DeepBlueCLI.
The DeepBlueCLI can be downloaded from GitHub > sans-blue-team/DeepBlueCLI (github.com), and once you’ve downloaded it, you can run with the scenarios below.
When I ran the DeepBlueCLI tool with many scenarios, I received helpful information from Azure Sentinel. Once I started with the hunting phases, I saw many indicators with File created, Process Create, and Network connection detected, including C2 connections.
Incident
Like any attack, we must create an incident, raise an alert when the attack appears on servers, and provide a way to investigate with all indicators from Sysmon. With this example, the query includes the Sysmon parse query and the new entity mapping for account, host, and files.
