FDREvent not converting TargetFileName to event.TargetFileName

[geoffg-sentry]

Tested with sigma-cli v1.0.1 and v1.0.4

Converting file_event sigma rules seems a bit buggy. Using this rule as an example. Core of the rule:

logsource:
    product: macos
    category: file_event
detection:
    selection:
        TargetFilename|re: '(?i)/lib/python3\.([5-9]|[0-9]{2})/site-packages/' # Unix and macOS
        TargetFilename|endswith: '.pth'
    condition: selection

Converting that to a python rule sigma convert -s -t panther -f python -p crowdstrike_panther [...] will result in:

import re
def rule(event):
    if all(
        [
            event.deep_get("event_simpleName", default="") == "FileOpenInfo",
            event.deep_get("event_platform", default="") == "Mac",
            re.match(
                r"(?i)/lib/python3\.([5-9]|[0-9]{2})/site-packages/",
                event.deep_get("TargetFilename", default=""),
            ),
            event.deep_get("TargetFilename", default="").endswith(".pth"),
        ]
    ):
        return True
    return False

Problem here is that the TargetFileName field is nested in the event{} object of FileOpenInfo of the FDREvent types. So that deep_get("TargetFileName") will never ever find event.TargetFileName Like this:

        "event":
          {
            [...]
            "TargetFileName": "/lib/python3.11/site-packages/hotpersistence.pth",
            [...]
          },
        "event_platform": "Mac",
        "event_simpleName": "FileOpenInfo",
        "fdr_event_type": "FileOpenInfo",

It looks like the mapping does exist, but it's not being reflected in the end state correctly as show above. This seems to be true for all the file_event rules I've converted so far.

I wonder if it's worth modifying the processing convert the use of event.deep_get() to the get_crowdstrike_field() function from panther_base_helpers?

def get_crowdstrike_field(event, field_name, default=None):
    return (
        deep_get(event, field_name)
        or deep_get(event, "event", field_name)
        or deep_get(event, "unknown_payload", field_name)
        or default
    )

If y'all have any advice for troubleshooting further, I'm all ears. I haven't figured out where the bug is in the backend here. Thanks!

[arielkr256]

@geoffg-sentry good catch, thank you! We are looking into this and hope to have a fix implemented soon.