feat: add field mapping check for process_creation rule

[fukusuket]

What Changed

• Fixed Incomplete field conversion in process_creation rules #443
• Changed so that non-existent fields are not output to the post-conversion rule in the process_creation rule conversion.

Specification

process_creation field conversion

Sysmon	Security	Value conversion
User	SubjectUserName	Domain\User -> User
User	SubjectDomainName	Domain\User -> Domain
LogonId	SubjectLogonId	-
ProcessId	NewProcessId	2468 -> 0x9a4 (to hex)
ParentProcessId	ProcessId	7772 -> 0x1e5c (to hex)
Image	NewProcessName	-
ParentImage	ParentProcessName	-
IntegrityLevel	MandatoryLabel	High -> S-1-16-12288

Fields for which post conversion rules are not created

If the following fields are in the AND condition(or all of the OR conditions), do not create post-conversion rules

Company
CurrentDirectory
Description
FileVersion
Hashes
LogonGuid
OriginalFileName
ParentCommandLine
ParentProcessGuid
ParentUser
ProcessGuid
Product
RuleName
TerminalSessionId
UtcTime

Evidence

Test Environment

• OS: macOS montery version 13.1
• Hard: MacBook Air(M1, 2020) , Memory 8GB, Core 8
• Python 3.11.1

I would appreciate it if you could review🙏

[fukusuket]

Test1 (Field mapping)

When run against the following rule, python logsource_mapping.py -r test.yml -o ./out

title: TEST
id: 6c5808ee-85a2-4e56-8137-72e5876a5097
status: test
author: TEST
date: 2023/06/30
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        User: 'DOMAIN\User'
        LogonId: '0x1864E'
        Image: C:\Windows\System32\PING.EXE
        ParentProcessId: 7772
        CommandLine: C:\WINDOWS\system32\PING.EXE 8.8.8.8
        ParentImage: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
        IntegrityLevel: High
    condition: selection
falsepositives:
    - Unknown
level: low
ruletype: Sigma

builtin rule is created as follows.

title: TEST
id: 6c5808ee-85a2-4e56-8137-72e5876a5097
status: test
author: TEST
date: 2023/06/30
logsource:
    category: process_creation
    product: windows
detection:
    process_creation:
        EventID: 4688
        Channel: Security
    selection:
        CommandLine: C:\WINDOWS\system32\PING.EXE 8.8.8.8
        SubjectUserName: User
        SubjectDomainName: DOMAIN
        SubjectLogonId: '0x1864E'
        NewProcessName: C:\Windows\System32\PING.EXE
        ProcessId: '0x1e5c'
        ParentProcessName: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
        MandatoryLabel: S-1-16-12288
    condition: process_creation and selection
falsepositives:
    - Unknown
level: low
ruletype: Sigma

sysmon rule is created as follows.

title: TEST
id: 6c5808ee-85a2-4e56-8137-72e5876a5097
status: test
author: TEST
date: 2023/06/30
logsource:
    category: process_creation
    product: windows
detection:
    process_creation:
        EventID: 1
        Channel: Microsoft-Windows-Sysmon/Operational
    selection:
        User: DOMAIN\User
        LogonId: '0x1864E'
        Image: C:\Windows\System32\PING.EXE
        ParentProcessId: 7772
        CommandLine: C:\WINDOWS\system32\PING.EXE 8.8.8.8
        ParentImage: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
        IntegrityLevel: High
    condition: process_creation and selection
falsepositives:
    - Unknown
level: low
ruletype: Sigma

[fukusuket]

Test2 (OR conversion logic)

When convertible fields and non-convertible fields are mixed in the OR condition,
(e.g proc_creation_win_apt_ta505_dropper.yml)

builtin rule is created as follows. (Image is convertible OR OriginalFileName is non-convertible)

title: TA505 Dropper Load Pattern
id: 18cf6cf0-39b0-4c22-9593-e244bdc9a2d4
status: deprecated
description: Detects mshta loaded by wmiprvse as parent as used by TA505 malicious
    documents
references:
    - https://twitter.com/ForensicITGuy/status/1334734244120309760
author: Florian Roth (Nextron Systems)
date: 2020/12/08
modified: 2023/04/05
tags:
    - attack.execution
    - attack.g0092
    - attack.t1106
logsource:
    category: process_creation
    product: windows
detection:
    process_creation:
        EventID: 4688
        Channel: Security
    selection_parent:
        ParentProcessName|endswith: \wmiprvse.exe
    selection_mshta:
        -   NewProcessName|endswith: \mshta.exe
        -   OriginalFileName: mshta.exe
    condition: process_creation and (all of selection_*)
falsepositives:
    - Unknown
level: critical
ruletype: Sigma

[fukusuket]

Test3 (AND conversion logic)

When convertible fields and inconvertible fields are mixed in the AND condition,
(e.g proc_creation_win_susp_compression_params.yml)

rules are not converted as follows(CommandLine is convertible AND OriginalFileName is non-convertible)

fukusuke@fukusukenoMacBook-Air sigmac % python logsource_mapping.py -r /sigma/rules/windows/process_creation/proc_creation_win_susp_compression_params.yml
...
[ERROR:logsource_mapping.py:262] This rule has incompatible field.{'process_creation': {'EventID': 4688, 'Channel': 'Security'}, 'selection': {'OriginalFileName': ['7z*.exe', '*rar.exe', '*Command*Line*RAR*'], 'CommandLine|contains': [' -p', ' -ta', ' -tb', ' -sdel', ' -dw', ' -hp']}, 'falsepositive': {'ParentProcessName|startswith': 'C:\\Program'}, 'condition': 'selection and not falsepositive'}. skip conversion.

[fukusuket]

Test4 (inconvertible field)

When inconvertible fields,
(e.g proc_creation_win_lolbin_ie4uinit.yml)

rules are not converted as follows(CurrentDirectory is non-convertible)

fukusuke@fukusukenoMacBook-Air sigmac % python logsource_mapping.py -r /Users/fukusuke/Scripts/Python/sigma/rules/windows/process_creation/proc_creation_win_lolbin_ie4uinit.yml
...
[ERROR:logsource_mapping.py:262] This rule has incompatible field.{'process_creation': {'EventID': 4688, 'Channel': 'Security'}, 'lolbin': [{'NewProcessName|endswith': '\\ie4uinit.exe'}, {'OriginalFileName': 'IE4UINIT.EXE'}], 'filter_correct': {'CurrentDirectory': ['c:\\windows\\system32\\', 'c:\\windows\\sysWOW64\\']}, 'filter_missing': {'CurrentDirectory': None}, 'condition': 'lolbin and not 1 of filter_*'}. skip conversion.

[fukusuket]

Test5 (hayabusa no parse error)

There is no parse error with This PR's rules.

fukusuke@fukusukenoMacBook-Air hayabusa-2.6.0-all-platforms % ./hayabusa-2.6.0-mac-arm csv-timeline -d ../hayabusa-sample-evtx --debug -C -q -o new.csv -r ../new_rule
Start time: 2023/07/01 20:28

Total event log files: 584
Total file size: 138.2 MB

Loading detections rules. Please wait.

Excluded rules: 30

Deprecated rules: 162 (4.70%) (Disabled)
Experimental rules: 1924 (55.87%)
Stable rules: 100 (2.90%)
Test rules: 1420 (41.23%)
Unsupported rules: 42 (1.22%) (Disabled)

Sigma rules: 3444
Total enabled detection rules: 3444

Output profile: standard

Scanning in progress. Please wait.

The comparison result of the number of detections with main is as follows.

Ver	Sigma rules	Hits / Total	crit(total/uniq)	high(total/uniq)	med(total/uniq)	low(total/uniq)	info(total/uniq)
main	3569	5,632 / 48,262	52 / 21	5,333 / 265	1,160 / 178	706 / 59	28 / 4
This PR	3444	5,434 / 48,262	52 / 21	5,305 / 261	1,155 / 177	399 / 58	99 / 5

[fukusuket]

Test6 (Reason for the difference in the number of detections from main)

I compared the number of detections(hayabusa-sample-evtx) with the following command.

hayabusa-2.6.0-all-platforms % cat new.csv | awk -F"," '{print $5, $7}' | sort | uniq -c > new-rule-count.csv
hayabusa-2.6.0-all-platforms % cat old.csv | awk -F"," '{print $5, $7}' | sort | uniq -c > old-rule-count.csv
hayabusa-2.6.0-all-platforms % diff new-rule-count.csv old-rule-count.csv

The diff results are as follows, and I have confirmed that they are all intended differences.

Level	Category	Rule Title	main	This PR	Diff Reason (field)
high	process_creation	Bad Opsec Defaults Sacrificial Processes With Improper Arguments	13	1	ParentCommandLine
high	process_creation	HackTool - Potential Impacket Lateral Movement Activity	12	9	ParentCommandLine
high	process_creation	Potentially Suspicious PowerShell Child Processes	5	4	ParentCommandLine
high	process_creation	Rundll32 Execution Without DLL File	18	6	ParentCommandLine
high	process_creation	Suspicious Spool Service Child Process	1	2	IntegrityLevel
high	process_creation	Windows Shell/Scripting Processes Spawning Suspicious Programs	5	4	CurrentDirectory
info	process_creation	Suspicious High IntegrityLevel Conhost Legacy Option	0	71	IntegrityLevel
low	process_creation	Non Interactive PowerShell Process Spawned	325	18	ParentCommandLine
med	process_creation	Gpscript Execution	10	4	ParentCommandLine
med	process_creation	Potential RDP Session Hijacking Activity	0	3	IntegrityLevel
med	process_creation	Potentially Suspicious Rundll32Activity	18	16	ParentCommandLine

A summary of the above diffs is:

• No difference except for process_creation rules
• There is no field ParentCommandLine/CurrentDirectory in Security:4688, so rule is not created.
• IntegrityLevel value conversion increase number of detections.

[hitenkoku]

LGTM.

[YamatoSecurity]

@fukusuket Thanks so much for the PR!

One question:
What happens if we have the following rule?

detection:
    lolbin:
        - Image|endswith: '\ie4uinit.exe'
        - OriginalFileName: 'IE4UINIT.EXE'
    filter_correct:
        CurrentDirectory:
            - 'c:\windows\system32\'
            - 'c:\windows\sysWOW64\'
    filter_high:
        IntegrityLevel: High
    condition: lolbin and not 1 of filter_*

That is, one filter section with incompatible fields but another filter section with a compatible field.

I checked and since Potentially Suspicious Rundll32Activity is not being converted, I assume that rules are not being created in this case? Although it might increase FPs, I think we should convert these rules as it may also lower True Positives.
What do you think?

Also, when it is all of filter*, the 4688 rule will not be created, right?

detection:
    lolbin:
        - Image|endswith: '\ie4uinit.exe'
        - OriginalFileName: 'IE4UINIT.EXE'
    filter_correct:
        CurrentDirectory:
            - 'c:\windows\system32\'
            - 'c:\windows\sysWOW64\'
    filter_high:
        IntegrityLevel: High
    condition: lolbin and not all of filter_*

because although it has a section with compatible fields (filter_high) it also relies on a section that includes incompatible fields (filter_correct).

[YamatoSecurity]

When a rule is filtering on a section with compatible fields OR a section with in-compatible fields then not creating a 4688 rule will lower FPs but may result in decrease of TPs... so I am wondering what the best way is.
What about converting rules in these cases but adding an extra label to mark that there is a higher chance of FPs?
For example, in such rules, we could add incompleterule: true to the end of the YML file.
Then in the next version of Hayabusa, we could add a --no-incomplete-rules option that will ignore all rules that are marked as incompleterule: true.
This will let us keep the detection rate the same as it is now but give the user the option of doing more accurate scans if they are getting too many FPs, etc...

What do you think?

(I don't want to lower the detection rate by default)

[fukusuket]

@YamatoSecurity
Thank you so much for your review :)

That is, one filter section with incompatible fields but another filter section with a compatible field.

I see, I hadn't thought of this case...😅 I agree with you, in this case it would be better to create a rule.
It seems a little difficult, but I will check if it can be implemented💪

At first, I'll count how many rules match this case and I'll understand the characteristics!

[fukusuket]

@YamatoSecurity

Addressing 1 of * or all of * completely is a bit expensive(Because need a new implementation of condition block grammar parsing) to implement... :(

Although it is not a perfect countermeasure, I tried the implementation below, what do you think? 🤔

Number of process_creation rules

The result of checking the process_creation rule (in the sigma repo) was as follows.

No	description	count
1	process_creation rule total count	1,326
2	Has fields unique to Sysmon	662 / 1,326
3	Has fields unique to Sysmon and condition with all of */ 1 of *	484 / 1,326
4	Has fields unique to Sysmon and condition without all of */ 1 of *	178 / 1,326
5	Has fields unique to Sysmon and condition without all of */ 1 of * and undetectable rule	61 / 1,326

New Implementation

I changed the implementation(460d7f1) to check only the case No.5. then result is as follows.

Ver	Sigma rules	Hits / Total	crit(total/uniq)	high(total/uniq)	med(total/uniq)	low(total/uniq)	info(total/uniq)
main	3,569	5,632 / 48,262	52 / 21	5,333 / 265	1,160 / 178	706 / 59	28 / 4
460d7f1	3,499	5,704 / 48,262	52 / 21	5,334 / 266	1,163 / 179	706 / 59	99 / 5

The diff is as follows.
(old.csv is main result / fix.csv is 460d7f1 result )

hayabusa-2.6.0-all-platforms % cat old.csv | awk -F"," '{print $5, $7}' | sort | uniq -c > old-rule-count.csv
hayabusa-2.6.0-all-platforms % cat fix.csv | awk -F"," '{print $5, $7}' | sort | uniq -c > fix-rule-count.csv
hayabusa-2.6.0-all-platforms % diff old-rule-count.csv fix-rule-count.csv
220c220
<    1 "high" "Suspicious Spool Service Child Process"
---
>    2 "high" "Suspicious Spool Service Child Process"
251a252
>   71 "info" "Suspicious High IntegrityLevel Conhost Legacy Option"
369a371
>    3 "med" "Potential RDP Session Hijacking Activity"

Rules using 1 of * or all of * are often valid rules(such as #445 (comment)), so it's not a perfect countermeasure,
but for now, I think 460d7f1 is better. Because with 460d7f1 we can detect more with fewer rules.

[YamatoSecurity]

@fukusuket
Thanks for looking into the different cases! LGTM!
Please merge this when ready. I updated the Changelog. Please check the Japanese version and fix if any mistakes.

[fukusuket]

@YamatoSecurity
Thank you for checking and update changelog :)
I updated the Japanese changelog a little because the number has changed. I would appreciate it if you could review🙏

[YamatoSecurity]

@fukusuket Thanks so much! I updated the count in the English changelog as well so I will merge this.