bohops/rogueassemblyhunterRogue Assembly Hunter — это утилита для обнаружения 'интересных' модулей .NET CLR в запущенных процессах.
__________ _____ . .
_____ \ ____ ____ __ __ ____ / _ \ ______ ______ ____ _ | | | ..
| // _ \ / __| | _/ __ \ / /\ \ / // __// __ \ / | __ | |< | |
| | ( <> ) // > | /\ / / | \ \ _ \ /| Y Y \ _\ \ |_ |
|| /_/_ /|/ _ > _| /____ >____ >___ >|| / /____/ |
/ // / / / / / / / /
___ ___ __
/ | \ __ __ / | ___________
/ ~ \ | / \ __/ __ _ __
\ Y / | / | \ | \ /| | /
_| /|/|| /| _ >|
/ / /
Rogue Assembly Hunter — это утилита для обнаружения «интересных» модулей .NET CLR в запущенных процессах.
.NET — это очень мощная и функциональная платформа разработки и среда выполнения для создания и запуска управляемых приложений .NET. За последние несколько лет .NET был принят на вооружение Red Teams (и подобными им) для инструментирования тактик в поддержку наступательных операций. В частности, переход от оборонительного PowerShell к .NET был логичным шагом (для многих) из-за повышенной видимости и оппортунистической наблюдаемости, присутствующих в PowerShell v5+. В связи с этим, наступательные средства и тактики .NET успешно использовались для обхода средств защиты на основе хоста, обхода контроля приложений, а также для создания/подготовки/доставки/выполнения вредоносного кода (аналогично PowerShell).
С точки зрения предотвращения, Microsoft делает больше для борьбы с угрозами, инструментированными через .NET, и для минимизации общей поверхности атаки .NET. Например, Microsoft добавила возможности проверки AMSI в .NET Framework 4.8, а механизмы WDAC/WLDP весьма эффективны. С точки зрения обнаружения/реагирования, дополнительная видимость и исследование экосистемы .NET всегда полезны для поиска новых способов борьбы с угрозами, ориентированными на .NET.
В 2017 году Джо Дезимоне (@dez_) написал замечательную статью под названием Hunting For In-Memory .NET Attacks. Актуальная и сегодня, статья описывает современные векторы атак на .NET, а также методы обнаружения по требованию и на основе событий. В дополнение к статье Джо выпустил инструмент (Get-ClrReflection) для активного обнаружения (и извлечения) модулей .NET CLR в памяти, у которых отсутствует корректная ссылка на диск. Вдохновленный работой Джо и используя возможности исследования библиотеки диагностики времени выполнения CLRMD (+ последующие возможности доступа к данным mscordacwks.dll), был создан Rogue Assembly Hunter для:
watch). В некоторых случаях может быть сложно «поймать» загрузку конкретной сборки из-за скорости выполнения (например, execute-assembly и жертвенные процессы).[*] Параметры:
--mode=<.> : Обязательно | Выберите режим анализа. Варианты: sweep, process и watch.
--hunt=<.> : Необязательно | Выберите тип сканирования для поиска интересных модулей CLR. Укажите all (по умолчанию), memory-only, unusual-dir,
sig-status, imposter-file или list.
--export=<.> : Необязательно, экспериментально | Укажите путь к файлу для экспорта загруженных модулей CLR для сканирования в памяти и сканирования модулей-самозванцев
(например, --hunt=memory-only/imposter-file/all).
--pid=<.> : Необязательно | Укажите целевой процесс по PID. Должен использоваться с параметром/значением --mode=process.
--checks=<.> : Необязательно | Укажите количество циклов сканирования. Это может помочь уменьшить пропуски из-за состояний гонки, но может также повторять вывод результатов.
Значение по умолчанию: 1.
--sleep=<.> : Необязательно | Укажите количество секунд задержки. Это может помочь уменьшить пропуски из-за состояний гонки, задерживая цикл проверки.
Значение по умолчанию: 0 секунд.
--debug : Необязательно | Отображать информацию об исключениях (например, ошибки подключения к процессу).
--nobanner : Необязательно | Подавить отображение баннера. Полезно для выполнения через скрипт PowerShell или для сценариев, использующих автоматизацию.