[Feature Request] Support for "contains", "|" and "all" in both chainsaw and sigma rules

[reece394]

I was wanting to write some Service Installation related rules for chainsaw and I tried doing the following as a test:

filter:
  Event.System.EventID: 7045
  Event.EventData.ServiceName|contains: 
    - servicenamehere

I checked the code here and it appears that there is no support for using contains for chainsaw rules specifically.

I then checked the sigma code here and it appears to support "contains" as well as "all" but when testing with this rule it refuses to load. Attempts to modify it to just use ImagePath|contains does not work either.

I noticed that "|" is marked as unsupported in the sigma code is that why it is failing to work?

I would be grateful if this feature could be added as powerful rules could be created with this.

Thanks for your work on this tool as always!

[alexkornitzer]

Hey,

So Chainsaw rules use Tau Engine syntax (https://github.com/WithSecureLabs/tau-engine) and not that of Sigma rules, so contains would be done like this:

filter:
  Event.EventData.ServiceName:
    - *servicenamehere*

While all can be achieved like so:

filter:
  all(Event.EventData.ServiceName):
    - *foo*
    - *bar*

Chainsaw converts Sigma rules into Tau Engine syntax and does a lot of preprocessing before finally parsing them. | is supported but is handled in the preprocessing stage to extract the modifiers so they can be applied in a Tau like way (https://github.com/WithSecureLabs/chainsaw/blob/master/src/rule/sigma.rs#L551). It appears to be linting fine to me:

$ chainsaw --no-banner lint --kind sigma /tmp/sigma/rules/windows/builtin/system/service_control_manager/win_system_cobaltstrike_service_installs.yml
[+] Validating as sigma for supplied detection rules...
[+] Validated 1 detection rules out of 1

[reece394]

Thanks for that information. It is my fault that I thought chainsaw used the sigma syntax for both sets of rules as the .yml files look similar. I have used the below as a test:

---
title: Service Installation Test
group: Service Installation 
description: This is a Test
authors:
  - reece394

kind: evtx
level: critical
status: stable
timestamp: Event.System.TimeCreated

fields:
  - name: Event ID
    to: Event.System.EventID
  - name: Record ID
    to: Event.System.EventRecordID
  - name: Computer
    to: Event.System.Computer
  - name: Service Name
    to: Event.EventData.ServiceName
  - name: Service File Name
    to: Event.EventData.ImagePath
  - name: Service Type
    to: Event.EventData.ServiceType
  - name: Service Start Type
    to: Event.EventData.StartType  
  - name: Service Account
    to: Event.EventData.AccountName  

filter:
  Event.System.EventID: 7045
  Event.EventData.ServiceName: 
    - '*Parallels*'
    - '*Arsenal*'
    - PrlVssProvider

When doing this I get "No valid detection rules were found in the provided paths" with just that rule enabled. This works great thanks! Needed to wrap it in quotes.

Additionally I used System_7045_namedpipe_privesc.evtx from EVTX_ATTACK_SAMPLES and modified the sigma rule I mentioned earlier to simplify testing as I don't have a CobaltStrike EVTX on hand for testing. It does load as you pointed out however no matches are generated from it even though clearly %COMSPEC% is in the ImagePath

title: CobaltStrike Service Installations - System
id: 5a105d34-05fc-401e-8553-272b45c1522d
status: test
description: Detects known malicious service installs that appear in cases in which a Cobalt Strike beacon elevates privileges or lateral movement
references:
    - https://www.sans.org/webcasts/119395
    - https://www.crowdstrike.com/blog/getting-the-bacon-from-cobalt-strike-beacon/
    - https://thedfirreport.com/2021/08/29/cobalt-strike-a-defenders-guide/
author: Florian Roth (Nextron Systems), Wojciech Lesicki
date: 2021/05/26
modified: 2022/11/27
tags:
    - attack.execution
    - attack.privilege_escalation
    - attack.lateral_movement
    - attack.t1021.002
    - attack.t1543.003
    - attack.t1569.002
logsource:
    product: windows
    service: system
detection:
    selection_id:
        Provider_Name: 'Service Control Manager'
        EventID: 7045
    selection2:
        ImagePath|contains:
            - '%COMSPEC%'
    condition: selection_id and selection2
falsepositives:
    - Unknown
level: critical

[alexkornitzer]

Not to worry, it never hurts to ask. I am glad you got it working.

Okay so with the knowledge of the Tau syntax you can now see what Chainsaw is doing under the hood for the rule, unmodified we get the following:

$ chainsaw --no-banner lint --kind sigma -t /tmp/sigma/rules/windows/builtin/system/service_control_manager/win_system_cobaltstrike_service_installs.yml
[+] Validating as sigma for supplied detection rules...
[+] Rule /tmp/sigma/rules/windows/builtin/system/service_control_manager/win_system_cobaltstrike_service_installs.yml:
condition: selection_id and (selection1 or selection2 or selection3 or selection4)
selection3:
  ImagePath: i*powershell -nop -w hidden -encodedcommand*
selection1:
  all(ImagePath):
  - i*ADMIN$*
  - i*.exe*
selection2:
  all(ImagePath):
  - i*%COMSPEC%*
  - i*start*
  - i*powershell*
selection_id:
  Provider_Name: iService Control Manager
  EventID: 7045
selection4:
  ImagePath:
  - i*SUVYIChOZXctT2JqZWN0IE5ldC5XZWJjbGllbnQpLkRvd25sb2FkU3RyaW5nKCdodHRwOi8vMTI3LjAuMC4xO*
  - i*lFWCAoTmV3LU9iamVjdCBOZXQuV2ViY2xpZW50KS5Eb3dubG9hZFN0cmluZygnaHR0cDovLzEyNy4wLjAuMT*
  - i*JRVggKE5ldy1PYmplY3QgTmV0LldlYmNsaWVudCkuRG93bmxvYWRTdHJpbmcoJ2h0dHA6Ly8xMjcuMC4wLjE6*

[+] Validated 1 detection rules out of 1

If I modify it to your changes above I get:

$ chainsaw --no-banner lint --kind sigma -t /tmp/sigma/rules/windows/builtin/system/service_control_manager/win_system_cobaltstrike_service_installs.yml
[+] Validating as sigma for supplied detection rules...
[+] Rule /tmp/sigma/rules/windows/builtin/system/service_control_manager/win_system_cobaltstrike_service_installs.yml:
condition: selection_id and selection2
selection2:
  ImagePath:
  - i*%COMSPEC%*
selection_id:
  Provider_Name: iService Control Manager
  EventID: 7045

[+] Validated 1 detection rules out of 1

The event does have all the required parameters as you say:

chainsaw --no-banner dump /tmp/EVTX-ATTACK-SAMPLES/Privilege\ Escalation/System_7045_namedpipe_privesc.evtx
[+] Dumping the contents of forensic artefact - /tmp/EVTX-ATTACK-SAMPLES/Privilege Escalation/System_7045_namedpipe_privesc.evtx...
---
Event:
  EventData:
    AccountName: LocalSystem
    ImagePath: '%COMSPEC% /c ping -n 1 127.0.0.1 >nul && echo ''WinPwnage'' > \\.\pipe\WinPwnagePipe'
    ServiceName: WinPwnage
    ServiceType: user mode service
    StartType: demand start
  System:
    Channel: System
    Computer: IEWIN7
    Correlation: null
    EventID: 7045
    EventID_attributes:
      Qualifiers: 16384
    EventRecordID: 10446
    Execution_attributes:
      ProcessID: 468
      ThreadID: 3256
    Keywords: '0x8080000000000000'
    Level: 4
    Opcode: 0
    Provider_attributes:
      EventSourceName: Service Control Manager
      Guid: '{555908d1-a6d7-4695-8e1e-26931d2012f4}'
      Name: Service Control Manager
    Security_attributes:
      UserID: S-1-5-21-3583694148-1414552638-2922671848-1000
    Task: 0
    TimeCreated_attributes:
      SystemTime: 2019-05-12T12:52:43.702578Z
    Version: 0
Event_attributes:
  xmlns: http://schemas.microsoft.com/win/2004/08/events/event

[+] Done

Therefore the issue is probably in the mapping file, and it looks like the Provider_Name is mapped to the wrong field, the following change gets the rule to match:

@@ -462,7 +462,7 @@ groups:
         to: Event.EventData.ProviderName
         visible: false
       - from: Provider_Name
-        to: Event.EventData.Provider_Name
+        to: Event.System.Provider
         visible: false
       - from: QNAME
         to: Event.EventData.QNAME

I wonder if the ProviderName needs the same change too?

[reece394]

I didn’t even think about the mapping file! Great spot on that. I can verify your findings on that. It appears ProviderName is not used much in sigma rules (I think just once). It should be safe to change both mappings over. Thanks for digging into that for me. With the mapping change more sigma rules should just work now 🤞. Feel free to close this after that change is put in