MacNoise

MacNoise genera telemetría real de macOS: conexiones de red, escrituras de archivos, creación de procesos, mutaciones de plist, sondeos de TCC y más. Apúntalo a una máquina que ejecute tu stack de EDR, SIEM o firewall y observa qué se dispara realmente, no lo que la hoja de datos del proveedor afirma que se disparará.

Para conocer los antecedentes sobre la motivación y el diseño, consulta la publicación del blog de lanzamiento.

Inicio rápido

# 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

Categorías de telemetría

Categoría	Descripción	Módulos
`network`	Conexiones salientes, DNS, beaconing, listeners, reverse shells, TLS, exfiltración	net_connect, net_listen, net_beacon, net_revshell, net_dns, net_dns_exfil, net_tls, net_exfil
`process`	Creación de procesos, entrega de señales, inyección de dylib, descubrimiento, bypass de Gatekeeper, osascript	proc_spawn, proc_signal, proc_inject, proc_discovery, proc_gatekeeper, proc_osascript
`file`	Creación y modificación de archivos, lecturas de archivos de credenciales y llavero, archivado, ocultación	file_create, file_modify, file_browser_creds, file_cred_files, file_keychain_copy, file_archive, file_hide
`tcc`	Sondeos de permisos TCC (FDA, Contactos, Llavero, Accesibilidad, Grabación de pantalla)	tcc_fda, tcc_contacts, tcc_keychain, tcc_accessibility, tcc_screen_recording
`endpoint_security`	Disparadores de eventos del framework ES, incluido el montaje de .dmg y la ejecución de payloads	es_file, es_process, es_mount
`service`	Persistencia mediante LaunchAgent/Daemon, cron, perfil de shell, Login Items	svc_launch_agent, svc_launch_daemon, svc_cron, svc_shell_profile, svc_login_item
`plist`	Creación y modificación de plist	plist_create, plist_modify
`xpc`	Enumeración de servicios XPC	xpc_enumerate
`evasion`	Evasión de defensas: borrado de logs, timestomping, eliminación de historial	evade_log_clear

Comandos

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

Flags globales

Flag	Predeterminado	Descripción
`--format`	`human`	Formato de salida: `human` o `jsonl`
`--output`	(ninguno)	Escribir la salida en un archivo (además de stdout)
`--verbose`	false	Salida detallada, incluidos los errores de limpieza
`--dry-run`	false	Previsualizar acciones sin ejecutarlas
`--no-cleanup`	false	Dejar los artefactos del módulo en su sitio (ver más abajo)
`--timeout`	`30`	Tiempo de espera por módulo en segundos
`--audit-log`	(ninguno)	Escribir registros de auditoría OCSF 1.7.0 en un archivo JSONL
`--config`	(ninguno)	Cargar valores predeterminados desde un archivo de configuración YAML

Dejar artefactos en su sitio

Por defecto, cada módulo se revierte a sí mismo cuando termina. Normalmente eso es lo que quieres, pero significa que una detección solo ve el evento de instalación. Para validar que tu stack detecta la persistencia en sí —un LaunchAgent situado en ~/Library/LaunchAgents, una entrada de cron, un perfil de shell modificado— el artefacto tiene que seguir ahí cuando se ejecute el escaneo:

./macnoise run svc_launch_agent --no-cleanup

Cada módulo que omite la limpieza imprime una línea nombrándose a sí mismo, y el registro de auditoría registra cleanup_result: skipped en lugar de ok, de modo que una ejecución que dejó persistencia atrás nunca se confunde con una que limpió. Usa macnoise info <module> para ver qué crea un módulo determinado.

Eres responsable de eliminarlos tú mismo. Volver a ejecutar el mismo módulo sin el flag solo limpiará lo que esa ejecución creó, no lo que dejó atrás una ejecución anterior con --no-cleanup.

Registro de auditoría

MacNoise escribe dos flujos separados. Los eventos de telemetría —lo que tu EDR/SIEM ve realmente— van a stdout o a --output. Un segundo flujo opcional registra lo que hizo MacNoise en sí: qué módulos se ejecutaron, los resultados de prerequisitos/limpieza y los mapeos de MITRE, en JSONL de OCSF 1.7.0.

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

Cada evento de telemetría lleva un outcome junto a success (esquema 1.1). success indica si MacNoise funcionó; outcome indica qué le ocurrió a la acción que intentó:

`outcome`	Significado	Marcador humano
`executed`	La acción se ejecutó e hizo lo que el módulo afirma	`[+]`
`denied`	La acción se ejecutó y el entorno la rechazó	`[-]`
`indeterminate`	La acción se ejecutó, pero no se puede concluir nada	`[?]`
`error`	MacNoise en sí falló al llevar a cabo la acción	`[!]`

Un sondeo TCC denegado o un beacon hacia un C2 muerto es la telemetría que esta herramienta existe para generar, así que esos permanecen como success: true y se distinguen por outcome. Solo error establece success: false. En el registro de auditoría el mismo valor aparece en unmapped.outcome, ya que el status de OCSF registra de forma idéntica una acción rechazada y una herramienta rota.

El registro de auditoría se abre en modo append, así que los registros de múltiples ejecuciones se acumulan en un solo archivo para análisis por lotes. Si estás añadiendo un módulo y quieres saber cómo se clasifica un nuevo tipo de evento en OCSF, consulta CONTRIBUTING.md.

Referencia de módulos

La documentación de los módulos se encuentra junto a cada categoría:

Categoría	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
`evasion`	modules/evasion/README.md

Escenarios

Los escenarios encadenan módulos en secuencias ordenadas: un único archivo YAML que reproduce un patrón de intrusión de múltiples etapas contra tus detecciones.

Archivo	Descripción
`network_only.yaml`	Todos los módulos de red
`edr_validation.yaml`	Cobertura integral de detección de EDR
`full_sweep.yaml`	Todas las categorías
`lazarus_group.yaml`	Lazarus Group: inyección de dylib, descubrimiento de servicios, reverse shell, persistencia mediante plist
`amos_atomic_stealer.yaml`	AMOS / Atomic Stealer: infostealer de tipo MaaS, bypass de Gatekeeper, volcado de llavero, exfiltración por ZIP, persistencia de backdoor
`clickfix.yaml`	ClickFix: one-liner ofuscado pegado en Terminal, decodificación base64, obtención de segunda etapa, persistencia mediante LaunchAgent

Los dos escenarios de APT siguen secuencias de intrusión reales documentadas, técnica por técnica: cada archivo YAML cita la inteligencia de amenazas real a partir de la cual está construido y anota cada paso con la técnica MITRE que ejercita, así que empieza por ahí para el desglose completo en lugar de una repetición aquí.

Ejecuta primero en dry-run:

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

Correlaciona con tu SIEM/EDR: cada comentario de paso nombra la técnica que debería desencadenar. Ninguna alerta coincidente tras una ejecución real es una brecha en tu cobertura.

Escribir el tuyo propio:

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

Contribuir

Consulta CONTRIBUTING.md para añadir nuevos módulos, estilo de código y el proceso completo de PR.

Las releases están automatizadas: release-please genera una nueva versión directamente a partir del título de tu PR con Conventional Commit, así que feat: add net_tls module o fix: correct beacon jitter es tanto el título de tu PR como tu entrada de changelog.

Aviso legal

MacNoise está destinado a pruebas de seguridad autorizadas, validación de EDR e ingeniería de detección en sistemas que posees o para los que tienes permiso escrito explícito de probar. Los autores no asumen ninguna responsabilidad por un uso indebido.

Política de código con IA

Las contribuciones de código con IA están bien, pero ten en cuenta que la revisión de código va a ser actualmente un proceso liderado por humanos, lo que significa que solo podemos revisar una cantidad limitada de código. Limita los PR a una corrección específica o a un nuevo módulo de telemetría. Es probable que los PR con cambios extensos se cierren.