coreSigma: Developing an Endpoint Security Framework Pipeline

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 events

What 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)
"denied", "failed", "rejected", "blocked", "invalid",
"violation", "unauthorized", "suspicious", "malware",
"quarantine", "xprotect", "codesign", "COMMAND="

# Noise keywords (filter from non-critical subsystems)
"succeeded", "allowed", "completed successfully"

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)
python3 scripts/deploy_sigma_rules.py --dry-run
# Deploy and enable rules
python3 scripts/deploy_sigma_rules.py --enable

The deployment script:

1. ‍Loads Sigma rules from the rules/esf/ or rules/ul/ directories‍
2. Converts to EQL (ESF rules) or Lucene (UL rules) using the pySigma backend‍
3. 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‍
4. Optionally enables rules for immediate alerting

Currently, coreSigma ships with 57 production-ready Sigma rules:

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 breakdown
• Users & Groups - Activity by user/group identity
• Events Over Time - Stacked area chart by event type
• Top/Rare Process Analysis - Executables, command lines, and parent → child relationships

The 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 distribution
• Events by Process - Which processes generate security-relevant logs
• Security Subsystems Table - Detailed counts per logger
• Timeline - Stacked bar chart of subsystem activity over time

Sigma Rule Triggers Overview

When detection rules fire, this dashboard shows:

• Total Alerts - Overall alert count
• Alerts by Severity - Distribution across critical, high, medium, low
• Top Triggered Rules - Which rules fire most frequently
• Alerts Over Time - Timeline of alert activity
• All Triggered Rules - Detailed table of every triggered rule

Detection 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:
  selection:
    event.action: signal
    signal.number: 9
    target.process.executable|endswith:
      - /LittleSnitch
      - /BlockBlock
      - /Santa
      - /CrowdStrike
      - /xprotectd

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
git clone https://github.com/Nebulock-Inc/macos-coresigma.git
cd macos-coresigma
# Setup environment
./setup.sh
source venv/bin/activate
# Start Elasticsearch and Kibana (Docker)
docker-compose up -d
# Note: ESF collector requires Full Disk Access for your terminal app
# Grant via System Settings → Privacy & Security → Full Disk Access
# Configure credentials (stores in macOS Keychain + syncs to Docker .env)
./scripts/setup_credentials.sh --sync-docker
# Start collectors
sudo python3 collectors/esf_collector.py --output elasticsearch
python3 collectors/ul_collector.py --output elasticsearch
# Deploy Sigma rules
python3 scripts/deploy_sigma_rules.py --enable
# Import dashboards
# Kibana → Stack Management → Saved Objects → Import
# Select exports/all_dashboards_latest.ndjson

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 coverage
• Correlation rules: detecting multi-stage attacks across ESF and UL events
• Custom backend support: building pipelines for additional SIEM platforms

The 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.