Azure Sentinel and Sysmon 4 B!ue T3amer$

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 Azure Sentinel and Sysmon 4 B!ue T3amer$.

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 the relevant information. We must expand how we collect logs and if it is advanced event log management or PowerShell advanced logging and others.

In the recent blog post, we saw how PowerShell advanced logging could provide us useful information. With this blog post, we can see how Sysmon can offer more capabilities to the incident response with Azure 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 it generates 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 useful 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 while 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 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 full 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, Application server, and whether it’s on a VM on Azure or any cloud provider. Once Sysmon is installed, we can configure Azure Sentinel to collect information from the relevant servers.

The way to achieve Sysmon with Azure 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 writing 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

Azure Sentinel and Sysmon Configuration

Connecting servers to Azure 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.

If you’re working with the Security Event, the agent can be downloaded via the Security Event connector.

TIP: It’s recommended to work with common Security Events alongside the Sysmon

Azure Sentinel Sysmon Queries

Once Sysmon is installed and configured on the Windows servers and configured on the Azure 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 of 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

The Sysmon prase query

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 including 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 full 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 main 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 much useful 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.

Azure Sentinel Incident

Like any attack, we must create an incident and 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.

More about Azure Sentinel