Crowdstrike Integration - TRaDE Feedback - 2nd Round

CrowdStrike - Windows Mappings Review

This issue contains further improvements to the CrowdStrike integration mappings.

Integration Version: 2.0.0 / Stack Version: 8.19.1

---

Not solved yet:

• host.id: Should be populated using the aid field that is not currently parsed.
  • Neither crowdstrike.aid or host.id are being currently populated, but aid is available in the original event.
• The following is valid for all events with the event.action ending with *Written, except for PeFileWritten, NewExecutableWritten, NewScriptWritten
  • event.category is not set for events ending with Written
  • event.action should be set to creation

---

New adjustments:

For all events:

• process.entity_id and process.parent.entity_id are not populated in network, file, configuration, registry, driver events. Use ContextProcessId & ParentProcessId to populate these as done in process events.
• process.pid can be also populated using ContextProcessId

Registry events for when (event.category is registry):

• event.category is missing for some events that we didn’t have in the previous dataset. We should include these event.action values:
  • RegCrowdstrikeKeyUpdate
  • RegCrowdstrikeValueUpdate
• registry.key contains extra backslash (\) in the start:
  • \SYSTEM\ControlSet001\Services\BcastDVRUserService_cbd3c should be
    SYSTEM\ControlSet001\Services\BcastDVRUserService_cbd3c
• registry.path is not populated when RegValueName is empty
  • Some events do not populate RegValueName. We can check if it is the case and use only RegObjectName if it is the only one available. Sample doc
• crowdstrike.RegOperationType
  • On RegOperationType 3 event.type is set to both change and creation, should be creation only
  • On RegOperationType 4 event.type is set change, but it is related to deletion, we should set it to deletion, and don’t populate the event.type with change by default.

File events for when (event.category is file):

• crowdstrike.OriginalFilename is being mapped to process.pe.original_file_name:
  • We should map it to file.pe.original_file_name instead
• user.id is not populated
  • We can use FileOperatorSid to populate it when present
• Set event.type to creation on FileDetectInfo events.
• For NewExecutableRenamed and FileRenameInfo event.action values:
  • Use crowdstrike.TargetFileName to populate file.path
    • We can extract the file name from to populate file.name
  • Use crowdstrike.SourceFileName to populate file.Ext.original.path
    • We can extract the file name from to populate file.Ext.original.name

Library events for when (event.category is library):

• crowdstrike.OriginalFilename is being mapped to process.pe.original_file_name:
  • We should map it to dll.pe.original_file_name instead
• dll.code_signature.trusted is being populated with true even for unsigned DLLs
  • The documentation says that ImageSignatureLevel 2 is ENTERPRISE (0x2), but when I tested with an unsigned DLL it was populated with 2. However, we can combine it with ImageSignatureType so it becomes more reliable.
  • Here is a more specific logic so we can refine this:
    • If ImageSignatureType == 0 (NONE (0x0)):
      • Set dll.code_signature.exists to false
      • Set dll.code_signature.trusted to false
    • If ImageSignatureType >= 1 and ImageSignatureLevel is 0 or 1:
      • Set dll.code_signature.exists to true
      • Set dll.code_signature.trusted to false
    • If ImageSignatureType >= 1 and ImageSignatureLevel >= 2:
      • Set dll.code_signature.exists to true
      • Set dll.code_signature.trusted to true
• Drop process.pid, I mistakenly suggested that we could use ContextProcessId to populate it, but considering other events, this doesn’t make sense

Driver events for when (event.category is driver):

• crowdstrike.OriginalFilename is being mapped to process.pe.original_file_name:
  • We should map it to dll.pe.original_file_name instead
• CertificatePublisher can used to populate dll.code_signature.subject_name
• ImageFileName can used to populate dll.path
  • dll.name can be extracted from the ImageFileName path
• ContextProcessId can used to populate process.entity_id
• CertificatePublisher can used to populate dll.code_signature.subject_name
• event.action can be set to load
• SHA256HashData can used to populate dll.hash.sha256
• MD5HashData can used to populate dll.hash.md5
• CertificatePublisher can used to populate dll.code_signature.subject_name
• ServiceDisplayName can used to populate service.name

---

Additional adjustments:

Misclassification of events as malware

• AssociateIndicator Events are classified as event.category == malware, may not be accurate as per events doc:

  This event is generated when the sensor generates an indicator. An indicator is like a detection event (AssociateTreeIdWithRoot) except that it is not necessarily malicious, either because it is just an indicator (e.g. when a process opens the Recycle Bin) or because CrowdStrike is not yet confident enough in the indicator to trigger it as a detection.

• Other misleading classification as malware for activity that are not malicious per nature:
  • SensitiveWmiQuery Events have event.category == malware
    • I suggest using event.category api or keeping process only, not malware
  • SuspiciousCreateSymbolicLink Events have event.category == malware
    • Drop the malware value, keep the file
  • DetectionExcluded Events have event.category == malware
    • As per event documentation: This event indicates that a detection has been excluded by the customer.
    • I suggest using event.category configuration, not malware
  • RegistryOperationDetectInfo Events have event.category == malware
    • As per event documentation: An event that describes a registry operation blocked using a callback filter.
    • Drop the malware value, keep the registry

Overuse of event.kind: alert

• Using event.kind == alert too broadly promotes many irrelevant events to security alerts
  • ErrorEvent
    • Definitely not something to promote as an alert: Event indicating a sensor error.
    • Set event.kind to event
  • RansomwareOpenFile
    • Is informational, like a counter, for their ransomware protections.

      • From a crowdstrike person: “It operates as a counter to help Falcon track which processes are opening a high number of files at high velocity. The presence of this event is not indicative of ransomware. It just helps the sensor keep track of what's being opened, how much is being opened, and how fast it's being opened. I hope that helps.” reference

    • Set event.kind to event
  • RansomwareCreateFile
    • As they have the same description on the docs, it is safe to assume that they have the same purpose
    • Set event.kind to event
  • ModifyServiceBinary
    • Too noisy to be automatically promoted
    • Set event.kind to event
  • DetectionExcluded
    • I would not promote this as an alert, it is more like an audit log.
  • SensitiveWmiQuery
    • Too noisy to be automatically promoted
    • Set event.kind to event
  • FileSystemOperationDetectInfo
    • Informational event for a file system operation detection.
    • Set event.kind to event

Missing event coverage (examples)

Based on the pipeline, we support 238 events, we are missing a lot of them which cause the events to not have basic stuff as event.category, event.type, event.kind, etc. Examples observed (not exhaustive):

• File Events
  • CrxFileWritten
  • JpegFileWritten
  • GzipFileWritten
  • PngFileWritten
  • EseFileWritten
  • WebScriptFileWritten
  • LnkFileWritten
  • MotwWritten
  • MsiFileWritten
  • CabFileWritten
  • MountedVolume
  • FileWrittenWithEntropyHigh
• Library Events
  • ReflectiveDotnetModuleLoad
• Alerts
  • SuspiciousPrivilegedProcessHandle
  • FalconProcessHandleOpDetectInfo
• Configuration Events
  • ServiceStopped
  • KernelServiceStarted
  • InstalledBrowserExtension
  • SensorAntiTamperState
  • SensorSettingsUpdate
  • ServicesStatusInfo