# DFIR vs WSL: цифровая криминалистика на стыке миров

Владислав Азерский · F6

MOSCOW FORENSICS DAY ’26 · День 2 — пятница, 4 сентября 2026 · По программе 12:15–12:35 · В записи 03:43:38–04:09:12

Саммари выступления · https://2026.moscow-forensics-day.workers.dev/summary/09-azersky
Расшифровка: https://2026.moscow-forensics-day.workers.dev/transcript/09-azersky · Слайды: https://2026.moscow-forensics-day.workers.dev/slides/08-dfir-vs-wsl · Смотреть с 03:43:38: https://youtu.be/WuMIv5sFPRs?t=13418

---

## Кратко

Доклад с отрицательным результатом, и это его главная ценность: своих криминалистических артефактов у подсистемы Linux в Windows практически нет — ни ETW-провайдеров, ни текстовых журналов, ни баз, только косвенные следы в реестре и паре логов. Зато у WSL2 есть три свойства, которыми пользуются атакующие: из Linux-дистрибутива запускаются исполняемые файлы Windows, файловая система хоста примонтирована внутрь, а сетевой стек изолирован — то есть Sysmon и EDR на хосте сетевой активности не видят. Дальше разбор трёх публичных кейсов (шифровальщик ELF у аффилиатов Qilin, стилер через тайпсквоттинг в npm), способов закрепления и доставки кастомного дистрибутива и вывод: отдельной «криминалистики WSL» нет, остаётся криминалистика Windows плюс криминалистика Linux внутри ext4.vhdx. Отдельно спикер разбирает, как в публикациях появился ложный список группировок, и называет это нейрослопом.

## Главное

- Сразу честная рамка: «прям какой-то зубодробительной цифровой криминалистики тут не будет, потому что, как оказалось, каких-либо криминалистических артефактов, именно связанных с этим компонентом, нет».
- Проверено руками: ETW-провайдеров, которые писали бы события WSL в журналы Windows, нет — поиск по извлечённым манифестам по вхождениям «Subsystem» и «Linux» пуст. Текстовых журналов и баз SQLite тоже нет; остаются лишь косвенные упоминания в журналах событий и в реестре.
- История компонента: WSL1 — 2016 год, WSL2 — 2019. Отдельно инструмент EasyWSL превращает образы из Docker Hub в полноценный WSL-дистрибутив с импортом и экспортом, а в 2025 году Microsoft открыла код — часть драйверов и библиотек осталась проприетарной.
- Разница версий: в WSL1 был слой трансляции, системные вызовы Linux шли через ядро Windows. В WSL2 поднимается Linux-виртуальная машина, внутри которой живут дистрибутивы — их может быть несколько одновременно, например Kali и Ubuntu.
- **Особенность 1**: из дистрибутива можно запускать исполняемые файлы Windows — достаточно указать `notepad.exe`. Для SOC это выглядит как процесс wsl.exe, запускающий notepad.exe.
- **Особенность 2**: файловая система Windows примонтирована в каждый дистрибутив, копировать можно в обе стороны. Важная деталь для аналитиков: файловые операции из WSL в файловую систему хоста обрабатываются системным процессом dllhost, и «в некоторых EDR-решениях либо просто отсутствуют детектирующие правила на данное поведение».
- **Особенность 3**: сетевой стек WSL2 полностью изолирован, поэтому Sysmon или EDR на хосте сетевых соединений не увидят — всё происходит внутри виртуальной машины. «Поэтому злоумышленники в некоторых кейсах как раз это использовали».
- Практический нюанс доступа: через wsl.exe можно получить листинг дистрибутивов и выполнить команду, причём «в каждый Linux-дистрибутив, который у нас стоит на системе, мы можем спокойно под рутом зайти» — пароль не запрашивается.
- Запуск Windows-бинарей из дистрибутива отключается двумя строчками в конфигурационном файле /etc/wsl.conf. Копирование: из Windows в дистрибутив — по UNC-пути вида \\wsl$ с именем дистрибутива, из дистрибутива на хост — через каталог /mnt.
- Методическая вставка: в двух-трёх источниках утверждалось, что WSL использовали известные группировки (назывались Turla, FIN7, Ryuk), но больше нигде этих упоминаний нет. Вывод спикера: это «просто был некий нейрослоп, когда человек все-таки не проверил, что было написано», и собранные данные о группировках надо перепроверять.
- **Кейс 1 (2017)**: компания сообщила, что нашла ELF-файл, взаимодействовавший с WSL, — «конкретики нет, вообще нет».
- **Кейс 2 (начало февраля 2026, аффилиаты Qilin)**: вход в инфраструктуру через RDP или уже имеющийся RAT, затем активация или развёртывание WSL (во втором случае нужны права полного контроля), загрузка шифровальщика в формате ELF и запуск его в среде WSL. Поскольку файловая система Windows примонтирована, ELF проходит по файлам в NTFS — на выходе зашифрованные пользовательские файлы на хостовой Windows.
- **Кейс 3 (август)**: тайпсквоттинг в npm — около 40–50 пакетов с именами, отличающимися перестановкой соседних символов или заменой «l» на единицу. Доставленный скрипт проверял, Linux ли система, затем по двум переменным окружения — WSL ли это, после чего скачивал стилер, копировал его из WSL в файловую систему Windows, запускал и крал аутентификационные данные.
- Два вектора: со стороны дистрибутива (вредоносный скрипт или пакет) и со стороны Windows (доступ к хосту с повышением прав). Во втором случае важно, установлен ли WSL: если нет, нужны админские права, чтобы включить компоненты WSL и Hyper-V; если есть — достаточно скачать дистрибутив.
- **Закрепление 1**: в /etc/wsl.conf в секции boot ключ command задаёт команду, запускаемую при старте дистрибутива — в примере это reverse shell, дающий атакующему оболочку на машине жертвы.
- **Закрепление 2** через WSL-плагин — «в основном не сработает»: нужна цифровая подпись доверенного центра, иначе придётся отключать недоверие самоподписанным сертификатам. Если подпись украдена, подписывают DLL с нагрузкой (например, загрузкой бикона) и регистрируют её в реестре; нагрузка срабатывает при перезапуске службы WSL или старте системы.
- **Доставка**: открытый проект на GitHub собирает кастомный WSL-дистрибутив с нагрузкой — в демонстрации при входе в дистрибутив запускается калькулятор. Сборка идёт на Alpine Linux, результат около 10 МБ.
- **Обнаружение**: в реестре есть ветка со списком установленных дистрибутивов — имя, путь и название виртуального диска. В косвенных журналах главное вхождение — файл виртуального диска, по умолчанию ext4.vhdx: по нему можно и правила в SOC настроить, и искать вручную.
- Более простые способы доставки: упаковать маленький дистрибутив в архив и импортировать, указав путь к ext4.vhdx, либо вообще ничего не приносить со своего сервера — скачать образ (например, Kali) утилитой winget из магазина или репозитория. Следы winget полезны защите: в его логах остаются сама команда, её успешность и факт установки.
- Упомянуто исследование SpecterOps: процессы в Linux-контейнере можно запускать напрямую через COM-интерфейс, без wsl.exe, — исследователи пришли к этому после открытия кода WSL.
- Итоговый вывод: раз своих артефактов нет, «приходим к стандарту» — криминалистика Windows на хосте плюс криминалистика Linux внутри дистрибутива. Порядок действий: сначала базовые артефакты и журналы Windows (установлен ли WSL, включены ли компоненты, есть ли дистрибутивы); если дистрибутив появился в странный момент и им никто не пользуется — триаж либо копирование ext4.vhdx и анализ; как incident responder — сформировать гипотезу по актуальным TTP и затем разбирать артефакты и журналы Linux.

## Инструменты, артефакты, технологии

- **WSL1** (слой трансляции системных вызовов) и **WSL2** (Linux-VM на **Hyper-V**), сервис WSL и отдельные дистрибутивы, **EasyWSL**, открытый код WSL (2025).
- **Артефакты и следы**: ветка реестра со списком дистрибутивов (имя, путь, виртуальный диск), **ext4.vhdx**, косвенные записи в журналах событий, логи **winget**, процесс **dllhost** при файловых операциях, родительский **wsl.exe** при запуске Windows-бинарей.
- **Конфигурация и закрепление**: **/etc/wsl.conf** (отключение запуска Windows-бинарей; секция boot с командой), WSL-плагины и подписанная DLL, **Secure Boot** как препятствие.
- **Пути обмена**: UNC-путь `\\wsl$`, каталог **/mnt**.
- **Атакующая сторона**: шифровальщик в формате **ELF** (аффилиаты **Qilin**), стилер через **npm typosquatting**, reverse shell, бикон, кастомный дистрибутив на **Alpine Linux** (~10 МБ), доставка через **winget** и Microsoft Store.
- **Защитная сторона**: **Sysmon**, **EDR**, плагин защитника Windows (оказался бесполезен для логов), исследование **SpecterOps** про запуск через COM.

## Правовой и организационный контекст

Правового и процессуального содержания нет — доклад чисто технический, адресован DFIR-специалистам и SOC. Организационная рекомендация одна и звучит в ответе на вопрос: ограничивать использование WSL для пользователей и мониторить включение компонентов, поскольку подсистема нужна единицам — «вряд ли там какой-нибудь бухгалтер, юрист».

## Вопросы из зала

- **1** (имя не названо): можно ли настроить аудит внутри подсистемы Linux и выводить логи в примонтированный путь на Windows? → Да, вероятно, это рабочий вариант. Спикер проверял путь через WSL-плагины, нашёл плагин защитника Windows и надеялся, что тот хотя бы пишет логи в файлы, — оказалось, нет. Плагины в принципе подошли бы (запуск внутри Linux-VM, сбор логов сразу со всех дистрибутивов), но придётся отключать Secure Boot и доверять самоподписанному сертификату. Практический вывод: либо ограничивать WSL и мониторить включение компонентов, либо ставить внутрь дистрибутива свою тулзу мониторинга и копировать собранное на хост.
- **2** (имя не названо): заглядывают ли современные EDR внутрь контейнеров на Hyper-V? → Прямого ответа нет: «такой аналитики, статистики нет»; у международных вендоров такой функционал, по его наблюдениям, внедряют, про российский рынок он не знает. Раз основные кейсы появились в 2026 году, «видимо, есть некоторая потребность все-таки провалиться дальше» в Linux-VM.
- **3** (тот же спрашивающий): сам факт запуска Hyper-V — уже сигнал? → «Это будет сигналом, это 100%», но нужен контекст: разумнее таргетировать тех пользователей, которым инструмент действительно нужен.
- **4** (тот же спрашивающий): можно ли зашифровать виртуальный диск дистрибутива, чтобы форензик без ключа ничего не получил, а ключ приходил, например, по DNS? → Технически возможно, но злоумышленники так делать не будут: им нужно довести дело до выкупа без ошибок — «вы приходите в чатик с ними беседоваться, они такие: хорошо, отлично, давайте на проверку какие-то файлики», и если файлы не восстановятся, «они не получат за это деньги потенциальные».

## Позиция спикера

Редкий доклад, построенный на отрицательном результате и прямо об этом заявляющий: артефактов нет, волшебного журнала не будет, работайте стандартными средствами двух операционных систем. Самый сильный эпизод — разбор того, как недостоверное утверждение о группировках разошлось по публикациям, и отказ его повторять. Там, где данных нет, спикер говорит «статистики нет» вместо оценок. Обратная сторона: атакующая часть проработана заметно лучше защитной, и конкретных средств детектирования он предложить не может — предел рекомендаций сводится к «ограничить и мониторить включение компонентов».

## Цитаты

- «…как оказалось, каких-либо криминалистических артефактов, именно связанных с этим компонентом, нет».
- «Иногда бывает, что в некоторых EDR-решениях либо просто отсутствуют детектирующие правила на данное поведение».
- «По итогу оказалось, что это просто был некий нейрослоп, когда человек все-таки не проверил, что было написано».
- «Так как у нас хостовая система на Windows, то это криминалистика Windows».
- «Потенциально это сделать можно, но злоумышленники вряд ли это будут делать…»