System Monitor (Sysmon) is one of the most common add-ons for Windows logging. With Sysmon, you can detect malicious activity by tracking code behavior and network traffic. Sysmon is part of the Sysinternals package and is owned by Microsoft. Sysmon can be used for collecting more logs.

Blog information:

Blog published: October 10, 2022
Blog latest updated: January 26, 2023

What is Sysmon

Sysmon makes it possible to monitor activities on the Windows operating system in detail. It provides detailed information on the created network connections, file changes, registry activities, or created processes. Sysmon can be used in combination with Defender for Endpoint. Microsoft is not logging all events with Defender for Endpoint – with the addition of Sysmon, it is possible to ingest more events and add additional events for investigation.

Sysmon is free and part of the Sysinternals software package. Sysmon itself is free; data ingestion in Sentinel can lead to significant costs for all data. Be careful with the amount of data and used configuration.

View the previous blog based on the MMA method. This new blog explains the AMA agent deployment for Sysmon with the new ASIM parser support and contains additional information focused on the available configuration files.

Do we need Sysmon on all systems?

Sysmon deployment can be scoped in the environment. Ideally ingest additional events for the Tier-0 servers and business-critical servers first. When starting small; the scope can be increased easily and tracking ingestion cost/ performance is easily possible to fine-tune configurations to save cost and ingestion of events. Even when Sysmon is locally installed without ingestion in Sentinel there is still a huge benefit.

Microsoft Defender for Servers P2 provides a 500MB/server/day benefit for log ingestion in Log Analytics. The ingestion allowance benefit will result in a reduction of your security analytics cost for servers in Sentinel. When Defender for Servers P2 is enabled; there is support for the SysmonEvent table. The following tables are supported:

  • SecurityAlert
  • SecurityBaseline
  • SecurityBaselineSummary
  • SecurityDetection
  • SecurityEvent
  • WindowsFirewall
  • SysmonEvent
  • ProtectionStatus
  • Update (when the Update Management solution isn’t running)
  • UpdateSummary (when the Update Management solution isn’t running)

IMPORTANT: Always check which table is used for ingesting Sysmon data. There is some difference between the available connectors AMA/ DCR/ MMA. SysmonEvent is not always the table that is used for ingestion.

More Sysmon information: Sysinternals – Sysmon | Microsoft Docs

Install Sysmon

System Monitor (Sysmon) is a Windows system service and device driver. For using Sysmon we need to have the following components:

  • Sysmon installer
  • Sysmon configuration file

Sysmon Installer

Sysmon can be downloaded directly from the Microsoft site Use the Sysmon(64).exe file for further deployment.

For large-scale deployment use GPO, PowerShell, Automation, MECM, or other existing management toolings for deployment packages, it is not different from other applications. Sysmon installer supports different types of parameters for silent installations.

Configuration file

Sysmon needs to be installed in combination with the configuration file. Currently, there are multiple Sysmon configuration files available. Let’s discuss the configuration file more in-depth in the next section.

Silent installation + configuration file

sysmon64.exe -accepteula -i sysmonconfiguration.xml

Validate Sysmon

##Show the configuration schema
sysmon -s

##Dump the current configuration
sysmon -c

Where are Sysmon’s Logs located?

Sysmon creates its own event log channel under “Applications and Services Logs”. For viewing all Sysmon logs:

  • Open “eventvwr.msc”
  • On the left panel, open “Applications and Services”
  • Open “Microsoft”
  • Open “Windows”
  • Open “Sysmon” – Operation Log

When the Sysmon service is installed successfully, all log files should be available in the event location.

Event ID example:

PowerShell can be used for viewing the first 10 results

Viewing the first 10 Sysmon events in “Microsoft-Windows-Sysmon/Operational” via PowerShell

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | Select-Object -First 10

Configuration file

The configuration file is important. In simple terms; the configuration file used in Sysmon configures how Sysmon works and which events are traced. There are multiple options;

  • Create your own configuration files
  • Use community profiles

Important: Use the Sysmon configuration file based on the needs of the security team/SOC. When using Defender for Endpoint (MDE) – there is already a set of logging available in Defender for Endpoint. Always check which events are needed – avoid too much ingestion in Sentinel. The costs can increase very quickly when ingesting Sysmon logs.

The Sysmon community is great – the following configuration files are the most common/used examples that can be used;

SwiftOnSecurity: Generic Sysmon configuration file template with default high-quality event tracing. This file can be used as a great starting point for system change monitoring.

Configuration Repo: SwiftOnSecurity | Github

Olafhartong – Sysmon modular: Sysmon modular is a great configuration repository for Sysmon. All shared configurations can be used as a starting point. For each environment, it is heavily recommended to fine-tune the configurations. The sysmonconfig.xml is a balanced configuration.

Olaf did some awesome work with the MDE augment configuration file sysmonconfig-mde-augmentation.xml. The configuration file is created to fill in the gaps of Microsoft Defender for Endpoint (MDE).

Configuration Repo: Sysmon-modular | Github

Neo23x0 – Sysmon-config

Forked from the SwiftOnSecurity Sysmon config with additional items. Since version Sysmon v14 basic blocking rules can be used.

Configuration Repo: Neo23x0 / Sysmon Config | Github

Deploy Sysmon using GPO

Sysmon can be deployed using all common management/ deployment toolings. Important to make sure there is some logic for validating the latest version of the configuration file. To make sure all systems run the same version of Sysmon and have the same up-to-date configuration.

Create a network share and give “Domain Computers” read access. Place the Sysmon installation file and configuration file in the shared folder.

Important: Assign permissions carefully; so, attackers are not able to replace the Sysmon installer.

When correct the shared folder contains the following files:

  • Sysmon
  • Sysmon64
  • Sysmonconfigurationfile

Now it is needed to configure the Group Policy to install Sysmon with the correct configuration. Create a new GPO with a scheduled task – Immediate Task (At least Windows 7).

In the task window, go to the General tab and click Change User or Group. Type SYSTEM and then click Check names. When correct the name NT AUTHORITY\SYSTEM appears. Select Run whether user is logged on or not.

Go to the Actions tab and create a new program. Select action; Start a program. Enter the .exe location in the program/script field.

Arguments are needed for the additional parameters and full path location of the sysmonconfigurationfile.xml.

Example:

  • Program/script: \\networkshare\Sysmon\Sysmon64.exe
  • Add arguments: -accepteula -i \\networkshare\Sysmon\Sysmonmonconfigurationfile.xml

Deploy Azure Monitor Agent

Microsoft migrates more features directly from the Microsoft Monitoring Agent (MMA) to the new Azure Monitor Agent (AMA). This blog explains the method for using Sysmon in combination with the Azure Monitor Agent (AMA). Azure Monitor Agent (AMA) will replace the Log Analytics agent in the future. The legacy Log Analytics agent will be retired on 31 August 2024.

For the Azure Monitor Agent some requirements need to be in place;

Device typeSupported?Installation methodAdditional information
Windows 10, 11 desktops, workstationsYesClient installer Installs the agent using a Windows MSI installer
On-premises serversNoVirtual machine extension (with Azure Arc agent)Installs the agent using Azure extension framework, provided for on-premises by installing Arc agent

Currently, there are two methods for installing the Azure Monitor agent. For Azure and on-premises servers (Azure Arc) it is recommended to use the Virtual machine extension which can be deployed via Defender for Cloud, PowerShell, Microsoft Sentinel, or Azure Policy.

Azure Arc is explained in the following blog post; Microsoft Defender for Endpoint series – Onboard using Azure Arc – Part3C

Deployment via Sentinel

The extension can be deployed via Sentinel with the use of the following connectors:

  • Windows Security Events via AMA
  • Windows Forwarded Events

Based on the logs the Windows Security Events via AMA is recommended for Windows Security and AppLocker logs. Events from other Windows logs won’t be parsed properly.

For Sysmon we use the Windows Forwarded Events connector in Sentinel. For configuring the connector:

  • Go to Microsoft Sentinel -> Data connectors -> Windows Forwarded Events (Preview)
  • Click on open connector page
  • Click on +Create data collection rule
  • Fill in the rule name+subscription and resource group of the Sentinel workspace.
  • Add new resources with the Add resource(s) button. The Azure Monitor Agent will be automatically installed on these machines.
  • Select the Resource group/VMs. For on-premises servers, Azure Arc is the requirement. After onboarding Azure Arc the device is visible in the selection of the machines. Click Apply for deploying the extension and DCR rule.
  • Now we need to create the DCR rules for collecting Sysmon events. Select Custom for specifying a custom set of rules/ events with the use of DCR.
  • Add for example the following events log location; Microsoft-Windows-Sysmon/Operational!*

NOTE: The rule can be changed for ingesting only a specific set of events.

Agent for clients

The Windows client installer is designed for Windows 10,11 workstations. In comparison with the extension, there are some differences. Comparison with virtual machine extension | Microsoft Docs

The machine must be domain joined to an Azure AD tenant (AADj or Hybrid AADj machines). It is needed to fetch the Azure AD device tokens for the authentication and data collection rules sync from Azure; this is only possible when the device is AADJ or HAADJ joined.

Installation command:

 msiexec /i AzureMonitorAgentClientSetup.msi /qn

When installing the Azure Monitor Agent on Windows 10/11 the following message is visible;

For Windows 10/11 hosted in Azure or Windows Cloud PC, the VM extension is the only option for now. Use the extension; AzureMonitorWindowsAgent

For the AzureMonitorAgentClientSetup.msi it is required to create and associate a ‘Monitored Object’ for the Azure AD tenant within Azure Resource Manager (ARM). This feature is currently is only limited to the AzureAD tenant scope (devices part of the tenant and running the AzureMonitorWindowsAgent)

Image source: Microsoft

For mapping the Monitored Object the following steps are required:

  • Assign the ‘Monitored Object Contributor’ role to the operator
  • Create Monitored Object
  • Associate DCR to Monitored Object

Microsoft created a couple of REST API and PowerShell examples.

After connecting the Monitored Object devices send data into the Log Analytics workspace which is used as a destination in the data collection rule. The device is part of the heartbeat in the Log Analytics workspace;

More information for the AzureMonitorAgentClientSetup.msi and additional configuration is available here.

Logs in Sentinel

After some time the extension is deployed and the DCR configuration is pushed. Sysmon events are ingested in the WindowsEvent table; when using the Windows Forwarded Events table.

Data parser/ ASIM

Data is not parsed; for visibility, the ASIM parser can be used for Sysmon. Currently, there are multiple parsers available. View here the ASIM Sysmon for Windows parser.

  • Provider: Microsoft-Windows-Sysmon
  • Channel: Microsoft-Windows-Sysmon/Operational

Raw event data example:

{"RuleName":"technique_id=T1543,technique_name=Service Creation","EventType":"SetValue","UtcTime":"2022-10-09T21:37:23.7550000Z","ProcessGuid":"{68ac79d2-672d-6341-2d00-000000001300}","ProcessId":"2080","Image":"C:\\Windows\\system32\\svchost.exe","TargetObject":"HKLM\\System\\CurrentControlSet\\Services\\W32Time\\Config\\LastKnownGoodTime","Details":"QWORD (0x01d8dc27-0x518e88f2)","User":"NT AUTHORITY\\LOCAL SERVICE"}

What is ASIM

ASIM is a framework that provides normalization to Microsoft Sentinel. It includes the following parts:

  • Normalized schemas
  • Parsers
  • Normalized content

More information: Normalization and the Advanced Security Information Model (ASIM)

Sentinel ASIM parsers

As part of the default Functions, there are some Asim Sysmon parsers available. For viewing the existing functions/ parsers open the Sentinel query experience for new queries.

Click in the left blade on functions; the following Asim parsers are by default visible for Sysmon-related events in the Microsoft Sentinel folder

Available Sysmon parsers ( Tip; search for Sysmon)

  • _ASim_Dns_MicrosoftSysmonV03
  • _ASim_NetworkSession_LinuxSysmonV02
  • _ASim_NetworkSession_LinuxSysmonV03
  • _Im_Dns_MicrosoftSysmonV03
  • _Im_NetworkSession_LinuxSysmonV02
  • _Im_NetworkSession_LinuxSysmonV03

Asim Sysmon parsers can be founded here; Github

Parsed result part of the _ASim_Dns_MicrosoftSysmonV03:

Of course; these are just a couple of Asim Sysmon parsers for specific events/ use cases. More parsers need to be created for specific events or Sysmon versions deployed. Tip; follow the community – there are awesome public resources available for Sysmon.

Sources

Microsoft:

Community: