Sigma rules with OR lists (list of maps) can stop matching entirely #232

Chainsaw version: 2.16.0 (Homebrew, macOS arm64)
Mapping: mappings/sigma-event-logs-all.yml from master (2026-07-08)
Test data: the public EVTX-ATTACK-SAMPLES repo at 4ceed2f

I was comparing chainsaw results against another Sigma evaluator on the Sysmon events in EVTX-ATTACK-SAMPLES and hit a pattern where rules using a list of maps under a selection (which the Sigma spec treats as OR of the sub-maps) miss events they should match.

Repro 1: adding an OR entry makes existing matches disappear

Take proc_creation_win_susp_system_user_anomaly.yml from SigmaHQ, keep all the metadata, and replace the detection with this:

detection:
    selection:
        IntegrityLevel:
            - 'System'
            - 'S-1-16-16384'
        User|contains:
            - 'AUTHORI'
            - 'AUTORI'
    selection_special:
        - Image|endswith:
              - '\calc.exe'
    condition: all of selection*

Running against Persistence/persistence_sysmon_11_13_1_shime_appfix.evtx:

chainsaw hunt <evtx> -s <rule dir> --mapping sigma-event-logs-all.yml --json

gives 22 detections. Now add a second entry to the selection_special list. This one matches nothing in the file (the CommandLine values there are things like plain calc.exe):

    selection_special:
        - Image|endswith:
              - '\calc.exe'
        - CommandLine|contains:
              - ' -e* JAB'

Same file, same mapping: 0 detections.

The list is an OR, so adding an entry should never reduce the number of matches. Going from 22 to 0 looks like the OR isn't being evaluated as an OR in this case. Note the CommandLine field is present on the events, its value just doesn't match the new entry.

Repro 2: OR entry on a field the event doesn't have

proc_creation_win_whoami_execution_from_high_priv_process.yml uses this very common pattern:

    selection_img:
        - OriginalFileName: 'whoami.exe'
        - Image|endswith: '\whoami.exe'

Execution/sysmon_exec_from_vss_persistence.evtx is an older capture where the event 1 records have no OriginalFileName field at all, but there is an event with Image ending in \whoami.exe and User NT AUTHORITY\SYSTEM. The rule as written gives 0 detections on that file. If I delete the OriginalFileName entry from the list and keep only the Image line, it gives 1.

Per the spec a missing field should just make that branch false, and the Image branch should still match. A lot of SigmaHQ rules use this exact OriginalFileName-or-Image idiom, so captures from older Sysmon versions quietly lose those detections.

Scale

Across the whole sample set (Sysmon provider events only, restricted to rules chainsaw loads and the mapping routes), I count 242 missed event/rule matches across 69 SigmaHQ rules that trace back to this construct, and none in the other direction. Full method writeup if useful: https://big-comfy.github.io/detsema/eval-differential/

Happy to share the exact rule variants or the converted events if that helps with debugging.