MacNoise

MacNoise genera telemetria macOS reale: connessioni di rete, scritture su file, spawn di processi, mutazioni di plist, probe TCC e altro. Puntalo verso una macchina che esegue il tuo stack EDR, SIEM o firewall e osserva cosa scatta davvero - non ciò che la scheda tecnica del vendor afferma che scatti.

Per il contesto su motivazione e design, consulta il post del blog di rilascio.

Avvio Rapido

# Build (aggiungi build-amd64 / build-arm64 per cross-compilare per Darwin, o release per entrambi)
make build

# Elenca i moduli disponibili
./macnoise list

# Esegui un singolo modulo
./macnoise run net_connect --param target=127.0.0.1 --param port=8080

# Anteprima senza eseguire
./macnoise run svc_launch_agent --dry-run

# Esegui tutti i moduli di rete
./macnoise run --category network

# Esegui uno scenario
./macnoise scenario configs/scenarios/edr_validation.yaml

# Emetti output JSONL strutturato
./macnoise run --category file --format jsonl --output /tmp/events.jsonl

Categorie di Telemetria

Categoria	Descrizione	Moduli
`network`	Connessioni in uscita, DNS, beaconing, listener, reverse shell, esfiltrazione	net_connect, net_listen, net_beacon, net_revshell, net_dns, net_exfil
`process`	Spawn di processi, invio di segnali, iniezione di dylib, discovery, bypass di Gatekeeper, osascript	proc_spawn, proc_signal, proc_inject, proc_discovery, proc_gatekeeper, proc_osascript
`file`	Creazione di file, modifica, letture di file di credenziali e portachiavi, archiviazione, occultamento	file_create, file_modify, file_browser_creds, file_cred_files, file_keychain_copy, file_archive, file_hide
`tcc`	Probe dei permessi TCC (FDA, Contatti, Portachiavi, Accessibilità, Registrazione Schermo)	tcc_fda, tcc_contacts, tcc_keychain, tcc_accessibility, tcc_screen_recording
`endpoint_security`	Trigger di eventi del framework ES, inclusi mount di .dmg ed esecuzione di payload	es_file, es_process, es_mount
`service`	Persistenza LaunchAgent/Daemon, cron, profilo shell, elementi di accesso	svc_launch_agent, svc_launch_daemon, svc_cron, svc_shell_profile, svc_login_item
`plist`	Creazione e modifica di plist	plist_create, plist_modify
`xpc`	Enumerazione dei servizi XPC	xpc_enumerate

Comandi

macnoise run <module> [--param key=val ...]   Esegue un modulo specifico
macnoise run --category <cat>                 Esegue tutti i moduli di una categoria
macnoise run --all                            Esegue tutti i moduli
macnoise list [--category <cat>]              Elenca i moduli
macnoise info <module>                        Mostra dettagli del modulo, parametri, MITRE
macnoise scenario <file.yaml>                 Esegue uno scenario YAML
macnoise categories                           Elenca le categorie con i conteggi
macnoise version                              Stampa la versione

Flag Globali

Flag	Default	Descrizione
`--format`	`human`	Formato di output: `human` o `jsonl`
`--output`	(nessuno)	Scrive l'output su file (in aggiunta a stdout)
`--verbose`	false	Output dettagliato inclusi gli errori di cleanup
`--dry-run`	false	Anteprima delle azioni senza eseguirle
`--no-cleanup`	false	Lascia gli artefatti dei moduli in posizione (vedi sotto)
`--timeout`	`30`	Timeout per modulo in secondi
`--audit-log`	(nessuno)	Scrive i record di audit OCSF 1.7.0 in un file JSONL
`--config`	(nessuno)	Carica i default da un file di configurazione YAML

Lasciare Artefatti in Posizione

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

./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 determinato 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.

Log di Audit

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, esiti di prerequisiti/cleanup e mapping MITRE, in OCSF 1.7.0 JSONL.

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

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

`outcome`	Significato	Marcatore umano
`executed`	L'azione è stata eseguita e ha fatto ciò che il modulo dichiara	`[+]`
`denied`	L'azione è stata eseguita e l'ambiente l'ha rifiutata	`[-]`
`indeterminate`	L'azione è stata eseguita, ma non si può concludere nulla	`[?]`
`error`	MacNoise stesso non è riuscito a portare a termine l'azione	`[!]`

Un probe TCC negato 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 OCSF registra un'azione rifiutata e uno strumento guasto in modo identico.

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 Moduli

La documentazione dei moduli vive accanto a ciascuna categoria:

Categoria	README
`network`	modules/network/README.md
`process`	modules/process/README.md
`file`	modules/file/README.md
`tcc`	modules/tcc/README.md
`endpoint_security`	modules/endpoint_security/README.md
`service`	modules/service/README.md
`plist`	modules/plist/README.md
`xpc`	modules/xpc/README.md

Scenari

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

File	Descrizione
`network_only.yaml`	Tutti i moduli di rete
`edr_validation.yaml`	Copertura completa delle rilevazioni EDR
`full_sweep.yaml`	Tutte le categorie
`lazarus_group.yaml`	Lazarus Group: iniezione dylib, discovery dei servizi, reverse shell, persistenza plist
`amos_atomic_stealer.yaml`	AMOS / Atomic Stealer: infostealer MaaS, bypass di Gatekeeper, dump del portachiavi, esfiltrazione ZIP, persistenza backdoor

I due scenari APT seguono sequenze di intrusione reali e documentate, tecnica per tecnica - ogni file YAML cita l'intelligence sulle minacce effettiva da cui è costruito e annota ogni passaggio con la tecnica MITRE che esercita, quindi inizia da lì per la ripartizione completa piuttosto che per una riscrittura qui.

Prima prova in dry-run:

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

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

Scrivere i tuoi:

name: Il Mio Scenario Personalizzato
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, stile del codice e l'intero processo di PR.

I rilasci sono automatizzati - release-please taglia una nuova versione direttamente dal titolo della tua PR 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 è pensato per test di sicurezza autorizzati, validazione EDR e ingegneria delle rilevazioni su sistemi di tua proprietà o per i quali hai esplicita autorizzazione scritta al test. Gli autori non si assumono alcuna responsabilità per un uso improprio.

Politica sul Codice AI

I contributi di codice AI sono ben accetti, ma tieni presente che la revisione del codice sarà attualmente un processo guidato da esseri umani, il che significa che possiamo revisionare solo una quantità limitata di codice. Ti preghiamo di limitare le PR a una correzione specifica o a un nuovo modulo di telemetria. Le PR con modifiche estese verranno probabilmente chiuse.