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

Вредоносы в 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
Code language: plaintext (plaintext)

Если коротко, то оно свидетельствует о появлении нового файла в реплицируемой папке, то есть искомый файл был изначально размещен на этом 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
Code language: plaintext (plaintext)

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

Чтобы понять, с какого 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