Категории телеметрии

Команды

Глобальные флаги

Оставление артефактов на месте

По умолчанию каждый модуль отменяет свои действия по завершении. Обычно это то, что нужно, но это означает, что детектирование видит только событие установки. Чтобы проверить, что ваш стек обнаруживает само постоянство — LaunchAgent в ~/Library/LaunchAgents, запись в cron, изменённый профиль оболочки — артефакт должен оставаться на месте, когда выполняется сканирование:

Каждый модуль, пропускающий очистку, выводит строку со своим именем, а журнал аудита записывает cleanup_result: skipped вместо ok, чтобы запуск, оставивший постоянство, никогда не был принят за тот, что всё убрал. Используйте macnoise info <module>, чтобы узнать, что создаёт конкретный модуль.

Вы сами отвечаете за их удаление. Повторный запуск того же модуля без флага очистит только то, что создал этот запуск, а не то, что осталось от предыдущего запуска с --no-cleanup.

Журнал аудита

MacNoise записывает два отдельных потока. События телеметрии — то, что реально видит ваш EDR/SIEM — выводятся в stdout или --output. Второй, опциональный поток записывает, что сделал сам MacNoise: какие модули запускались, результаты предусловий/очистки и сопоставления MITRE, в формате OCSF 1.7.0 JSONL.

Каждое событие телеметрии несёт outcome наряду с success (схема 1.1). success указывает, сработал ли MacNoise; outcome указывает, что произошло с действием, которое он пытался выполнить:

Отклонённая проверка TCC или биконинг на мёртвый C2 — это та телеметрия, ради которой существует этот инструмент, поэтому они остаются success: true и различаются по outcome. Только error устанавливает success: false. В журнале аудита то же значение появляется в unmapped.outcome, поскольку статус OCSF одинаково записывает и отклонённое действие, и сломанный инструмент.

Журнал аудита открывается в режиме добавления, поэтому записи из нескольких запусков накапливаются в одном файле для пакетного анализа. Если вы добавляете модуль и хотите узнать, как новый тип события классифицируется в OCSF, см. CONTRIBUTING.md.

Справочник модулей

Документация модулей находится рядом с каждой категорией:

Сценарии

Сценарии объединяют модули в упорядоченные последовательности — один YAML-файл, который воспроизводит многоэтапный паттерн вторжения против ваших детектирований.

Два APT-сценария следуют реальным задокументированным последовательностям вторжений, техника за техникой — каждый YAML-файл ссылается на реальную threat intel, на которой он построен, и аннотирует каждый шаг техникой MITRE, которую он задействует, так что начните с них для полного разбора, а не с пересказа здесь.

Сначала dry-run:

Сверка с вашим SIEM/EDR: комментарий к каждому шагу называет технику, которую он должен запускать. Отсутствие совпадающего алерта после реального запуска — это пробел в вашем покрытии.

Создание собственного:

Участие в разработке

См. CONTRIBUTING.md о добавлении новых модулей, стиле кода и полном процессе PR.

Релизы автоматизированы — release-please выпускает новую версию прямо из заголовка вашего Conventional Commit PR, так что feat: add net_tls module или fix: correct beacon jitter — это одновременно и заголовок вашего PR, и запись в журнале изменений.

Отказ от ответственности

MacNoise предназначен для авторизованного тестирования безопасности, валидации EDR и инженерии детектирования на системах, которыми вы владеете или на тестирование которых имеете явное письменное разрешение. Авторы не несут ответственности за неправомерное использование.

Политика в отношении ИИ-кода

Вклад кода от ИИ приветствуется, но имейте в виду, что ревью кода в настоящее время будет процессом под руководством человека, а значит, мы можем просмотреть лишь ограниченный объём кода. Пожалуйста, ограничивайте PR конкретным исправлением или новым модулем телеметрии. PR с обширными изменениями, скорее всего, будут закрыты.