Вредоносы в SYSVOL: ищем источник 😐

Допустим, мы расследуем инцидент с шифровальщиком. Для запуска шифровальщика хакеры использовали групповую политику (например, прописали задачу планировщика). Сам вредонос они положили в папку SYSVOL на контроллере домена (DC).

🥷 Как понять, откуда действовал хакер? В этом посте сфокусируемся на файловом следе.

Логика простая: чтобы положить файл в SYSVOL, хакер должен был так или иначе «зайти» на DC. Поэтому смотрим, когда был создан файл (кстати, поэтому важно сначала собрать данные для расследования, а потом уже зачищать системы), и соотносим эту информацию с входами в систему.

Кажется, все просто, но есть нюанс: содержимое каталога SYSVOL реплицируется между DC с помощью DFSR (Distributed File System Replication). То есть хакеру достаточно положить вредоносный файл на один DC, а дальше система автоматически распространит его по всем остальным. Как понять, какой DC был исходным, особенно если DC много?

Посмотрим отладочные логи DFSR на произвольном DC из тех, на которых вредонос попал в папку SYSVOL. Обычно эти логи находятся в папке %systemroot%\debug, имена файлов имеют вид Dfsrxxxxx.log и Dfsrxxxxx.log.gz (.gz в Windows? Да!). Логи текстовые, вполне поддаются грепу, но при этом некоторые события имеют многострочный формат, — учитывайте это, если не хотите потерять контекст.

Поищем в логах имя нашего вредоноса (пусть это будет badfile.exe). Если мы нашли исходный DC с первого раза, мы должны найти в логах подобное сообщение:

20250526 02:44:24.906 5628 USNC  2871 UsnConsumer::CreateNewRecord LDB Inserting ID Record:
+  <...>
+  name                            badfile.exe

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

Можно на всякий случай перепроверить это в журнале $UsnJrnl:$J:

badfile.exe,.exe,132035,6849,257939,4,.\Windows\SYSVOL\domain\scripts,52168700184,2025-05-25 23:44:23.6245532,FileCreate,Archive,436154648

Видно, что файл создается на файловой системе (FileCreate).

Если бы файл был реплицирован, это выглядело бы так:

2025-03-25 23:44:25 +0000 UTC,badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,System Volume Information\DFSR\Private\{F0285778-7EF8-4808-85D7-68223AA11FB5}-{24DC8227-6461-4D16-96D5-537D78549536}\Installing\badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,FILE_CREATE,archive,7|109885

2025-05-25 23:44:25 +0000 UTC,badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,System Volume Information\DFSR\Private\{F0285778-7EF8-4808-85D7-68223AA11FB5}-{24DC8227-6461-4D16-96D5-537D78549536}\Installing\badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,RENAME_OLD_NAME,archive,7|109885

2025-05-25 23:44:25 +0000 UTC,badfile.exe,Windows\SYSVOL\domain\scripts\badfile.exe,RENAME_NEW_NAME,archive,5|269425

Видно, что файл сначала создается в папке DFSR, а потом уже переносится в SYSVOL.

Если же вредонос был реплицирован на исследуемый DC, мы увидим в логах DFSR подобное сообщение:

20250526 02:44:24.949 4452 INCO  3065 InConnection::ReceiveUpdates Received: uid:{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456 gvsn:{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456 fileName:badfile.exe session:86382 connId:{C62DFB26-63FA-4E9F-B533-0F487BF8E043} csId:{F0285778-7EF8-4808-85D7-68223AA11FB5} csName:SYSVOL Share

Очень интересно, но ничего не понятно.

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

#ir #dfir #DFSR
@ptescalator

Продолжаем искать файловый след из поста выше 🐾

Чтобы понять, с какого DC реплицировался файл, нужно узнать, какому хосту соответствует указанный connId (это значение статично и соответствует однонаправленной связи между двумя машинами).

Как это сделать

1️⃣ Можно посмотреть таблицу соответствия в файле \System Volume Information\DFSR\Config\Replica_<GUID группы репликации>.XML. Поищем в нем наш connId и увидим примерно следующее:

<DfsrConnection>
  <ConnectionGuid>C62DFB26-63FA-4E9F-B533-0F487BF8E043</ConnectionGuid>
  <...>
  <PartnerName>DC02</PartnerName>
  <...>
  <PartnerDns>dc02.corp.local</PartnerDns>
  <...>
</DfsrConnection>

2️⃣ Можно поискать в логах DFSR события, содержащие одновременно интересующий нас connId и слова "partnerDns", "partnerName" или "partnerAddress". Можем обнаружить что-то типа:

20250314 01:22:31.307 6304 DOWN  3959 [ERROR] DownstreamTransport::EstablishConnection EstablishConnection failed. Check that the connection partner is valid. If not then recreate the connection with valid partner. connId:{C62DFB26-63FA-4E9F-B533-0F487BF8E043} rgName:Domain System Volume partnerName:DC02 partnerDns:dc02.corp.local

3️⃣ Если DC «живы», то информацию о GUID’ах можно извлечь с помощью утилиты Dfsradmin. Этот способ разбирать не будем — более подробно про логи DFSR можно почитать по ссылке.

Итак, в ходе расследования мы выяснили, что изначально вредоносный файл был размещен на DC02.

Дело за малым — узнать, кто и откуда заходил на этот DC и положил туда этот файл. Журналы ОС и SUM в помощь — никто не обещал, что будет легко! 🙂

#ir #dfir #DFSR
@ptescalator

Всем привет 💻✌️

mr.dox не дает отдыхать и выпускает FileFix2

Суть атаки - для решения captcha пользователю нужно сохранить html-страницу и при сохранении, поменять расширение на .HTA, файл сохранится без MoTW 😇

🔭 Для обнаружения FileFix2 отслеживаем цепочку процессов, например

mshta.exe -> powerhshell|cmd|cscript|curl|certutil - можно хоть весь LOLBAS перечислить

и запуск hta из директорий пользователя *:\Users\

#ttp@detectioneasy
#detection@detectioneasy

Всем привет 💻✌️

Давайте познакомимся со статьей trustedsec про использование встроенных VPN-клиентов в Windows.

Windows из коробки поддерживает клиенты для PPTP, L2TP, SSTP, IKev2 - не нужно приносить с собой сторонний клиент для организации доступа

🔭 Все не так страшно, мы можем относительно легко обнаружить такое поведение:

🔤 Доступ к файлу rasphone.pbk в:

 %appdata%\Microsoft\Network\Connections\Pbk\
C:\Users\All Users\Microsoft\Network\Connections\Pbk\rasphone.pbk
C:\ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk

предварительно нужно настроить DACL

🔤 Отслеживаем события:

Channel="Application" and ProviderName="RasClient" and  (EventId = 20221 or EventId = 20222)

#detection@detectioneasy
#ttp@detectioneasy

Всем привет 💻✌️
Журнал за Q2

Всем привет 💻✌️
Давайте познакомимся с C2-фреймворком OnionC2

Основное преимущество OnionC2 перед аналогами, по мнению автора, — это использование сети Tor для связи сервера и клиента.

By utilizing the Tor network, it ensures that communications between the C2 server and remote systems remain secure, anonymous, and available

🔭 Для формирования гипотез обнаружения и Threat Hunting обратим внимание на следующие особенности агента:

🔤 Для проверки реального IP-адреса агент использует сервис https://checkip.amazonaws.com

🔤 Из коробки идет два варианта закрепа - реестр и Shortcut Takeover

🔤Для реестра, стандартно, отслеживаем создание ключей в *\Software\\Microsoft\\Windows\\CurrentVersion\Run\, имя ключа - Agent

🔤 Shortcut Takeover - для изменения (или создания нового) используется ярлык %USERPROFILE%\Desktop\Microsoft Edge, целевой файл ярлыка - путь до агента, а значение аргумента - --run-lnk, укажет агенту запустить C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe

🔤 Для выполнения команд используется cmd.exe /C

#detection@detectioneasy
#ttp@detectioneasy

Всем привет 💻✌️

Сталкивались ли вы с ситуацией, когда при расследовании инцидента цепочка приводит к хосту, который уже успели переустановить? 😱

Вспомнил полезное видео с PHD и решил дополнить список инструментов, которые помогут в таких случаях:

🔍 Основные из видео:
🔤 r-studio
🔤 photorec
🔤 strings

➕ Дополнение:
🔤 binwalk
🔤 Windows-Prefetch-Carver
🔤 EVTXtract
🔤 bulk_extractor
🔤 scalpel

А какие инструменты используете вы? Делитесь в комментах! 👇

#dfir@detectioneasy

Всем привет! 💻✌️
Обратили внимание, что жизненный цикл реагирования на инциденты от NIST обновился в NIST.SP.800-61r3? Новая версия руководства интегрирована с Cybersecurity Framework (CSF) 2.0

На рисунке показана высокоуровневая модель жизненного цикла реагирования на инциденты, основанная на шести функциях:
- Управление (Govern): Стратегия, ожидания и политика организации в области управления рисками кибербезопасности устанавливаются, доводятся до сведения и отслеживаются
- Идентификация (Identify): анализируются текущие риски
- Защита (Protect): используются меры защиты для управления рисками
- Обнаружение (Detection): выявляются и анализируются возможные инциденты
- Реагирование (Respond): принимаются меры по реагированию в отношении обнаруженного инцидента
- Восстановление (Recover): восстанавливаются активы и процессы, затронутые инцидентом

Все шесть функций взаимосвязаны и формируют непрерывный процесс, где подготовка (управление, идентификация, защита) служит фундаментом для комплексной системы защиты.

Подготовка (управление, идентификация, защита) теперь выделена в отдельный этап, который не входит в процесс реагирования, но является основой для предотвращения инцидентов и снижения их последствий.

Реагирование (обнаружение, реагирование, восстановление) организовано как отдельный цикл, что связано с развитием MSSP (Managed Security Service Providers) и MDR (Managed Detection and Response). Эти сервисы позволяют организациям передать на аутсорс мониторинг и реагирование на инциденты, что особенно важно для малого и среднего бизнеса.


#dfir@detectioneasy

Всем привет! 💻✌️

У коллег из BI.ZONE вышел отчет об использовании новых уязвимостей в WinRAR

Уязвимости использовались для получения доступа к хостам жертв - фишинг.

Письмо имеет вложение - rar-архив, который эксплуатирует CVE‑2025‑6218. Уязвимость позволяет вредоносному архиву при распаковке записывать файлы за пределами целевого каталога - значит мы можем закрепиться в папку автозагрузки текущего пользователя.

🔭 Обнаружение строится достаточно легко:

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 11 and Image endswith "winrar.exe" and TargetFilename = ".*\Microsoft\Windows\Start Menu\Programs\Startup\"

Если атакующие продвинутые можно комбнировать несколько процедур, например заменить LNK на рабочем столе или разместить там RDP-rogue файл... Это уже будет другое правило)

#detection@detectioneasy
#ttp@detectioneasy

Всем привет! 💻✌️
Давайте рассмотрим несколько способов закрепления в системе, которые использовали Lazarus 😤

Они использовали уязвимость - Phantom DLL Loading, в службе SessionEnv
Для обнаружения такого поведения можем отслеживать создание dll-файлов в директории Windows\System32\

🔭 Обнаружение:

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 11 and 
(
TargetFilename contains \Windows\System32\TSMSISrv.dll 
or
TargetFilename contains \Windows\System32\TSVIPSrv.dll
)

#detection@detectioneasy
#ttp@detectioneasy

Всем привет! 💻✌️

Коллеги из bi.zone уведомили о новых техниках Fluffy Wolf

Давайте вспомним как это было в прошлогоднем отчете. Хакеры использовали схему фишинга RAR (с паролем) -> COM. Примечательно, что пароль был указан в имени архива, возможно использовалось для обхода антифишинга

🔭 Обнаружение:
🔤 в двух кампаниях злоумышленники используют раширение com, вместо exe, можем этим воспользоваться для хантинга
🔤 можем похантить имена файлов с "парол|pass"
🔤 создать правило обнаружения таких файлов

ProviderName="Microsoft-Windows-Sysmon" and EventId = 11 and TargetFilename contains "\Users\" and (Image contains "парол" or Image contains "pass")

ProviderName="Microsoft-Windows-Sysmon" and EventId = 11 and TargetFilename contains "\Users\" and (Image endswith ".com")

#detection@detectioneasy
#ttp@detectioneasy

Всем привет! 💻✌️

Команда any.run выпустила интересный материал о применении SVG-файлов в фишинге.

Что важно помнить?

Файл формата SVG (векторная графика), часто используется злоумышленниками для обхода стандартных механизмов защиты. Такие файлы могут содержать код скриптов

🔭 Обнаружение:

🔤 можем отслеживать создание SVG-файлов в каталогах пользователей:

ProviderName="Microsoft-Windows-Sysmon" and EventId=11 and TargetFilename contains "\\Users\\" and TargetFilename endswith ".svg"

#detection@detectioneasy
#ttp@detectioneasy

Всем привет! 💻✌️

Коллеги из ЛК отметили, что группировка RevengeHotels (TA558) использует LLM для разработки дроперов на JS. Отличительная особенность - большое количество комментариев и отсутствие обфускации

🔭 Обнаружение:

🔤 Ищем JS-файлы по паттерну *.js в директориях пользователя

ProviderName="Microsoft-Windows-Sysmon" and EventId=11 and TargetFilename endswith ".js" and TargetFilename contains ":\Users\"

🔤 Для закрепа VenomRAT использует ключ реестра HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

ProviderName="Microsoft-Windows-Sysmon" and EventId=13 and EventType="SetValue" and TargetObject startswith "HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run"

обнаружим Run, RunOnce, RunOnceEx

🔤 Малварь копирует себя на съемные диски под именем My Pictures.exe. Отслеживаем создание EXE-файлов на съемных устройствах

ProviderName="Microsoft-Windows-Sysmon" and EventId=11 and TargetFilename endswith ".exe" and TargetFilename matches "[C-M]:\\\\.*" and not Image endswith "explorer.exe"

#detectioneasy
#ttp@detectioneasy

Всем привет! 💻✌️

Коллеги из Zero Salarium описали кейс, когда при создании новой задачи или службы указывается несуществующий исполняемый файл, например, C:\TMP\test

При создании процесса CreateProcess пытается найти указанный файл, если test не существует, система автоматически ищет в той же директории файл test.exe
Таким образом, если в папке C:\TMP\ лежит файл test.exe, он будет успешно запущен

Такой же трюк можно сделать с двойным расширением:
В задаче указываем c:\temp\test.exe, а в директории будет файл c:\temp\test.exe.exe

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

🔭 Обнаружение (Threat Hunting):

🔤 мониторим процессы и файлы с двойным расширением
🔤 можем смапить путь к файлу в реестре (задаче или службы) и его наличие на диске

#detectioneasy
#ttp@detectioneasy