GitHub - 0xv1n/macnoise: Extensible MacOS system telemetry generator.

MacNoise is an extensible and modular macOS system telemetry generation framework. It generates real system events (network connections, file writes, process spawns, plist mutations, TCC permission probes, and more) so security teams can validate that their EDR, SIEM, and firewall tooling detects what it is supposed to detect.

For background on the motivation and design, see the release blog post.

Quick Start

# Build
make build

# List available modules
./macnoise list

# Run a single module
./macnoise run net_connect --param target=127.0.0.1 --param port=8080

# Preview without executing
./macnoise run svc_launch_agent --dry-run

# Run all network modules
./macnoise run --category network

# Run a scenario
./macnoise scenario configs/scenarios/edr_validation.yaml

# Emit structured JSONL output
./macnoise run --category file --format jsonl --output /tmp/events.jsonl

Telemetry Categories

Commands

macnoise run <module> [--param key=val ...]   Run a specific module
macnoise run --category <cat>                 Run all modules in a category
macnoise run --all                            Run all modules
macnoise list [--category <cat>]              List modules
macnoise info <module>                        Show module details, params, MITRE
macnoise scenario <file.yaml>                 Run a YAML scenario
macnoise categories                           List categories with counts
macnoise version                              Print version

Global Flags

Audit Logging

MacNoise produces two distinct output streams:

• Telemetry events: the TelemetryEvent records written to stdout (or a file via --output) by every module. These are what your EDR, SIEM, or firewall sees.
• Audit records: a separate, structured log of what MacNoise itself did: which modules ran, prereq outcomes, timing, events emitted, cleanup results, and MITRE technique mappings.

Audit records are written in OCSF 1.7.0 (Open Cybersecurity Schema Framework) JSONL format. Each record maps to a valid OCSF class (HTTP: 4002, DNS: 4003, network: 4001, file system: 1001, etc.), with MacNoise-specific fields placed in the unmapped object so the record remains schema-compliant.

Enable audit logging with --audit-log:

# Audit a single module run
./macnoise run net_connect --audit-log /tmp/audit.jsonl

# Audit a full scenario
./macnoise scenario configs/scenarios/amos_atomic_stealer.yaml \
  --audit-log /tmp/amos_audit.jsonl --format jsonl

# Audit log path can also be set per-scenario in the YAML (audit_log: /tmp/audit.jsonl)
# or as a default in a config file passed via --config

Each OCSF record contains:

The audit log is opened in append mode, so records from multiple runs accumulate in one file for batch analysis. Lifecycle records (prereq check, dry-run, cleanup) are written automatically by the runner; individual modules require no changes.

Module Reference

Module documentation lives alongside each category:

MITRE ATT&CK Coverage

Scenarios

Scenarios chain modules into ordered sequences that emulate realistic attacker behavior. Each step runs a module or an entire category, optionally with params, making it straightforward to replay multi-stage intrusion patterns against your detections.

Pre-built scenarios are in configs/scenarios/ to provide users with an example of the framework's capabilities:

APT Scenarios

The APT emulation scenarios follow documented intrusion sequences attributed to real threat groups, mapped to MITRE ATT&CK. Each step is annotated with the technique it exercises so you can correlate generated telemetry directly against expected alerts.

Lazarus Group (lazarus_group.yaml)

Models a DPRK-style implant deployment: dropper execution → dylib injection into a legitimate process → XPC service enumeration → DNS C2 → reverse shell attempt → payload staging → plist persistence → persistent beaconing.

AMOS / Atomic macOS Stealer (amos_atomic_stealer.yaml)

Models the full 2025 variant kill chain across 10 phases: Gatekeeper bypass → defense evasion → credential access (keychain, browser sweeps) → discovery → collection → staging → exfiltration → cleanup → persistence → C2 establishment. Unlike the APT scenarios, AMOS is financially motivated crimeware with an aggressive, fast-moving collection profile.

Validating Scenarios

Dry-run first: preview the full sequence without executing anything:

./macnoise scenario configs/scenarios/<scenario>.yaml --dry-run

Structured output for automated correlation: emit JSONL so every event carries module name, params, timestamps, and outcome:

./macnoise scenario configs/scenarios/<scenario>.yaml --format jsonl --output /tmp/<scenario>.jsonl

Check individual module behavior before running a scenario: inspect params and MITRE mappings:

./macnoise info proc_inject

Cross-reference with your SIEM/EDR: each step comment in the scenario YAML includes the expected MITRE technique. Use those to search for corresponding alerts after the run. If an alert is missing, the module that maps to that technique is a gap in your coverage.

Writing Custom Scenarios

name: My Custom Scenario
steps:
  - module: net_connect
    params:
      target: "192.168.1.1"
      port: "443"
  - category: file
    params:
      base_dir: "/tmp/test"

Building

make build          # host OS
make build-amd64    # darwin/amd64
make build-arm64    # darwin/arm64
make release        # both Darwin architectures

Contributing

See CONTRIBUTING.md for how to add new modules, code style expectations, and the PR process.

This project follows Semantic Versioning. Every PR that changes user-visible behaviour must include a CHANGELOG.md entry under [Unreleased].

Disclaimer

MacNoise is intended for authorized security testing, EDR validation, and detection engineering on systems you own or have explicit written permission to test. The authors assume no liability for misuse.

AI Code Policy

AI Code contributions are fine, but please keep in mind that code review is currently going to be a human-led process which means there is only so much code we can review. Please limit PRs to a specific fix, or new telemetry module. PRs with extensive changes are likely going to be closed.