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 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:
Endpoint Security Framework (ESF) Unified Logging (UL) 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 incompatibilitiesManual 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 consistencyLimited 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
coreSigma includes:
Comprehensive Pipeline Configurations : Field mappings and log source definitions that translate native macOS event formats to Sigma-compatible field namesCustom Backend Support : Enhanced Elasticsearch backend integration for seamless rule conversionExtensive Event Coverage : Support for (23) ESF event types and (12) UL subsystemsIntelligent Filtering : 98.5% log volume reduction while maintaining 100% security coverage50 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
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 detectionKernel 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]:
Key normalization steps:
Extract process information from nested process.audit_token structure Flatten command-line arguments array to single string Map event-specific data structures (kext info, signal targets, XPC services, etc.) 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.
ESF & UL Collection Stats Dashboard in Kibana
ESF event example as Elastic document
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
Converted Elasticsearch Query :(event_type:17 AND event_name:kextload) AND (NOT kext.team_id:*)
Triggered ESF Sigma Unsigned 'kextload' query via Elastic Saved Search conversion
2. SIGKILL Sent to Security Tools (HIGH) This rule detects defense evasion attempts where malware terminates security tools using ESF SIGKILL (signal 9) events.
Converted Elasticsearch Query :event_type:27 AND event_name:signal AND signal.number:9 AND
Triggered ESF Sigma 'SIGKILL' query via Elastic Saved Search conversion
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
Converted Elasticsearch Query :message:(*LSQuarantine* OR *XProtect* OR *Malware removed*)
Triggered UL Sigma Unsigned 'XProtect Malware' query via Elastic Saved Search conversion
Rule Statistics Total Rules : 50ESF Rules : 38 (covering 23 event types)UL Rules : 12 (covering 12 subsystems)Critical/High Severity : 24 rulesMITRE 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 platformsFaster Time-to-Detection : Convert existing Windows/Linux rules to macOS with minimal modificationCommunity Collaboration : Share and consume detection rules across organizationsConsistent Field Names & Mappings : Use familiar field names (Image, CommandLine, etc.) across platforms; Field mappings enable rule portabilityComprehensive Coverage : Detect threats across (23) ESF event types and (12) UL subsystemsProduction Ready : 50 tested rules covering critical security scenariosOpen 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).
