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 Queriesolafhartong did publish a nice map of interesting data that we can gather from sysmon.
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.
# sysmon.exe -accepteula -i [sysmon rules xml]
sysmon.exe -accepteula -i quantum-sysmonconfig.xmlOnce 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
- Search for
Log Analytics workspace - Open the created or existing
Log Analytics workspacewhere you want to onboard - Open
Agent Management - 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
- Search for
Log Analytics workspace - Open the created or existing
Log Analytics workspacewhere you are onboarding - Open
Agents configuration - Click on
Add Windows event logs - By default
Sysmonis not listed, just type the followingMicrosoft-Windows-Sysmon/Operational - Ensure that
Error,WarningandInformationare checked - 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 10Example 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
- 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
- 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.