Let's dive into the world of Sigma rules using a sample named shell.exe (a renamed version of ) residing in the C:\Samples\YARASigma directory of this section's target as an illustration. We want to understand the process behind crafting a Sigma rule, so let's get our hands dirty.
After executing shell.exe as follows, we collected the most critical events and saved them as lab_events.evtx inside the C:\Events\YARASigma directory of this section's target.
The process created by shell.exe (mimikatz) will try to access the process memory of lsass.exe. The system monitoring tool was running in the background and captured this activity in the event logs (Event ID ).
First off, Sysmon Event ID 10 is triggered when a process accesses another process, and it logs the permission flags in the GrantedAccess field. This event log contains two important fields, TargetImage and GrantedAccess. In a typical LSASS memory dumping scenario, the malicious process needs specific permissions to access the memory space of the LSASS process. These permissions are often read/write access, among other things.
Now, why is 0x1010 crucial here? This hexadecimal flag essentially combines PROCESS_VM_READ (0x0010) and PROCESS_QUERY_INFORMATION (0x0400) permissions. To translate that: the process is asking for read access to the virtual memory of LSASS and the ability to query certain information from the process. While 0x0410 is the most common GrantedAccess flag used for reading LSASS memory, 0x1010 implies both reading and querying information from the process and is also frequently observed during credential dumping attacks.
So how can we weaponize this information for detection? Well, in our security monitoring stack, we would configure Sysmon to flag or alert on any Event ID 10 where the TargetImage is lsass.exe and GrantedAccess is set to 0x1010.
A Sigma rule that checks for the abovementioned conditions can be found below.
title: LSASS Access with rare GrantedAccess flag
status: experimental
description: This rule will detect when a process tries to access LSASS memory with suspicious access flag 0x1010
date: 2023/07/08
tags:
- attack.credential_access
- attack.t1003.001
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|endswith: '0x1010'
condition: selection
Suppose that we wanted to convert our Sigma rule into a PowerShell (Get-WinEvent) query. This could have been accomplished with the help of sigmac as follows.
Let's adjust the Get-WinEvent query above by specifying the .evtx file that is related to LSASS access by another process (lab_events.evtx inside the C:\Events\YARASigma directory of this section's target) and see if it will identify the Sysmon event (ID 10) that we analyzed at the beginning of this section.
But let's not stop there - remember, false positives are the enemy of effective security monitoring.
We should also cross-reference the SourceImage (the process initiating the access) against a list of known, safe processes that commonly interact with LSASS.
If we see an unfamiliar or unusual process trying to read LSASS with a GrantedAccess that ends with 10, 30, 50, 70, 90, B0, D0, F0, 18, 38, 58, 78, 98, B8, D8, F8, 1A, 3A, 5A, 7A, 9A, BA, DA, FA, 0x14C2, and FF (these suffixes come from studying the GrantedAccess values that various LSASS credential dumping techniques require), that's a red flag, and our incident response protocol should kick in.
Especially, if the SourceImage resides in suspicious paths containing, \Temp\, \Users\Public\, \PerfLogs\, \AppData\, \htb\ etc. that's another red flag, and our incident response protocol should kick in.
A more robust version of the Sigma rule we created taking the above points into consideration.
Notice how the condition filters out false positives (selection and not 1 of filter_optional_*).
Example 2: Multiple Failed Logins From Single Source (Based on Event 4776)
This event occurs only on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative.
If a credential validation attempt fails, you'll see a Failure event with Error Code parameter value not equal to 0x0.
A valid Sigma rule to detect multiple failed login attempts originating from the same source.
title: Failed NTLM Logins with Different Accounts from Single Source System
id: 6309ffc4-8fa2-47cf-96b8-a2f72e58e538
related:
- id: e98374a6-e2d9-4076-9b5c-11bdb2569995
type: derived
status: unsupported
description: Detects suspicious failed logins with different user accounts from a single source system
author: Florian Roth (Nextron Systems)
date: 2017/01/10
modified: 2023/02/24
tags:
- attack.persistence
- attack.privilege_escalation
- attack.t1078
logsource:
product: windows
service: security
detection:
selection2:
EventID: 4776
TargetUserName: '*'
Workstation: '*'
condition: selection2 | count(TargetUserName) by Workstation > 3
falsepositives:
- Terminal servers
- Jump servers
- Other multiuser systems like Citrix server farms
- Workstations with frequently changing users
level: medium
Sigma Rule Breakdown:
logsource: This section specifies that the rule is intended for Windows systems (product: windows) and focuses only on Security event logs (service: security).
detection: selection2 is essentially the filter. It's looking for logs with EventID 4776 (EventID: 4776) regardless of the TargetUserName or Workstation values (TargetUserName: '*', Workstation: '*'). condition counts instances of TargetUserName grouped by Workstation and checks if a workstation has more than three failed login attempts.
Sigma Rule Development Resources
As you can imagine, the best Sigma rule development resource is the official documentation, which can be found at the following links.
The following series of articles is the next best resource on Sigma rule developement.
Q & A
1) Using sigmac translate the "C:\Tools\chainsaw\sigma\rules\windows\builtin\windefend\win_defender_threat.yml" Sigma rule into the equivalent PowerShell command. Then, execute the PowerShell command against "C:\Events\YARASigma\lab_events_4.evtx" and enter the malicious driver as your answer. Answer format: _.sys
