Skip to main content
Skip table of contents

Installing and Configuring Sysmon for Windows

This document describes how to install sysmon in Windows. It will configure sysmon to log messages for effective security monitoring.

What is Sysmon?

Sysmon is part of the Sysinternals suite and is useful for extending the default Windows logs with higher-level monitoring of events and process creations. Sysmon contains detailed information about process creations, networks connections, and file changes.

More Information on Sysmon - Windows Sysinternals | Microsoft Docs

Interesting data available:

Process Information
Network connections tracking
Drivers and DLL loading
WMI monitoring
File Events
Registry Operations
DNS Queries

olafhartong did publish a nice map of interesting data that we can gather from sysmon.

Sysmon-graph.png

Sysmon Event ID’s

  • Event ID 1: Process creation
  • Event ID 2: A process changed a file creation time
  • Event ID 3: Network connection
  • Event ID 4: Sysmon service state changed
  • Event ID 5: Process terminated
  • Event ID 6: Driver loaded
  • Event ID 7: Image loaded
  • Event ID 8: CreateRemoteThread
  • Event ID 9: RawAccessRead
  • Event ID 10: ProcessAccess
  • Event ID 11: FileCreate
  • Event ID 12: RegistryEvent (Object create and delete)
  • Event ID 13: RegistryEvent (Value Set)
  • Event ID 14: RegistryEvent (Key and Value Rename)
  • Event ID 15: FileCreateStreamHash
  • Event ID 16: ServiceConfigurationChange
  • Event ID 17: PipeEvent (Pipe Created)
  • Event ID 18: PipeEvent (Pipe Connected)
  • Event ID 19: WmiEvent (WmiEventFilter activity detected)
  • Event ID 20: WmiEvent (WmiEventConsumer activity detected)
  • Event ID 21: WmiEvent (WmiEventConsumerToFilter activity detected)
  • Event ID 22: DNSEvent (DNS query)
  • Event ID 23: FileDelete (File Delete archived)
  • Event ID 24: ClipboardChange (New content in the clipboard)
  • Event ID 25: ProcessTampering (Process image change)
  • Event ID 26: FileDeleteDetected (File Delete logged)
  • Event ID 255: Error

Each Event Id's emit different fields, olafhartong publish a very good Sysmon cheat sheet

Limitation

This knowledge base as well as the files and rules only applies to Sysmon 13 and above, Sysmon below 13 will not be completely supported although will still work.

Setting up Sysmon on Windows

Pre-requisites

Note: We recommend using Armor Security Sysmon rules but you can also create your own and or download the ones that are readily available like BlueTeamsLabs (useful for the Sentinel workbook)

Installation

For installing Sysmon use the installer from the pre-requisite section. Once Sysmon is installed, we can configure the Microsoft Sentinel connector to collect the Sysmon events from the machines.

SHELL
# sysmon.exe -accepteula -i [sysmon rules xml]
sysmon.exe -accepteula -i quantum-sysmonconfig.xml

Once Sysmon is installed and starts logging actions, you can find the event log by opening the local Event Viewer and going to the event path: Windows Logs – Applications and Services Logs – Microsoft – Windows -Sysmon

Onboarding to Microsoft Sentinel

Pre-requisites

Permission: - Workspace - read/write permission

  • Workspace data sources - read/write permission

Id/Token - Workspace ID

  • Primary key

Installation of Windows Agent into the client

Microsoft Monitoring Agent collects the data from the machines. With the Microsoft Monitoring Agent it is possible to collect logs from a machine and push it into the Log Analytics workspace (Sentinel).

Multiple ways are available to connect the server with the Log Analytics gateway. In this case the explanation of the Microsoft Monitoring Agent event collector. From the Security Event connector page, it is possible to download the Windows Agent or direct from the Log Analytics workspace view.

One of the easiest way to onboard is to use the Log analytics agent - Download Windows Agent (64 bit)

Or you can explore this from Sentinel under Log Analytics. 1. Go to Azure Portal

  1. Search for Log Analytics workspace
  2. Open the created or existing Log Analytics workspace where you want to onboard
  3. Open Agent Management
  4. Click on Windows servers

Configure Sentinel Sysmon Event’s

It is required to configure the Agent configuration for collecting the Sysmon event log. For configuring the Sysmon events: Or you can explore this from Sentinel under Log Analytics. 1. Go to Azure Portal

  1. Search for Log Analytics workspace
  2. Open the created or existing Log Analytics workspace where you are onboarding
  3. Open Agents configuration
  4. Click on Add Windows event logs
  5. By default Sysmon is not listed, just type the following Microsoft-Windows-Sysmon/Operational
  6. Ensure that Error, Warning and Information are checked
  7. Apply the configuration

Verifying your setup

It would take time for the first sysmon to appear in Sentinel, but if everything works correctly you can use the query below to check if there are any logs received

Event
| where Source == 'Microsoft-Windows-Sysmon'
| limit 10

Example of a specific event check, Example for Event ID: 1 (Process Creation) “` Event | where Source == ‘Microsoft-Windows-Sysmon’ | where EventID == 1 | project TimeGenerated, Computer, EventID, RenderedDescription | limit 100


## Armor Security Specific Task

### Sysmon Parser

In order for us to user the Sysmon data with detection rules as well as workbooks it is required for us to parse the data, additionally to facilitate common queries and uniformity across different events and logs, Armor Security has created a custom Sysmon parser that our client can use.

Sysmon_Security | where Source == ‘Microsoft-Windows-Sysmon’ | limit 10


### Armor Detection Rules

Based on the Armor Sysmon parsed data, Armor has deployed detection rules that would help detecting and or mitigating attacks. Armor has created a couple of ioc and threat hunting rules for Sysmon.

You can see all the rules that are deployed from Sentinel Analytics 1. Go to [Azure Portal](http://portal.azure.com/)
2. Search for `Sentinel`
3. Open the existing `Workspace`
4. On the side bar click on `Analytics`
5. This view would show you a list of detection rules that has been deployed like `Severity`, `Names`, `Enabled`,
   `Tactics`, `Techniques` and some more information.

### Triggering a rule

From the previous section, we have talked about there are 2 types of rules that we are deploying 1. IOC - These are rules that are confirmed malicious. If you see this rules alerts then it means a red flag.
2. Threat-Hunting - These rules are created for research and or audit purpose. It does not mean that the alert are malicious.

If we want to test the trigger we can check on the rules that are deployed as `Threat-Hunting`. Please note that it is possible that threat-hunting rules are not deployed on your environment hence in your case you can create a canary rule.

To create your canary rule: 1. Go to [Azure Portal](http://portal.azure.com/)
2. Search for `Sentinel`
3. Open the existing `Workspace`
4. On the side bar click on `Analytics`
5. Click the the `+ Create` button
6. Set the details
- Name: Test Detection Rule
- Status: Enabled
- Rule Query:

Sysmon_Security | where ((TargetProcessName endswith ‘powershell.exe’) and

TargetProcessCommandLine contains 'Test-NetConnection' and
TargetProcessCommandLine contains '-TraceRoute' and
TargetProcessCommandLine contains 'test-sentinel-process-alert.com')

”`

  • Run query every: 12 Hours
  • Lookup data from the last: 12 Hours
  1. Create rule

Once you created a rule, you can test this in one of the clients that has been on-boarded: 1. Open a powershell prompt

  1. Run the command: powershell -command "Test-NetConnection test-sentinel-process-alert.com -TraceRoute"

This should create an entry into Sentinel and in 12 hours would create an alert (you can shorten this time).

Explanation of the commands

The command would use powershell commands to test the connection and do a trace route to test-sentinel-process-alert.com which is a non-existent site but would still generate an event that would be forwarded to Sentinel.

  • Test-NetConnection - Displays diagnostic information for a connection.
  • -TraceRoute - Indicates that Tracert runs to test connectivity to the remote host.

Sources and Additional Reading

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.