Подводка ведущего
Чаще всего у нас в целом в прицеле DFIR-специалистов оказываются совершенно разные вещи. Но наш следующий спикер взял туда обычные приложения Windows. Как в целом все это работает, расскажет нам Владислав Азерский из компании F6. Владислав, пожалуйста, давайте поддержим его аплодисментами.
Кликер, микрофон.
[аплодисменты]
Доклад и вопросы
Всем привет. Ну, я думаю, что мы можем на самом деле начать и поговорить по большей части даже не про какой-нибудь incident response, а чаще даже больше компьютерную криминалистику.
Сегодня мы поговорим про, на самом деле, приложение, которое мы часто можем встретить в каком-нибудь Microsoft Store, но на самом деле и не только. Мы можем даже их собрать, и тем самым они будут упакованы так же, как приложение UWP. Мы про это как раз сегодня поговорим. Немного о себе. Я уже 7 лет работаю в информационной безопасности, занимаюсь в основном реагированием на инциденты информационной безопасности, цифровой криминалистикой, и очень часто провожу различные киберучения в формате Purple Teaming. И также люблю участвовать в различных конференциях, и, следовательно, делать ресерчи на темы как Offensive Security, так и Defensive.
Что у нас такое UWP? Мы можем начать, на самом деле, с самого той истории, когда это все произошло. Windows 8 выпустила различные приложения, которые назывались Metro Apps, либо Modern Apps, и они были, работали, так сказать, контейнеры, изолированы, и у них не было доступа к каким-нибудь важным системным ресурсам самой системы. И это первая история. Дальше уже через некоторое время у нас вышла Windows 10, здесь же у нас появились уже Universal App и сама экосистема как раз UWP, которая позволяла создавать нам, по сути, универсальные приложения, которые можно было запустить, возможно, на каком-нибудь IoT, где у нас есть операционная система Windows, так и на обычных Surface Hub, либо обычных PC.
И при этом нам не требовалось бы это все перекомпилировать, пересобирать и уже хорошо. Но нужно учитывать следующий момент. Вроде бы все это изолировано. Эти приложения мы можем увидеть в основном, например, в Microsoft Store. Но давайте посмотрим, что Microsoft сделали еще. В определенной сборке 1607 они реализовали такую функцию, как Desktop Bridge, которая позволяла нам обычные Win32 программы упаковывать в виде UWP. И при этом мы могли задавать определенные разрешения, которые позволяли нашему приложению спокойно обращаться к системным компонентам самой системы, к функциям различного API. То есть в данном случае у нас пропадала изоляция. И это очень важный момент.
В общем, как они у нас представлены в формате файла? Чаще всего мы, если работаем с Microsoft Store, то мы можем спокойно скачать, нажав на кнопочку, и без этого мы не увидим там какой-то файл, который будет устанавливаться, мы просто увидим прогресс-бар. А что такое у нас, как они выглядят? Это установка MSIX-пакета на сегодняшний момент времени. Они представляют собой некий архив, позволяют нам упростить процессы установки, обновления различных приложений, в данном случае, как обычный инсталлер. Это является некоторым развитием APPX, другого формата, который был чисто привязан на UWP, у которых как раз были вот эти истории с изоляцией, но потом это убрали.
Что еще важно знать? Здесь на скриншоте можем увидеть, что есть, я выделил три основных файла, которые мы встретим в данном MSIX пакете. Это у нас AppxManifest.xml, там будет написано, как у нас приложение будет установлена, как она будет запускаться и также какие разрешения можно ей выставить. Например, там run full trust, это означает, что у нее есть доступ ко всем компонентам самой системы, например, там персональной системы Windows. Дальше это у нас сама подпись, потому что у нас каждый MSIX-пакет должен подписан валидным сертификатом. Об этом мы еще чуть попозже поговорим. И как раз в этом файлике, в пакете сертификат также присутствует.
И помимо этого, тоже очень немаловажная история. Это файлик BlockMap, которым у нас есть все файлы в пакете с их хэш-суммами, что может даже нам помочь.
Давайте вообще посмотрим, как у нас они классифицируются. У нас в основном есть четыре типа приложений, три из которых мы можем встретить в Microsoft Store, последний уже подписан самим разработчиком. Это системные приложения, они по сути по дефолту входят в сборку Windows, их нельзя там допустим, обновить кнопкой, то есть удалить. И, например, они обновляются у нас по кону через Microsoft Store. Дальше у нас есть приложения, которые в данном случае разработка самой Microsoft. Это, например, какой-нибудь Paint, калькулятор, который мы все часто видим. И это, по сути, те приложения, которые также часто поставляются в сборке Windows, но при этом мы можем удалить, переустановить и что угодно сделать с этими приложениями.
Следующие два как раз пункта — это, следовательно, приложения, которые находятся в Microsoft Store, но они не принадлежат и не разработаны Microsoft. И здесь это такие, например, приложения, как там тот же самый Netflix, который мы можем спокойно установить через Microsoft Store, либо же всем известный интерпретатор Python, различных версий, которые мы из Microsoft Store можем взять и установить без каких-либо проблем. И последнее, самое важное, что мы будем и, в принципе, иногда встречали в различных инцидентах, это приложение, которое подписано разработчиком. И здесь я как раз сделал определенное упоминание, что большинство вредоносных MSIX-приложений, они как раз подписаны сертификатом разработчика. Это либо может быть история, когда злоумышленники скомпрометировали какую-то компанию, собрали у них сертификаты и впоследствии подписали свой MSIX-пакет.
Для чего это вообще необходимо? Если мы попытаемся установить какой-нибудь MSIX-пакет, и он не подписан валидной подписью, мы встретим историю, что когда пользователь нажмет на кнопку install, он увидит, что, ой, извините, мы не позволим вам запустить это приложение, потому что мы не смогли провалидировать вашу подпись. И про это мы и поговорим. Как у нас вообще создаются MSIX-файлы? Как мы их можем создать? Какой софт мы можем использовать? Здесь на самом деле в основном два основных гиганта. Это у нас MSIX Packaging Tool, который также можно установить через Microsoft Store. И также коммерческий продукт, Advanced Installer, который тоже бесплатная версия, позволяет нам взять наше обычное приложение и упаковать его в виде UWP.
Хорошо. А вообще, можем ли мы это создать без использования даже этого инструментария? Да, мы можем в данном случае взять утилиту MakeAppx. И для этого нам потребуется на самом деле два основных критерия, даже возможно три. Первый. Мы должны выбрать то приложение, которое мы хотим упаковать. Второе. Мы должны по итогу прописать вручную файлик AppxManifest.xml, в котором будет прописано, как приложение у нас будет установлено, как оно будет запущено и какие разрешения мы ему дадим. Например, мы хотим дать этому приложению возможность работать без изоляции и иметь доступ ко всем компонентам. И для этого как раз во втором примечании мы можем указать runFullTrust, что позволяет нам приложение не находиться в изоляции в каком-нибудь контейнере.
После того, как мы создали с помощью MakeAppx наш пакет, мы должны на самом деле его подписать. Мы можем пойти следующим образом, сделать самоподписанный сертификат и подписать его пакет утилиты SignTool. Но тут нужно помнить одну вещь. Так как этот сертификат самоподписанный, то он не пройдет на самом деле историю с различными доверенными центрами сертификации и нам потребуется до того, как установить сам MSIX-пакет, импортировать в систему сертификат, который мы создали в Trusted Root, в Local Computer, что потребует на самом деле от пользователя админских прав. Но, как я уже сказал, мы не можем вроде устанавливать неподписанные MSIX-пакеты, но с появлением 11 винды разработчики решили сделать следующее, что мы можем спокойно с помощью PowerShell определенного командлета установить как раз неподписанные приложения. Для этого мы должны будем указать в манифесте, в издателе Publisher как раз Organization ID, который у нас указан вот здесь.
Он всегда будет один и тот же, и поэтому это будет один из индикаторов, чтобы найти неподписанные приложения там дальше. Что мы можем посмотреть и понять, что происходит вообще в мире. Например, там середина 23 года компания Microsoft, то есть даже их подразделение Threat Intelligence фиксировала определенную активность некоторых финансово-мотивированных группировок. И они распространили как раз MSIX-пакеты и для их запуска установки использовался как раз обработчик ms- appinstaller. Он по итогу был выключен уже через некоторое время Microsoft, потому что они увидели, что да, очень много различных там как фишинговых атак, так и распространения через SEO poisoning, когда мы, в данном случае, злоумышленники, продвигают свои веб-сайты на позиции выше в индексации, например, Яндекса, Гугла и так далее, поисковых систем. Также это распространяли через различные рекламные вложения. И, например, также они использовали фишинг через Microsoft Teams.
Как здесь вся еще история происходила? Есть определенная CVE, которая на самом деле, я так и не нашел более подробного описания ее работы, но могу предположить, что в данном случае злоумышленники подписывали сертификаты невалидными, допустим, подписями, но исходя из этой уязвимости, они могли спокойно проходить и пользователь получал вот это окошко, где он мог нажать кнопочку install. Но при этом у нас в издателе указывалась совсем не та компания, которая, так сказать, разработала Perimeter 81.
Что еще нужно помнить? И да, вот я описал, что есть некоторые финансово мотивированные группировки, которые как раз всю эту историю смотрели и использовали, но кейсов не так, чтобы очень много. Что еще нужно помнить? Есть фреймворк, который, например, использовала группировка FIN7, и они, что делали? Они создавали MSIX-пакет и внедряли как раз этот фреймворк, который позволяет нам без вмешательства в самый исходный код программы, например, запустить скрипты до его выполнения. И мы видим, что для этого нам нужно в config.json прописать наш PS1, например, сценарий, либо батник, любой на самом деле скрипт, и впоследствии у нас исполнится он уже до исполнения самого необходимого, например, нам приложения.
А что мы можем увидеть на самом деле с позиции DFIR? Нас будет в основном волновать история о том, какие приложения у нас на самом деле установлены с помощью MSIX-пакетов. И здесь есть на самом деле четыре основных point. Первый — это у нас каталоги, так как у нас, когда приложение устанавливается, у нас создается определенный каталог с его названием и три других источника информации, о которых мы сейчас поговорим. В операционной системе Windows есть такая SQLite база данных, которая называется StateRepository-Deployment, и по ней в некоторых таблицах мы можем найти довольно полезную информацию. Если, например, приложение устанавливать как в тех атаках, которые проводились финансово мотивированными группировками, мы сможем увидеть именно линк, в данном случае URL-ссылку, откуда у нас был по сути скачан наш MSIX-пакет. И следующее, если он у нас был запущен дабл кликом спокойно из операционной системы, то мы увидим просто полный путь к этому файлу.
Но помимо этого, если порыться еще поглубже в различных таблицах, мы можем увидеть даже хэш-суммы каждых файлов, которые были в MSIX-пакетах. И следовательно, мы можем таким образом также, например, имея какие-то индикаторы компрометации, искать какие-нибудь файлы, либо просто собирать эти индикаторы компрометации. Но тут нужно учитывать, что вот эта база данных и следующая, они по большей части содержат только информацию про установленные приложения, но не содержат информацию про удаленные. Но на самом деле удаленные нам и особо не нужны в данном случае. Следующая база данных тоже SQLite 3. Тоже есть несколько полезных таблиц, которые здесь приведены. И здесь что мы можем узнать. Например, я говорил, что там Windows 11 позволяет нам установить неподписанные MSIX-пакеты. Следовательно, мы можем в рамках одной таблицы найти как раз вот этот Organization ID, который будет говорить, что да, пакет был установлен у нас без подписи.
И также помимо этого узнать, какой у нас там издатель, тоже что на самом деле важно. Помимо этого у нас есть всеми любимый журнал событий, который есть во всех операционных системах Windows. И тут я разобрал как раз четыре основных кейса. Первый и второй кейс связаны с тем, что мы сделаем гипотезу, что злоумышленники устанавливали приложение с помощью интерпретатора PowerShell. В одном случае у нас устанавливался подписанный пакет, в другом – неподписанный. И разница здесь в основном будет заключаться в том, что в рамках создания неподписанного пакета у нас будет создаваться событие 9545, которое явно говорит нам о том, что пакет у нас неподписан.
Дальше популярные варианты – это когда пользователь просто два раза нажимает на иконку на данный пакет, и у нас он запускается. Либо использование ms-appinstaller. Как и из типичных кейсов, различие будет заключаться в том, что в одном случае пользователь просто его запустит, мы увидим полный путь к файлу, а в другом он у нас будет указывать на ссылку-источник, откуда был этот файл у нас скачен.
Помимо этого у нас есть еще такие журналы, как журнал App Installer. Что здесь важного и что нужно учитывать? Я сказал ранее, что мы можем посмотреть, например, по журналам событий, что вот с помощью PowerShell у нас устанавливались какие-то подписанные, неподписанные пакеты. Так вот, в App Installer этой информации нет, но есть как раз третий, четвертый кейс, когда мы либо запускаем через графический интерфейс, либо с помощью обработчика ms-appinstaller. Чтобы их отделить друг от друга, мы можем просто посмотреть как раз на строчку, которая у нас зеленым цветом выделена, и в данном случае понять, каким образом у нас был произведен запуск. Но помимо этого у нас есть еще история такая. А вдруг там злоумышленнику потребуются какие-нибудь приложения из Microsoft Store? В данном случае они воспользуются, скорее всего, утилитой winget, которая позволит им установить какой-то пакет. Для этого даже не потребуются прав администратора, и это можно будет увидеть как раз в журнале.
Хорошо, мы поговорили про то, что злоумышленники могут доставлять какие-нибудь MSIX-пакеты, там используют какие-то CVE, чтобы их спокойно запускать, могут импортировать сертификат и все остальное. Но для этого иногда требуются даже админские права. А давайте подумаем, а что у нас есть в Microsoft Store, что можно установить без прав администратора, и что злоумышленникам будет интересно. Здесь я выделил пять определенных направлений. Первое — это различные интерпретаторы. В данном случае в Microsoft Store это есть интерпретатор Python и интерпретатор Julia. Это туннели, которые позволяют нам выстраивать, грубо говоря, туннель между нашим хостом и инфраструктурой, чтобы, грубо говоря, иметь доступ к жертве. Третье – это веб-браузер. Например, некоторые злоумышленники любят в рамках атаки доставлять какие-нибудь свои portable версии браузеров и уже в рамках их работы просматривать какие-нибудь веб-ресурсы, которые находятся внутри компании.
Четвертое – это SHRDP-агенты. И последнее – это всем популярный Remote Access Tool, а либо по-другому легитимные утилиты удаленного администрирования, которые как раз нам позволяют помочь каким-нибудь бухгалтерам и так далее. В данном случае поддержка помогает им, подключается по TeamViewer и впоследствии отрабатывает и ликвидирует какую-то проблему техническую. Хорошо, давайте поговорим про интерпретаторы. Я как раз рассматриваю интерпретаторы и в данном случае туннели. Что мы можем делать с интерпретаторами? Допустим, у злоумышленника получилась возможность как-то порвать какую-нибудь нагрузку, либо у них есть уже доступ к хосту, они могут воспользоваться командой winget.
Как раз команд-лайн здесь указан. После этого, как у нас будет установлен интерпретатор, они могут, например, либо передать интерпретатору Python, либо Julia файлик с кодом, либо указать просто в команд-лайне какую-то нагрузку. Данная нагрузка позволяет нам злоумышленнику отдать, по сути, CMD для взаимодействия с хостом, и это у нас как раз reverse shell. И вторая очень важная история – это, в принципе, туннели. С туннелями тут интересная ситуация. Почти во многих кейсах, где у нас фигурируют различные финансово мотивированные группировки, которые занимаются тем, что подкидывают в инфраструктуру и запускают шифровальщик, они используют туннели.
Самых популярных, которые я еще нашел в Microsoft Store, которые недавно были добавлены, это на самом деле ngrok и localtunnel. Они также можно установить с помощью winget и потом запустить. Но очень часто злоумышленники помимо этого еще закрепляют данные утилиты. И самое последнее, что здесь я как раз оставил напоследок, это VS Code. VS Code — это вообще у нас история про, на самом деле это IDE разработчика, то есть его среда. И когда мы его устанавливаем, мы на самом деле получаем там еще дополнительный утилиту code.exe, с помощью которой мы можем создать как раз туннель. Но для этого нам надо аутентифицироваться на GitHub. Чаще всего это не проблема уже для злоумышленников.
И переходим к основному, последнему блоку этой рекомендации, как минимум минимальный, который можно делать. Это первое, запрещать пользователям устанавливать недоверенные пакеты. В данном случае те пакеты, которые были доставлены не через Microsoft Store. И второе, запрещать пользователям, вообще непривилегированным, запускать какие-нибудь и устанавливать MSIX-пакеты, даже из того же Microsoft Store. То есть им потребуются для этого админские права. То есть как минимум позвать администратора, чтобы он это сделал. Что еще можно сделать? Это написать детектирующие правила, например, на определенный повышенный командлет с параметром, который будет говорить нам о том, что у нас был установлен неподписанный MSIX-пакет.
И также, например, собирать события 9545, в котором мы как раз тоже видели, есть указание, о, а у нас тут установлен пакет как раз. И последнее, если мы говорим, что у компании есть какие-нибудь SIEM или лог-менеджмент системы, мы можем просто собирать, например, вот эти четыре события, которые здесь указаны, и дополнительно, помимо этого, собирать различные команды, в данном случае журнал PowerShell и журнал событий, что тоже будет очень важно. На этом на самом деле все. Я позже даже выложу презентацию дополнительного материала, которые как раз и будут дополнительно покрывать некоторые вопросы данной презентации.
Коллеги, ваши вопросы, если они есть. Как всегда, сломал мне всю аудиторию. Бывает, бывает, бывает. Так, ну если рук нет, Владислав, еще раз большое спасибо. Это было супер круто.
Итак, дорогие гости, а мы с вами сейчас уходим на небольшой перерыв и снова встретимся в зале в час десять на вторую секцию наших докладов. Спасибо.
[В записи вырезан перерыв (по программе 12:40–13:10); таймкоды идут без разрыва.]