DSCourier BOF

Это реализация BOF проекта Dylan Davis и Matthew Schramm DSCourier. Он использует COM-интерфейс WinGet для выполнения произвольного кода PowerShell в подписанном и доверенном процессе Microsoft. Полный исследовательский блог можно найти здесь.

В отличие от большинства проектов, которые я выпускаю, это НЕ готовый к эксплуатации инструмент, а скорее POC. Я решил не продолжать его после обнаружения ряда проблем, которые мешают сделать его легко развертываемым BOF. Код был почти полностью слеплен на коленке. Некоторые проблемы остаются нерешенными и обсуждаются ниже

Использование

Поместите ваш произвольный PowerShell-код в файл dist/rev.yml. По умолчанию он содержит простой реверс-шелл PowerShell из оригинального репозитория. Если вы решите использовать его, обязательно замените IP-адрес в существующем примере на ваш желаемый IP.

Пример использования реверс-шелла PowerShell:

Как это работает / Ограничения

Без определенного порядка, вот некоторые проблемы/ограничения этого инструмента.

1. Для успешных COM-вызовов файл Microsoft.Management.Configuration.winmd должен находиться в той же директории, что и исполняемый файл, совершающий COM-вызовы. Это создает немедленную проблему при запуске Beacon из выдолбленного (hollowed-out) процесса system32, где обычные пользователи не имеют прав на запись. Чтобы обойти это, файл вместо этого помещается в %APPDATA%\temp, а функция WinTypes!RoGetMetaDataFile, которая получает путь к winmd, перехватывается с помощью inline-хука, чтобы мы могли указать путь к временной папке. Это позволяет читать файл winmd / успешно выполнять COM-вызовы, но при этом происходят вызовы VirtualProtect и перезапись памяти DLL, что создает индикаторы компрометации (IOCs).
2. После пункта #1, файл winmd блокируется на диске после запуска BOF до выхода процесса Beacon. Я немного игрался с этим, пытаясь решить проблему, включая добавление функциональности самоудаления, которая на данный момент хорошо известна, но файл оставался заблокированным на диске. Возможно, можно обойти это/решить, но пусть этим занимается кто-то другой.
3. Как упоминалось в оригинальном исследовании, поскольку используется ресурс pwsh в WinGet, процесс conhost.exe порождается под ConfigurationRemotingServer.exe. Клод предположил, что можно загрузить пользовательский бинарный модуль в качестве ресурса вместо вызова pwsh, что должно решить проблему conhost, но это требует сброса дополнительных файлов на диск, и мне не удалось заставить это работать. Возможно, это невозможно. Если бы это было возможно, это открыло бы дверь для сброса обычной .NET DLL на диск, которая могла бы быть загружена ConfigurationRemotingServer.exe и выполнять переданный shellcode/параметры и т.д.
4. Этот BOF реализует асинхронные версии необходимых COM-интерфейсов. Использование синхронных версий приводит к зависанию Beacon / отсутствию обратного вызова до завершения процесса ConfigurationRemotingServer.exe; в примере с простым реверс-шеллом это означало бы, что Beacon не будет проверять соединение до тех пор, пока не будет убит шелл. Переключение на асинхронные интерфейсы предотвращает эту проблему, но вводит некоторые проблемы синхронизации. Есть жестко заданный 3-секундный сон, который на практике сработал для создания задержки между конкретными вызовами, но это, конечно, не правильный способ реализации.
5. Определения COM-интерфейсов были получены путем загрузки winget-cli .msixbundle с Github, извлечения, извлечения .msix и поиска файла .winmd. Затем с помощью winmdidl.exe были извлечены IDL-файлы. midlrt.exe использовался для преобразования IDL в заголовочные файлы/.c файлы, которые затем были проанализированы Клодом для получения только необходимых определений. Это всё ещё каша из кода. Эта ссылка Microsoft вероятно, поможет лучше понять этот процесс
6. Код в целом довольно запутанный, потому что он не вышел из стадии POC.
7. Команда winget configure --enable должна быть выполнена хотя бы один раз на целевой машине, чтобы BOF сработал. Я отследил причину этого: каталог DotNet, содержащий ConfigurationremotingServer.exe, даже не существует, пока команда не будет выполнена / бинарник не будет загружен. Эти файлы находятся в C:\Program files\WindowsApps... и поэтому не доступны для записи пользователю с низкими привилегиями, так что мы не можем даже сбросить эти файлы на диск с помощью BOF и заставить всё работать.
8. Я изучал это, и насколько я могу судить, это НЕ DCOM-интерфейсы, а просто COM. Так что это не является жизнеспособным примитивом для бокового перемещения на другие машины.
9. Из-за пункта #7, это не является хорошим/надежным методом начального доступа, на мой взгляд. Если вы попадете на машину с отключенным WinGet (см. оригинальный пост в блоге) или команда configure --enable не была выполнена, вы жестко остановлены. Для целей пост-эксплуатации это может иметь ценность, но вы несколько ограничены тем, что это фиксированный процесс, который порождает/запускает ваш код, и так как это pwsh, будет задействован AMSI.

Компиляция

Этот инструмент был написан без использования обычных объявлений BOF API (например, файла bofdefs.h). Как описано в этом посте в блоге от Matt Ehrnschwender, можно использовать objcopy для пропатчивания правильных символов формата DLL$API в BOF после компиляции.

Я написал инструмент под названием BOFPatcher, который автоматизирует этот процесс. Это позволяет пользователям писать BOF как обычный C, не беспокоясь о громоздких объявлениях API:

Этот инструмент доступен тем, кто приобретает мой курс BOF Development and Tradecraft.

Хотя инструмент BOFPatcher не включен в этот репозиторий, Makefile этого инструмента вызывает objcopy, передавая файл imports_dscourier64.txt, содержащий правильные замены символов, что делает BOF работоспособным.

Благодарности

1. Отличная работа от Dylan и Matt. Надеюсь увидеть больше от них!
2. Клоду за то, что собрал большую часть этого на коленке