We’ve continued to improve coreSigma to make it easier for the community to implement. Read Part 1 for the background on this research and our approach to closing detection gaps for the macOS ecosystem.
The need for standardized macOS detection capabilities is clear. Based on the response to introducing coreSigma, we wanted to make it even easier for the community to gain additional macOS observability and implement their own macOS detections in their environment. That’s why we’ve made coreSigma publicly available in the Nebulock GitHub repository .
Sigma Approved: Endpoint Security Framework (ESF) Pipeline Our macOS Endpoint Security Framework (ESF) pipeline has been approved by Sigma maintainers and merged into the pySigma backend for Elasticsearch.
A huge thank you to Thomas Patzke and the Sigma team for their thorough review and guidance throughout the process. Getting macOS telemetry properly integrated into the Sigma ecosystem has been the ultimate goal & driver of this project, and this milestone represents a significant step toward that vision.
What This Means for You If you're using pySigma with Elasticsearch, you can now convert macOS ESF Sigma rules to EQL (Event Query Language) out of the box. The pipeline handles:
Field mapping : Sigma taxonomy fields (Image , CommandLine , ProcessId ) map to ECS-compliant fields (process.executable , process.command_line , process.pid )Log source conditions : Automatic event type filtering based on rule categories (process_creation , file_event , kernel_extension , etc.)23+ ESF event types : Full coverage from process execution to authentication, kernel extensions, and security policy eventsWhat about Unified Logging and Splunk? We prioritized ESF for Elasticsearch to deliver coreSigma, and the following are currently in development:
Unified Logging (UL) pySigma pipeline for Elasticsearch - Field mappings for 12+ macOS subsystems including TCC , Gatekeeper , sudo , and firewall events (the in-dev UL pipeline is already packaged with coreSigma ).ESF and UL pipelines for additional backends - Splunk and other SIEM platforms are on the roadmap as development continues.We're committed to working with the Sigma community to ensure macOS detection rules are as portable as their Windows and Linux counterparts.
Application Updates: Enhanced Telemetry Collection Since the start of this project, we've made significant improvements to the telemetry collectors. Here's what's new:
ESF Collector Enhancements Expanded Event Coverage
The ESF collector now supports over 45 ESF event types, with intelligent filtering to reduce noise while maintaining security coverage. Key additions include:
Process injection events (trace /ptrace , remote_thread_create )OpenDirectory events (user creation, deletion, password modification)Screen sharing events (attach /detach )Profile events (MDM profile add/remove)Enhanced authentication (login/logout events)Intelligent Noise Filtering
Endpoint telemetry can be inherently noisy, and macOS ESF is no exception. The ESF collector achieves approximately 98.5% log volume reduction while maintaining security-relevant coverage. The filtering logic:
Always keeps critical event types (exec , authentication , kextload , signal , xpc_connect , etc.) Filters mprotect events to only W+X memory mappings (code injection indicators) Path-based filtering for file events to security-relevant locations Sampling for high-volume events from noisy but trusted processes You can disable filtering with --no-filtering if you want additional telemetry, or run collectors with --daemon for background operation with auto-restart.
UL Collector Improvements New Subsystems
We've expanded UL collection to include:
com.apple.ManagedClient - MDM and enterprise policy events com.apple.launchd - Persistence mechanism activity com.apple.xpc - Inter-process communication security events com.apple.authd - Authentication decision events Signal vs Noise Filtering
The UL collector now intelligently filters based on message content:
# Signal keywords (always keep)
Critical subsystems (TCC, sudo, gatekeeper, syspolicy) bypass noise filtering entirely.
Note on Tuning & Filtering : These filtering defaults are starting points, not universal prescriptions. Events classified as "noise" in one environment may be valuable signals in another. For example, successful sudo executions might be low-volume and highly relevant for environments with strict acceptable use policies. We recommend testing coreSigma's filtering settings in your environment before production deployment, as the only way to truly understand signal-to-noise ratios is to observe them against your own baseline. Use --no-filtering during evaluation to capture everything, then tune based on what matters to your security operations.
Automated Rule Deployment: Sigma to Kibana One of coreSigma's most powerful features is the automated deployment pipeline. With a single command, you can convert Sigma rules to Elasticsearch queries and deploy them as Kibana Detection Rules.
How It Works # Deploy all ESF rules (dry-run first)
The deployment script:
Loads Sigma rules from the rules/esf/ or rules/ul/ directories Converts to EQL (ESF rules) or Lucene (UL rules) using the pySigma backend Creates Detection Rules in Kibana with proper metadata:MITRE ATT&CK mappings extracted from rule tags Severity and risk scores from rule level References and false positives preserved Optionally enables rules for immediate alertingCurrently, coreSigma ships with 57 production-ready Sigma rules :
Category Count Examples ESF Rules 38 Unsigned kextload, SIGKILL to security tools, W+X memory UL Rules 19 TCC bypass, sudo failures, SIP modification, keychain access
New Dashboards: Visibility at a Glance We've built three Kibana dashboards that ship with coreSigma:
macOS Endpoint Security (ESF) Telemetry Overview This dashboard provides comprehensive visibility into ESF events:
Event Actions - Distribution of exec , fork , create , signal , etc.Event Types - Numeric ESF event type breakdownUsers & Groups - Activity by user/group identityEvents Over Time - Stacked area chart by event typeTop/Rare Process Analysis - Executables, command lines, and parent → child relationshipsThe parent-child process tables are particularly useful for identifying unusual execution chains.
macOS Unified Logging Overview Visibility into UL subsystems:
Events by Subsystem - TCC , sudo , gatekeeper , firewall distributionEvents by Process - Which processes generate security-relevant logsSecurity Subsystems Table - Detailed counts per loggerTimeline - Stacked bar chart of subsystem activity over timeSigma Rule Triggers Overview When detection rules fire, this dashboard shows:
Total Alerts - Overall alert countAlerts by Severity - Distribution across critical, high, medium, lowTop Triggered Rules - Which rules fire most frequentlyAlerts Over Time - Timeline of alert activityAll Triggered Rules - Detailed table of every triggered ruleDetection Rules Monitoring Native Kibana rule performance monitoring for tracking rule execution health and status.
All dashboards are included in exports/all_dashboards_latest.ndjson and can be imported via Kibana's Stack Management.
Threat Hunting with coreSigma The real power of coreSigma emerges when you use it for threat hunting. Let's walk through how to leverage ESF and UL datasets to hunt for the kinds of behaviors that Nebulock's Sydney Marrone outlined in her DigitStealer analysis .
Hunting Initial Access and Execution Chains DigitStealer and similar macOS infostealers rely on DMG-based delivery and scripting execution chains. In coreSigma's ESF telemetry, you can hunt for these patterns using the parent → child relationship data.
Start by looking for osascript or bash executing from unusual parent processes:
process.name:osascript AND NOT process.parent.executable:(/System/*)
Or hunt for the classic curl → bash → osascript chain by examining exec events where the parent is a shell interpreter downloading content:
process.parent.name:(bash OR zsh OR sh) AND process.parent.command_line:*curl*
The "Rare Parent → Child Process Names " panel on the ESF dashboard is designed specifically for this type of hunting. Unusual execution chains will stand out against your baseline.
Hunting Defense Evasion and Credential Access ESF signal events (event type 27) are gold for detecting defense evasion attempts. When malware tries to terminate security tools, it typically sends SIGKILL (signal 9). Our sigkill_sent_to_security_tools.yml rule catches this:
detection:
Note: You will likely need to update the target.process.executable list with your internal security tools.
For credential access hunting, the UL dataset captures keychain access events. Look for the security command being invoked from script interpreters:
log.logger:com.apple.securityd AND message:*keychain*
Combined with ESF exec events showing security find-generic-password invoked by bash or python, you can identify credential harvesting behavior.
Hunting Persistence and C2 ESF file create events to LaunchAgent /LaunchDaemon paths are a strong persistence indicator. The coreSigma rule macos_esf_launch_persistence_creation.yml covers this, but for hunting you can broaden the search:
event.action:create AND file.path:(*LaunchAgents* OR *LaunchDaemons*)
For C2 detection, UL's network subsystem and ESF's exec events for curl , wget , or dig are key. Hunt for DNS TXT queries (unusual for legitimate traffic) or repeated outbound POST requests from script contexts:
process.name:(curl OR wget OR dig) AND process.parent.name:(bash OR osascript OR python)
The key insight from Sydney's analysis applies perfectly here: hunt the behavior, not the indicator . Every infostealer must execute, evade, access credentials, collect, persist, communicate, and exfiltrate. Each stage leaves traces in ESF and UL telemetry that coreSigma can help you find.
Get Started with coreSigma Ready to deploy coreSigma ? Here's the quick start:
# Clone the repository# Setup environment# Start Elasticsearch and Kibana (Docker)# Note: ESF collector requires Full Disk Access for your terminal app# Configure credentials (stores in macOS Keychain + syncs to Docker .env)# Start collectors# Deploy Sigma rules# Import dashboards
Full documentation is available in the repository's docs / directory.
What's Next for coreSigma We'll continue to develop and improve coreSigma. Some areas we're exploring:
Rule tuning guides : how to reduce false positives without losing coverageCorrelation rules : detecting multi-stage attacks across ESF and UL eventsCustom backend support : building pipelines for additional SIEM platformsThe project is open source and we welcome contributions, feedback, and feature requests.
We built this to solve a real gap in macOS security visibility, but the project is only as strong as the community using it. If you deploy coreSigma, find a bug, write a rule, or have ideas for improvement, we want to hear about it.
Open an issue, submit a PR, or reach out directly. Let's close the macOS detection gap together.
Special thanks to:
The Sigma team, particularly Thomas Patzke, for their support in getting the macOS ESF pipeline officially accepted into the pySigma ecosystem. 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). The rest of the Nebulock team for testing and providing valuable feedback. 
