MacNoise

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

Für Hintergründe zu Motivation und Design siehe den Release-Blogbeitrag.

Schnellstart

# Build (build-amd64 / build-arm64 hinzufügen, um für Darwin zu cross-kompilieren, 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

Telemetrie-Kategorien

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 und MITRE anzeigen
macnoise scenario <file.yaml>                 Ein YAML-Szenario ausführen
macnoise categories                           Kategorien mit Anzahl auflisten
macnoise version                              Version anzeigen

Globale Flags

Artefakte an Ort und Stelle hinterlassen

Standardmäßig macht jedes Modul seine Änderungen rückgängig, sobald es fertig ist. Das ist normalerweise gewünscht, bedeutet aber, 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 modifiziertes Shell-Profil – muss das Artefakt noch vorhanden sein, wenn der Scan läuft:

./macnoise run svc_launch_agent --no-cleanup

Jedes Modul, das das Cleanup ü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 werden kann, 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. Wenn Sie dasselbe Modul ohne das Flag erneut ausführen, wird nur das aufgeräumt, was dieser Lauf erstellt hat, nicht das, was ein früherer --no-cleanup-Lauf hinterlassen hat.

Audit-Protokollierung

MacNoise schreibt zwei getrennte Streams. Telemetrie-Ereignisse – das, was Ihr EDR/SIEM tatsächlich sieht – gehen an stdout oder an --output. Ein zweiter, optionaler Stream zeichnet auf, was MacNoise selbst getan hat: welche Module liefen, Ergebnisse von Voraussetzungen/Cleanup und MITRE-Zuordnungen, im OCSF-1.7.0-JSONL-Format.

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

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

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

Das Audit-Log wird im Append-Modus geöffnet, sodass sich Datensätze mehrerer Läufe für die Stapelanalyse in einer Datei ansammeln. Wenn Sie ein Modul hinzufügen und wissen möchten, wie ein neuer Ereignistyp in OCSF klassifiziert wird, lesen Sie CONTRIBUTING.md.

Modulreferenz

Die Moduldokumentation befindet sich neben jeder Kategorie:

Szenarien

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

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

Zuerst als Trockenlauf ausführen:

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

Mit Ihrem SIEM/EDR abgleichen: Jeder Schrittkommentar benennt die Technik, die er auslösen sollte. Wenn nach einem echten Lauf keine passende Warnung erscheint, ist das eine Lücke in Ihrer Abdeckung.

Eigene Szenarien schreiben:

name: My Custom Scenario
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-Commits-PR-Titel. feat: add net_tls module oder fix: correct beacon jitter ist also sowohl Ihr PR-Titel als auch Ihr Changelog-Eintrag.

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 bedenken Sie bitte, dass das Code-Review derzeit ein von Menschen 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.