Алексей Вишняков: Мы предлагаем для детектирования шифровальщиков в PT Sandbox 5.0 стопроцентное обнаружение

На волне импортозамещения всё больше отечественных производителей средств защиты (СЗИ) радуют клиентов новыми практичными решениями. По случаю релиза песочницы PT Sandbox 5.0 мы побеседовали с одним из её идеологов — Алексеем Вишняковым, руководителем отдела обнаружения вредоносного ПО экспертного центра безопасности Positive Technologies (PT Expert Security Center). Алексей рассказал нам о том, как новая версия продукта поможет бороться со всё более изощрёнными вредоносными программами.

Алексей, появились ли за последние годы какие-то новые семейства вредоносных программ и новые техники, о которых пока мало кто знает?

А. В.: Сначала поговорим про обыкновенные зловредные программы. Они делятся на два больших вида: действующие в пользовательском пространстве и в пространстве ядра.

В пользовательском пространстве видоизменения техник не произошло. Но при этом видны логические перемены в функционировании вредоносных программ, а именно — их стало труднее обнаружить. Безусловно, это значительно осложняет работу специалистов по кибербезопасности.

Например, существует такое понятие, как DLL Sideloading (подгрузка библиотек — ред.). Это — не новая функция операционной системы, а штатная активность, когда запускается программа и ей нужны дополнительные фрагменты кода. Их можно найти в библиотеке.

Для злонамеренной эксплуатации этой функциональности, как правило, берётся серьёзная подписанная программа, например антивирусный продукт или утилита от Microsoft, настолько доверенная, что никто и никогда не усомнится в её надёжности. При этом библиотека, которая подгружается этими программами, может являться вредоносной.

Классические подходы к обнаружению здесь оказываются неэффективными. Причина — в том, что подписанный софт, которого много, ведёт себя по-разному и классические СЗИ предпочитают его не разбирать. В данной же ситуации он начинает выполнять прямые вредоносные функции, которые как раз и «зашиты» в библиотеку.

Анализ существующих мировых практик и трендов за последние годы показывает, что больше 80 % атак происходят именно с применением техники DLL Sideloading. Об этом можно узнать в отчётах по киберугрозам. Дальше будем говорить о вариациях, но эта техника — одна из ключевых. Она очень часто используется злоумышленниками, что лишний раз подтверждает её эффективность.

Можно ли сказать, что DLL Sideloading является по существу механизмом обхода белых списков?

А. В.: Верно, это одновременно проблема белых списков и характера производительности. Когда средства сбора событий наблюдают за происходящим в системе, они справляются со слежением за запускаемыми программами, а вот за теми компонентами, которые «подтягивают» эти программы, уследить гораздо труднее, потому что их значительно больше. Например, программа одна, а библиотек — 20, а файлов — ещё больше, и чтобы проконтролировать их все, нужно много ресурсов.

При этом, повторюсь, программа может быть абсолютно доверенная, с проверенной подписью. Такая подпись очень важна, когда мы говорим о системных файлах, например подписанных Microsoft.

Приведу ещё несколько примеров зловредных программ, действующих в пользовательском пространстве. Возьмём языки программирования, любой из них, на котором часто пишут. Когда-то злоумышленники писали на С, С++, С#. За двадцать лет к этому привыкли: написали эмуляторы и специальные разборщики структур кода, научились раскладывать части на отдельные полочки и разработали подходы для детектирования, в том числе основанные на машинном обучении.

Теперь же стали писать на других языках, которые позволяют ещё и быстро компилировать код под разные платформы. При этом, во-первых, подходы по эмуляции, равно как и подходы с машинным обучением, не работают. Структуры данных другие и в бинарном коде всё расположено иначе.

А во-вторых, что касается операционных систем, — всё, что написали под Windows, перекомпилировали, и получилась вредоносная программа под Linux. Ещё раз перекомпилировали — теперь под macOS. И такая картина наблюдается всё чаще, когда одновременно появляются прототипы вредоносных программ под разные платформы.

Безусловно, гораздо больше вредоносов написано под Windows, чем под Linux. При этом последних явно становится всё больше и существуют пересечения по семействам вредоносных программ между платформами.

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

Раньше злоумышленникам приходилось думать, как им написать алгоритм шифрования под Linux, а теперь у них есть все готовые «обёртки» и нужно лишь описать саму программную логику. Это ускоряет процесс разработки вредоносов и одновременно снижает порог вхождения.

Ещё один вид изменений — это другие векторы атак. Когда-то все злоумышленники любили использовать макросы и 99 % отчётов об атаках описывали точечный фишинг (spearphishing): на почту присылается документ, а в нём макрос. Затем появились вариации на тему макросов; в конечном итоге специалисты по ИБ, в частности — сама Microsoft в своих мерах смягчения последствий, научились бороться с ними и стало появляться всё больше предупреждений и ограничений. Так, например, теперь нельзя сразу запустить макросы в загружаемых из интернета документах. Это стало проблемой для злоумышленников, и они перестали экспериментировать с макросами. Они просто пошли другим путём и стали выбирать другие векторы атак.

Для этого злоумышленники вспомнили, какие ещё есть форматы файлов, и стали использовать их. Хронологически, сначала это были ярлыки, которые появились сразу же после того, как были «закрыты» макросы в скачиваемых из интернета документах. И сразу же, мгновенно, все атаки заработали. Потом появились контейнеры: ISO, VHD/VHDX, MSI. Почему именно они? Потому что с их помощью можно обойти ту самую пометку (Mark-of-the-Web, MoTW), которая появляется в документах, если их загружают из интернета. Она воспринимается системой как сигнал, что файл потенциально опасен, и пользователь видит на экране многочисленные предупреждения. Контейнеры же позволяют так распространять файлы, чтобы этих пометок не оставалось и система не считала бы файлы пришедшими извне. И тогда предупреждений не будет; раз нет предупреждений, то нет и проблем, а значит, меры безопасности не работают и можно использовать всё старое.

Другой пример — банковский троян Emotet. Одно время считалось, что его удалось победить. В этом принимали участие ФБР и Европол. Все были рады. В итоге его не было какое-то время, а недавно он опять появился и распространяется через OneNote.

Те же самые техники используются и «красными командами» (Red Team), и пентестерами. Всё это говорит о том, что они действительно работают.

Мы рассмотрели очень интересные техники в пользовательском пространстве. Как обстоят дела в ядерной части ОС?

А. В.: Здесь можно выделить два вида: руткиты и буткиты. Говоря о руткитах, следует начать с такого понятия, как BYOVD, Bring Your Own Vulnerable Driver («принеси свой уязвимый драйвер» — ред.). Это очень похоже на DLL Sideloading в пользовательском пространстве, только всё происходит в ядре.

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

Неважно, как он будет выглядеть: это может быть некий фрагмент, манипуляция с чем-то в ядре — например, с какой-нибудь структурой данных; это также может быть полноценный драйвер. Тем временем всё происходящее в системе выглядит абсолютно нормально и легитимно.

Обнаружить руткиты при помощи стандартных СЗИ невозможно.

Мониторинг того, что происходит в ядре, реализован далеко не везде. В PT Sandbox он есть, и позже поговорим о мерах защиты.

Злоумышленники пошли в сторону легитимизации поведения руткитов. Идея состоит в следующем: когда-то они занимались такими задачами, как перезапись SSDT — ядерной таблицы с сетевыми вызовами и адресами. Благодаря этому получалось перехватывать управление выполняемым кодом. Затем в Microsoft создали PatchGuard — защитника ядерного пространства. Он периодически проверяет целостность ядерных структур данных, и если где-то что-то подменено, он тут же активирует аварийное отключение машины (BSOD), так что вредонос не успевает закончить своё действие.

Тогда злоумышленники стали использовать функции и механизмы операционной системы, которыми пользуется легитимный софт. Существуют антивирусные продукты, банковские приложения, где клиенты авторизовываются при помощи специальных токенов; всё это предполагает наличие драйверов. Для того чтобы они нормально функционировали, Microsoft придумала специальные сущности (нотификации с обратными вызовами функций), которые позволяют корректно обрабатывать события. Это, в свою очередь, означает, что нужно где-то в ядре на что-то подписаться. Так, если необходимо корректно маршрутизировать сетевой трафик, то нам нужно «подсадить» сетевой обработчик на определённые пакеты в ядре. Если обобщить, то всё, что мы хотим корректно обработать в легитимных целях, например процессы и потоки, можно получить как информацию на подписках. Это легитимное свойство самой операционной системы. Разработчики руткитов стали этим пользоваться, и теперь трудно сказать, с легитимной или вредоносной целью фильтруется происходящее в файловой системе.

Существует ещё один момент — разрушительное поведение вредоносов. Например, руткиты стали отключать ETW-трассировки, способ наблюдения за системой, который ввела у себя Microsoft. Им пользуется подавляющее большинство продуктов класса EDR (Endpoint Detection and Response, система для обеспечения информационной безопасности конечных точек). Все современные EDR-решения получают большинство полезных событий с точки зрения безопасности именно с его помощью; по факту это — архитектурная особенность. Пример из «дикой природы»: северокорейская группа Lazarus создала свой руткит-драйвер, который отключает ETW в ядре. Существуют разные подходы. Можно отключить трассировку совсем, можно сделать фильтрацию событий на стеке. Так или иначе, это «ослепляет» СЗИ.

При этом разрушительные действия — уже не те, что были раньше. Соответственно, PatchGuard к этому просто не готов. Он может контролировать только определённые воздействия по модели угроз. Помимо этого существуют и другие технологические нюансы того, как его можно обойти. Я рассказал про самые значимые из них.

А как обстоит ситуация с буткитами?

А. В.: Когда мы говорим про буткиты, всё иначе. Если рассматривать последние и самые актуальные, то можем назвать MosaicRegressor, CosmicStrand и Moonbounce. Это так называемые прошивочные буткиты. Они предполагают заражение прошивки отдельного чипа на материнской плате — SPI, который отвечает за безопасную загрузку ОС и обеспечивает корректную работу технологии запуска SecureBoot.

Злоумышленники, которые писали и внедряли эти буткиты, сумели вшить вредоносные компоненты в такой чип. Первым таким буткитом был LoJax, его открыли в 2018 году. Идея — следующая: если есть исходная точка, которая контролирует целостность всего остального, можно поместить в неё зловред, и тогда вся процедура заражения окажется в наших руках.

Поскольку там (в прошивке) находятся в том числе драйверы, злоумышленники либо заменяли их на свои, либо видоизменяли их так, чтобы там содержался вредоносный код. И с этого момента дальнейшее развитие атаки для злоумышленников не составляло труда. На стадии старта ОС буткит внедряет руткит, а последний «подсаживает» в пользовательское пространство бэкдор или загрузчик. Основная идея состоит в том, что скомпрометировано звено, которое проверяет целостность загрузки операционной системы, и никто это звено проверить не может.

Какие существуют варианты установки перечисленных буткитов? С физическим доступом или удалённым?

А. В.: Здесь есть два варианта действия вредоноса, и они оба работают.

Во-первых, буткиты могут быть установлены вручную инсайдерами. Для этого злоумышленнику необходимо предварительно отключить проверку целостности при загрузке системы (SecureBoot). Это киберпреступник может сделать при наличии доступа к устройству.

Второй вариант — это удалённое заражение. Примером такого способа как раз и служит LoJax. Там использовалась уязвимость, которая позволяла «на лету» отключать SecureBoot и заражать прошивку.

Отдельно хочется сказать о бутките BlackLotus. Он был обнаружен совсем недавно, и его особенность состоит в том, что эксплуатировались ранее найденные опубликованные уязвимости, для которых вышли соответствующие исправления. Эти бреши позволяли перезаписывать хранилище доверенных подписей в прошивке. Там есть отдельный раздел, который хранит информацию о доверенных и, наоборот, отозванных подписях. Благодаря этому можно быть уверенными, что программы с доверенными подписями легитимны и не скомпрометированы. На этой части цепочки доверия и происходило вмешательство.

BlackLotus можно объединить в одну группу с такими буткитами, как FinFisher и ESPecter. В ОС есть раздел, который называется EFI System Partition. Он находится прямо на жёстком диске; туда записываются несколько программ управления загрузкой (Boot Managers). Самое простое, что делают злоумышленники, когда «подсаживают» буткиты, — это подмена таких программ. Переписать их очень легко: достаточно получить доступ к диску, а не к чипу. Однако SecureBoot проверяет целостность этих компонентов и наличие подписи из хранилища, о котором говорилось выше.

Что делал BlackLotus: он сначала перезаписывал программы Boot Manager, меняя их на свои, а в хранилище подписей заносил информацию о том, что эти компоненты якобы надёжны и их подпись нужно считать доверенной. Дальше на старте компоненты прошивки проверяют подписи, сравнивают со своей базой и видят, что всё сходится, а затем система корректно загружается. Следом запускается руткит и развёртывается тот же сценарий атаки, о котором шла речь выше, итогом чего является компрометация.

Вот два ключевых вектора, которые реализуются удалённо благодаря уязвимости. При этом здесь важно отметить, что сама логика подхода — такая же, как в мире «обыкновенных» зловредов. Как только появляются уязвимости, для них создаются демонстрации (proof-of-concept), злоумышленники быстро адаптируют их под себя и реализуют атаку. Это продолжается до тех пор, пока к пользователям не приедут «заплатки», либо пока последние в принципе не будут выпущены. Здесь происходит то же самое: находят уязвимости в прошивках разных производителей, об этом уведомляются и производители, и клиенты, а дальше есть временной зазор до появления обновлений. Пока этот зазор существует, через уязвимость проникают зловреды и пытаются всё это заражать.

Давайте теперь поговорим о распространённости. Насколько часто встречаются описанные выше сценарии атак с использованием буткитов и руткитов в реальной жизни?

А. В.: На каждую сотню тысяч вредоносных программ пользовательского пространства приходится 10 руткитов. При этом на каждый руткит едва ли приходится один буткит.

С чем это связано? Во-первых, это сложно. Злоумышленникам требуются большие ресурсы для того, чтобы разработать такой код. С другой стороны, причина статистики может быть и в том, что подобных руткитов много пропускается, то есть атаки были успешны. То же самое — и с буткитами: найти их ещё труднее, потому что для этого нужно достаточно эффективно сканировать прошивки, с чем-то сравнивать и находить несоответствия. Далеко не все программные продукты умеют это делать.

Я помню, когда больше 10 лет назад нашли первый буткит, это воспринималось как что-то фантастическое. Сам факт, что его удалось обнаружить, казался чудом.

А. В.: Теперь логичным продолжением будет рассказ о том, как это обнаруживаем мы. Как известно, у обычных антивирусов очень ограничены возможности работы на уровне ядра. Поэтому у нас есть песочница PT Sandbox — представитель класса продуктов, которые позволяют обнаруживать передовые зловреды: руткиты и буткиты. При этом стоит сделать оговорку, что далеко не все песочницы сейчас к этому готовы.

Говоря про устройство песочницы, в ней можно выделить три среза, три пространства, три зоны происходящего. Одну из них мы сегодня упоминали: это пользовательское пространство, где есть определённые вредоносные объекты. Затем есть ядро ОС и гипервизор, который позволяет виртуализировать среды, запускать виртуальные машины, в которых ищутся зловреды. И вот здесь-то видно ключевой момент: где именно у вендора стоит анализатор происходящего.

У большинства из них он размещается в пользовательском пространстве. Также есть другой компонент, который располагается в ядерном пространстве. Другими словами, вендор выпускает пользовательскую службу и свой драйвер, а дальше эта пара программ ищет и выявляет всё нежелательное в виртуальной машине. Это эффективно с точки зрения производительности и позволяет легко находить вредоносные объекты, включая руткиты. Но есть нюанс: если система наблюдения «умнее», чем руткит, она его обнаружит, а если наоборот, то мы ничего не увидим. Таким образом, очень важно, чтобы ваше средство наблюдения было достаточно сильным. И именно поэтому руткиты так редко обнаруживаются.

А как меняются правила игры, когда ты переносишь какие-то точки контроля на уровень гипервизора?

А. В.: Это позволяет сделать наблюдение невидимым для ОС. Операционная система — это ядро и пользователь. Соответственно, для программ в ядре или пользовательском пространстве тебя как наблюдающего не существует. Вредонос не видит средство наблюдения (оно находится в другой плоскости, как в другом измерении), не может его сломать, так как оно располагается вне зоны его доступа. С другой стороны, у анализатора, который «сидит» в зоне гипервизора, есть всё поле зрения. У него также есть то преимущество, что его возможность фиксировать операции неизменна.

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

Методика анализа вредоносов в PT Sandbox становится очень простой благодаря тому, что есть архитектурное преимущество.

Архитектурная сложность реализации анализа выравнивает чашу весов по отношению к самой логике обнаружения. Наша логика в основном сводится к контролю целостности структур данных.

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

Приведу несколько простых примеров. Когда Positive Technologies разрабатывала эту систему защиты, миру были известны LoJax и FinFisher. Уже потом, когда нами была спроектирована своя система и её тестировали, выступая на PHDays в прошлом году, стали появляться остальные представители класса, о которых говорилось выше. Мы просто читали отчёты и видели, что уже превентивно обнаруживаем эти техники. В данном случае это было заранее спрогнозировано.

Мы даже не меняли компоненты защиты. Как их спроектировали, так они и выходили постепенно в продукте PT Sandbox, и даже сейчас не меняем их от релиза к релизу. Защита устойчива, стабильна и не требует изменений.

То же самое касается руткитов. Когда появились новые руткиты, в том числе от упомянутой Lazarus, киберпреступники стали использовать драйверы в дополнение к механизмам очистки (вайперам) для того, чтобы с ядерного слоя надёжно удалять данные на диске. Было любопытно наблюдать за этими манипуляциями: наша логика защиты работала как часы. Нарушалась целостность структур данных, которые мы уже контролировали.

Скажу несколько слов про пользовательское пространство и преимущество на этом уровне. В контексте песочницы очень важная разновидность уязвимости «нулевого дня» — это повышение привилегий. Вредоносная программа приходит в ОС как гость, даже не администратор, потом что-то делает и становится программой с правами «SYSTEM». Это открывает большие возможности сбора информации по системе, получения учётных записей и данных по кустам реестров. Способов локально повысить свои привилегии до «SYSTEM» существует множество; их просто не пересчитать. Поначалу мы группировали всё это, классифицировали и проходились по способам детектирования этих подгрупп. Однажды, уже прочувствовав положение дел, поняли, как можно с уровня гипервизора «дотягиваться» до пользовательского пространства и видеть факт повышения привилегий.

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

Когда мы реализовали наблюдение «сверху», нам удалось сразу закрыть 99,9 % проблем с локальным повышением привилегий.

Когда выходили новые вариации на эту тему, уже было просто видно, что сама эта суть нерушима и наше детектирование вредоносов в PT Sandbox срабатывает. Таким образом, благодаря архитектурному преимуществу у нас есть возможность наблюдать, как решение превентивно ловит угрозы.

Раз заговорили о песочницах и гипервизоре, понятно, что вредоносные программы могут быть «заточены» под определённые версии ОС, «железо» и сетевое окружение. Насколько важна здесь индивидуализация среды?

А. В.: Давайте сначала поговорим о кастомизации машин для пользователей, а потом обсудим кастомизацию гипервизора. Существует несколько моментов, на которые стоит обратить внимание.

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

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

Это был простой пример. Есть и более сложные. Зловред могут принести с эксплойтом, неважно, каким именно. Это может быть повышение привилегий, запуск произвольного кода в Microsoft Office, Adobe Acrobat или каком-нибудь интерпретаторе.

Если зловред не отработал в песочнице и не был ею обнаружен, он не сможет ничего проэксплуатировать и отработать на машине реального пользователя. Это действует и в обратном направлении: если уникальный и корректно «заточенный» эксплойт срабатывает в песочнице благодаря тому, что она кастомизирована под настоящее окружение, она его поймает именно в этой инфраструктуре. В другой среде такого уже не случится.

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

Следующий важный момент — приманки. Это путь к обобщённому детектированию. Когда мне задают вопрос, что мы можем предложить по детектированию шифровальщиков, я отвечаю — стопроцентное обнаружение. У всех шифровальщиков есть нечто общее: то, что они ищут и пытаются повредить (не уничтожить, а заменить содержимое). Пример такой «общности» — расширения файлов.

У нас есть приманки: файлы, которые мы расположили в определённых точках ОС. По логике действия шифровальщика он до них «дотянется» и обязательно их изменит. Когда видим, что кто-то изменил наши файлы, особенно в большом количестве и в разных местах, становится ясно, что это сделал шифровальщик.

Это же касается и вайперов. Вспоминаем историю 2022 года, когда они получили распространение и развитие. У нас есть «интересные» файлы, которые вайперы нацелены уничтожить. Если файлы-приманки уничтожены, не остаётся сомнений в том, кто это сделал, так как легитимный софт подобных операций выполнять не будет.

Здесь важно подготовить разнообразные файлы под соответствующие задачи детектирования и разместить их должным образом, чтобы и шифровальщики, и вайперы успевали до них добраться. Также важно правильно сбалансировать эту количественную меру проверки.

Необходимо правильно установить пороговую границу, и тогда дальше возникает «магия»: ты просто наблюдаешь за появлением в песочнице всё новых и новых зловредов, но все они один за другим обнаруживаются и не доставляют совершенно никаких проблем. Таким образом, на этих приманках стабильно ловятся сразу два класса вредоносных программ.

Окончание первой части. Продолжение следует. 

Пока мы готовим вторую часть интервью с Алексеем Вишняковым, где будет рассказано о доставке экспертизы PT Expert Security Center в песочницу, о технологии приманок, а также о том, как вектор на импортозамещение изменил дорожную карту продукта, вы можете изучить функциональность песочницы PT Sandbox 5.0. Чтобы оставить заявку на пилотный проект, заполните форму. Действующие пользователи смогут обновить версию продукта, обратившись в техническую поддержку.

Реклама. Рекламодатель АО «Позитив Текнолоджиз», ИНН 7718668887, ОГРН 1077761087117
LdtCKQSPw