
Обнаружение-осведомлённое скоринг атакующих путей BloodHound — самый незаметный маршрут к вашей цели, откалиброванный по пяти уровням обнаружения (audit/EDR/Elastic/MDI/WDAC) плюс Azure.

Оценка путей атаки в Active Directory с учётом обнаружения. DreadHost Research | дополнение к OffsetInspect (PowerShell) и OffsetScan (Rust)
BloodHound (и PlumHound поверх него) находит некоторый путь к цели. NoiseHound принимает те же данные графа и переранжирует пути по ожидаемой стоимости обнаружения вместо числа переходов, так что оператор может спросить «какой самый тихий способ добраться до Domain Admin» вместо просто «какой есть способ».
Впервые здесь? Operator Walkthrough — самый быстрый способ увидеть, что это делает — практическое, основанное на скриншотах руководство от установки до живого proof of concept в BloodHound CE (оценки записываются обратно в интерфейс), движка DeadAir и отчёта о пробелах в обнаружении для blue team.
Статус проекта (v1.2.0): стабилен и протестирован на реальных данных BloodHound в нескольких доменах. 37 из 77 рёбер корпуса измерены в лаборатории в пяти локальных уровнях обнаружения (Windows audit, Defender for Endpoint, Elastic SIEM, runtime-оповещения Defender for Identity и WDAC audit) плюс измеренный уровень Azure/Entra — поставляется как шесть готовых профилей в
profiles/, с доказательством замкнутого цикла, что они меняют ранжирование путей (docs/VALIDATION.md). Корпус включает 13 рёбер Azure/Entra (docs/AZURE.md), принимаемых напрямую из вывода AzureHound. Неизмеренные локальные и все рёбра Azure несут экспертные оценки; стенд калибровки (noisehound-calibrate) — это то, как они и ваша собственная среда получают измерения. Относитесь к некалиброванным рейтингам как к хорошо обоснованным рекомендациям, а не как к истине в последней инстанции.
Только для авторизованных работ. Этот инструмент оценивает пути атаки для планирования OPSEC против систем, на тестирование которых у вас есть письменное разрешение.
NoiseHound — независимый общественный проект. Он не связан с, не одобрен и не ассоциирован со SpecterOps или проектом BloodHound; он использует открытый формат данных BloodHound.
.zip), необработанный JSON-файл или каталог
с экспортами во внутренний граф. Также принимается нормализованный JSON-формат {nodes, edges}
для офлайн-анализа и тестов. Рёбра эскалации AD CS ESC1-8 синтезируются
при загрузке на основе фактов о шаблонах сертификатов и CA, которые собирает
BloodHound (см. ниже).effective_noise_score (0-100). Если несколько прав соединяют одну и ту же пару
узлов, выбирается самое тихое. Типы рёбер, отсутствующие в корпусе, по умолчанию
получают консервативную оценку (60), чтобы пробелы срабатывали безопасно, а не занижали
отчётность. Необязательный профиль окружения корректирует оценки в соответствии
с заявленной целевой позицией обнаружения (см. ниже).Шум пути намеренно не является простой суммой. Срабатывание одного и того же обнаружения дважды не делает его вдвое громче (триаж SOC, а не подсчёт сырых событий). NoiseHound использует:
path_score = max(edge_scores) * 0.6 + mean(edge_scores) * 0.4
Это смещает вес в сторону самого громкого отдельного шага (один плохой шаг часто сжигает всю операцию), при этом всё ещё учитывая накопленную экспозицию. Веса настраиваются (--max-weight / --mean-weight), поэтому их можно эмпирически подобрать, когда появятся реальные данные обнаружения из лаборатории APT29/Caldera.
Каждый путь также сообщает вероятность обнаружения — шанс, что он вызовет коррелированную тревогу — смешивая самое громкое ребро с накопленным noisy-OR всех рёбер (настраивается через --correlation). Это отвечает на другой вопрос, чем оценка шума: короткий, но громкий путь может иметь меньшую общую вероятность быть пойманным, чем длинный, но тихий. Ранжируйте по ней с помощью --rank-by probability.
Для больших графов решение передаётся в DeadAir — сопутствующий движок на Rust (уровень OffsetScan-to-OffsetInspect). NoiseHound остаётся многофункциональным фронтендом — приём данных, корпус, окружение/Sigma, ограничения, отчётность — и передаёт подготовленный граф тому движку, который его решает, поэтому результаты идентичны в любом случае.
--engine auto (по умолчанию): DeadAir, когда найден его бинарник и граф большой (>= 5000 узлов); в противном случае встроенный решатель на Python.--engine python: принудительно использовать встроенный решатель (бинарник не нужен).--engine rust: принудительно использовать DeadAir (ошибка, если бинарник отсутствует).DeadAir ищется через $NOISEHOUND_DEADAIR, затем PATH, затем соседнюю сборку ../deadair/target/{release,debug}/. Он в 10-100 раз быстрее на больших графах (граф на 250 тыс. узлов решается за ~2 с против ~30 с на Python), при этом выдавая побайтово идентичные ранжирования. В выводе записывается, какой движок работал.