Подводка ведущего
Час дня, как я говорил, открываем вторую часть нашего сегодняшнего мероприятия.
[В записи вырезан перерыв (22,5 минуты). Программа к этому месту сдвинулась: доклад Владислава Азерского заявлен на 12:15, а ведущий открывает вторую часть дня словами «Час дня…».]
И откроет ее Владислав Азерский. Windows и Linux долгое время существовали для специалиста как два отдельных мира. Но непосредственно с появлением WSL граница между ними как-то уже стала гораздо более очевидной. Что теперь все это меняет для DFIR-специалиста и как все это работает, как раз-таки расскажет наш коллега. Давайте поддержим его аплодисментами.
Владислав, вам слово.
Доклад
— Так, надеюсь, слышно. Да, слышно. Сегодня мы поговорим про в основном такой компонент в виде, который появился в определенный момент времени, как Windows Subsystem for Linux. И вроде бы я хотел честно поговорить про некую там криминалистику. Так, следующий. А, вот, все.
Давайте как раз поговорим. Но сразу скажу, что прям какой-то зубодробительной цифровой криминалистики тут не будет, потому что, как оказалось, каких-либо криминалистических артефактов, именно связанных с этим компонентом, нет. То есть очень удивительно, что нет никаких ETW-провайдеров, которые будут пушить события в журнал событий Windows Event Logs. И это удивительно. Ты начинаешь гуглить, даже не гуглить, скачиваешь уже извлеченные манифесты, смотришь там по вхождению Subsystem, Linux, и все пусто, ничего нет. И это первая проблема. Второе: думаешь, хорошо, а есть ли какие-нибудь журналы текстовые, либо что-то еще, что может генерироваться.
Вдруг какой-нибудь SQLite в базе данных это будет находиться, либо где-то еще. Нет, пусто. Конечно, остаются какие-то определенные вхождения, по которым мы можем определить. Есть некоторые упоминания, опять же, в тех же журналах событий, но они такие более косвенные. И в реестре.
Касаемо самой истории развития WSL, здесь сразу можно сделать момент, что версии их две. Первая появилась у нас в 16-м году, вторая в 19-м. На следующем слайде я более конкретно скажу, чем они отличаются. Но для конечного пользователя принцип особо как бы неважно. Ну вот, для чего, в общем, WSL нам нужен? Если вы любите все-таки работать с Linux-окружением, но при этом у вас там на работе Windows Host, либо вы разработчик, который по большей части работает на операционной системе Windows, то, возможно, это будет для вас решение, потому что вы можете спокойно настроить определенный компонент в Винде, включить, так сказать, некоторые рычажки и впоследствии скачать дистрибутив, его открыть и работать как бы из консоли без каких-либо проблем, вот именно линуксовой.
А что касаемо следующих витков, так сказать, не развития, а истории, EasyWSL нам уже помогает, такой некий инструмент открытый, open source, бесплатный. Он позволяет нам как раз образы, которые мы можем там подтянуть из Docker Hub, преобразовать уже в полноценный WSL- дистрибутив. То есть у нас уже появляется возможность хотя бы что-то импортировать, также экспортировать. А уже в 2025 году появилась такая история: Microsoft решили все-таки выложить в публичное поле код ядра и всего остального. Но есть несколько моментов: там некоторые, опять же, драйвера, библиотеки, они все равно являются там проприетарными, но большая часть всего кода, она как бы присутствует.
А давайте... Давайте посмотрим, как WSL выглядит и чем принципиальное отличие. Возможно, для форензика это не так, чтобы будет очень сильно важно, и то же самое для какого-нибудь разработчика и все остальное, но неплохо знать эти тонкости, чтобы впоследствии понимать, как, например, атакующий либо пользователь может с этим взаимодействовать.
WSL1 и WSL2: как устроено и что это меняет для DFIR
В первой версии у нас просто был уровень, некий слой, уровень трансляции, который, по сути, как раз реализовывал то, что у нас системные вызовы Linux проходили через ядро Windows. А вот вторая версия, мы про нее в основном поговорим. Мы можем увидеть вот здесь справа большую типа картинку. И, в принципе, принципиально так все это выглядит. У нас поднимается Linux виртуальная машина, и в которой у нас каждый дистрибутив, потому что мы можем их несколько сделать. Например, мы хотим, чтобы у нас на Windows-системе было Kali Linux и Ubuntu. Следовательно, у нас будет два таких пунктирных коробочки в данной виртуальной машине. И получается, можем уже как-то взаимодействовать.
По итогу получаем: есть хостовая тачка на ОС Windows. У нас в ней поднимается при старте сервис WSL Service, Linux VM. А в ней уже, когда мы хотим открыть какой-то дистрибутив и в нем поработать, естественно, уже создаётся WSL-дистрибутив. И касаемо особенностей работы с WSL здесь как раз очень много важного, потому что в некоторых как раз вот атаках и кейсах, которые у нас в принципе их довольно-таки было мало, но в основном, если посмотреть, что есть в новостном поле, то можно было что-то найти. Касаемо особенностей. Давайте начнем. Первое. Мы можем запускать исполняемые файлы Windows из-под WSL. Мы, например, спокойно заходим в какой-нибудь дистрибутив, получаем оболочку bash и можем запускать, либо указывая полный путь, либо указывая просто, например, notepad.exe, у нас будет запущен.
Отлично. И здесь можно отметить, например, для какого-нибудь SOC-специалиста, что в данном случае у нас родительским процессом будет wsl.exe, который запускает, в свою очередь, notepad.exe. Дальше это история, что у нас к каждому дистрибутиву примонтирована файловая система Windows, то есть хостовая. И мы можем спокойно, как двухнаправленную историю, как копировать, так и сохранять определенные файлы. Мы немножко даже попозже посмотрим и здесь. Опять же, для аналитиков будет важен момент, если, опять же, у них есть телеметрия, то, что все файловые операции, которые мы производим из WSL, например, мы скачали какой-нибудь файлик и его хотим закинуть в файловую систему Windows, у нас будет обрабатываться системным процессом dllhost.
Почему на это я делаю акцент? Иногда бывает, что в некоторых EDR-решениях либо просто отсутствуют детектирующие правила на данное поведение. И в основном вот этот второй абзац, он больше справедлив для WSL 2. В первом тоже есть такой механизм, но он немного по-другому работает. И последнее — это сетевая изоляция. По сути, у нас WSL 2 полностью изолирован, то есть его сетевой стек. И в данном случае к чему это может привести? Если у нас на системе хостовой, виндовой установлен какой-нибудь Sysmon, который собирает телеметрию по сетевым соединениям, либо EDR, то впоследствии мы ничего не увидим, потому что все это будет проходить внутри виртуальной машины, в которой находится у нас Linux-дистрибутив.
Поэтому злоумышленники в некоторых кейсах как раз это использовали. Дальше вот как раз пройдемся, как в принципе это все выглядит. Например, мы можем запускать команды в дистрибутиве, указывая его из ОС Windows. Здесь мы просто используем нативный инструмент wsl.exe. Например, делаем листинг, чтобы посмотреть, сколько у нас дистрибутивов есть. А дальше уже указываем какой-то конкретный из них. Дальше пользователь root и exec. Как вы заметили, тут нет ситуации, что у нас идет запрос пароля, либо мы его даже не передаем здесь. Это означает, что в рамках работы с WSL-инструментом у нас получается так, что в каждый Linux-дистрибутив, который у нас стоит на системе, мы можем спокойно под рутом зайти.
Это определенная специфика работы. Следовательно, даже если мы рут где-то прописали, такой хорошо у нас никто ничего не сделает, но из-за Windows мы можем спокойно это провернуть. И второй момент, про который я говорил, особенность, то, что когда мы уже находимся в дистрибутиве, в WSL, то мы можем запустить, указав, например, абсолютный путь до калькулятора.exe, и он у нас как раз тут появится. Все это работает по умолчанию. Именно вот механизм, когда у нас запускается какой-нибудь виндовый файлик, исполняемый из дистрибутива Linux. Здесь мы можем увидеть, как это отключить. Мы просто прописываем в каждом дистрибутиве, у него есть конфигурационный файл /etc/wsl.conf.
Например, эти две строчки. Следовательно, дальше ничего такого не будет происходить. Второй момент. Как вы заметили, там во втором столбце у нас был момент, что мы можем туда и обратно копировать файлы. И здесь как это будет выглядеть? Мы, если хотим из винды скопировать какой-нибудь WSL-дистрибутив, мы переходим по UNC-пути \wsl$ и дальше указывается уже название самого дистрибутива. И дальше мы получаем как раз файлы и каталоги, которые будут верны для Linux ОС. И второй момент. Мы находимся в дистрибутиве Linux и мы хотим скопировать какие-нибудь файлики на хостовую тачку. Здесь у нас уже все примонтировано. Это находится в каталоге /mnt.
Мы переходим, например, в папочку и можем уже копировать. Как минимум здесь сделан просто листинг. Хорошо, а почему я вот рассказал про особенности? Потому что эти особенности используются уже в некоторых кейсах, которые можно публично видеть. Но перед этим хочу сказать, что даже вы когда собираете какую-то информацию, чтобы понять, какие группировки что делали, когда это делали, и в общем делали это они, нужно все-таки перепроверять информацию, потому что в нескольких источниках было упоминание, что несколько группировок, такие как Turla, FIN7, Ryuk, использовали WSL. Это было на двух-трех каких-то источниках, и это было очень странно, потому что больше упоминаний нигде не было.
По итогу оказалось, что это просто был некий нейрослоп, когда человек все-таки не проверил, что было написано, поэтому вот это более актуальная информация.
Кейсы: Qilin и npm-тайпсквоттинг
Первое упоминание там примерно на самом деле было в 2017 году, но более-менее какая-то из компаний расписала, что мы нашли ELF-файл, который взаимодействовал с WSL. Конкретики нет, вообще нет. Они просто нашли какой-то определенный сэмпл, проанализировали, сказали, мы нашли, а все остальное до свидания. Второе — это у нас раз, по сути, некоторые аффилиаты группировки Qilin. Начало февраля 26-го года, злоумышленники стандартно получают доступ в инфраструктуру через какой-нибудь RDP, либо уже там есть какой-нибудь ратник. Дальше. Я не знаю зачем, но они решили это провернуть. Они либо активируют, либо развертывают WSL. Но для этого нам уже нужно иметь на самом деле полный контроль над машиной.
Если мы говорим про ситуацию, когда WSL нет. Дальше что они делают? Они загружают шифровальщик в формате ELF и выполняют в среде WSL. И что у нас происходит? Так как у нас примонтирована файловая система Windows, то все пользовательские файлы будут затронуты, потому что у нас данный ELF-файл пройдется по файлам, уже находящимся в NTFS. И по итогу что мы получаем? Зашифрованные файлы на хостовой ОС Windows. И последняя недавняя история. Была определенная кампания, которую злоумышленники провернули. Она была в августе. В чем специфика? Это npm typosquatting. Они создали около 40, либо даже 50 npm-пакетов со сходными названиями. То есть там разница могла быть в том, что они перепутали два символа, рядом находящихся, либо там, например, l заменили на единицу.
И после того, как такой пакет доставлялся на систему, там выполнялся скрипт. Что этот скрипт делал? Он проверял сначала, а находится ли система, то есть работает ли пользователь под системой Linux. Если он работает под системой Linux, следовательно, проверял следующий момент. А работает ли в данном случае именно в рамках дистрибутива WSL. Для этого он проверял две переменные окружения, потому что они всегда есть по умолчанию. И что дальше происходило? Скачивался шифровальщик, копировался он из WSL на файловую систему Windows и запускался. Ой, даже не шифровальщик, а стилер. И крал аутентификационные данные. Это в принципе те кейсы, которые как минимум можно найти.
Вектор атак. Перейдем уже, немножко сужаемся, то есть даже обобщаем. Что в итоге получаем? У нас есть два варианта вектора атак. Первый – это когда у нас злоумышленники получили доступ к дистрибутиву WSL с помощью вредоносного скрипта либо пакета, как вот третья из представленных новостей, которые были опубликованы. И Windows side, когда у нас злоумышленник получил доступ к хостовой машине. Это может быть в корпоративной инфраструктуре. Человек решил подключиться, дальше поднял свои права и начал работать. И здесь важны два сценария. Первое – WSL у нас не установлен, следовательно, потребуется получить полный контроль над системой. Это означает, что нам должны быть админские права.
Если их нет, то WSL мы не поставим, потому что нужно включить как раз вот эти два компонента, связанные с WSL и связанные с системой Hyper-V, то есть с виртуализацией. Если у нас установлен, мы можем дальше скачать какой-нибудь дистрибутив и с ним дальше работать.
Закрепление, доставка дистрибутива и обнаружение
Рассмотрим как раз закрепление. У нас есть, опять же, в каждом дистрибутиве файлик /etc/wsl.conf, есть секция boot, есть переменная, допустим, слово command, ключ. Сюда мы можем указать команду, которая будет запущена при запуске самого дистрибутива. Здесь у нас на самом деле это просто reverse shell, оболочка, которая дает уже злоумышленнику shell жертвы. И здесь мы пойдем по сценарию, который скорее всего будет более применим. То, что WSL у нас установлен на системе, к хосту подключились и дальше вот провели вот эту историю. Они, получается, сделали листинг, потом указали определенный дистрибутив и дальше уже сделали следующий момент. Они прописали команду в файле /etc/wsl.conf.
Второй момент, очень специфический, который в основном не сработает, это закрепление через WSL-плагин. Есть такая возможность, но тут нам требуется цифровая подпись. И, скорее всего, выдана все-таки каким-то доверенным центром, потому что в противном случае для тестового нам придется отключать определенный механизм, при котором Windows не доверяет самоподписанным цифровым подписям. Отлично. Допустим, злоумышленники иногда могут их своровать в какой-нибудь компании, подписали. Дальше что им нужно сделать? Это подписать саму DLL, которая имеет какую-то полезную нагрузку, например, скачать какой-то бикон и его запустить, и дальше зарегистрировать по определенной ветке пути.
И здесь у нас как раз указывается просто путь, где у нас все это будет. И здесь два формата работы. Мы можем перезапустить WSL, либо выключить компьютер. По сути, при старте системы, либо при перезапуске службы у нас будет запускаться та нагрузка, находящаяся в DLL. И еще очень важный момент. Поговорим про то, что вот эти дистрибутивы, их же откуда-то нужно забирать. Мы можем их, например, доставить.
Есть один проект на GitHub, который, по сути, позволяет создать кастомный дистрибутив WSL и добавить туда полезную нагрузку. В данном случае использовался калькулятор. Человек, разработчик данного скрипта, написал код и, в принципе, как это выглядит. Мы указываем там название, какое у нас будет дистрибутив, и -p calc.exe – это какой исполняемый файл у нас будет запущен при как раз старте, при заходе в сам дистрибутив.
Далее у нас создается вот этот вот calc.wsl файл. Мы его доставляем на хост, указываем вот эту команду. У нас он спокойно здесь появляется в листинге. И мы его запускаем. При его запуске wsl -d calc в WSL у нас запускается калькулятор. Собирается, скорее всего, на довольно маловесном Alpine Linux образе. И там он где-то будет в районе 10 мегабайт. Как это выглядит, если нам нужно посмотреть их наличие? Первое, в реестре, в определенном пути, здесь, возможно, плохо видно, у нас есть информация, сколько дистрибутивов у нас установлено. Здесь есть путь, здесь есть название, здесь есть, а также дополнительно, если нужно, какое название виртуального диска данного Linux-дистрибутива у нас фигурирует.
И дальше мы идем уже по косвенным определенным логам, которые можем как-нибудь выцепить. Есть два журнала, про них я подробно разговаривать не буду, потому что здесь нам важны как раз те вхождения, которые мы тут видим. Во-первых, там, где находится у нас виртуальный диск. Чаще всего он по умолчанию будет при создании нового дистрибутива называться ext4.vhdx. Следовательно, мы можем как-то подумать и в одном случае SOC-ом настроить правила, в другом поискать.
Еще проще. Мы можем, допустим, не делать вот эти странные вещи, которые делает злоумышленник, либо какой-нибудь пользователь, который захотел таким образом доставлять в прошлом кейсе. Мы, например, собрали какой-нибудь маленький дистрибутив 10 мегабайт, сделали из него архив. И что мы можем сделать? Мы можем просто доставить этот архив, его импортировать и указать путь, где у нас будет находиться виртуальный диск ext4.vhdx, и спокойно он потом запускается. Это еще один пример. Хорошо, мы не хотим ничего доставлять со своего сервера. Мы можем воспользоваться утилитой winget, которая заберет что-нибудь с Microsoft Store из магазина, например, образ тоже Kali Linux, либо из публичного открытого репозитория winget.
Здесь у нас, например, злоумышленник делает winget search kali, находит дистрибутивы, и там уже в зависимости от выбора он будет скачан либо из репозитория winget, либо из Microsoft Store. И здесь нужно учитывать, если злоумышленник использует утилиту winget, то вот по этой директории, вот по такому паттерну файла у нас будет находиться много полезного. У нас будет фиксироваться команда, которая запускалась. То есть в тех случаях у нас будет видно, что winget search kali присутствует, насколько это успешно, неуспешно. И вот последнее, что у нас производилась установка.
Также хотелось бы упомянуть, но я прямо ярко про это рассказывать не буду, то, что специалисты SpecterOps сделали довольно хороший ресерч, где рассказали, что они могут запускать напрямую процессы в Linux-контейнере без использования утилиты WSL, как мы раньше уже видели. Для этого используется определенный COM-интерфейс. Если интересно, можете почитать, там довольно-таки очень подробно все расписано. К этому они пришли после того, когда опубликовали открытый код WSL.
Хорошо, вот мы прошлись по этой истории, что есть WSL, какие его особенности, а что, правда, с цифровой криминалистикой. Ну, как мы можем заметить, особо ничего не генерируется, толком есть только какие-то косвенные связи, поэтому приходим к стандарту. Так как у нас хостовая система на Windows, то это криминалистика Windows. И дальше уже, если работаем с дистрибутивами, уже смотрим на то, что мы можем найти, какие криминалистические артефакты, либо логи в самом дистрибутиве линуксовом. И тут можно сделать некий такой pipeline действий. Первое, мы проходимся по базовым артефактам и журналам Windows, которые нам позволяют установить, а есть ли у нас установленный WSL, используется, то есть включены ли компоненты и есть ли какие-то уже дистрибутивы.
Это без контекста, чтобы об этом узнать. Дальше мы переходим уже к цифровой криминалистике ОС Linux. Если мы заметили, что у нас есть какие-то дистрибутивы, они появились в какой-то странный момент, их не пользуется разработчик, либо какой-то там пользователь, следовательно, мы что делаем? Мы либо делаем триаж, либо копируем этот ext4.vhdx образ и дальше его анализируем. В рамках там DFIR-а я бы пошел уже именно как incident responder с позиции сформировать гипотезу на основе актуальных TTP злоумышленников, потому что чаще всего мы сталкиваемся именно с какой-то внешней угрозой, которая часто работает по определенному своему стандарту. И дальше уже бы переключился вот к анализу криминалистических артефактов и журналов ОС Linux.
Если будет интересно почитать какие-то другие исследования и в принципе получить данную презентацию, можете как раз перейти по данному телеграм-каналу, там будет все, скорее всего, либо сегодня, либо завтра. Спасибо. Жду тогда вопросов от вас.
Вопросы из зала
— Через поднятую руку, коллеги. Есть ли вопросы?
Да, вижу, вижу, вижу, бегу, бегу, бегу. Это прекрасно, потому что я думал, что опять вопросов не будет.
— Владислав, добрый день. Очень хороший доклад. И мы вот на самом деле с коллегой сейчас думаем над вопросом, а если, например, настроить аудит на вот этой сабсистеме Linux и логи выводить через путь, который монтирован на Windows-системе. Такой вариант возможен для мониторинга активности там? Да, возможно, и, скорее всего, это один из вариантов, потому что я еще тут не упомянул, я в рамках ресерча нашел, что есть вот эти вот системы плагинов, мы можем как-то их там использовать, и заметил: о, есть Windows Defender плагин, я могу его поставить, и что-то будет. Я такой смотрю, хорошо, я надеюсь, что это чисто не под MDE решение их, и он хотя бы будет сохранять какие-то логи в файликах.
Оказалось, что нет. Но потенциально можно как раз посмотреть в сторону WSL-плагинов, но здесь есть большая проблема. Придется, скорее всего, отключать Secure Boot и давать винде трасты на то, что самоподписанный сертификат работает. Отчасти вот этот функционал, который они внедрили, мог бы работать очень хорошо, потому что это бы запускалось внутри вот этого Linux VM, и ты мог бы просто собирать из различных дистрибутивов, которые там поднимаются, сразу какие-нибудь логи.
А так, да, скорее всего, в данной истории либо просто ограничивать для пользователей использование WSL, мониторить включение компонент, потому что, опять же, использовать будет их ограниченное количество, вряд ли там какой-нибудь бухгалтер, юрист. Но если собирать туда, то придется именно в самом дистрибутиве настраивать какую-нибудь тулзу для мониторинга и сбора данных, чтобы потом как хороший вариант прокопировать на хостовую тачку и уже дальше забирать. Ну, как будто это действительно единственный пока что предполагаемый вариант. Спасибо.
— Коллеги.
— Спасибо за доклад. Вопрос такой. А современные EDR-ки, они не заглядывают внутрь контейнеров в Hyper-V? В WSL же она на Hyper-V в основном работает, правильно? Да. Честно, у меня такой аналитики, статистики нет. Но я видел где-то, что как минимум в различных международных вендорах такой функционал как бы внедряют. Касаемо того, что происходит сейчас на ру-рынке, не знаю, но, возможно, некоторые уже на эту тему как минимум либо что-то сделали базово просматривать, либо сейчас на пути. Потому что все-таки, если обратить внимание, 26-й год, и как бы основные кейсы появились вот здесь. Видимо, есть некоторая потребность все-таки провалиться дальше как раз вот в данный Linux VM.
И по сути вот как раз те же опять же плагины, если бы их можно было нормально ставить, они могли быть хотя бы каким-то решением.
— Ну, а сам факт запуска Hyper-V — это фактически же тоже будет сигналом, потому что… Это будет сигналом, это 100%, но, опять же, здесь нужно, типа, учитывать контекст, и, опять же, я не сторонник того, чтобы использовать там WSL, его будут малое количество людей использовать, поэтому, скорее всего, просто таргетироваться на тех пользователей, которым этот инструмент, конечно, нужен. А средством WSL можно шифровать этот виртуальный диск? Ну, то есть, грубо говоря, запускается Калюха уже в зашифрованном диске, и когда приходит форензик, он, соответственно, ничего не сможет без какого-то ключа, а ключ, соответственно, получается там по DNS или еще что-нибудь подобное.
Потенциально это сделать можно, но злоумышленники вряд ли это будут делать, потому что им чаще всего нужно без каких-то потенциальных ошибок дальше что-то сделать, потому что дальше что идет? Вы приходите в чатик с ними беседоваться, они такие: хорошо, отлично, давайте на проверку какие-то файлики. И потом окажется, если их нельзя будет восстановить, либо что-то другое, то все, это уже большая проблема. Они не получат за это деньги потенциальные.
— Ладно, окей, спасибо. Коллеги, еще вопросы? Не вижу ни одной руки. Владислав, большое спасибо. Как всегда, исчерпывающе клево.