Отслеживание создания файлов неизвестным приложением в виртуальной среде: методы, инструменты и практика анализа

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

Почему стандартные средства часто недостаточны

Процесс мониторинг (Process Monitor, Procmon) — де-факто стандарт для Windows. Он использует драйвер файловой системы и коллбэки ядра (FsFilter, PsSetCreateProcessNotifyRoutine) для перехвата IRP-запросов. В чистой виртуальной машине это работает хорошо, но есть нюансы:

• Объём шума. Система генерирует тысячи событий в секунду. Фильтрация по PID процесса-цели помогает, но если образец запускает дочерние процессы или инжектируется в легаitimate процессы (например, werfault.exe, svchost.exe), цепочку событий легко разорвать.
• Анти-отладка и анти-VM. Многие образцы проверяют наличие драйверов Procmon (PROCMON24.SYS, PROCMON23.SYS), ключи реестра HKLM\SYSTEM\CurrentControlSet\Services\ProcMon*, или просто измеряют задержки на системных вызовах. Обнаружив мониторинг, вредонос может сменить поведение или завершиться.
• Потеря событий при высокой нагрузке. Буфер событий Procmon конечен. При массовом создании файлов (ransomware, вайперы) часть IRP не попадает в лог.
• Отсутствие контекста памяти. Procmon показывает что произошло, но не почему — нет стека вызовов, нет содержимого регистров, нет данных, записанных в файл (только путь и операция).

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

Уровни перехвата файловой активности

Методы делятся на уровни абстракции. Чем ниже уровень, тем сложнее обойти, но тем сложнее развернуть и интерпретировать данные.

1. User-mode API Hooking

Инструменты: API Monitor, Rohitab API Monitor, кастомные DLL-инжекции (Detours, MinHook, Frida).

Принцип: перехват функций WinAPI (CreateFile, WriteFile, NtCreateFile, NtWriteFile) в адресном пространстве целевого процесса.

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

Минусы: легко детектируется (проверка контрольных сумм кода, NtQueryInformationProcess с ProcessDebugPort, тайминги), не видит прямые системные вызовы (syscall), не работает, если образец использует Heaven’s Gate / WoW64 переходы для обхода хуков в 32-битном подсистеме.

2. Kernel-mode File System Minifilter

Инструменты: Procmon, FileMon (устарел), самописные minifilter-драйверы на базе FltRegisterFilter.

Принцип: регистрация коллбэков IRP_MJ_CREATE, IRP_MJ_WRITE, IRP_MJ_SET_INFORMATION (переименование, удаление).

Плюсы: видит всю файловую активность системы, независимо от API, сложнее обойти без эксплойта ядра.

Минусы: требует подписи драйвера (Test Signing Mode или WHQL), высокая сложность разработки, риск BSOD при ошибках, видимость драйвера в списке загруженных модулей (lm в WinDbg, fltmc filters).

3. Hypervisor-level / VMI (Virtual Machine Introspection)

Инструменты: Cuckoo Sandbox с VMI, DRAKVUF, LibVMI, HyperDbg, VMware vProbes, Intel PT / AMD IBS (трекинг инструкций).

Принцип: мониторинг извне гостевой ОС через гипервизор. Перехват EPT violation (#VE) на страницах файловой системы, мониторинг MSR / CR3 переключений, трассировка инструкций.

Плюсы: полностью невидимый для гостевой ОС (нет драйверов, нет хуков в памяти процесса), видит прямые системные вызовы, SMM-код, bootkit-актвиность, можно снять полную трассировку выполнения (Intel PT).

Минусы: высокая сложность настройки, требовательно к железу (VT-x/EPT, AMD-V/RVI), огромный объём данных (Intel PT — гигабайты в секунду), сложная корреляция виртуальных адресов гостя с физическими/линейными адресами хоста.

4. Filesystem-level снапшотирование и диффинг

Инструменты: Regshot (реестр + файлы), FolderChangesView, WinDirStat (пост-фактум), FTK Imager / Arsenal Image Mounter (сравнение образов диска), VHD/VMDK diff.

Принцип: снятие состояния ФС до и после запуска, сравнение.

Плюсы: абсолютно пассивно, не детектируется, находит файлы, созданные и удалённые за сессию, работает с любыми FS (NTFS, ReFS, FAT32).

Минусы: нет временной привязки (когда именно создано), нет процесса-создателя, нет содержимого записанных данных, не видит временные файлы, удалённые до снапшота.

Практический рабочий процесс: от подготовки к отчёту

Ниже — последовательность действий, которая минимизирует риск упустить активность и максимально автоматизирует сбор артефактов.

1. Подготовка чистого образа. Используйте базовый образ Windows (10/11 LTSC, Server 2019/2022) с отключенными автообновлениями, телеметрией, Defender (через GPO или Set-MpPreference -DisableRealtimeMonitoring $true), индексацией поиска, SysMain (Superfetch). Установите только необходимые инструменты мониторинга. Сделайте снапшот ВМ (checkpoint) — это ваша точка отката.
2. Настройка мониторинга «в глубину». Запустите Procmon с бэкендом в файл (PML) на отдельном виртуальном диске (чтобы не забить системный том). Включите «Enable Advanced Output» — это сохраняет стек вызовов (Call Stack) для каждого события. Настройте фильтр: Process Name is <имя_образца>.exe + Operation is CreateFile / WriteFile / SetRenameInformationFile / SetDispositionInformationFile. Добавьте «Include Subkeys» для реестра, если нужен полный контекст.
3. Дополнительный слой: API Monitor / Frida. Присоединитесь к процессу сразу после создания (PID известен из Procmon или через скрипт запуска). Логируйте NtCreateFile, NtWriteFile, NtSetInformationFile с полными стеками и буферами. Frida-скрипт можно инжектировать автоматически при старте процесса через —spawn флаг.
4. Запуск образца. Используйте лаунчер, который: (а) создаёт процесс в приостановленном состоянии (CREATE_SUSPENDED), (б) инжектирует хуки / присоединяет отладчик, (в) резюмирует основной поток. Это гарантирует, что ни один системный вызов не уйдёт нелогированным.
5. Сбор сетевой активности параллельно. Wireshark / npcap на хосте (mirror port) или внутри ВМ (RawCap). Корреляция создания файла с сетевым запросом (скачивание полезной нагрузки, эксфильтрация) критически важна.
6. Контрольные точки времени. Если образец работает долго (майнеры, ботнеты), делайте периодические снапшоты диска (каждые 5–15 минут) для пост-анализа диффа.
7. Завершение и сохранение артефактов. Остановите мониторинг. Сохраните PML (Procmon), CSV/JSON (API Monitor / Frida), PCAP (сеть), дамп памяти (procdump -ma или WinPMEM / LiME), образ диска (dd / FTK Imager). Зафиксируйте хэши (SHA256) всех артефактов.
8. Автоматизированный разбор. Напишите парсер (Python + procmon-parser, pandas, sqlite), который: агрегирует события по PID/путям, выделяет уникальные пути, коррелирует с MITRE ATT&CK (T1547, T1105, T1486 и др.), выделяет подозрительные расширения (.exe, .dll, .bat, .ps1, .vbs, .tmp в нестандартных папках), проверяет цифровые подписи созданных файлов.

Типичные сценарии создания файлов и что они означают

Сценарий	Типичные пути / паттерны	MITRE ATT&CK	Что проверить дополнительно
Дроппер / загрузчик	%TEMP%\*.exe, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*, C:\ProgramData\*	T1105, T1547.001	Хэш созданного файла, VT/HA запрос, подпись, импортная таблица
Установка персистентности	HKCU\Software\Microsoft\Windows\CurrentVersion\Run, Shell\Open\Command, Tasks\*, WMI Event Subscription	T1547, T1053, T1546	Содержимое значения реестра / задачи, командная строка запуска
Ransomware шифрование	Массовое WriteFile + SetRenameInformationFile (добавление расширения), создание README.txt / HOW_TO_DECRYPT.html в каждой папке	T1486, T1490	Алгоритм шифрования (статика/динамика), ключи в памяти, shadow copies удаление (vssadmin, wmic)
Сбор данных (стейлер)	%TEMP%\*log*.txt, %TEMP%\*grab*.zip, архивация перед эксфильтрацией	T1005, T1020, T1041	Содержимое архива, целевые пути (браузеры, кошельки, FTP-клиенты), C2 адреса в PCAP
Логирование / отладка вредоноса	%TEMP%\<имя>.log, C:\Windows\Temp\*.log	—	Содержимое лога — часто раскрывает C2, ключи, внутреннюю логику
Living-off-the-land (LOLBins)	Создание скриптов для powershell.exe, wscript.exe, mshta.exe, certutil.exe в %TEMP%	T1059, T1218	Командная строка родительского процесса, содержимое скрипта, подпись родителя

Обход анти-анализа: как остаться невидимым

Современные образцы активно ищут следы мониторинга. Набор практических мер, который снижает вероятность детектирования:

• Переименование и маскировка драйверов. Пересоберите драйвер Procmon (есть исходники в Windows Driver Kit samples) с другим именем сервиса, именем файла, GUID-классом. Подпишите тестовым сертификатом, добавьте в доверенные.
• Сокрытие артефактов API Monitor / Frida. Frida использует именованные каналы (\\.\pipe\frida-*) и создаёт потоки в целевом процессе. Используйте frida —no-pause с кастомным агентом, который не экспортирует символы frida_agent_main. Для API Monitor — отключите GUI, работайте через CLI (APIMonitor.exe /capture /p /o log.xml).
• VMI / HyperDbg — золотой стандарт скрытности. Нет кода в гостевой ОС. Но требует настройки EPT hooks на страницы NtCreateFile в ntoskrnl.exe или мониторинга записей в MFT (Master File Table) через парсинг $MFT на лету.
• Тайминг-обход. Некоторые образцы измеряют RDTSC до/после системного вызова. На гипервизоре можно эмулировать RDTSC с фиксированной задержкой. В user-mode — патчить KUSER_SHARED_DATA или использовать Time Travel Debugging (TTD) в WinDbg, который записывает полную трассировку без накладных расходов в реальном времени.
• Чистая среда без артефактов VM. Удалите VMware Tools / VirtualBox Guest Additions. Используйте QEMU/KVM с -cpu host,+invtsc,+vmx и SMBIOS/DMI таблицами реального железа (серийные номера материнки, BIOS, MAC-адреса). Инструмент vmcloak или packer с provisioner’ами автоматизирует это.

Инструментарий для автоматизации и масштабирования

Ручной анализ одного образца — нормально. Анализ десятков в день — требует пайплайна.

• Cuckoo Sandbox (модифицированный) + DRAKVUF для VMI. Даёт JSON-отчёты с файловой активностью, сетевыми IOC, дампами памяти. Требует доработки под актуальные Windows 10/11 (оригинальный Cuckoo давно не обновлялся).
• CAPE (Community Automated Payload Extractor) — форк Cuckoo с фокусом на распаковку и извлечение конфигов. Включает модули для мониторинга файловой системы через minifilter и API хуки.
• Joe Sandbox / ANY.RUN / Hybrid Analysis — облачные, но позволяют загрузить свой образец и получить детальный лог ФС. Полезны для быстрой триажи, но не дают полного контроля над средой.
• Собственный оркестратор на Python + libvirt / vSphere API: создаёт ВМ из шаблона, инжектирует мониторинг (через shared folder или сетевой загрузчик), запускает образец, собирает артефакты, уничтожает ВМ. Позволяет параллелить сотни сессий.
• Procmon-to-SQLite / Elastic Stack: парсинг PML в структурированную БД для запросов вроде «все файлы, созданные в %APPDATA% за последние 24 часа во всех сессиях».

Распространённые ошибки и как их избежать

• Запуск образца до готовности мониторинга. Даже 100 мс разницы — упущен CreateFile конфига или ключа шифрования. Решение: CREATE_SUSPENDED + инжекция хуков до ResumeThread.
• Игнорирование дочерних процессов. Образец запускает cmd.exe /c, powershell -enc, rundll32.exe. Procmon фильтр по имени процесса их пропустит. Решение: фильтр по дереву PID (Parent PID) или мониторинг всех процессов с пост-фильтрацией по дереву.
• Анализ только путей, без содержимого. Файл config.bin может быть безобидным, а может содержать C2 IP, ключи RSA, список целей. Решение: дамп созданных файлов (Procmon «Save» → «Save All Events» → экспорт, или скрипт, копирующий файлы по путям из лога сразу после создания).
• Отсутствие корреляции с реестром и сетью. Создание файла в автозагрузке бессмысленно без ключа Run. Шифрование файлов бессмысленно без удаления теневых копий и сетевого бикона. Решение: единая временная шкала (таймлайн) всех событий: ФС, реестр, сеть, процессы.
• Работа на «грязном» образе. Остаточные файлы прошлых запусков, обновления Windows, логи Defender создают ложные срабатывания. Решение: реверт к чистому снапшоту перед каждым запуском.

Сценарии выбора подхода: «Если условия такие — действуйте так»

• Быстрая триажа одного файла, Windows 10/11, время 15 минут. Procmon (PML на отдельный диск) + Process Hacker (проверка потоков/модулей) + Regshot (пре/пост снимок ФС+реестр). Запуск через CREATE_SUSPENDED батником.
• Глубокий реверс неизвестного упакованного образца, нужны стеки и буферы. Frida-скрипт с перехватом NtCreateFile/NtWriteFile + дамп памяти после распаковки (procdump -ma) + Intel PT трассировка (если есть железо).
• Массовая проверка фида (сотни семплов в сутки). CAPE / модифицированный Cuckoo с VMI, автоматическое извлечение IOC (файлы, пути, хэши, IP, домены) в MISP / OpenCTI.
• Образец с агрессивным анти-VM/анти-отладкой, падает при любом хуке. Только VMI (DRAKVUF / HyperDbg) или аппаратная трассировка (Intel PT) на голом железе с восстановлением состояния через снапшоты диска. User-mode и kernel-mode хуки будут обнаружены.
• Анализ bootkit / rootkit, заражающего MBR / VBR / загрузчик. Только гипервизорный уровень (мониторинг до загрузки ОС) или физический диск + внешний анализатор (Chipsec, UEFI scanner). Внутренние инструменты бесполезны — они загружаются после заражения.

Чек-лист качества сбора артефактов перед анализом

Перед тем как переходить к статическому/динамическому реверсу созданных файлов, пройдитесь по пунктам:

• [ ] Лог Procmon (PML) открывается без ошибок, события есть за весь период работы образца.
• [ ] В логе присутствуют события CreateFile с DesiredAccess: Write / Append для целевого PID и его детей.
• [ ] Включены стеки вызовов (Advanced Output) — они позволяют найти код, инициировавший запись.
• [ ] Снят дамп памяти процесса (или полного ядра) в момент пиковой активности.
• [ ] Сравнены снапшоты диска до/после — найдены все новые файлы, включая удалённые.
• [ ] PCAP содержит трафик, коррелирующий по времени с созданием подозрительных файлов.
• [ ] Хэши (SHA256) всех извлечённых файлов посчитаны и проверены в VT / Hybrid Analysis / локальной базе.
• [ ] Цифровые подписи созданных .exe/.dll проверены (signtool / sigcheck) — самоподписанные или невалидные = подозрительно.
• [ ] Строки из созданных файлов (strings, floss) просканированы на IOC (IP, URL, домены, ключи, расширения).
• [ ] Сохранён полный набор артефактов (PML, дампы, PCAP, снапшоты, скрипты запуска) с читаемыми именами и таймстемпами для повторного анализа.

FAQ: частые вопросы при настройке мониторинга

В: Procmon не видит файлы, которые точно создаёт образец (вижу в Explorer).

О: Проверьте фильтры — по умолчанию Procmon скрывает «File System» операции для системных процессов. Сбросьте фильтры, включите «Show File System Activity». Убедитесь, что драйвер загружен (fltmc в админ-cmd). Если образец пишет через кэш-менеджер (Memory Mapped Files / CreateFileMapping + MapViewOfFile), физическая запись на диск может произойти позже (Lazy Writer) — ищите FASTIO_WRITE или IRP_MJ_WRITE с флагом IRP_PAGING_IO.

В: Как логировать содержимое записываемых данных, а не только пути?

О: Procmon этого не делает. Используйте Frida: Interceptor.attach(Module.findExportByName(‘ntdll.dll’, ‘NtWriteFile’), { onEnter: function(args) { var buf = args[5]; var len = args[6].toInt32(); console.log(hexdump(buf, {length: len})); } }). Или API Monitor с включённым «Buffer Logging». Для больших объёмов — дамп памяти процесса и парсинг виртуального адресного пространства.

В: Образец детектирует Procmon по имени драйвера и выходит. Что делать?

О: Пересоберите драйвер Procmon из исходников WDK (sample «File System Mini-Filter»), изменив ServiceName, Altitude, имя файла .sys. Подпишите самоподписанным сертификатом, добавьте в «Trusted Publishers» и «Trusted Root CA» в гостевой ОС. Включите Test Signing Mode (bcdedit /set testsigning on). Альтернатива — VMI (DRAKVUF), где в гостевой ОС нет никаких драйверов.

В: Стоит ли использовать Sysmon (Event ID 11 — FileCreate) вместо Procmon?

О: Sysmon отличен для продакшн-мониторинга и SIEM, но для реверса одного образца — избыточен и менее детален. Нет стеков вызовов, нет буферов, выше накладные расходы, логи пишутся в ETW (можно потерять при перегрузке). Procmon / Frida / VMI дают большую гранулярность. Sysmon полезен, если вы разворачиваете стэнд для долгосрочного наблюдения (ботнет, APT-симуляция).

В: Как автоматизировать извлечение всех созданных файлов из PML-лога?

О: Используйте procmon-parser (Python) или PML2CSV (C#). Пример логики: отфильтровать Operation == ‘CreateFile’ and Result == ‘SUCCESS’ and DesiredAccess contains ‘Write’, собрать уникальные пути, скопировать файлы с диска (если ВМ ещё жива) или из снапшота диска (mount VHD/VMDK read-only).

Ключевой принцип и следующие шаги

Надёжное отслеживание файловой активности неизвестного приложения в виртуальной среде строится на многослойности и невидимости. Ни один инструмент не даёт полной картины: user-mode хуки дают контекст и буферы, kernel-mode — полноту и устойчивость к обходу API, VMI — абсолютную скрытность и доступ к предзагрузочной фазе, снапшотирование — обнаружение файлов, удалённых до финиша сессии. Комбинируйте минимум два уровня (например, Procmon + Frida, или VMI + снапшоты диска) и всегда коррелируйте файловую активность с процессами, реестром и сетью на единой таймлайне.

Следующие конкретные действия:

1. Подготовьте «золотой образ» ВМ с отключенной телеметрией, установленным Procmon (пересобранным), Frida-сервером и скриптом автозапуска мониторинга при создании процесса.
2. Напишите/возьмите парсер PML → SQLite/Elastic для быстрой выборки «все файлы, созданные PID X и его детьми».
3. Настройте автоматический дамп памяти (procdump -ma) на триггер: создание файла в %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup или массовые WriteFile в пользовательских профилях.
4. Внедрите в пайплайн пост-обработку: извлечение созданных файлов → расчёт хэшей → запрос к VT/HA → обогащение MITRE ATT&CK тегами → отчёт аналитику.
5. Периодически тестируйте стэнд на детектируемость: запускайте известные анти-VM/анти-отладку тесты (pafish, al-khaser, InviZzzible) и проверяйте, видят ли они ваши инструменты.

Материал носит информационный характер и описывает технические подходы к анализу программного обеспечения в изолированных средах. При исследовании потенциально вредоносных образцов соблюдайте меры изоляции (отдельная VLAN, отсутствие доступа к производственной инфраструктуре, снапшоты для отката). Работа с вредоносным кодом и инструментами реверс-инжиниринга может нарушать политики безопасности организации и законодательство — убедитесь в наличии соответствующих полномочий и согласовании с ИБ-службой перед началом работ.