MacNoise

MacNoise genera telemetria macOS reale: connessioni di rete, scritture su file, spawn di processi, mutazioni di plist, probe TCC e altro ancora. Puntalo verso una macchina che esegue il tuo stack EDR, SIEM o firewall e osserva cosa si attiva realmente - non ciò che il datasheet del fornitore dichiara che si attiverà.

Per il contesto sulle motivazioni e sul design, consulta il post del blog di rilascio.

Avvio Rapido

# Build (add build-amd64 / build-arm64 to cross-compile for Darwin, or release for both)
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

Categorie di Telemetria

Comandi

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

Flag Globali

Lasciare gli Artefatti in Posizione

Per impostazione predefinita ogni modulo si annulla al termine. Di solito è ciò che vuoi, ma significa che una detection vede solo l'evento di installazione. Per validare che il tuo stack rilevi la persistenza stessa - un LaunchAgent che risiede in ~/Library/LaunchAgents, una voce cron, un profilo shell modificato - l'artefatto deve essere ancora presente quando viene eseguita la scansione:

./macnoise run svc_launch_agent --no-cleanup

Ogni modulo che salta il cleanup stampa una riga che lo identifica, e il log di audit registra cleanup_result: skipped invece di ok, così un'esecuzione che ha lasciato persistenza non viene mai confusa con una che ha ripulito. Usa macnoise info <module> per vedere cosa crea un dato modulo.

Sei responsabile di rimuoverli tu stesso. Rieseguire lo stesso modulo senza il flag pulirà solo ciò che quella esecuzione ha creato, non ciò che una precedente esecuzione con --no-cleanup ha lasciato.

Audit Logging

MacNoise scrive due flussi separati. Gli eventi di telemetria - ciò che il tuo EDR/SIEM vede effettivamente - vanno su stdout o su --output. Un secondo flusso opzionale registra ciò che MacNoise stesso ha fatto: quali moduli sono stati eseguiti, gli esiti di prerequisiti/cleanup e le mappature MITRE, in JSONL OCSF 1.7.0.

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

Ogni evento di telemetria porta un outcome accanto a success (schema 1.1). success indica se MacNoise ha funzionato; outcome indica cosa è successo all'azione tentata:

Una probe TCC negata o un beacon verso un C2 morto è la telemetria che questo strumento esiste per generare, quindi questi restano success: true e vengono distinti tramite outcome. Solo error imposta success: false. Nel log di audit lo stesso valore appare in unmapped.outcome, poiché lo status di OCSF registra allo stesso modo un'azione rifiutata e uno strumento malfunzionante.

Il log di audit si apre in modalità append, quindi i record di più esecuzioni si accumulano in un unico file per l'analisi batch. Se stai aggiungendo un modulo e vuoi sapere come un nuovo tipo di evento viene classificato in OCSF, consulta CONTRIBUTING.md.

Riferimento dei Moduli

La documentazione dei moduli si trova accanto a ciascuna categoria:

Scenari

Gli scenari concatenano i moduli in sequenze ordinate - un singolo file YAML che riproduce un pattern di intrusione multi-stadio contro le tue detection.

I due scenari APT seguono sequenze di intrusione reali documentate, tecnica per tecnica - ogni file YAML cita la threat intel effettiva su cui è costruito e annota ogni passo con la tecnica MITRE che esercita, quindi parti da lì per l'analisi completa piuttosto che da un racconto qui.

Esegui prima il dry-run:

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

Correla con il tuo SIEM/EDR: ogni commento di passo nomina la tecnica che dovrebbe attivare. Nessun alert corrispondente dopo un'esecuzione reale è una lacuna nella tua copertura.

Scriverne di tuoi:

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

Contribuire

Consulta CONTRIBUTING.md per aggiungere nuovi moduli, lo stile del codice e il processo completo delle PR.

I rilasci sono automatizzati - release-please genera una nuova versione direttamente dal titolo della tua PR secondo Conventional Commit, quindi feat: add net_tls module o fix: correct beacon jitter è sia il titolo della tua PR che la voce del changelog.

Disclaimer

MacNoise è destinato a test di sicurezza autorizzati, validazione EDR e detection engineering su sistemi di tua proprietà o per i quali hai esplicita autorizzazione scritta a testare. Gli autori non si assumono alcuna responsabilità per usi impropri.

Politica sul Codice AI

I contributi di codice AI vanno bene, ma tieni presente che la code review è attualmente un processo guidato da esseri umani, il che significa che c'è un limite alla quantità di codice che possiamo revisionare. Limita le PR a una correzione specifica o a un nuovo modulo di telemetria. Le PR con modifiche estese verranno probabilmente chiuse.