MacNoise

MacNoise erzeugt echte macOS-Telemetrie: Netzwerkverbindungen, Dateischreibvorgänge, Prozessstarts, Plist-Mutationen, TCC-Sonden und mehr. Richten Sie es auf eine Maschine, auf der Ihr EDR-, SIEM- oder Firewall-Stack läuft, und sehen Sie, was tatsächlich ausgelöst wird – nicht das, was das Datenblatt des Anbieters behauptet.

Hintergrund zu Motivation und Design finden Sie im Release-Blogbeitrag.

Schnellstart

# Build (build-amd64 / build-arm64 für Cross-Compile auf Darwin hinzufügen, oder release für beides)
make build

# Verfügbare Module auflisten
./macnoise list

# Ein einzelnes Modul ausführen
./macnoise run net_connect --param target=127.0.0.1 --param port=8080

# Vorschau ohne Ausführung
./macnoise run svc_launch_agent --dry-run

# Alle Netzwerkmodule ausführen
./macnoise run --category network

# Ein Szenario ausführen
./macnoise scenario configs/scenarios/edr_validation.yaml

# Strukturierte JSONL-Ausgabe erzeugen
./macnoise run --category file --format jsonl --output /tmp/events.jsonl

Telemetriekategorien

Befehle

macnoise run <module> [--param key=val ...]   Ein bestimmtes Modul ausführen
macnoise run --category <cat>                 Alle Module einer Kategorie ausführen
macnoise run --all                            Alle Module ausführen
macnoise list [--category <cat>]              Module auflisten
macnoise info <module>                        Moduldetails, Parameter, MITRE anzeigen
macnoise scenario <file.yaml>                 Ein YAML-Szenario ausführen
macnoise categories                           Kategorien mit Anzahl auflisten
macnoise version                              Version ausgeben

Globale Flags

Artefakte an Ort und Stelle belassen

Standardmäßig macht jedes Modul seine Änderungen rückgängig, wenn es fertig ist. Das ist normalerweise das, was Sie wollen, aber es bedeutet, dass eine Erkennung nur das Installationsereignis sieht. Um zu validieren, dass Ihr Stack die Persistenz selbst erkennt – einen LaunchAgent in ~/Library/LaunchAgents, einen cron-Eintrag, ein geändertes Shell-Profil – muss das Artefakt noch vorhanden sein, wenn der Scan läuft:

./macnoise run svc_launch_agent --no-cleanup

Jedes Modul, das die Bereinigung überspringt, gibt eine Zeile mit seinem Namen aus, und das Audit-Log protokolliert cleanup_result: skipped statt ok, sodass ein Lauf, der Persistenz hinterlassen hat, niemals mit einem verwechselt wird, der aufgeräumt hat. Verwenden Sie macnoise info <module>, um zu sehen, was ein bestimmtes Modul erstellt.

Sie sind dafür verantwortlich, diese selbst zu entfernen. Das erneute Ausführen desselben Moduls ohne das Flag bereinigt nur das, was dieser Lauf erstellt hat, nicht das, was ein früherer --no-cleanup-Lauf hinterlassen hat.

Audit-Protokollierung

MacNoise schreibt zwei getrennte Streams. Telemetrieereignisse – was Ihr EDR/SIEM tatsächlich sieht – gehen an stdout oder --output. Ein zweiter, optionaler Stream protokolliert, was MacNoise selbst getan hat: welche Module liefen, Voraussetzungs-/Bereinigungsergebnisse und MITRE-Zuordnungen, im OCSF-1.7.0-JSONL-Format.

./macnoise scenario configs/scenarios/amos_atomic_stealer.yaml --audit-log /tmp/audit.jsonl

Jedes Telemetrieereignis trägt ein outcome neben success (Schema 1.1). success sagt, ob MacNoise funktioniert hat; outcome sagt, was mit der versuchten Aktion passiert ist:

Eine verweigerte TCC-Sonde oder ein Beacon zu einem toten C2 ist die Telemetrie, für deren Erzeugung dieses Tool existiert, also bleiben diese success: true und werden durch outcome unterschieden. Nur error setzt success: false. Im Audit-Log erscheint derselbe Wert unter unmapped.outcome, da der OCSF-status eine verweigerte Aktion und ein defektes Tool identisch aufzeichnet.

Das Audit-Log wird im Anhängemodus geöffnet, sodass sich Datensätze aus mehreren Läufen in einer Datei für die Stapelanalyse ansammeln. Wenn Sie ein Modul hinzufügen und wissen möchten, wie ein neuer Ereignistyp in OCSF klassifiziert wird, siehe CONTRIBUTING.md.

Modulreferenz

Die Moduldokumentation befindet sich neben jeder Kategorie:

Szenarien

Szenarien verketten Module zu geordneten Sequenzen – eine einzelne YAML-Datei, die ein mehrstufiges Eindringmuster gegen Ihre Erkennungen abspielt.

Die beiden APT-Szenarien folgen echten dokumentierten Eindringsequenzen, Technik für Technik – jede YAML-Datei zitiert die tatsächliche Threat Intelligence, auf der sie aufbaut, und annotiert jeden Schritt mit der MITRE-Technik, die er ausübt. Beginnen Sie also dort für die vollständige Aufschlüsselung, statt einer Nacherzählung hier.

Zuerst Trockenlauf:

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

Querverweis mit Ihrem SIEM/EDR: Jeder Schrittkommentar benennt die Technik, die er auslösen sollte. Keine passende Warnung nach einem echten Lauf ist eine Lücke in Ihrer Abdeckung.

Eigene Szenarien schreiben:

name: Mein Benutzerdefiniertes Szenario
steps:
  - module: net_connect
    params:
      target: "192.168.1.1"
      port: "443"
  - category: file
    params:
      base_dir: "/tmp/test"

Mitwirken

Siehe CONTRIBUTING.md für das Hinzufügen neuer Module, Codestil und den vollständigen PR-Prozess.

Releases sind automatisiert – release-please erstellt eine neue Version direkt aus Ihrem Conventional-Commit-PR-Titel, sodass feat: add net_tls module oder fix: correct beacon jitter sowohl Ihr PR-Titel als auch Ihr Changelog-Eintrag ist.

Haftungsausschluss

MacNoise ist für autorisierte Sicherheitstests, EDR-Validierung und Detection Engineering auf Systemen gedacht, die Ihnen gehören oder für die Sie eine ausdrückliche schriftliche Testgenehmigung haben. Die Autoren übernehmen keine Haftung für Missbrauch.

KI-Code-Richtlinie

KI-Code-Beiträge sind in Ordnung, aber bitte beachten Sie, dass die Code-Review derzeit ein menschlich geführter Prozess ist, was bedeutet, dass wir nur eine begrenzte Menge an Code reviewen können. Bitte beschränken Sie PRs auf eine bestimmte Korrektur oder ein neues Telemetriemodul. PRs mit umfangreichen Änderungen werden wahrscheinlich geschlossen.