InlineExecute-Assembly

InlineExecute-Assembly — это доказательство концепции Beacon Object File (BOF), которое позволяет специалистам по безопасности выполнять .NET сборки в рамках процесса, как альтернатива традиционному модулю execute-assembly Cobalt Strike, работающему через fork and run. InlineExecute-Assembly выполнит любую сборку с точкой входа Main(string[] args) или Main(). Это позволяет запускать большинство опубликованных инструментов без предварительных изменений.

BOF автоматически определит, какую версию Common Language Runtime (CLR) необходимо загрузить в процесс для вашей сборки (v2.0.50727 или v4.0.30319) перед выполнением и в большинстве случаев корректно завершится при возникновении проблем. BOF также поддерживает несколько флагов, которые позволяют оператору управлять различными аспектами перед выполнением .NET, включая отключение AMSI через патчинг памяти, отключение и восстановление ETW через патчинг памяти, настройку имени создаваемого домена приложения CLR, возможность перенаправлять вывод консоли сборки в именованный канал (named pipe) или почтовый слот (mailslot), а также переключение точки входа с Main(string[] args) на Main(). Более подробная информация об использовании, сценариях и возможных способах обнаружения приведена ниже и по адресу https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/.

Наконец, преимущество выполнения наших .NET сборок в том же процессе, что и наш beacon implant, заключается в том, что мы избегаем стандартного поведения модуля execute-assembly Cobalt Strike, который создаёт новый процесс для загрузки/внедрения CLR/.NET сборки. Однако существуют и другие соображения по opsec, например: загружает ли процесс, в котором мы выполняемся, обычно CLR? Есть ли у выполняемой .NET сборки известные сигнатуры? Поэтому недостатком является то, что если что-то будет обнаружено и заблокировано (например, AMSI), ваш beacon также будет убит.

Ссылки по теме

Этот инструмент не появился бы без возможности опереться на действительно отличные исследования, инструменты и код, уже опубликованные членами сообщества безопасности. Спасибо им. Если кто-то остался не упомянутым ниже, дайте мне знать, и я обязательно добавлю их.

• HostingCLR - здесь - Логика CLR/выполнения сборки
• Dotnet-Loader-Shellcode - (от @modexpblog) - здесь - Отличные исследования, включая COM-интерфейсы для выполнения .NET в C -> Настоящий MVP
• Donut - (от @TheRealWover и @modexpblog) - здесь - Заголовок COM-интерфейсов
• Memory Patching AMSI Bypass - (от @_RastaMouse) - здесь - Исследование патчинга памяти AMSI
• Metasploit-Execute-Assembly - (от @b4rtik) - здесь - Модифицированный патчинг AMSI и функция определения версии .NET
• ExecuteAssembly - (от @med0x2e) - здесь - Модифицированный aggressor-скрипт
• Hiding Your .NET ETW - (от @xpn) - здесь - Отличные исследования ETW
• ETW BOF - (от @ajpc500) - здесь - Модифицированный патчинг ETW
• ExecuteAssembly_Mailslot - (от @N4k3dTurtl3) - здесь - Модифицированное использование почтовых слотов для перенаправления консоли
• @freefirex2 - Был так любезен, что поделился хорошими сведениями о внутреннем устройстве BOF и подводных камнях.

Начало работы

1. Скопируйте папку inlineExecute-Assembly со всем содержимым на систему, к которой вы планируете подключаться через графическое приложение Cobalt Strike.
2. Загрузите aggressor-скрипт inlineExecute-Assembly.cna.
3. Выполните inlineExecute-Assembly --dotnetassembly /путь/к/assembly.exe для базового выполнения (см. примеры использования ниже для конкретных флагов).

Сборка собственной версии

Выполните следующую команду в каталоге src через x64 Native Tools Command Prompt для VS 2019.

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx64.o

Выполните следующую команду в каталоге src через x86 Native Tools Command Prompt для VS 2019.

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx86.o

Флаги

--dotnetassembly        Путь к сборке **обязательно**
--assemblyargs          Аргументы для сборки
--appdomain            Изменить имя по умолчанию AppDomain (значение по умолчанию: totesLegit, задаётся во включённом aggressor-скрипте) *Домен всегда выгружается*
--amsi                 Попытка отключить AMSI через патчинг памяти (в случае успеха AMSI будет отключён на всё время жизни процесса)
--etw                  Попытка отключить ETW через патчинг памяти (в случае успеха ETW будет отключён на всё время жизни процесса, если не отменить)
--revertetw            Попытка отключить ETW через патчинг памяти, а затем восстановить исходное состояние
--pipe                 Изменить имя по умолчанию именованного канала (значение по умолчанию: totesLegit, задаётся во включённом aggressor-скрипте)
--mailslot             Переключиться на использование почтовых слотов для перенаправления вывода консоли. Изменяет имя по умолчанию почтового слота (если оставить пустым, значение по умолчанию: totesLegit, задаётся во включённом aggressor-скрипте)
--main                 Изменить точку входа на Main() (значение по умолчанию: Main(string[] args))

Пример использования

Выполнение .NET сборки

Синтаксис

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe

Пример использования

Выполнение .NET сборки с аргументами

Синтаксис

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker

Пример использования

Выполнение .NET сборки с аргументами и отключением AMSI

Синтаксис

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi

Пример использования

Выполнение .NET сборки с аргументами и отключением ETW

Синтаксис

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --etw

Пример использования

Выполнение .NET сборки с аргументами и перенаправлением вывода через почтовый слот вместо именованного канала по умолчанию

Синтаксис

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --mailslot

Пример использования

Выполнение .NET сборки с аргументами и изменение имени именованного канала, заданного в aggressor-скрипте

Синтаксис

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --pipe forRealLegit

Пример использования

Выполнение .NET сборки и изменение домена приложения по умолчанию, заданного в aggressor-скрипте

Синтаксис

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --appdomain forRealLegit

Пример использования

Выполнение .NET сборки с точкой входа Main() вместо Main(string[] args)

Синтаксис

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/simpleMain.exe --main

Пример использования

Полный набор

Синтаксис

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi --etw --appdomain forRealLegit --mailslot forRealLegit

Предостережения

1. Хотя я старался сделать этот инструмент максимально стабильным, нет гарантий, что всё никогда не упадёт и beacons не погибнут. У нас нет дополнительной возможности «fork and run», когда при проблемах наш beacon остаётся жив. Это компромисс BOF. При этом я не могу не подчеркнуть, как важно предварительно тестировать ваши сборки, чтобы убедиться, что они будут корректно работать с инструментом.
2. Поскольку BOF выполняется в процессе и захватывает beacon на время выполнения, это следует учитывать перед использованием для длительных сборок. Если вы решите запустить что-то, что будет долго возвращать результаты, ваш beacon не будет активен для выполнения других команд до тех пор, пока результаты не вернутся и сборка не завершится. Это также не подчиняется настройке sleep. Например, если ваш sleep установлен на 10 минут, а вы запускаете BOF, результаты вернутся сразу после завершения BOF.
3. Если не вносить изменения в инструменты, которые загружают PE в память (например, SafetyKatz), они, скорее всего, убьют ваш beacon. Многие такие инструменты корректно работают с execute-assembly, потому что они могут отправлять вывод консоли из жертвенного процесса перед выходом. Когда они завершаются через наш внутрипроцессный BOF, они убивают наш процесс, что убивает beacon. Их можно модифицировать для работы, но я рекомендую запускать такие сборки через execute-assembly, так как в ваш процесс могут быть загружены другие не-OPSEC-дружественные вещи, которые не будут удалены.
4. Если ваша сборка использует Environment.Exit, его необходимо удалить, так как он убьёт процесс и beacon.
5. Именованные каналы и почтовые слоты должны быть уникальными. Если вы не получаете данные обратно, а ваш beacon всё ещё жив, скорее всего, проблема в том, что нужно выбрать другое имя для именованного канала или почтового слота.

Обнаружение

Некоторые стратегии обнаружения и смягчения, которые могут быть использованы:

1. Используется PAGE_EXECUTE_READWRITE при патчинге памяти AMSI и ETW. Это сделано намеренно и должно быть тревожным сигналом, так как очень мало программ имеют диапазоны памяти с защитой PAGE_EXECUTE_READWRITE.
2. Имя именованного канала по умолчанию — totesLegit. Это сделано намеренно, и для его обнаружения можно использовать сигнатуры.
3. Имя почтового слота по умолчанию — totesLegit. Это сделано намеренно, и для его обнаружения можно использовать сигнатуры.
4. Имя домена приложения по умолчанию — totesLegit. Это сделано намеренно, и для его обнаружения можно использовать сигнатуры.
5. Хорошие советы по обнаружению вредоносного использования .NET (от @bohops) здесь, (от F-Secure) здесь, и здесь.
6. Поиск загрузки .NET CLR в подозрительные процессы, например, в неуправляемые процессы, которые никогда не должны загружать CLR.
7. Event Tracing здесь
8. Поиск других известных IOC Cobalt Strike Beacon или C2 egress/communication IOC.