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

Кратко

Доклад с отрицательным результатом, и это его главная ценность: своих криминалистических артефактов у подсистемы 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».
• «Потенциально это сделать можно, но злоумышленники вряд ли это будут делать…»