# Developing Sigma Rules
## Manually Developing a Sigma Rule
### **Example 1: LSASS Credential Dumping**
Let's dive into the world of Sigma rules using a sample named `shell.exe` (a renamed version of [mimikatz](https://en.wikipedia.org/wiki/Mimikatz)) 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 [Sysmon](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon) was running in the background and captured this activity in the event logs (Event ID [10](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon#event-id-10-processaccess)).
```
C:\Samples\YARASigma>shell.exe
.#####. mimikatz 2.2.0 (x64) #19041 Sep 19 2022 17:44:08
.## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
## / \ ## /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
## \ / ## > https://blog.gentilkiwi.com/mimikatz
'## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com )
'#####' > https://pingcastle.com / https://mysmartlogon.com ***/
mimikatz # privilege::debug
Privilege '20' OK
mimikatz # sekurlsa::logonpasswords
---SNIP---
Authentication Id : 0 ; 100080 (00000000:000186f0)
Session : Interactive from 1
User Name : htb-student
Domain : DESKTOP-VJF8GH8
Logon Server : DESKTOP-VJF8GH8
Logon Time : 8/25/2023 2:17:20 PM
SID : S-1-5-21-1412399592-1502967738-1150298762-1001
msv :
[00000003] Primary
* Username : htb-student
* Domain : .
* NTLM : 3c0e5d303ec84884ad5c3b7876a06ea6
* SHA1 : b2978f9abc2f356e45cb66ec39510b1ccca08a0e
tspkg :
wdigest :
* Username : htb-student
* Domain : DESKTOP-VJF8GH8
* Password : (null)
kerberos :
* Username : htb-student
* Domain : DESKTOP-VJF8GH8
* Password : (null)
ssp :
credman :
cloudap :
Authentication Id : 0 ; 100004 (00000000:000186a4)
Session : Interactive from 1
User Name : htb-student
Domain : DESKTOP-VJF8GH8
Logon Server : DESKTOP-VJF8GH8
Logon Time : 8/25/2023 2:17:20 PM
SID : S-1-5-21-1412399592-1502967738-1150298762-1001
msv :
[00000003] Primary
* Username : htb-student
* Domain : .
* NTLM : 3c0e5d303ec84884ad5c3b7876a06ea6
* SHA1 : b2978f9abc2f356e45cb66ec39510b1ccca08a0e
tspkg :
wdigest :
* Username : htb-student
* Domain : DESKTOP-VJF8GH8
* Password : (null)
kerberos :
* Username : htb-student
* Domain : DESKTOP-VJF8GH8
* Password : HTB_@cademy_stdnt!
ssp :
credman :
cloudap :
---SNIP---
```
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.
```yaml
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.
```powershell-session
PS C:\Tools\sigma-0.21\tools> python sigmac -t powershell 'C:\Rules\sigma\proc_access_win_lsass_access.yml'
Get-WinEvent | where {($_.ID -eq "10" -and $_.message -match "TargetImage.*.*\\lsass.exe" -and $_.message -match "GrantedAccess.*.*0x1010") } | select TimeCreated,Id,RecordId,ProcessId,MachineName,Message
```
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.
```powershell-session
PS C:\Tools\sigma-0.21\tools> Get-WinEvent -Path C:\Events\YARASigma\lab_events.evtx | where {($_.ID -eq "10" -and $_.message -match "TargetImage.*.*\\lsass.exe" -and $_.message -match "GrantedAccess.*.*0x1010") } | select TimeCreated,Id,RecordId,ProcessId,MachineName,Message
TimeCreated : 7/9/2023 7:44:14 AM
Id : 10
RecordId : 7810
ProcessId : 3324
MachineName : RDSEMVM01
Message : Process accessed:
RuleName:
UtcTime: 2023-07-09 14:44:14.260
SourceProcessGUID: {e7bf76b7-c7ba-64aa-0000-0010e8e9a602}
SourceProcessId: 1884
SourceThreadId: 7872
SourceImage: C:\htb\samples\shell.exe
TargetProcessGUID: {e7bf76b7-d7ec-6496-0000-001027d60000}
TargetProcessId: 668
TargetImage: C:\Windows\system32\lsass.exe
GrantedAccess: 0x1010
CallTrace: C:\Windows\SYSTEM32\ntdll.dll+9d4c4|C:\Windows\System32\KERNELBASE.dll+2c13e|C:\htb\samples\sh
ell.exe+c291e|C:\htb\samples\shell.exe+c2cf5|C:\htb\samples\shell.exe+c285d|C:\htb\samples\shell.exe+85a4
4|C:\htb\samples\shell.exe+8587c|C:\htb\samples\shell.exe+85647|C:\htb\samples\shell.exe+c97a5|C:\Windows
\System32\KERNEL32.DLL+17034|C:\Windows\SYSTEM32\ntdll.dll+526a1
SourceUser: %12
TargetUser: %13
```
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.
```yaml
title: LSASS Access From Program in Potentially Suspicious Folder
id: fa34b441-961a-42fa-a100-ecc28c886725
status: experimental
description: Detects process access to LSASS memory with suspicious access flags and from a potentially suspicious folder
references:
- https://docs.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights
- https://onedrive.live.com/view.aspx?resid=D026B4699190F1E6!2843&ithint=file%2cpptx&app=PowerPoint&authkey=!AMvCRTKB_V1J5ow
- https://web.archive.org/web/20230208123920/https://cyberwardog.blogspot.com/2017/03/chronicles-of-threat-hunter-hunting-for_22.html
- https://www.slideshare.net/heirhabarov/hunting-for-credentials-dumping-in-windows-environment
- http://security-research.dyndns.org/pub/slides/FIRST2017/FIRST-2017_Tom-Ueltschi_Sysmon_FINAL_notes.pdf
author: Florian Roth (Nextron Systems)
date: 2021/11/27
modified: 2023/05/05
tags:
- attack.credential_access
- attack.t1003.001
- attack.s0002
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|endswith:
- '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' # https://github.com/b4rtik/ATPMiniDump/blob/76304f93b390af3bb66e4f451ca16562a479bdc9/ATPMiniDump/ATPMiniDump.c
- 'FF'
SourceImage|contains:
- '\Temp\'
- '\Users\Public\'
- '\PerfLogs\'
- '\AppData\'
- '\htb\'
filter_optional_generic_appdata:
SourceImage|startswith: 'C:\Users\'
SourceImage|contains: '\AppData\Local\'
SourceImage|endswith:
- '\Microsoft VS Code\Code.exe'
- '\software_reporter_tool.exe'
- '\DropboxUpdate.exe'
- '\MBAMInstallerService.exe'
- '\WebexMTA.exe'
- '\WebEx\WebexHost.exe'
- '\JetBrains\Toolbox\bin\jetbrains-toolbox.exe'
GrantedAccess: '0x410'
filter_optional_dropbox_1:
SourceImage|startswith: 'C:\Windows\Temp\'
SourceImage|endswith: '.tmp\DropboxUpdate.exe'
GrantedAccess:
- '0x410'
- '0x1410'
filter_optional_dropbox_2:
SourceImage|startswith: 'C:\Users\'
SourceImage|contains: '\AppData\Local\Temp\'
SourceImage|endswith: '.tmp\DropboxUpdate.exe'
GrantedAccess: '0x1410'
filter_optional_dropbox_3:
SourceImage|startswith:
- 'C:\Program Files (x86)\Dropbox\'
- 'C:\Program Files\Dropbox\'
SourceImage|endswith: '\DropboxUpdate.exe'
GrantedAccess: '0x1410'
filter_optional_nextron:
SourceImage|startswith:
- 'C:\Windows\Temp\asgard2-agent\'
- 'C:\Windows\Temp\asgard2-agent-sc\'
SourceImage|endswith:
- '\thor64.exe'
- '\thor.exe'
- '\aurora-agent-64.exe'
- '\aurora-agent.exe'
GrantedAccess:
- '0x1fffff'
- '0x1010'
- '0x101010'
filter_optional_ms_products:
SourceImage|startswith: 'C:\Users\'
SourceImage|contains|all:
- '\AppData\Local\Temp\'
- '\vs_bootstrapper_'
GrantedAccess: '0x1410'
filter_optional_chrome_update:
SourceImage|startswith: 'C:\Program Files (x86)\Google\Temp\'
SourceImage|endswith: '.tmp\GoogleUpdate.exe'
GrantedAccess:
- '0x410'
- '0x1410'
filter_optional_keybase:
SourceImage|startswith: 'C:\Users\'
SourceImage|endswith: \AppData\Local\Keybase\keybase.exe
GrantedAccess: '0x1fffff'
filter_optional_avira:
SourceImage|contains: '\AppData\Local\Temp\is-'
SourceImage|endswith: '.tmp\avira_system_speedup.tmp'
GrantedAccess: '0x1410'
filter_optional_viberpc_updater:
SourceImage|startswith: 'C:\Users\'
SourceImage|contains: '\AppData\Roaming\ViberPC\'
SourceImage|endswith: '\updater.exe'
TargetImage|endswith: '\winlogon.exe'
GrantedAccess: '0x1fffff'
filter_optional_adobe_arm_helper:
SourceImage|startswith: # Example path: 'C:\Program Files (x86)\Common Files\Adobe\ARM\1.0\Temp\2092867405\AdobeARMHelper.exe'
- 'C:\Program Files\Common Files\Adobe\ARM\'
- 'C:\Program Files (x86)\Common Files\Adobe\ARM\'
SourceImage|endswith: '\AdobeARMHelper.exe'
GrantedAccess: '0x1410'
condition: selection and not 1 of filter_optional_*
fields:
- User
- SourceImage
- GrantedAccess
falsepositives:
- Updaters and installers are typical false positives. Apply custom filters depending on your environment
level: medium
```
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)**
According to Microsoft, [Event 4776](https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4776) generates every time that a credential validation occurs using NTLM authentication.
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.
```yaml
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
```
python sigmac -t powershell 'C:\Tools\chainsaw\sigma\rules\windows\builtin\windefend\win_defender_threat.yml'
```
```
Get-WinEvent -Path C:\Events\YARASigma\lab_events_4.evtx | where {($_.ID -eq "1006" -or $_.ID -eq "1116" -or $_.ID -eq "1015" -or $_.ID -eq "1117") } | select TimeCreated,Id,RecordId,ProcessId,MachineName,Message
```
Answer: mimidrv.sys
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://faresbltagy.gitbook.io/footprintinglabs/soc-hackthebox-notes-and-labs/yara-and-sigma-for-soc-analysts-module/developing-sigma-rules.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.