Как обнаружить fileless-шифровальщик в памяти: практические методы

Когда антивирус молчит, а файлы уже зашифрованы, поздно искать файл вредоносной программы на диске. Её там просто нет. Fileless-шифровальщик живёт исключительно в оперативной памяти, прячется в легитимных процессах и не оставляет привычного следа в файловой системе. Эта статья — о том, как найти его в памяти, пока он не нанёс полный ущерб, и что делать, когда вы уже подозреваете компрометацию.

Почему fileless-шифровальщик так сложно обнаружить

Классический малварь приходит в систему как файл: вы скачали что-то, запустили, и она записала себя на диск. Антивирус видит этот файл, сканирует, удаляет. Всё просто. Fileless-подход ломает эту логику. Вредоносный код попадает в память через уязвимости в браузере, через макросы в документах, через инструменты вроде PowerShell или WMI, и никогда не касается диска в виде исполняемого файла.

Он заражает запущенный процесс — например, explorer.exe или svchost.exe — и от его имени начинает работать. С точки зрения файловой системы всё чисто. С точки зрения антивируса, который смотрит на файлы, тоже. А тем временем процесс в памяти уже сканивает ваши документы и шифрует их.

Первые признаки, что в памяти кто-то лишний

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

• Процесс потребляет аномально много CPU или памяти, хотя вы ничего тяжёлого не запускали.
• Сетевой трафик возрастает без видимой причины — особенно подозрительны соединения на нестандартных портах.
• PowerShell, WMI или certutil запускаются с параметрами вроде -enc, -e, Invoke-Expression — это классические признаки выполнения кода из командной строки.
• Службы, которых вы не ставили, появляются в автозагрузке или в списке запущенных процессов.
• Антивирус или EDR-агент внезапно отключается, а попытка его перезапустить не срабатывает.

Если вы видите два-три из этих признаков одновременно — это повод перейти к детальному анализу памяти.

Метод 1: анализ процессов через встроенные инструменты

Начнём с того, что есть под рукой на любой Windows-машине.

Process Explorer — ваш первый инструмент

Скачайте Process Explorer с сайта Microsoft Sysinternals. Это продвинутый диспетчер процессов, который показывает то, что стандартный Task Manager скрывает. Откройте его и обратите внимание на следующее:

1. Проверьте родительские процессы. Если PowerShell запущен из winword.exe — это красный флаг. Word не должен запускать командную строку.
2. Посмотрите вкладку «Strings» в свойствах процесса. Если там видны строки с упоминанием шифрования, адресов крипто-кошельков, Tor-узлов — процесс подозрителен.
3. Проверьте загруженные DLL. Вкладка «DLLs» покажет, какие библиотеки загружены в процесс. Необычные DLL без цифровой подписи или с подозрительными именами — повод для беспокойства.
4. Обратите внимание на процессы с пустыми или случайными именами. Легитимные процессы обычно имеют осмысленные названия и путь к исполняемому файлу.

Сетевые соединения под прицелом

Откройте командную строку от администратора и выполните:

netstat -anob

Этот вывод покажет все активные соединения с привязкой к процессам. Ищите исходящие подключения к неизвестным IP-адресам, особенно если они идут от процессов, которые не должны выходить в сеть — например, от lsass.exe или svchost.exe на нестандартных портах.

Метод 2: дамп памяти и его анализ

Если подозрительный процесс найден, нужно заглянуть внутрь него. Для этого делается дамп памяти — полный снимок того, что процесс держит в RAM.

Как снять дамп

Самый простой способ — через Task Manager: правый клик на процесс → «Создать файл дампа». Дамп сохраняется в папку TEMP. Для более детального анализа используйте Sysinternals ProcDump:

procdump -ma  output.dmp

Флаг -ma даёт полный дамп со всей памятью процесса — это именно то, что нужно для поиска вредоносного кода.

Что искать в дампе

Откройте дамп в WinDbg (бесплатный отладчик Microsoft) или в любом HEX-редакторе. Ищите:

• Шелл-код — последовательности байтов, которые не принадлежат ни одной загруженной DLL.
• Зашифрованные или обфусцированные строки — блоки данных с высокой энтропией.
• Упоминания алгоритмов шифрования: AES, RSA, Salsa20, ChaCha20 — шифровальщики часто содержат эти строки в коде.
• Адреса кошельков или инструкции по выкупу — иногда они хранятся в открытом виде в памяти.

В WinDbg для поиска строк используйте команду s -a 0 L?80000000 "password" (замените на нужный ключевой фрагмент). Для поиска шелл-кода — плагины вроде ! или специализированные скрипты.

Метод 3: поведенческий анализ через ETW

Event Tracing for Windows (ETW) — это встроенная система трассировки, которая логирует практически всё, что происходит в системе. Она работает на уровне ядра и видит то, что обычные инструменты упускают.

Для анализа используйте Windows Performance Recorder (входит в Windows Assessment and Deployment Kit):

1. Запишите трассировку в нормальном состоянии системы — это будет ваш baseline.
2. Запишите трассировку в момент подозрительной активности.
3. Сравните два файла в Windows Performance Analyzer.

На что смотреть в трассировке:

• Необычные вызовы API — особенно VirtualAllocEx, WriteProcessMemory, CreateRemoteThread. Это классическая цепочка для внедрения кода в чужой процесс.
• Аномальные выделения памяти — если процесс резервирует большие блоки памяти с правами RWX (чтение, запись, выполнение), это почти наверняка инжект.
• Подозрительные обращения к реестру — добавление в автозагрузку, отключение защитных инструментов.

Метод 4: проверка на уровне ядра

Продвинутые fileless-шифровальщики могут прятаться с помощью техник типа process hollowing (создание легитимного процесса в приостановленном состоянии, замена его памяти на вредоносный код, запуск) или process doppelgänging (использование NTFS-транзакций для загрузки подменного кода). Для их обнаружения нужен взгляд на уровень ядра.

Здесь помогают:

• WinDbg с подключением к ядру — позволяет просматривать структуры данных ядра, включая список процессов (EPROCESS) и загруженные модули.
• Kernel callbacks через EDR — если у вас установлен EDR-агент, он регистрирует коллбеки на создание процессов, загрузку модулей, выделение памяти. Логи EDR могут показать инжект в реальном времени.
• Проверка драйверов — некоторые fileless-атаки используют уязвимые легитимные драйверы (Bring Your Own Vulnerable Driver, BYOVD) для получения доступа к ядру. Проверьте список загруженных драйверов через driverquery /v и сравните с известными уязвимыми списками (например, от Microsoft или LOL Drivers).

Метод 5: память как аренбий свидетель — Volatility Framework

Volatility — это open-source фреймворк для анализа дампов памяти. Он создан специально для форензики и содержит плагины для поиска именно fileless-активности.

Базовый рабочий процесс:

1. Снимите полный дамп памяти всей системы через winpmem или аналогичный инструмент.
2. Запустите Volatility с нужными плагинами:

volatility -f memory.raw --profile=Win10x64 pslist
volatility -f memory.raw --profile=Win10x64 malfind
volatility -f memory.raw --profile=Win10x64 ldrmodules
volatility -f memory.raw --profile=Win10x64 handles -t Key
volatility -f memory.raw --profile=Win10x64 getsids

Плагин malfind — ключевой. Он ищет участки памяти с правами RWX, которые не соответствуют ни одному файлу на диске. Это классический признак инжектированного кода. Плагин ldrmodules показывает загруженные модули и может обнаружить скрытые DLL — те, что есть в памяти, но отсутствуют в официальных списках процесса.

Сравнение подходов: что и когда применять

Метод	Сложность	Что находит	Когда использовать
Process Explorer	Низкая	Подозрительные процессы, необычные DLL, строки в памяти	Первая проверка, быстрый скрининг
netstat + командная строка	Низкая	Аномальные сетевые соединения	Когда подозревается активная атака
Дамп памяти + WinDbg	Средняя	Шелл-код, строки шифрования, кошельки	Детальный анализ конкретного процесса
ETW-трассировка	Средняя	Инжекты, подозрительные выделения памяти, API-вызовы	Мониторинг в реальном времени, сравнение baseline
Анализ ядра	Высокая	Process hollowing, BYOVD, руткиты в памяти	Подозрение на продвинутую атаку
Volatility Framework	Высокая	Полная картина fileless-активности в дампе	Пост-инцидентный анализ, форензика

Частые ошибки при поиске fileless-шифровальщика

Ошибка 1: Полагаться только на антивирус. Большинство классических антивирусов плохо видят fileless-малварь. Если вы ограничились проверкой и она ничего не нашла — это не значит, что системы чиста.

Ошибка 2: Искать файл на диске. Fileless — значит без файла. Поиск по файловой системе здесь бесполезен. Нужно смотреть в память.

Ошибка 3: Игнорировать PowerShell-логи. PowerShell Script Block Logging и Module Logging записывают весь выполняемый код. Если они не включены — вы теряете огромный пласт информации. Включите через GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging.

Ошибка 4: Не сохранять дамп до перезагрузки. После перезагрузки память очищается, и все следы исчезают. Если подозреваете компрометацию — сначала дамп, потом всё остальное.

Ошибка 5: Считать, что одной проверки достаточно. Fileless-шифровальщик может иметь несколько стадий и спящих компонентов. Один чистый снимок памяти не гарантирует отсутствия угрозы — нужен мониторинг.

Что делать в зависимости от вашей ситуации

Ситуация 1: Вы администратор и хотите проверить рабочую станцию

Начните с Process Explorer и netstat. Включите PowerShell Script Block Logging и настройте алерты на запуск PowerShell с обфусцированными параметрами. Если есть EDR — проверьте его логи на аномальные выделения памяти. Этого достаточно для 80% случаев.

Ситуация 2: Вы уже обнаружили шифрование и хотите понять, как оно работало

Снимите дамп памяти немедленно, до перезагрузки. Проанализируйте через Volatility с плагинами malfind и ldrmodules. Найденный шелл-код поможет определить семейство шифровальщика и, возможно, найти известный дешифратор.

Ситуация 3: У вас корпоративная сеть и нужен системный подход

Внедрите EDR с поведенческим анализом (не сигнатурным). Настройте Sysmon с правилами, которые логируют создание процессов, загрузку модулей и сетевые соединения. Регулярно снимайте эталонные трассировки ETW и сравнивайте с текущим состоянием. Настройте алерты на аномалии в памяти процессов.

Ситуация 4: Вы реагируете на активный инцидент

Изолируйте машину от сети (но не выключайте). Снимите полный дамп памяти. Запишите список запущенных процессов и их командные строки. Проверьте автозагрузку и запланированные задачи. Только после сбора доказательств — перезагружайте и восстанавливайте из бэкапа.

Практические рекомендации

• Включите аудит PowerShell. Script Block Logging запишет даже обфусцированный код после деобфускации, потому что PowerShell выполняет уже расшифрованную версию.
• Ограничьте PowerShell. Настройте Constrained Language Mode через AppLocker или WDAC. Это не остановит продвинутого атакующего, но усложнит жизнь массовым шифровальщикам.
• Отключите ненужные инструменты. Если вы не используете WMI, certutil, mshta для рабочих задач — заблокируйте их через AppLocker. Это уменьшит поверхность атаки.
• Мониторьте аномальные выделения памяти. Настройте алерты на выделение RWX-памяти процессами, которые этого не делают в норме.
• Ведите baseline. Запишите нормальный список процессов, загруженных DLL и сетевых соединений для каждой рабочей станции. Отклонение от baseline — сигнал для проверки.
• Регулярно обновляйте систему. Многие fileless-атаки используют известные уязвимости в браузерах, Office, компонентах Windows. Патчи закрывают эти векторы.

Итог

Fileless-шифровальщик — это не миф и не экзотика. Это реальная техника, которую используют как продвинутые группировки, так и массовые малварь-кампании. Ключевой принцип обнаружения: не ищите файл — ищите аномалию в поведении процессов и в оперативной памяти.

Начните с малого: включите PowerShell-логирование, поставьте Process Explorer на рабочие станции и научите команду пользоваться ими. Для серьёзной защиты нужен EDR с поведенческим анализом и регулярный мониторинг памяти критичных систем. Если инцидент уже произошёл — не перезагружайте машину, пока не сняли дамп памяти. Каждая секунда работает на вашу сторону, пока память ещё не очищена.