optiv/dentФреймворк для создания обходов на основе COM, использующий уязвимости в сенсорах Microsoft WDAPT.
Чтобы просмотреть последнюю версию Dent или отправить вопрос, обратитесь к https://github.com/Tylous/Dent.
Dent
Если вы хотите узнать больше о методах, используемых в этом фреймворке, пожалуйста, ознакомьтесь с этой статьей.
Этот фреймворк генерирует код для эксплуатации уязвимостей в правилах сокращения поверхности атаки (ASR) Microsoft Defender Advanced Threat Protection, чтобы выполнить шелл-код без обнаружения или блокировки. ASR был разработан как первая линия защиты, обнаруживающий события на основе действий, нарушающих набор правил. Эти правила сосредоточены на конкретных индикаторах поведения на конечной точке, которые часто связаны с тактиками, техниками или процедурами (TTP) злоумышленника. Правила в значительной степени ориентированы на пакет Microsoft Office, поскольку это распространенный вектор атаки для создания удаленного плацдарма на конечной точке. Многие средства контроля на основе правил сосредоточены на индикаторах поведения на основе сети или процессов, которые выделяются из нормальной деловой активности. Эти правила направлены либо на начальную компрометацию системы, либо на технику, которая может серьезно повлиять на организацию (например, раскрытие учетных данных или программа-вымогатель). Они охватывают большую часть общей поверхности атаки и направлены на затруднение известных методов, используемых для компрометации активов.
Dent использует несколько уязвимостей для обхода этих ограничительных средств контроля и выполнения полезных нагрузок на конечной точке без блокировки или эффективного обнаружения датчиками Microsoft Defender Advanced Threat Protection. В статье выше описаны эти уязвимости, которые все еще присутствуют в Microsoft Defender Advanced Threat Protection даже после раскрытия.
Первый шаг, как всегда, — клонировать репозиторий, затем собрать его
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
"Call someone a hero long enough, and they'll believe it. They'll become it.
They have no choice. Let them call you a monster, and you become a monster."
Usage of ./Dent:
-C string
Name of the COM object.
-N string
Name of the XLL playload when it's writen to disk.
-O string
Name of the output file. (default "output.txt")
-P string
Path of the DLL for your COM object. (Either use \\ or '' around the path)
-U string
URL where the base64 encoded XLL payload is hosted.
-show
Display the script in the terminal.
Этот фреймворк предназначен для эксплуатации уязвимостей и недостатков Microsoft Defender Advanced Threat Protection, поэтому он не генерирует сами полезные нагрузки/импланты. Для их создания можно использовать множество общедоступных инструментов, однако все исследования, разработка и тестирование проводились с помощью ScareCrow. Microsoft Defender Advanced Threat Protection не использует перехват на уровне пользователя для телеметрии, а применяет различные другие механизмы, такие как колбэки ядра. По результатам тестирования этот фреймворк отлично обходит Microsoft Defender Advanced Threat Protection для выполнения шелл-кода.
На момент выпуска существует две техники. Я буду постоянно добавлять новые, использующие эти уязвимости разными способами, так что следите за обновлениями.
COM-объекты часто создаются при установке приложения в систему. После создания любое приложение или скрипт может их вызвать, однако это не единственный способ их создания. Изменяя или создавая ключи реестра в разделе HKEY_CLASSES_ROOT реестра Windows, мы можем создать COM-объект, указывающий на наш шелл-код в системе. Это означает, что любое приложение или скрипт, способное использовать COM, может вызвать его, выполнив шелл-код.
Это работает благодаря тому, как функционирует API CoCreateInstance. CoCreateInstance используется для создания и инициализации COM-объектов на основе CLSID (глобально уникального идентификатора, используемого для идентификации конкретного класса COM-объекта). Эта функция получает информацию для выполнения вызова, используя значения, хранящиеся в ключах реестра. Эти значения CLSID можно найти в пути HKEY_CLASSES_ROOT\CLSID\ реестра. Однако прежде чем процесс сможет вызвать CLSID, он должен знать значение этого CLSID. Для этого сначала выполняется запрос к реестру для поиска COM-объекта в HKEY_CLASSES_ROOT\<имя COM-объекта>, и если он существует, выполняется второй запрос к реестру для получения значения CLSID, хранящегося в подпапке.
Дальнейшее изучение подпапок реестра показывает, что права доступа для значений CLSID не единообразны. Большинство COM-объектов, хранящихся здесь, предоставляют "Полный доступ" только Trusted Installer. Trusted Installer — это служебная учетная запись, владеющая ресурсами для их защиты, даже от администраторов. Это предназначено для того, чтобы даже при получении злоумышленником привилегий администратора ресурсы не могли быть злонамеренно изменены. К сожалению, многие COM-объекты разрешают любой группе "Администраторы" "Полный доступ". Кроме того, корневой ключ CLSID предоставляет группе "Администраторы" права "Полный доступ", а не NT AUTHORITY\System или Trusted Installer. Из-за этого в повышенном контексте мы можем создавать или даже изменять значения определенных COM-объектов.
Важно
Создание этих ключей реестра работает только при запуске в повышенном контексте. Двойной щелчок в графическом интерфейсе не выполнит VBS-файл в повышенном контексте, даже если вы администратор. Рекомендуется запускать его из административной командной строки или оболочки. Однако после создания ключей любое приложение может вызывать этот COM-объект в любом контексте.
Чтобы использовать полезную нагрузку ScareCrow с этим типом обхода, выполните следующую команду:
./ScareCrow -I <путь к вашему «сырому» шелл-коду без стадий> -domain <доменное имя> -Loader dll
После получения полезной нагрузки используйте флаг -N для имени файла при записи на диск, флаг -C для имени COM-объекта, флаг -I для пути записи и, наконец, флаг -O для выходного файла для сохранения содержимого.
Этот параметр генерирует блок кода для обхода нескольких правил ASR с целью загрузки, записи на диск, загрузки и выполнения шелл-кода, минуя средства предотвращения ASR. Это делается с помощью COM-объекта Excel.Application, который представляет все приложение Excel, но в автоматизированной форме и позволяет программно взаимодействовать с ним. Поскольку это все еще Excel, он не активирует правило ASR. Это связано с тем, что при вызове Excel.Application можно увидеть, что он запускается в процессе Service Host (Svchost.exe), а не в процессе WinWord.exe. Хотя Svchost.exe — это системный процесс, используемый для размещения нескольких служб Windows, созданный дочерний процесс (Excel.exe) не получил привилегий системного уровня. Поскольку мы создали COM-объект, представляющий целое приложение, процесс Excel был создан в рамках Svchost.exe для правильной обработки и предотвращения нестабильности процесса WinWord.exe. Хотя этот процесс находится в Svchost.exe, есть еще одна проблема: выполнение шелл-кода. Поскольку бинарное выполнение или использование WinAPI внутри макроса активирует другие правила ASR, это ограничивает наши действия без активации правила ASR или обнаружения компонентом EDR системы WDAPT. Здесь на помощь приходят DLL. Если полезная нагрузка на основе DLL скомпилирована с правильными функциями экспорта, ее можно использовать как плагин Office, который при загрузке автоматически запускает шелл-код. Для этого мы можем использовать функцию Excel RegisterXLL. Функция RegisterXLL загружает плагин XLL в память, автоматически регистрируя и выполняя его. Файлы XLL — это, по сути, DLL на основе Excel.
Чтобы получить содержимое в систему, мы можем использовать другой COM-объект (Microsoft.XMLHTTP), получая возможность выполнять HTTP-запрос, в данном случае HTTP GET-запрос к URL. Второй COM-объект (ADODB.stream) обеспечивает возможность чтения/записи байтов потока данных. Комбинируя два COM-объекта, злоумышленник может запросить удаленный ресурс через HTTP GET-запрос и записать ответ (в данном случае сам файл) на диск. Это делается с помощью COM-объекта (ADODB.stream) для обработки чтения/записи байтов потока данных. Второй COM-объект (Microsoft.XMLDOM) позволяет читать данные, хранящиеся в файле. Объект XMLDOM позволяет задать тип данных (в данном случае base64), и после открытия и сохранения в строке с правильным типом данных объект ADODB.stream может записать строку кода на диск, используя другой тип данных (в данном случае BinaryStreamType), преобразуя строку base64 обратно в бинарную форму.
Чтобы использовать полезную нагрузку ScareCrow с этим типом обхода, выполните следующую команду:
./ScareCrow -I <путь к вашему «сырому» шелл-коду без стадий> -domain <доменное имя> -Loader excel -O <имя выходного файла>
После генерации скопируйте строки 13 и 14 из выходного файла и объедините их, убедившись, что удалены:
var <имя переменной>; в конце каждой строки
После получения закодированной полезной нагрузки используйте флаг -N для имени файла при записи на диск, флаг -U для URL, на котором будет размещена закодированная полезная нагрузка (например, https:///), и флаг -F для имени файла, размещенного на сайте. Выходной код предназначен для работы в макросе документа .
В ходе дальнейшего расследования было замечено, что это не пробел в датчиках WDATP, а скорее то, что WDATP действительно имеет видимость этой активности, но игнорирует ее. Просматривая временную шкалу событий конечной точки WDATP в поисках упоминаний Appwiz.xll, мы обнаружили, что WDATP зафиксировал событие "создан файл", когда Word создал файл AppWiz.xll. Важно отметить, что файлы .XLL являются исполняемыми.
20.11.2020 - Разработка исследования и написание статьи.
14.03.2021 - Предоставлен Microsoft предварительный документ о раскрытии, описывающий выявленные проблемы.
31.03.2021 - Microsoft признал и подтвердил, что уязвимости, связанные с порождением дочернего процесса Office и записью файлов на диск, являются реальными, и начал работу над их устранением. Однако несоответствия прав доступа в реестре не были признаны уязвимостью из-за необходимости повышенных привилегий.
21.04.2021 - Microsoft уведомил автора, что сборка сигнатур 1.333.1055.0, выпущенная 22.03.2021, и 1.335.1321.0, выпущенная 21.04.2021, содержат обнаружение уязвимостей на основе приложений Office, и закрыл дело.
22.04.2021 - Автор повторно протестировал те же методы и выявил, что уязвимости все еще присутствуют.