coreSigma: Expanding Sigma Detection for macOS

The macOS Detection Gap

The Current State of macOS Security Monitoring

The target on macOS’ back is ever-increasing for sophisticated threat actors. From ransomware campaigns like LockBit targeting Apple systems, to targeted infostealer campaigns, e.g., Atomic/AMOS & Poseidon, or nation-state malware like XCSSET, the macOS threat landscape has evolved dramatically. Yet, the security community's detection capabilities haven't kept pace.

macOS has long been underrepresented in the threat detection ecosystem. While Windows benefits from robust native telemetry sources like Windows Event Logs or Sysmon, and Linux enjoys flexible auditing via auditd, macOS detection largely hinges on proprietary, enterprise Endpoint Detection & Response (EDR) platforms.

The Sigma Gap

Sigma has emerged as the de facto standard for sharing detection rules across the security community. With over 3,000 detection rules covering Windows, Linux, cloud platforms, and cloud or local applications, Sigma enables security teams to implement vendor-agnostic threat detection.

However, when it comes to macOS, there's a significant gap.

Current Sigma macOS Coverage:

• logsource:
  • category: process_creation: ~70 rules
  • category: file_event: ~3 rules
  Total: Approximately 73 rules covering only two event types

While these cover fundamental security use cases, they represent only a fraction of the telemetry available on macOS systems. Modern macOS provides rich security event data through:

1. Endpoint Security Framework (ESF): A kernel-level API providing real-time notifications for security-relevant events including process execution, file operations, kernel extensions, process signals, XPC connections, authentication, and more.
2. Unified Logging (UL): A centralized logging system that captures application and system events, including critical security subsystems like TCC (Transparency, Consent, and Control), Gatekeeper, firewall events, DNS resolution, and authentication logs.

What's Missing – Telemetry Types & Detections:

• Network connections and DNS queries
• Authentication and privilege escalation
• System extensions and kernel modules
• Process injection and memory manipulation
• File system mount operations
• Transparency, Consent, and Control (TCC) privacy violations
• Gatekeeper and code signing bypass
• Firewall and security policy modifications

This gap leaves defenders blind to almost 85% of the MITRE ATT&CK techniques applicable to macOS.

Author note: It’s worth mentioning that most enterprise EDR platforms “worth their salt” are collecting macOS ESF and UL telemetry via endpoint agents, forwarding and transforming according to their data model, and running proprietary (or open-source) detections & analytics against that data. However, this is typically a “black box” end-to-end operation leaving practitioners minimal insight into how this occurs.

Why the Gap Exists

Without proper pipeline support, security teams face several critical challenges:

• Inability to use existing Sigma rules: Rules written for Windows or Linux often cannot be adapted to macOS due to field name mismatches and log source incompatibilities
• Manual query writing: Security analysts must manually convert detection logic to Elasticsearch queries, Splunk SPL, or other SIEM query languages, increasing time-to-detection and reducing consistency
• Limited community sharing: The lack of standardized pipelines prevents the security community from effectively sharing macOS detection rules

The Solution: macOS coreSigma

We've developed macOS coreSigma, a macOS endpoint telemetry collection, detection, and analysis app built with the primary goal of extending Sigma's capabilities for macOS ESF and UL logs. As a proof of concept, we’ve built ESF and UL collectors & pipelines and are using a custom Elasticsearch backend to support these pipelines and better handle macOS events and rules utilizing new event types and fields. We then are able to view these events and rule matches in Kibana.

coreSigma includes:

• Comprehensive Pipeline Configurations: Field mappings and log source definitions that translate native macOS event formats to Sigma-compatible field names
• Custom Backend Support: Enhanced Elasticsearch backend integration for seamless rule conversion
• Extensive Event Coverage: Support for (23) ESF event types and (12) UL subsystems
• Intelligent Filtering: 98.5% log volume reduction while maintaining 100% security coverage
• 50 Production-Ready Rules: Including kernel extension detection, defense evasion, privilege escalation, and network security mappings, sharing detection rules between organizations becomes impractical.

Individual components of coreSigma (new ESF and UL pipelines) have been submitted as PRs to Sigma's official GitHub pySigma project. We are actively engaged with the Sigma team and community to submit these as official macOS additions to the Sigma ecosystem.

Author note: We landed on the name coreSigma, as a “clever” nod to Apple’s “Core Foundation” framework. SPAM4ME&U didn't seem like a very inviting handle – Sigma Pipeline and Mappings 4 macOS Endpoint (Security Framework) and Unified (Logging). Shoutout to Nebulock’s own, Sydney Maronne, for the suggestion.

Architecture and Design

Pipeline Structure

Our solution consists of two main pipeline configurations, following the pySigma YAML pipeline format:

ESF Pipeline (pipelines/macos_esf.yml)

The ESF pipeline handles kernel-level security events with comprehensive field mappings:

‍name: macos-esf
priority: 100
transformations:
 - type: field_name_mapping
   mapping:
     # Process fields - standard Sigma fields
     Image: Image
     CommandLine: CommandLine
     ProcessId: ProcessId
     ParentProcessId: ParentProcessId
     
     # Kernel extension fields
     kext.identifier: kext.identifier
     kext.path: kext.path
     kext.team_id: kext.team_id
     
     # Signal fields
     signal.number: signal.number
     target.process.path: target.process.path
     
     # XPC fields
     xpc.service_name: xpc.service_name
     
     # Event metadata
     event_type: event_type
     event_name: event_name


Log Source Categories:

The pipeline defines 10+ log source categories:

• process_creation: Process execution events (event_type 9)
• file_event: File operations (CREATE, OPEN, WRITE, UNLINK, RENAME)
• kernel_extension: Kext load/unload (event_types 17, 18)
• process_signal: Process signals (event_type 27)
• xpc_connection: XPC connections (event_type 65)
• authentication: Login and authentication (event_type 111)
• privilege_escalation: Setuid/setgid operations (event_types 24, 25)
• codesigning: Code signature validation failures (event_type 62)
• security_policy: XProtect, Gatekeeper, TCC events (event_types 112, 113, 146, 147)

Event Type Coverage:

We collect (23) ESF event types, including:

• Process Events: exec (9), fork (11), exit (28)
• File Events: open (10), create (13), unlink (19), rename (21)
• Memory Events: mprotect (20) - filtered to W+X only for code injection detection
• Kernel Events: kextload (17), kextunload (18)
• Security Events: signal (27), xpc_connect (65), authentication (111)
• Security Policy: xp_malware_detected (112), tcc_modify (147), gatekeeper_user_override (146)

UL Pipeline (pipelines/macos_ul.yml)

The Unified Logging pipeline handles application and system log events with subsystem-based log sources:

• tcc: Transparency, Consent, and Control events (subsystem: com.apple.TCC)
• gatekeeper: Application trust and execution policy
• sudo: Privilege escalation via sudo
• firewall: Application Layer Firewall (subsystem: com.apple.alf)
• network: Network subsystem events (subsystem: com.apple.network)

Data Collection and Normalization

ESF Collector

The ESF collector (network collectors/esf_collector.py) bridges native ESF events to Sigma-compatible format:

def normalize_event(self, esf_event: Dict[str, Any]) -> Dict[str, Any]:
   """Normalize ESF event to Sigma-compatible field names"""
   event_type = esf_event.get("event_type")
   event_name = ESF_EVENT_TYPE_MAP.get(event_type, "unknown")
   
   normalized = {
       "@timestamp": esf_event.get("time"),
       "event_type": event_type,
       "event_name": event_name,
       "ProcessId": audit_token.get("pid"),
       "Image": executable.get("path", ""),
       "CommandLine": " ".join(args),
   }
   
   # Handle kernel extension load
   if event_type == 17:
       kext_info = esf_event.get("event", {}).get("kextload", {}).get("kext", {})
       normalized["kext.identifier"] = kext_info.get("identifier", "")
       normalized["kext.path"] = kext_info.get("path", "")
       normalized["kext.team_id"] = kext_info.get("team_id", "")
   
   # Handle process signals
   elif event_type == 27:
       signal_data = esf_event.get("event", {}).get("signal", {})
       normalized["signal.number"] = signal_data.get("sig", 0)
       normalized["target.process.path"] = signal_data.get("target",
   {}).get("process", {}).get("executable", {}).get("path", "")
   
   return normalized

Key normalization steps:

1. Extract process information from nested process.audit_token structure
2. Flatten command-line arguments array to single string
3. Map event-specific data structures (kext info, signal targets, XPC services, etc.)
4. Preserve full event structure for advanced queries while providing flat fields for Sigma compatibility

Using our ESF and UL pipelines & collectors, and modified Elasticsearch Sigma backend, we were able to collect these new macOS endpoint events and ingest these into Elastic for viewing in Kibana.

‍

‍

Detection Capabilities

Example Detection Rules

Our repository includes (50) production-ready Sigma rules. Here are key examples:

1. Unsigned Kernel Extension Load (CRITICAL)

This rule detects attempts to load unsigned kernel extensions, ESF - kextload (17), a critical indicator of rootkit installation or malicious kernel-level access.

title: Unsigned Kernel Extension Load Attempt
id: 7e7a1a47-45dd-4f97-8205-1d6aea67f682
status: experimental
description: Detects attempts to load unsigned kernel extensions which may indicate
rootkit installation or malicious kernel-level access.
references:
- https://attack.mitre.org/techniques/T1547/006/
- https://objective-see.com/blog/blog_0x4B.html author: Eric Brown - Nebulock, Inc.
date: 2025/10/29
tags:
- attack.persistence
- attack.privilege_escalation
- attack.t1547.006
logsource:
  product: macos
  service: endpointsecurity
  category: kernel_extension
detection:
  selection:
    event_type: 17
    event_name: kextload
  filter_signed:
    kext.team_id: '*'
  condition: selection and not filter_signed
falsepositives:
- Legitimate unsigned kexts in development environments
- Testing scenarios
level: critical

Converted Elasticsearch Query:

(event_type:17 AND event_name:kextload) AND (NOT kext.team_id:*)


‍

2. SIGKILL Sent to Security Tools (HIGH)

This rule detects defense evasion attempts where malware terminates security tools using ESF SIGKILL (signal 9) events.


title: SIGKILL Sent to Security Tools
id: 3028231e-acae-4e0b-88a6-3044502c7478
status: experimental
description: Detects SIGKILL signals sent to security tools which may indicate
defense evasion.
references:
- https://attack.mitre.org/techniques/T1562/001/ author: Eric Brown - Nebulock, Inc.
date: 2025/10/29
tags:
- attack.defense_evasion
- attack.t1562.001
logsource:
  product: macos
  service: endpointsecurity
  category: process_signal
detection:
  selection:
    event_type: 27
    event_name: signal
    signal.number: 9
    target.process.path|endswith:
      - /LittleSnitch
      - /BlockBlock
      - /KnockKnock
      - /OverSight
      - /ReiKey
      - /Santa
      - /xprotectd
      - /MRT
      - /CrowdStrike
      - /SentinelOne
  condition: selection
falsepositives:
- System updates
- Legitimate process management
level: high

Converted Elasticsearch Query:

event_type:27 AND event_name:signal AND signal.number:9 AND
target.process.path:(*xprotectd OR *LittleSnitch OR *BlockBlock OR *KnockKnock OR
*OverSight OR *ReiKey OR *Santa OR *MRT OR *CrowdStrike OR *SentinelOne)

‍

3. UL Quarantine or XProtect Detection (HIGH)

This rule detects UL events referencing quarantine (LSQuarantine) or XProtect malware detections, providing an alternative detection method via system logs.

title: macOS ULS Quarantine or XProtect Detection
id: 0a1b2c3d-4e5f-4789-abcd-ef0123456789
status: experimental
description: Detect logs referencing quarantine (LSQuarantine) or XProtect malware
  detections.
author: Eric Brown - Nebulock, Inc.
date: 2025-10-29
logsource:
  product: macos
  service: unifiedlog
level: high
detection:
  selection:
    message|contains:
    - LSQuarantine
    - XProtect
    - Malware removed
  condition: selection
falsepositives:
- rare, but test systems may trigger intentionally
modified: 2025/01/15


Converted Elasticsearch Query:

message:(*LSQuarantine* OR *XProtect* OR *Malware removed*)

‍

Rule Statistics

• Total Rules: 50
• ESF Rules: 38 (covering 23 event types)
• UL Rules: 12 (covering 12 subsystems)
• Critical/High Severity: 24 rules
• MITRE ATT&CK Coverage:
  • T1547.006: Persistence - Kernel Modules and Extensions
  • T1562.001: Defense Evasion - Impair Defenses: Disable or Modify Tools
  • T1059: Execution - Command and Scripting Interpreter
  • T1021.004: Lateral Movement - Remote Services: SSH
  • T1570: Lateral Movement - Lateral Tool Transfer
  • T1489: Impact - Service Stop
  • T1068: Privilege Escalation - Exploitation for Privilege Escalation
  • T1559: Execution - Inter-Process Communication
  • …and more

Benefits and Impact

For Security Teams

• Standardized Detection Rules: Write once, deploy to multiple SIEM platforms
• Faster Time-to-Detection: Convert existing Windows/Linux rules to macOS with minimal modification
• Community Collaboration: Share and consume detection rules across organizations
• Consistent Field Names & Mappings: Use familiar field names (Image, CommandLine, etc.) across platforms; Field mappings enable rule portability
• Comprehensive Coverage: Detect threats across (23) ESF event types and (12) UL subsystems
• Production Ready: 50 tested rules covering critical security scenarios
• Open Source: Complete solution available on GitHub (COMING SOON)

Advancing macOS Detection for the Security Community

The macOS Sigma framework presented here aims to uplift the broader security community by closing long-standing visibility gaps on macOS endpoints, especially in environments where enterprise-grade EDR platforms are not feasible due to cost, complexity, or “customizability”. By leveraging native telemetry from the Endpoint Security Framework and Unified Logging, this solution empowers detection engineers and threat hunters to widen their aperture and harness high-fidelity, platform-native data sources.

This visibility expansion is essential as macOS continues to face increased targeting from ransomware, espionage actors, and commodity malware campaigns. The framework helps defenders proactively detect and respond to suspicious or malicious behavior through portable, scalable, and community-driven detection content.

Whether you're an individual researcher, a blue-teamer at a startup, or part of a mature SOC looking to enrich macOS telemetry, these tools and methods offer an open and extensible foundation for advancing macOS defense.

Stay Tuned

Keep an eye out for more posts in this macOS series, where we’ll be expanding the macOS Sigma framework with additional detection & hunt-focused rulesets, Splunk and Elastic pipelines with alerting and dashboarding, event and detection tuning guidelines, and of course, sharing this new coreSigma build-out for protecting your macOS ecosystem.

Special thanks to these contributors:

Christopher Witter - Witter's observations of the current macOS Sigma gaps were the catalyst for this project.

Sydney Marrone - For sharing her knowledge and learnings of macOS systems with the Nebulock team (and helping find a much better name for this research).