Sigma Discussions

How can we improve this

"We can solve any problem by introducing an extra level of indirection." (David Wheeler)

Let's just define a new "Standard":

• That everyone understands...
• Can be converted to all other EDR systems
• Can facilitate detection interchange

Anatomy of a Sigma rule

• To compile a Sigma Rule into a SIEM query we need:

1. A compiler able to generate SIEM Query Language output
2. Log Sources -> Map from generic log source to concrete data collected by SIEM
3. Field Mappings -> Map from generic field names to SIEM schema transformation.

Example

logsource:
    category: process_creation
    product: windows
detection:
    process_creation:
        EventID: 4688
        Channel: Security
    selection:
        -   CommandLine|contains|all:
                - \AppData\Roaming\Oracle
                - \java
                - '.exe '
        -   CommandLine|contains|all:
                - cscript.exe
                - Retrive
                - '.vbs '
    condition: process_creation and selection

Let's consider how a Sigma Compiler might work

• Logsource: What does process_creation mean exactly?

  • Could be Sysmon EID 1
  • System EID 4688
  • ... Or maybe something else?

• What fields do we need?

  • CommandLine - Do we even collect this?

• Actually this rule can only ever work on Security.evtx!

  • The Rule author ensures this because they specifically test for the right EID and Channel within the rule logic.
  • The log source is kind of redundant

How do we know if a rule even makes sense?

• Rule do not refer directly to the fields in the event
• Instead they refer to an "abstract" field name
• The compiler maps the abstract field name to the SIEM schema
  • Assuming there is such a mapping
  • Assuming that field is actually available in the SIEM

Example 2: Invalid Field Mapping

title: Remote Thread Creation By Uncommon Source Image
logsource:
    product: windows
    category: create_remote_thread
detection:
    create_remote_thread:
        EventID: 8
        Channel: Microsoft-Windows-Sysmon/Operational
    selection:
        SourceImage|endswith:
            - \bash.exe
            - \cscript.exe
            ...
            - \wmic.exe
            - \wscript.exe
    filter_main_winlogon_1:
        SourceImage: C:\Windows\System32\winlogon.exe
        TargetImage:
            - C:\Windows\System32\services.exe
            - C:\Windows\System32\wininit.exe
            - C:\Windows\System32\csrss.exe
    filter_main_winlogon_2:
        SourceImage: C:\Windows\System32\winlogon.exe
        TargetParentImage: System
        TargetParentProcessId: 4
        ...
    condition: create_remote_thread and (selection and not 1 of filter_main_* and
        not 1 of filter_optional_*)

How Does Velociraptor employ Sigma Rules?

The sigma() plugin in Velociraptor allows us to directly use rules

• Define log sources as VQL queries
• Define Field mappings as VQL lambda functions.
• Plugin stacks rules on log sources and runs them in parallel

Can be used in the following contexts

• Triaging an endpoint using existing EVTX files
• Live detection using ETW or EVTX following
• Post process analysis of collected artifacts.

Velociraptor sigma compiler transforms the rule into a VQL artifact.

Log Source example

Many Sigma rules have nonsense log sources, but really use Channel matches to refer to an event log.

  '*/windows/sysmon':
    query: |
      SELECT * FROM parse_evtx(filename=ROOT + "/Microsoft-Windows-Sysmon%4Operational.evtx")
    channel:
      - Microsoft-Windows-Sysmon/Operational

Field Mappings are VQL fragments

  SysmonVersion: "x=>x.EventData.SysmonVersion"
  CommandLine: "x=>x.EventData.CommandLine"

Velociraptor's sigma compiler checks that fields are actually valid and rejects the rule if they are not.

Errored Rules which were rejected:
  Missing field mapping 'TargetName' in */windows/ntlm:
    hayabusa/sigma/builtin/ntlm/win_susp_ntlm_rdp.yml
  Missing field mapping 'ParentIntegrityLevel' in */windows/security:
    hayabusa/sigma/builtin/unsupported/win_kernel_and_3rd_party_drivers_exploits_token_stealing.yml

Triaging an endpoint

Live detection with Sigma

Links and References

• Live Incident Response with Velociraptor
• VeloCon 2023: Fast DFIR with Velociraptor
• AusCERT2022: I CAN SEE YOU! IMPROVING DETECTION EFFICIENCY ON THE ENDPOINT...
• Sigma HQ
• Velociraptor Sigma Compiler
• Velociraptor Sigma Rules Github
• Sigma in Velociraptor