Кайл Куччи

Кайл Куччи увлёкся компьютерами ещё подростком, когда собрал ПК и купил книгу по C++. У него более 17 лет разнообразного опыта в кибербезопасности и ИТ. Сейчас он работает в группе исследования угроз Proofpoint, ежедневно занимаясь поиском и обратной разработкой вредоносных программ. Ранее Кайл руководил группой исследования вредоносных программ и криминалистических расследований в крупном международном финансовом учреждении. На протяжении его карьеры вклад Кайла в разведку угроз и его исследования находили отражение в правительственных разведывательных отчётах, а также в инструментах и продуктах безопасности. Кайл регулярно выступает на конференциях по безопасности и проводил международные учебные курсы и практические занятия по анализу вредоносных программ и проектированию безопасности. В свободное время он участвует в жизни сообщества, создавая инструменты с открытым исходным кодом и ведя блог, спокойно проводит время с семьёй и варит вполне пригодное для питья пиво.

От всего сердца благодарю нынешних и бывших коллег, а также друзей, которых встретил на этом пути, за ценные отзывы на протяжении всей работы.

Идёт 2010 год. Исследователи угроз со всего мира обнаружили новую вредоносную программу, которая использует несколько методов заражения конкретных жертв. Она нацелена именно на контроллеры определённого типа производства Siemens, применяемые в процессе обогащения урана на иранских ядерных объектах. Вредоносная программа, впоследствии получившая имя Stuxnet, составляет профиль среды, в которой работает, чтобы заразить только намеченную жертву. Stuxnet оставался незамеченным несколько месяцев не только благодаря узкой направленности, но и благодаря множеству имевшихся в его арсенале методов обхода средств защиты и скрытного присутствия. Один из таких методов заключался в использовании похищенных сертификатов подписи кода - сравнительно новой тактики, придававшей вредоносной программе видимость подлинности.

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

Вскоре после этого, в 2020 году, мир потрясает деятельность группировки, проникшей в сеть SolarWinds - компании, поставляющей сотням тысяч организаций программное обеспечение для мониторинга сетей и систем. Злоумышленники внедряют вредоносный код в легитимную службу обновления программного обеспечения платформы SolarWinds Orion. Эти обновления доставляются организациям, использующим Orion, а вредоносный код незаметно и эффективно устанавливает троян удалённого доступа в сети организаций-жертв. Благодаря методам слияния с целевыми средами участники этой атаки долго остаются незамеченными. Позднее атаку называют Sunburst.

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

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

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

Что такое вредоносная программа?

В общем случае вредоносная программа - это любая программа, совершающая вредоносные действия. Кажется довольно простым, не правда ли? Однако определения вредоносной программы нередко противоречат друг другу. Remcos - это программное обеспечение, которое открыто продаётся в Интернете и описывается авторами как «средство удалённого администрирования». Но поскольку Remcos может купить любой желающий - совершенно законно, замечу я, - его в значительной мере используют в преступных целях, и он обладает многими возможностями известного вида вредоносных программ, называемого трояном удалённого доступа. Другой пример - AsyncRAT, средство удалённого доступа с открытым исходным кодом, которое, по словам автора, «предназначено для удалённого наблюдения за другими компьютерами и управления ими через защищённое зашифрованное соединение». Так являются ли Remcos и AsyncRAT вредоносными программами? Ответ в значительной степени зависит от того, кого спросить, кто их использует и с какой целью. Решающее значение имеет контекст.

Вредоносные программы можно разделить на различные виды, или классы. Классы определяются группами моделей поведения и возможностей, встречающихся в разных семействах вредоносных программ. Ниже перечислены некоторые наиболее распространённые классы.

Трояны удалённого доступа (RAT)

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

Похитители информации

Похитители информации обычно нацеливаются на конфиденциальные сведения на узле жертвы: учётные данные, банковскую информацию, криптовалютные кошельки, файлы cookie, историю браузера и подобные данные. Затем они отправляют эти данные злоумышленникам. Банковские трояны, нацеленные именно на банковские и финансовые данные, можно считать одним из видов похитителей информации.

Дропперы и загрузчики

Дропперы и загрузчики предназначены для развёртывания в системе дополнительных вредоносных программ. Строго говоря, дропперы содержат встроенную полезную нагрузку и при выполнении сохраняют её в системе жертвы. Загрузчики, напротив, скачивают полезную нагрузку из внешнего источника, например из Интернета. Однако эти термины часто используют как взаимозаменяемые.

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

Программы-вымогатели

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

Вайперы

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

Черви

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

Вирусы

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

Руткиты и буткиты

Руткиты - специализированные варианты вредоносных программ, предназначенные для сокрытия своего присутствия как от пользователей системы, так и от средств безопасности. Чтобы избежать обнаружения, руткиты обычно модифицируют системные компоненты на уровне ядра операционной системы, что позволяет злоумышленнику сохранять доступ к скомпрометированной системе. Буткиты обычно преследуют те же цели, что и руткиты, но заражают главную загрузочную запись (MBR) или другие компоненты процесса загрузки компьютерной системы, благодаря чему получают управление системой до загрузки операционной системы.

Троянские программы

Исторически трояны определялись как вредоносные программы, маскирующиеся под легитимное программное обеспечение. Я включил их в список ради полноты, но мне не нравится ни этот термин, ни его определение. В конце концов, какая вредоносная программа не маскируется под легитимную? Если бы вредоносная программа сообщала нам о своей вредоносности, нас не удалось бы обманом заставить её выполнить. Следовательно, «троян» - архаичный термин, которым очень часто злоупотребляют.

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

Нередко вредоносные программы делят на две общие группы: массовые и специализированные. Массовые вредоносные программы часто доступны широкому рынку - как в открытом Интернете, так и на форумах даркнета. Вредоносные программы этого вида одновременно используют разные группировки. В качестве примеров можно назвать Lokibot и Agent Tesla - две наиболее популярные вредоносные программы из находящихся в обращении. Специализированные вредоносные программы лучше приспособлены к конкретной цели: зачастую они нацелены на определённую отрасль или даже конкретную компанию либо человека и решают строго определённую задачу. Примерами служат упомянутый ранее Stuxnet и HermeticWiper, который атаковал системы на Украине в начале российского вторжения в 2022 году. Массовую вредоносную программу можно дополнить, сделав её более целевой и специализированной.

Примечание. Вредоносные программы существуют для всех основных операционных систем, включая, помимо прочего, Windows, macOS и разновидности Unix, а также мобильные операционные системы вроде Android и iOS. Поскольку Windows распространена шире всего, я решил сосредоточиться в этой книге на вредоносных программах для Windows. Однако многие рассматриваемые здесь методы уклонения в том или ином виде можно реализовать и в других операционных системах.

Что такое анализ вредоносных программ?

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

Зачем вредоносные программы используют уклонение?

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

Затруднение анализа

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

Обход средств защиты

Сетевые и узловые средства защиты, такие как система предотвращения вторжений (IPS), средства защиты от вредоносных программ и продукты обнаружения угроз на конечных точках и реагирования на них (EDR), создают вредоносным программам помехи. Уклоняющиеся угрозы пытаются обходить эти средства защиты, чтобы оставаться скрытыми на заражённом узле.

Выбор целевых систем и профилирование контекста

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

Почему я написал эту книгу

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

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

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

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

Для кого предназначена эта книга

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

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

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

Структура книги

Книга состоит из четырёх частей, включающих 17 глав, и трёх приложений.

Часть I, «Основы», закладывает базовый уровень знаний, необходимый для остальной книги.

• Глава 1. Основные понятия Windows. Рассматриваются фундаментальные понятия операционной системы Windows.

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

• Глава 3. Статический и динамический анализ кода. Рассматриваются основы статического и динамического анализа кода, а также применение этих методов для раскрытия истинных намерений вредоносной программы.

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

• Глава 4. Перечисление артефактов операционной системы. Обсуждается, как вредоносная программа может тщательно исследовать базовые артефакты операционной системы, чтобы обнаружить попытки анализа.

• Глава 5. Обнаружение пользовательской среды и взаимодействий. Объясняются способы, которыми вредоносная программа препятствует расследованию, перечисляя взаимодействия пользователя и элементы среды своего выполнения.

• Глава 6. Перечисление конфигураций оборудования и сети. Исследуется, как вредоносная программа может проверять оборудование системы и параметры сети, чтобы обнаружить песочницы и виртуальные машины аналитика.

• Глава 7. Аномалии среды выполнения и виртуального процессора. Рассматривается, как аномалии обработки и среды выполнения способны выдать вредоносной программе попытку анализа.

• Глава 8. Уклонение от песочниц и нарушение анализа. Исследуются некоторые другие методы, с помощью которых злоумышленник может полностью уклониться от среды анализа и нарушить её работу.

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

• Глава 9. Противодействие дизассемблированию. Объясняется, как вредоносная программа использует методы противодействия дизассемблированию, чтобы предотвращать и нарушать ручной анализ кода.

• Глава 10. Противодействие отладке. Обсуждается, как вредоносная программа обнаруживает отладчики и уклоняется от них, а также от динамического анализа кода.

• Глава 11. Скрытое выполнение кода и введение в заблуждение. Демонстрируются способы, которыми вредоносная программа может скрытно выполнять код либо запутывать аналитиков вредоносных программ и направлять их по ложному пути.

В части IV, «Обход средств защиты», подробно рассматривается, как вредоносные программы уклоняются от защитных мер.

• Глава 12. Внедрение в процессы, манипулирование ими и перехват. Раскрывается, как вредоносная программа внедряет вредоносный код в разные процессы, манипулирует процессами и перехватывает код функций.

• Глава 13. Обход узловых и сетевых средств защиты. Рассматривается, как вредоносная программа уклоняется от сетевых и узловых средств защиты и обходит их.

• Глава 14. Введение в руткиты. Обсуждаются основы особенно опасного вида уклоняющихся вредоносных программ - руткитов.

• Глава 15. Бесфайловые методы, применение штатных средств и методы противодействия криминалистике. Исследуется, как вредоносная программа использует так называемые бесфайловые методы и меры противодействия криминалистике, чтобы уклоняться от средств защиты и криминалистических инструментов.

• Глава 16. Кодирование и шифрование. Основное внимание уделяется методам кодирования и шифрования; предлагаются практические методики анализа вредоносных программ.

• Глава 17. Упаковщики и распаковка вредоносных программ. Обсуждается работа обфускаторов и упаковщиков вредоносных программ и подробно рассматривается распаковка вредоносного кода.

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

Образцы вредоносных программ для этой книги

На протяжении всей книги я привожу лабораторные работы по анализу и сведения о конкретных образцах и семействах вредоносных программ. Я часто указываю сигнатуру файла вредоносной программы в формате SHA256:значение_хеша. Вот пример:

Большинство образцов вредоносных программ, на которые я ссылаюсь таким образом, можно скачать с VirusTotal (virustotal.com), если у вас есть коммерческая учётная запись, либо бесплатно получить на MalShare (malshare.com). Обратите внимание: эти образцы являются настоящими вредоносными программами. Прежде чем скачивать и выполнять любую вредоносную программу, на которую я ссылаюсь в книге, обязательно создайте отдельную лабораторию анализа вредоносных программ и настройте её для безопасного анализа. Советы о том, как это сделать, приведены в приложении A.

Наконец, для этой книги я постарался подобрать разные образцы, в том числе 32- и 64-разрядные вредоносные программы. Возможно, вы задаётесь вопросом, почему я уделяю так много внимания 32-разрядному коду, хотя его в значительной мере вытесняет 64-разрядный. Ответ прост: 32-разрядные вредоносные программы всё ещё широко распространены, вероятно, потому, что у них нет причин переходить на 64-разрядную архитектуру. Им не нужны дополнительное адресное пространство памяти или производительность, предоставляемые 64-разрядными архитектурами. И, возможно, самое главное: 32-разрядные вредоносные программы работают почти во всех версиях Windows. Не забывайте, что некоторые люди до сих пор используют устаревшие операционные системы, такие как Windows XP, Windows Server 2003 и Windows 7, а также старые процессорные архитектуры.

Теперь приступим к изучению основных понятий Windows. Увидимся в главе 1.

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

Обзор архитектуры Windows

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

Пользовательский режим и режим ядра

Архитектура Windows включает два режима - пользовательский и режим ядра, которые являются основными составляющими ОС. Режим - это контекст, в котором выполняется код в системе. Пользовательский режим - то, что большинство людей представляет себе при работе с компьютером: обычные повседневные программы и процессы, с которыми взаимодействует пользователь, например программы Microsoft Office и веб-браузеры. Режим ядра, напротив, предназначен для основных функций ОС, отвечающих за такие важные низкоуровневые задачи, как управление памятью и взаимодействие с оборудованием.

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

На рисунке 1-1 показана связь между пользовательским режимом и режимом ядра.

Рисунок 1-1. Связь между пользовательским режимом и режимом ядра

Рассмотрим представленные на рисунке понятия подробнее.

Приложения. Это программное обеспечение и программы, запускаемые пользователем.

Программный интерфейс приложений Windows (WinAPI). На него опираются приложения при выполнении своих функций. Подробнее он будет рассмотрен в разделе «Windows API» на странице 6.

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

Уровень абстракции оборудования. Он предоставляет интерфейс, посредством которого драйверы устройств могут взаимодействовать с базовым оборудованием системы. Благодаря ему ядро и приложения более высокого уровня способны работать независимо от оборудования системы.

Само ядро Windows содержится в исполняемом файле ntoskrnl.exe и делится на две части: ядро и исполнительный уровень. Ядро отвечает за основные функции, например синхронизацию и планирование задач, а также обеспечивает низкоуровневую поддержку оборудования, необходимую для эффективной работы системы. Исполнительный уровень содержит критически важные системные службы, такие как диспетчер памяти, реализующий функции виртуальной памяти (см. раздел «Виртуальная память» на странице 11), и диспетчер процессов, управляющий созданием и завершением процессов и потоков.

Процессы и потоки

Когда запускается приложение, например Excel.exe или Calculator.exe, загрузчик переносимых исполняемых файлов Windows создаёт для этой программы процесс. Процесс содержит исходный исполняемый файл программы, а также все вспомогательные библиотеки и код. Каждому процессу назначается собственное виртуальное адресное пространство в памяти, закрытое и изолированное от других процессов. Это означает, что сбой процесса не влияет - или не должен влиять - на другие процессы или на саму ОС.

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

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

Объекты и дескрипторы

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

Все объекты в Windows представляют собой структуры данных, обычно хранящиеся в памяти ядра. Поскольку большинство приложений Windows работают в пользовательском пространстве, для доступа к объекту процесс использует уникальный идентификатор, называемый дескриптором. У каждого процесса может быть множество дескрипторов различных объектов. Дескрипторы организованы в таблице дескрипторов процесса, которая содержит указатели на объекты в памяти ядра, как показано на рисунке 1-2.

Рисунок 1-2. Таблица дескрипторов процесса Windows и структура объектов

Взаимные исключения, или мьютексы, представляют собой способ управления доступом к объектам, предотвращающий возможные проблемы. Например, процесс A и процесс B могут одновременно попытаться получить доступ к файлу и изменить его - такая ситуация называется состоянием гонки. В зависимости от того, как Windows использует конкретный файл, это может привести к несогласованности данных или, что ещё хуже, к аварийному завершению процесса либо ОС. Чтобы избежать нежелательных событий вроде состояния гонки, процесс A может создать для файла объект-мьютекс, заблокировав файл для собственного использования и не позволяя процессу B получать к нему доступ или записывать в него данные до снятия блокировки.

Взаимодействием программы с этими объектами и с самой ОС управляет Windows API.

Windows API

Программный интерфейс приложений Windows (WinAPI) - это общая библиотека кода, доступная приложениям пользовательского режима. Когда выполняется программа Windows, WinAPI вызывает функции Windows, позволяющие программе работать в ОС Windows согласно своему назначению.

WinAPI охватывает почти все функции, которые разработчик может захотеть реализовать в своём коде: от пользовательского интерфейса и сетевых возможностей до устройств ввода, таких как мышь и клавиатура, и управления памятью. Например, если разработчик хочет создать новое окно приложения, он может вызвать функцию CreateWindowEx. Если программе требуется доступ к жёсткому диску, она может вызвать GetLogicalDrives, чтобы получить список доступных жёстких дисков.

Существует также более низкоуровневый API, называемый собственным API Windows, или просто Native API. Если WinAPI хорошо документирован и предназначен для использования разработчиками, то Native API в значительной мере не документирован, по крайней мере компанией Microsoft.

Примечание. К счастью, сообщество специалистов по обратной разработке приложило огромные усилия для документирования внутреннего устройства Native API. Два прекрасных примера - проект ntinternals (undocumented.ntinternals.net) и исследование Джеффа Чаппелла (geoffchappell.com).

Native API задуман как внутренний интерфейс ОС, однако при желании программы могут вызывать его функции напрямую. Функции Native API, в свою очередь, обращаются к ещё более низкоуровневому коду API ядра, находящемуся в ntoskrnl.exe. Обращение к ядру называется syscall или sysenter. Между syscall и sysenter есть незначительные технические различия, но обе операции преследуют одну цель: предоставить пользовательским приложениям доступ к службам ядра. Для простоты в этой книге я буду использовать термин syscall.

На рисунке 1-3 показано взаимодействие WinAPI с Native API.

Рисунок 1-3. Вызов низкоуровневых API из API пользовательского режима

В верхней части рисунка программа вызывает функцию WinAPI VirtualAlloc, которая, в свою очередь, вызывает функцию WinAPI VirtualAllocEx, не показанную на схеме. Далее следует вызов функции Native API NtAllocateVirtualMemory. Наконец, программа вызывает функцию NtAllocateVirtualMemory внутри ntoskrnl.exe. Такая сложная цепочка вызовов API очень распространена в Windows и позволяет разрабатывать код без необходимости знать все внутренние детали Windows и низкоуровневых API.

Как вы, возможно, заметили, имена функций WinAPI часто имеют один или несколько суффиксов, например Ex, A или W. В общем случае суффиксом Ex компания Microsoft обозначает новую, расширенную версию старой функции, обладающую дополнительными возможностями. Например, функция CreateWindowExA является новой, расширенной версией функции CreateWindowA. Суффикс A означает, что функция использует входные и выходные данные в формате ANSI, а функции с суффиксом W используют входные и выходные данные в формате Unicode. Различие между ANSI и Unicode важно не так часто, поэтому я больше не буду рассматривать эту тему и, как правило, не стану добавлять A или W к имени функции. Например, функцию CreateWindowA я буду называть просто CreateWindow. Однако для функций Ex я всегда буду указывать этот суффикс.

Имена функций Native API Windows обычно имеют префикс Nt или Zw; примерами служат NtCreateProcess и ZwNotifyChangeKey. Как правило, у каждой функции API есть варианты как с Nt, так и с Zw. Функции Zw чаще всего используются драйверами и другим низкоуровневым системным программным обеспечением, но в значительной мере взаимозаменяемы с функциями Nt.

Возможно, вы также заметили на рисунке 1-3 имена файлов kernel32.dll и ntdll.dll. Это библиотеки динамической компоновки (DLL) - наборы ресурсов, которые разработчики могут импортировать в свои программы, чтобы использовать существующий код Microsoft или сторонних разработчиков. Программы Windows могут импортировать такие библиотеки, а сами DLL-файлы экспортируют функции программе, которая их импортировала. Например, если разработчику нужен доступ к жёсткому диску в системе Windows, он может импортировать библиотеку kernel32.dll, которая экспортирует, то есть предоставляет, необходимую функцию GetLogicalDrives.

Ниже перечислены некоторые DLL, часто используемые в программах Windows.

• kernel32.dll. Одна из основных DLL, необходимых для работы программ Windows; она содержит множество фундаментальных функций пользовательского режима.

• user32.dll. Эта DLL предоставляет функции графического пользовательского интерфейса (GUI), необходимые программам Windows.

• Winhttp.dll. Эта DLL, также известная как Windows HTTP Interface, предоставляет программам Windows функции подключения к Интернету.

• ntdll.dll. Эта критически важная DLL содержит функции синхронизации, работы с потоками и выполнения других системных задач; кроме того, она взаимодействует с ядром.

Примечание. Если вы анализируете код с функциями, экспортированными из kernel32.dll, а таких функций много, то можете заметить: когда процесс выполняет функцию kernel32.dll, сразу происходит переход к другой DLL - kernelbase.dll. Библиотека kernelbase.dll, появившаяся в Windows 7, обеспечивает обратную совместимость старых и новых версий Windows. Большинство вызовов функций kernel32.dll просто переходят в kernelbase.dll, где находится фактический код функции. Например, после вызова функции WriteFile, экспортированной из kernel32.dll, немедленно происходит переход в kernelbase.dll, где в действительности расположен её код. Для простоты на протяжении книги я буду использовать имена kernel32.dll и kernelbase.dll как взаимозаменяемые.

Легитимные программы Windows в значительной мере зависят от лежащих в основе системы WinAPI и Native API, однако те же возможности использует и нелегитимное программное обеспечение, то есть вредоносные программы, как вы увидите в последующих главах. А пока подробно рассмотрим процессы.

Внутреннее устройство процессов

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

Структуры EPROCESS

Хотя большинство доступных конечному пользователю процессов работает в пользовательском режиме, в адресном пространстве ядра они представлены объектами, называемыми структурами EPROCESS. У каждого процесса имеется собственная структура EPROCESS, содержащая указатели на такие элементы, как список открытых процессом дескрипторов, а также его блок окружения процесса (PEB) - структуру с жизненно важной информацией о процессе. Структуры EPROCESS образуют двусвязный список, то есть цепочку, в которой каждая структура ссылается на предыдущую и последующую структуры. Члены структуры EPROCESS, называемые прямыми ссылками (flink), являются указателями на следующую структуру EPROCESS в цепочке, а обратные ссылки (blink) указывают на предыдущую. Упрощённый вариант этой цепочки показан на рисунке 1-4.

Рисунок 1-4. Цепочка двусвязного списка структур EPROCESS

Структура EPROCESS содержит множество других элементов данных и указателей, в основном выходящих за рамки этой книги. Главное, что нужно усвоить: каждый процесс пользовательского режима в Windows связан со структурой EPROCESS, работающей в режиме ядра. Это станет важным позднее, когда в части IV будут рассматриваться такие темы, как непосредственное манипулирование объектами ядра (DKOM).

Блоки окружения процесса

Структура памяти PEB содержит сведения о работающем процессе, необходимые ядру для взаимодействия с ним, а также информацию для межпроцессного взаимодействия. У каждого работающего процесса есть собственный PEB, хранящийся в адресном пространстве пользовательского режима внутри памяти этого процесса. В таблице 1-1 перечислены некоторые важные данные, содержащиеся в структуре PEB. Для каждого члена структуры приведены смещения как в архитектуре x86, так и в x64.

Таблица 1-1. Смещения и данные структуры PEB

Не нужно запоминать все элементы PEB, но важно иметь общее представление об этой структуре, поскольку я буду ссылаться на неё на протяжении всей книги.

Блоки окружения потока

Блок окружения потока (TEB), иногда называемый информационным блоком потока (TIB), содержит информацию о работающих потоках процесса. Подобно PEB, это просто структура данных, хранящая критически важные сведения о каждом потоке и находящаяся в адресном пространстве памяти процесса, которому принадлежит поток. В таблице 1-2 перечислены некоторые наиболее интересные элементы TEB.

Таблица 1-2. Смещения и данные структуры TEB

Примечание. Локальное хранилище потока (TLS) используется для хранения переменных и других сведений, относящихся к разным потокам. В главе 11 будет рассказано, как вредоносная программа способна злоупотреблять TLS для скрытного выполнения вредоносного кода.

Стеки и кучи

У процесса может быть несколько активных потоков, каждый из которых обладает собственным стеком памяти. В стеке поток хранит временные данные, такие как переменные, указатели и другие объекты, которые неизбежно будут уничтожены после завершения выполнения и прекращения потока. Поскольку стек настолько изменчив и временен, программам иногда требуется более «постоянное» решение для хранения данных. Для этого и нужны кучи.

Куча - область памяти переменного размера, которую программа динамически выделяет во время выполнения. Кучи часто применяются для хранения объектов и структур данных, слишком больших для стека. Кроме того, в них хранят глобальные переменные и данные, которые сохраняются и могут использоваться несколькими функциями одной программы. Важно отметить: если стеком в основном управляет ОС, то кучами управляет сама программа. Плохо реализованное управление памятью кучи может вызвать проблемы со стабильностью программы.

Виртуальная память

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

Виртуальная память служит своего рода барьером между физической памятью и адресным пространством памяти процесса. При запуске процессу выделяется объём виртуальной памяти, отображаемой в физическую память посредством таблицы страниц. Таблица страниц отслеживает, где в RAM физически находятся различные сегменты виртуальной памяти. На рисунке 1-5 показана связь между виртуальной памятью, таблицей страниц и физической памятью.

Рисунок 1-5. Отображение виртуальной памяти в физическую посредством таблицы страниц

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

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

Просмотреть виртуальную память процесса можно с помощью такого средства анализа процессов, как Process Hacker (processhacker.sourceforge.io). Для этого запустите программу, например Calculator.exe, откройте Process Hacker и дважды щёлкните процесс, который хотите исследовать. На рисунке 1-6 показана вкладка Memory процесса в Process Hacker.

Рисунок 1-6. Просмотр виртуальной памяти процесса в Process Hacker

Столбец Base address содержит базовый адрес памяти каждой области виртуальной памяти, назначенной Calculator.exe. В столбце Type указан тип памяти для каждой области, в столбце Size - размер выделенной области, а в столбце Protection - состояние защиты области.

Каждой области виртуальной памяти обычно назначается один из трёх распространённых типов.

• Память образа (Image, IMG) обычно содержит исполняемые файлы или библиотеки, отображённые в память стандартным механизмом загрузчика Windows, который вскоре будет описан.

• Отображённая память (Mapped, MAP) часто содержит либо файлы, отображённые в память с диска, либо другие данные, используемые приложением, работающим внутри процесса.

• Закрытая память (Private, PRV) обычно выделяется с помощью VirtualAlloc и подобных функций выделения памяти.

Кроме того, каждая область памяти может быть зафиксированной или зарезервированной. Зафиксированные области активно используются и отображены в физическую память. Зарезервированные области выделены процессу, но активно не используются и ещё не отображены в RAM.

Теперь подробно рассмотрим внутреннее устройство исполняемых файлов Windows - точнее, переносимых исполняемых файлов.

Формат файлов PE

Компания Microsoft создала формат файлов PE (Portable Executable) для исполняемых файлов, работающих в ОС Windows. Формат PE содержит всё, что требуется загрузчику PE Windows для выполнения вложенного кода. Понимание формата PE критически важно для понимания работы вредоносных программ, поэтому в этом разделе мы подробно рассмотрим составляющие его структуры.

Примечание. Я буду называть PE-файлами файлы PE как x86, так и x64. Однако в действительности у x64 есть собственная версия формата PE под названием PE32+. Поскольку PE32+ лишь незначительно отличается от аналога для x86, отдельно рассматривать его я не стану.

Заголовки и разделы

Формат PE содержит несколько заголовков - метаданные или другие сведения в начале файла, указывающие ОС и прочему программному обеспечению, что делать с его содержимым. Заголовок DOS содержит информацию, необходимую MS-DOS и самым ранним версиям Windows, и существует в основном ради совместимости с унаследованными системами. Заголовок PE содержит используемую загрузчиком PE Windows информацию, например архитектуру процессора, для которой скомпилирован исполняемый файл, и такие метаданные, как отметка времени компиляции файла. В заголовок PE также входит необязательный заголовок, содержащий важные сведения: базовый адрес PE в памяти, то есть адрес, по которому PE будет отображён в память, размер кода внутри исполняемого файла и целевую ОС, в которой он будет работать. В действительности в современных системах Windows «необязательный» заголовок уже не является необязательным.

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

• .text - основной исполняемый код файла.

• .rdata - данные только для чтения, например статические переменные и константы.

• .bss - неинициализированные данные, например переменные, которым ещё не присвоено значение.

• .data - переменные, не размещённые в разделах .rdata и .bss, например глобальные переменные.

• .rsrc - ресурсы, которые исполняемый файл загрузит во время выполнения, например изображения, шрифты и другие вспомогательные файлы.

• .idata - таблица адресов импорта; см. следующий раздел.

• .edata - таблица адресов экспорта; см. следующий раздел.

Импорт и экспорт

Разделы .idata и .edata - два наиболее важных компонента PE-файла. Раздел .idata содержит сведения о функциях, которые PE-файл будет импортировать во время выполнения. После запуска PE-файла программа загрузит в память указанные здесь библиотеки и функции и построит таблицу адресов импорта (IAT), сопоставляющую импортированные функции Windows API с их адресами в памяти.

Раздел .edata содержит сведения о функциях, которые PE-файл экспортирует другим программам, чтобы те могли импортировать и загружать их в память для собственного использования. Например, исполняемые DLL-файлы часто содержат список экспортируемых функций. Как и у импорта, у экспорта есть собственная таблица, называемая таблицей адресов экспорта.

Примечание. Однако на практике разделы .edata и .idata часто находятся внутри раздела .rdata.

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

Процесс загрузки PE-файла в Windows

При запуске в Windows исполняемого файла, например Firefox, происходит следующее.

1. Windows создаёт для программы Firefox новую структуру данных EPROCESS и назначает новый идентификатор процесса.

2. Windows инициализирует необходимую процессу виртуальную память, создаёт структуру PEB и загружает две библиотеки, которые требуются почти всем процессам Windows: ntdll.dll и kernel32.dll. Затем система готовится загрузить PE-файл Firefox, инициализируя загрузчик PE.

3. Загрузчик PE разбирает заголовки DOS, PE и необязательный заголовок PE-файла, чтобы собрать всю информацию, необходимую для успешного выполнения файла.

4. Загрузчик PE разбирает заголовок разделов, подготавливая их отображение в память. Каждый раздел он отображает в виртуальную память нового процесса.

5. Загрузчик PE загружает все библиотеки, указанные в разделе импорта, обычно .idata или .rdata, и разрешает адреса всех необходимых функций. Затем все адреса сохраняются в IAT внутри процесса.

6. В текущем процессе создаётся новый поток, после чего загрузчик выполняет первые байты кода исполняемого файла, обычно находящиеся в разделе .text.

На рисунке 1-7 показаны загрузка PE-файла и его отображение в виртуальную память.

Рисунок 1-7. Загрузка и отображение PE-файла в виртуальную память процесса

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

Рандомизация размещения адресного пространства. Рандомизация размещения адресного пространства (ASLR) - метод противодействия таким атакам, как повреждение памяти. Повреждение памяти может произойти, когда управляемая злоумышленником программа записывает вредоносный код в область памяти, которая в обычных условиях находилась бы за пределами области действия программы, например в другой процесс. Это может привести к сбою программы или ОС либо, что ещё хуже, предоставить злоумышленнику управление системой.

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

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

Реестр

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

Значения представляют собой фактическую конфигурацию параметров. Например, корневой раздел HKEY_CURRENT_USER содержит подраздел Control Panel, а тот - подраздел Mouse. В Mouse находится несколько значений, в том числе MouseSpeed, где хранится настройка скорости мыши для пользователя, вошедшего в систему. Путь к разделу реестра можно записать так же, как путь к файлу или каталогу Windows: HKEY_CURRENT_USER\Control Panel\Mouse\MouseSpeed.

Ниже перечислены пять наиболее важных кустов реестра.

HKEY_LOCAL_MACHINE (HKLM). Значения, относящиеся к системе: низкоуровневая конфигурация ОС и оборудования, политика безопасности и параметры учётных записей, а также параметры различного установленного программного обеспечения.

HKEY_CURRENT_USER (HKCU). Значения, относящиеся к пользовательским параметрам и конфигурации системы, например настройки звука, мыши, клавиатуры, сети и принтера.

HKEY_USERS (HKU). Значения, относящиеся к настройкам каждого пользователя, у которого есть учётная запись в системе. Под этим корневым разделом находится несколько подразделов, имена которых начинаются с S, например S-1-5-20. Каждый подраздел представляет идентификатор учётной записи пользователя в системе и хранит конфигурационные сведения этого пользователя.

HKEY_CURRENT_CONFIG (HKCC). Указатели на раздел HKEY_LOCAL_MACHINE для профиля оборудования, который в настоящее время использует вошедший в систему пользователь. Для наших целей этот раздел менее важен, поскольку все ценные сведения хранятся в HKEY_LOCAL_MACHINE.

HKEY_CLASSES_ROOT (HKCR). Сведения о зарегистрированных приложениях, например сопоставления файлов, связывающие типы файлов с приложениями, способными их обработать. Например, файлы .doc должны открываться в Microsoft Word.

Кусты реестра хранятся на жёстком диске в виде файлов. При загрузке Windows эти файлы загружаются в память и на их основе строится реестр. Все изменения реестра после загрузки системы сохраняются в памяти, а не непосредственно на диске. Именно поэтому некоторые вредоносные программы способны хранить в реестре вредоносный код и конфигурацию, не обязательно обращаясь к диску.

Наконец, в Windows есть встроенная служебная программа Registry Editor (Regedit), показанная на рисунке 1-8. С ней должен быть очень хорошо знаком каждый аналитик вредоносных программ.

Рисунок 1-8. Средство Registry Editor в Windows

Regedit позволяет просматривать и изменять каждый раздел и каждое значение реестра в системе, что помогает понять устройство реестра. Эта программа также полезна при расследовании изменений данных, которые могла внести вредоносная программа.

Итоги

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

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

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

Приступим и начнём с важности среды анализа.

Среда анализа

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

Прежде чем двигаться дальше, важно дать несколько определений. Виртуальная машина (VM) имитирует физический компьютер, но целиком работает внутри приложения, называемого гипервизором. Гипервизор создаёт своего рода контейнер, позволяющий безопасно выполнять вредоносный код и запускать вредоносные программы. Песочница для анализа вредоносных программ обычно, хотя и не всегда, представляет собой разновидность VM, настроенную на автоматический анализ вредоносной программы и составление отчёта или оценки её поведения, возможностей и свойств. Примерами служат песочница Cuckoo с открытым исходным кодом и проприетарные песочницы Joe Sandbox и Any.Run. Главное здесь заключается в том, что почти все песочницы анализа вредоносных программ являются VM, однако далеко не каждая VM настроена как такая песочница.

Типичная лабораторная среда анализа вредоносных программ часто состоит из основной системы и одной или нескольких VM и песочниц. Основная система хранит и запускает аналитические VM и песочницы; на ней могут быть установлены Windows, Linux или macOS, а также гипервизор. Операционная система и программное обеспечение, настроенные на VM и в песочницах, зависят от исследуемого вида вредоносной программы. Например, для анализа вредоносных программ Windows у аналитика могут быть VM с Windows 7, Windows 10 и Windows 11, а также множество специализированных средств анализа.

Предупреждение. Если вы начинающий аналитик вредоносных программ, настоятельно рекомендую перед погружением в анализ изучить приложение A, чтобы получить представление о настройке и безопасности лаборатории. Анализ вредоносных программ связан с рисками, и важно максимально их ограничить.

Процесс анализа вредоносных программ

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

• К какому типу относится этот файл?

• Что он делает при открытии?

• Артефакты каких видов файл создаёт после запуска?

• Пытается ли запущенный файл подключиться к Интернету или взаимодействовать по локальной сети? Если да, то с какими IP-адресами или доменами?

• Проявляет ли запущенный файл признаки возможной вредоносной деятельности, например скрывает ли себя в заражённой системе, пытается ли похитить конфиденциальные данные или обнаружить средства анализа вредоносных программ?

• Если файл имеет вредоносную природу, каковы его возможности и намерения?

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

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

Первичное исследование вредоносной программы

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

У первоначального исследования несколько целей. Во-первых, необходимо определить тип файла. Это документ Microsoft Excel? PDF? Сценарий? Исполняемый файл? Ответ определяет весь дальнейший процесс анализа. Во-вторых, нужно получить о файле как можно больше сведений. Например, известен ли он открытым репозиториям вредоносных программ и другим исследователям? Эти сведения помогут достичь третьей цели: определить, является ли файл вредоносным и, если да, к какому классу он относится. Программа-вымогатель? Похититель информации? Наконец, следует получить общее представление о возможностях файла. Одна из основных целей первоначального исследования - помочь определить последующие действия при изучении образца вредоносной программы.

Примечание. В следующих подразделах я последовательно разберу основные действия по первичному исследованию файла во время расследования угрозы. Если вы хотите повторять действия самостоятельно, загрузите вредоносный файл с VirusTotal или MalShare по следующему хешу:

SHA256: 8348b0756633b675ff22ed3b840497f2393e8d9587f8933ac2469d689c16368a

Определение типа файла

Одно из самых простых, но важных действий при анализе вредоносной программы - определение типа файла. От него зависят подход к анализу, используемые инструменты и порядок действий. Тип файла обозначается его магическими байтами, или сигнатурой, - одним или несколькими байтами данных в начале файла. Просмотреть магические байты можно в шестнадцатеричном редакторе, например McAfee FileInsight. У файла на рисунке 2-1 магические байты имеют значения 4D 5A, или MZ в ASCII, что характерно для PE-файлов.

Рисунок 2-1. Заголовок PE в шестнадцатеричном редакторе

В таблице 2-1 перечислены некоторые другие распространённые сигнатуры. Ещё больше можно найти в Википедии по запросу «list of file signatures».

Таблица 2-1. Распространённые сигнатуры файлов

Помимо шестнадцатеричного редактора, для определения типа файла в Linux можно использовать команду file. Она читает сигнатуру файла и выводит её в понятном человеку виде. Просто выполните команду file, передав файл вредоносной программы как входной параметр:

Как видно из следующего вывода, файл действительно является исполняемым - точнее, 32-разрядным PE-файлом Windows:

Команда file - хорошее универсальное средство определения многих распространённых форматов, включая не только PE-файлы, но также документы и архивы. Для PE-файлов особенно полезны средства статического анализа PE, которые я называю средствами первичного исследования PE. Например, CFF Explorer (ntcore.com) прекрасно подходит для начального анализа, поскольку предоставляет такие сведения, как размер файла и отметки времени его создания; некоторые из них показаны на рисунке 2-2.

Рисунок 2-2. Исполняемый файл, загруженный в CFF Explorer

Возможно, вы заметили на рисунке 2-2 и другие сведения о файле, например вкладки Import Directory и Section Headers слева. Подробнее эти атрибуты будут рассматриваться далее в этой и следующей главах. Обратите внимание на загадочно выглядящие поля MD5 и SHA-1 в правой нижней части. Это хеши файла, о которых пойдёт речь далее.

Получение хеша файла

Хеш файла служит своего рода отпечатком, поскольку уникален для этого файла. Когда файл обрабатывается алгоритмом хеширования, алгоритм создаёт последовательность символов фиксированного размера. Точный размер зависит от применяемого алгоритма. Наиболее распространённые алгоритмы хеширования файлов при анализе вредоносных программ - MD5, SHA-1 и SHA256, самый новый и надёжный из трёх.

На рисунке 2-3 хеш MD5 файла равен C37CFC5C7EFD645BEE48ED745EC12906, а хеш SHA-1 - D2DD576536813A87CDC00E87FAC65DA75FB36A0F. Эти значения однозначно идентифицируют файл. Обратите внимание: MD5 - старый алгоритм, но он применяется до сих пор. Для MD5 и SHA-1 существует риск коллизий: два или несколько файлов могут иметь одинаковый хеш. Это происходит очень редко, но всё же случается. Здесь мы не будем подробно обсуждать коллизии хешей; достаточно сказать, что если вы обнаружите два совершенно разных файла с одной сигнатурой, то, вероятно, столкнулись с коллизией.

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

Первичное исследование с помощью VirusTotal

VirusTotal (virustotal.com) - общедоступная платформа для первичного исследования и анализа вредоносных программ. Учётная запись не требуется, поэтому любой пользователь может загрузить файлы и быстро получить оценку. VirusTotal проверяет загруженный файл средствами более чем 60 поставщиков защиты от вредоносных программ, чтобы определить общий коэффициент обнаружения, запускает файл в песочнице, которую мы вскоре рассмотрим, и получает дополнительные сведения о файле из нескольких источников. Типичная оценка VirusTotal может включать:

• количество обнаружений файла средствами защиты от вредоносных программ, то есть коэффициент обнаружения;

• отчёты песочниц о файле;

• метаданные файла, например его создателя и дату создания;

• связанные с файлом цифровые сертификаты;

• совпадения с правилами Yara, которая будет рассмотрена позднее в этой главе;

• множество других полезных сведений.

Одно из ключевых преимуществ VirusTotal - возможность выполнять поиск по хешу в очень большой базе вредоносных программ. Можно просто вставить хеш в VirusTotal, после чего сервис выполнит пассивный запрос файла и предоставит все сведения так, словно вы загрузили сам файл. Если файл есть в базе данных, VirusTotal выдаст отчёт о нём. Запрос хеша SHA-1 нашего вредоносного файла с рисунка 2-2 (D2DD576536813A87CDC00E87FAC65DA75FB36A0F) возвращает отчёт, показанный на рисунке 2-3.

Рисунок 2-3. Отчёт VirusTotal о файле с рисунка 2-2

Видно, что коэффициент обнаружения этого файла равен 56/68: 56 из 68 поставщиков программного обеспечения для защиты от вредоносных программ классифицируют файл как вредоносный. На основании этих сведений можно заключить, что файл с очень высокой вероятностью является вредоносной программой. Помимо коэффициента обнаружения, некоторые поставщики указывают класс и название семейства вредоносной программы. Отчёт позволяет сделать обоснованное предположение, что это может быть семейство Ave Maria - распространённый вариант трояна удалённого доступа и похитителя информации. Однако учтите, что классификации VirusTotal не всегда верны. Вредоносный файл может быть упакован, что приводит к ошибочной классификации. Упаковка будет подробно рассмотрена в главе 17.

Примечание. Запрашивать файл в VirusTotal по хешу всегда полезно. Но прежде чем загружать туда сам файл, следует оценить риски его появления в открытом доступе на платформе VirusTotal. Спросите себя: содержит ли файл конфиденциальные сведения, например данные обо мне или моей компании? Является ли файл частью активного расследования, связанного с моей компанией? Сообщит ли его загрузка авторам вредоносной программы, что их программу обнаружили и активно анализируют? Помните: злоумышленники тоже следят за VirusTotal.

Поиск в поисковых системах и других ресурсах

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

Поиск в Google хеша SHA-1 нашей вредоносной программы возвращает результаты, показанные на рисунке 2-4.

Рисунок 2-4. Поиск хеша SHA-1 нашей вредоносной программы в Google

Похоже, этот файл уже довольно хорошо известен! Некоторые сведения о нём есть у MalwareBazaar - прекрасного ресурса для аналитиков и исследователей вредоносных программ. Он также, судя по всему, уже известен Joe Sandbox, о которой я расскажу позднее в этой главе. Изучение этих ресурсов может помочь лучше понять файл и его возможности ещё до самостоятельного анализа, сэкономив немало времени и сил.

Теперь у вас должно сложиться хотя бы общее представление о файле и, возможно, даже о том, к какому семейству вредоносных программ он относится, если он присутствует в открытых репозиториях. Если файл неизвестен, придётся копнуть глубже, чтобы определить его возможности и поведение. Но именно в этом и состоит самое интересное в анализе вредоносных программ! Рассмотрим, как исследовать неизвестный файл.

Выявление и классификация неизвестных вредоносных программ с помощью Yara

Yara (virustotal.github.io) позволяет создавать определения сигнатур, называемые правилами, предназначенные для поиска совпадений в неизвестном файле. Такие определения могут иметь форму строк, последовательностей байтов или других свойств. В следующем коде, доступном по адресу github.com, приведена сокращённая версия правила Yara для обнаружения Ave Maria:

Это правило Yara специально предназначено для поиска образцов, которые могут быть связаны с RAT Ave Maria, или Warzone. Оно совпадёт с любым файлом, содержащим три или более строк из раздела strings. Запустим правило Yara для исследуемого образца. Чтобы выполнить правило, используйте следующий синтаксис; параметр -s показывает точные совпадения строк в файле вредоносной программы:

Выполнение этого правила Yara для нашего образца даёт следующие результаты:

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

Правила Yara помогают быстро получать ценные сведения о файле и иногда даже определять связанное с ним семейство вредоносных программ. Дополнительные сведения о Yara приведены на странице yara.readthedocs.io.

Теперь рассмотрим, как оценить неизвестный файл по его статическим свойствам.

Анализ статических свойств

Изучая статические свойства неизвестного файла, можно узнать о нём очень многое. Некоторые из этих свойств рассматривались в разделе «Формат файлов PE» на странице 13.

Строки

Строки - последовательности символов в файлах различных типов. Иногда это текст, понятный человеку, а иногда просто последовательность байтов. В любом случае строки могут стать прекрасной отправной точкой при исследовании неизвестного файла. Самый простой способ извлечь строки из файла - воспользоваться консольной утилитой strings в Linux. Она сканирует файл, пытается найти строки двоичных данных и представить их в понятном человеку виде:

Обратите внимание, что по умолчанию команда strings выводит только строки ASCII. Строки другого типа - Unicode, или широкие строки, - можно извлечь командой strings -e l suspicious.exe. Уже в следующем выводе обнаруживаются интересные сведения:

Особенно примечательна ссылка warzone160. Быстрый поиск показывает, что она с большой вероятностью связана с семейством RAT Ave Maria, или Warzone, как видно на рисунке 2-5. Это хороший пример включения разведки по открытым источникам (OSINT) в процесс анализа вредоносных программ.

Рисунок 2-5. OSINT-исследование встроенных строк вредоносной программы

При работе именно с исполняемыми файлами очень полезны такие средства PE, как PEStudio. PEStudio не только извлекает из исполняемого файла строки различных форматов, но и упорядочивает и классифицирует их по определённым характеристикам, как показано на рисунке 2-6.

Рисунок 2-6. Классификация строк в PEStudio

PEStudio обнаружила несколько примечательных строк: возможные возможности повышения привилегий (Elevation:Administrator), команду командной строки (cmd.exe) и ссылки на PowerShell и WMIC, а также упоминания служб SMTP и паролей (SMTP, POP и так далее). По этим строкам можно предположить, что файл способен повысить свои привилегии от обычного пользователя до администратора, запускать такие средства Windows, как cmd.exe, PowerShell и WMIC, а также использовать SMTP для сетевого взаимодействия. Полезные сведения, обнаруженные в строках, могут направлять расследование и давать подсказки о намерениях вредоносного файла.

Ещё два весьма полезных средства анализа строк - FLOSS и StringSifter. FLOSS (github.com) предназначена для выявления и извлечения обфусцированных строк, то есть строк, намеренно скрытых от посторонних глаз. Ниже приведён фрагмент вывода FLOSS для другого подозрительного файла:

В этом случае FLOSS смогла декодировать несколько примечательных обфусцированных строк, в том числе путь к файлу (C:\Program Files\Office\W0rd.exe), ссылку на средство командной строки (taskkill) и возможное имя функции Windows, которую вредоносная программа импортирует позднее (ZwQueryInformationProcess). В главе 16 я рассмотрю способы, которыми вредоносные программы могут обфусцировать данные, а также применение FLOSS для их раскрытия.

StringSifter (github.com) получает вывод другого средства извлечения строк, например уже упомянутых strings и FLOSS, а затем ранжирует и сортирует строки по их полезности и значимости для аналитиков вредоносных программ. Далее в книге StringSifter не рассматривается, однако это средство может быть очень полезным для быстрого анализа большого набора строк.

Импорт и экспорт

Как объяснялось в главе 1, импорт - это библиотеки и функции, которые использует исполняемый файл, а экспорт - функции, предоставляемые исполняемым файлом другим функциям или программам. Импорт и экспорт позволяют получить подсказки о назначении исполняемого файла. Например, если файл импортирует такие библиотеки, как Winhttp.dll, можно сделать обоснованное предположение, которое всегда следует проверять, что он попытается связаться с удалённым сервером, например сервером управления.

PEStudio также может извлекать импорт и экспорт вредоносной программы и организованно отображать эти сведения, как показано на рисунке 2-7.

Рисунок 2-7. Список импортируемых функций в PEStudio

Здесь видны различные функции Windows, которые импортирует вредоносная программа и, вероятно, вызовет во время выполнения. Среди особенно интересных - функции BCrypt*, которые могут применяться для шифрования или расшифровки данных, WriteProcessMemory и CreateRemoteThread, способные использоваться при внедрении в процесс, а также WriteFile, предназначенная для записи данных в файл. Хотя эти функции не являются окончательным доказательством вредоносности или возможностей файла, они дают дополнительные подсказки для процесса анализа вредоносной программы.

Метаданные и другие сведения

Наконец, подсказки о намерениях файла могут содержаться в его метаданных. PEStudio умеет показывать отметки времени файла, которые могут отражать момент его первоначальной компиляции. Она также отображает сведения о языке программирования, на котором написан файл, различных разделах PE-файла и даже встроенных сертификатах, которыми файл мог быть подписан. Иными словами, с помощью таких средств анализа PE-файлов, как PEStudio, можно собрать огромное количество дополнительных сведений. Однако помните, что авторы вредоносных программ способны изменять и подделывать метаданные, как будет показано далее в книге.

Автоматизированное первичное исследование вредоносных программ в песочницах

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

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

На момент написания книги существует огромное множество песочниц с разными возможностями. Хороших песочниц слишком много, чтобы перечислить все, но в таблице 2-2 приведены те, с которыми я работал и которые считаю достойными упоминания. Многие из них позволяют загружать файлы бесплатно, однако в бесплатных тарифах некоторых сервисов ограничено количество отправляемых файлов либо действуют другие ограничения. Обратите внимание, что первые два пункта списка, CAPE и Cuckoo, не являются коммерческими: проекты придётся скачать с GitHub и развернуть самостоятельно. Кроме того, на момент написания книги Cuckoo больше не поддерживается, но авторы проекта работают над новой версией.

Таблица 2-2. Коммерческие и бесплатные песочницы

Ссылки из таблицы: github.com · capev2.readthedocs.io · github.com · tria.ge · hybrid-analysis.com · intezer.com · joesecurity.org · unpac.me · virustotal.com · vmray.com

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

На рисунке 2-8 показан результат отправки нашего вредоносного файла в экземпляр песочницы Cuckoo.

Рисунок 2-8. Сводка о вредоносной программе в песочнице Cuckoo

На этой странице сводки Cuckoo содержится немало полезной информации: основные сведения о файле, включая тип, размер и хеши, оценка обнаружения - «10 из 10!» - и даже сигнатуры Yara. По-видимому, механизм Yara песочницы Cuckoo определяет образец как возможный Gh0st либо Ave Maria / Warzone. Для сравнения: Joe Sandbox сообщает, что образец относится к Ave Maria, как показано на рисунке 2-9.

Рисунок 2-9. Обзор вредоносной программы в Joe Sandbox

Даже одно знание о вероятной связи вредоносной программы с Ave Maria уже полезно. Этот пример также показывает, что запуск образца более чем в одной песочнице никогда не бывает лишним. Разные песочницы иногда дают разные результаты, из которых складывается более полная картина вредоносной программы. Исследуем образец в Joe Sandbox немного глубже. Дерево процессов вредоносной программы, показанное на рисунке 2-10, - один из основных источников сведений при анализе образцов в песочнице.

Рисунок 2-10. Дерево процессов вредоносной программы в Joe Sandbox

В дереве показан процесс исходного исполняемого файла вредоносной программы (cY7cusWGCA.exe), а также все порождённые дочерние процессы, что позволяет понять некоторые возможности и модели поведения программы. Особенно примечательно, что процесс PowerShell выполняет команду Add-MpPreference -ExclusionPath C:\. Эта команда добавляет вредоносную программу в список исключений Windows Defender, фактически обходя средства защиты от вредоносных программ.

Кроме того, раздел Anti Debugging в Joe Sandbox, показанный на рисунке 2-11, демонстрирует некоторые методы, которые образец может использовать для обнаружения отладчиков и защиты от них.

Рисунок 2-11. Методы противодействия отладке вредоносной программы в Joe Sandbox

По всей видимости, образец может обнаруживать отладчики с помощью таких методов, как динамическая загрузка библиотек, ручное чтение PEB и вызов GetProcessHeap.

Также видно, что Joe Sandbox обнаружила применение нескольких возможных методов обхода узловых средств защиты, например внедрения в процесс и добавления исключений Windows Defender; см. рисунок 2-12.

Рисунок 2-12. Методы обхода средств защиты, выявленные Joe Sandbox

Противодействие отладке и обход средств защиты будут подробнее рассмотрены соответственно в главе 10 и части IV.

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

Наконец, песочницы прекрасно подходят для быстрого извлечения из образцов вредоносных программ индикаторов компрометации (IOC). IOC могут быть сетевыми артефактами, например взаимодействием с определённым доменом или IP-адресом либо особым заголовком HTTP, или артефактами узла, например конкретным именем файла, изменением раздела реестра или выполнением подозрительной команды. Позднее их можно использовать для обнаружения этой вредоносной программы и предотвращения заражения других узлов. Дополнительные сведения о том, что является и не является IOC, приведены по адресу crowdstrike.com.

Среда Joe Sandbox смогла извлечь из образца IP-адрес сервера управления, как показано на рисунке 2-13.

Рисунок 2-13. Конфигурация вредоносной программы, извлечённая Joe Sandbox

Проанализировав образец в нескольких песочницах, мы получили довольно хорошую оценку многих его возможностей и моделей поведения. Вероятно, это вариант Ave Maria, способный взаимодействовать с управляющим адресом, а значит, скорее всего, загружать дополнительную полезную нагрузку, обнаруживать такие средства анализа, как отладчики, и обходить узловые средства защиты посредством внедрения в процессы и методов обхода защиты от вредоносных программ. В зависимости от целей анализа в рамках этого расследования таких сведений может быть достаточно. Однако для детального понимания образца нужно погрузиться глубже.

Интерактивный поведенческий анализ

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

Интерактивный поведенческий анализ - звучное название ручного запуска вредоносной программы и наблюдения за ней в контролируемой среде вместо того, чтобы полагаться исключительно на полностью автоматизированный запуск в такой песочнице, как Cuckoo. Это гораздо более ручной и, как следует из названия, интерактивный процесс, предоставляющий больше свободы. Обычно такой анализ проводится в VM.

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

Все рассматриваемые далее инструменты доступны бесплатно. Если вы хотите повторять действия, загрузите и установите в среде VM следующие средства:

• Procmon (learn.microsoft.com);

• Process Hacker (processhacker.sourceforge.io);

• Fiddler (telerik.com);

• Wireshark (wireshark.org).

Примечание. В этом примере анализа мы будем работать с образцом вредоносной программы, который можно найти в VirusTotal или MalShare по следующему хешу:

SHA256: 9bbc55f519b5c2bd5f57c0e081a60d079b44243841bf0bc76eadf50a902aaa61

Наблюдение за поведением вредоносной программы

Значительная часть интерактивного поведенческого анализа заключается в наблюдении за поведением, или действиями, вредоносной программы на узле жертвы. Популярным средством для этой задачи является Process Monitor (Procmon), входящий в комплект Sysinternals. Procmon может собирать множество подробных сведений о действиях вредоносной программы на узле: порождении процессов, чтении и записи файлов и реестра, попытках подключения к сети. На рисунке 2-14 показано дерево процессов подозрительного файла Microsoft Word в Procmon.

Рисунок 2-14. Анализ дерева процессов образца вредоносной программы в Procmon

Видно, что WINWORD.EXE, то есть Microsoft Word, порождает подозрительный процесс rundll32.exe - такой результат всегда заслуживает дальнейшего исследования. Дерево процессов также позволяет анализировать связи между родительскими и дочерними процессами и выявлять механизмы внедрения кода. Внедрение кода будет рассмотрено в главе 12.

Изучив раздел Files программы Procmon, можно увидеть, что файл создаёт несколько дополнительных подозрительных файлов; см. рисунок 2-15.

Рисунок 2-15. Просмотр подозрительных операций записи файлов в Procmon

Главное, на что следует обратить внимание, - операции WriteFile и следующие за ними пути записи файлов. Эти два файла, diplo.ioe и flex.xz, необходимо дополнительно исследовать во время анализа.

Аналогичным образом на рисунке 2-16 показана вкладка Registry в Procmon.

Рисунок 2-16. Просмотр запросов к реестру в Procmon

Показанный здесь процесс rundll32.exe выполняет операцию RegQueryValue, то есть читает несколько значений реестра на узле. Все особенно интересующие его разделы реестра, судя по всему, связаны с доменом, именем узла и сведениями о сетевых адаптерах. Операции чтения реестра не обязательно вредоносны: для нормальной работы всем приложениям Windows приходится читать различные кусты реестра. Но иногда они подсказывают, чего пытается добиться вредоносная программа. Как будет неоднократно показано в этой книге, целевая и уклоняющаяся вредоносная программа может перечислять содержимое реестра и файловой системы в поисках определённого значения или шаблона, например конкретного имени узла или пути к файлу.

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

Ещё одно средство интерактивного анализа - Process Hacker. Вместе с похожими средствами, например Process Explorer, его можно использовать для изучения дерева процессов, исследования памяти процесса вредоносной программы и многого другого. Особенно полезно исследование памяти: щёлкните целевой процесс правой кнопкой мыши, выберите Properties, затем вкладку Memory. В памяти можно даже искать определённые шаблоны строк. Как видно на рисунке 2-17, хорошей отправной точкой всегда служит поиск http.

Рисунок 2-17. Поиск шаблона строки в памяти процесса с помощью Process Hacker

Показанные строки памяти содержат подозрительные данные. Видно несколько URL-адресов таких доменов, как armerinin.com и siguages.ru, которые необходимо дополнительно исследовать. Вредоносная программа может использовать эти домены для управления или загрузки дополнительных вредоносных программ. Проверим эту гипотезу.

Исследование сетевого трафика вредоносной программы

Многие образцы вредоносных программ в какой-то момент пытаются подключиться к удалённому серверу в Интернете. Это может делаться по различным причинам:

• чтобы загрузить дополнительные вредоносные файлы, полезные нагрузки и модули;

• чтобы связаться с сервером управления и запросить дальнейшие указания;

• чтобы отправить на удалённый сервер похищенные сведения, например учётные данные или файлы; это часто называют эксфильтрацией;

• чтобы определить, подключён ли заражённый узел к Интернету, или получить его общедоступный IP-адрес; это часто применяется как метод обнаружения и обхода песочницы.

Какова бы ни была причина, важно определить, когда и с кем устанавливает соединение вредоносная программа. Веб-прокси - средство, способное перехватывать и изменять сетевой трафик, отправляемый узлом и получаемый им, поэтому оно прекрасно подходит для анализа вредоносных программ. Показанный на рисунке 2-18 веб-прокси Fiddler перехватил несколько подозрительных попыток вредоносной программы подключиться к Интернету.

Рисунок 2-18. Попытки подключения вредоносной программы к Интернету в веб-прокси Fiddler

Видно, что Fiddler перехватил веб-запросы к api.ipify.org и ещё трём сайтам: armerinin.com, houniant.ru и siguages.ru. Если запросить последние три домена в VirusTotal, вы, вероятно, увидите, что они считаются вредоносными. Во всяком случае, так было на момент написания книги. Вероятно, вредоносная программа пытается загрузить дополнительную вредоносную программу с одного из этих доменов. Сайт api.ipify.org просто возвращает внешний общедоступный IP-адрес узла. Зачем вредоносной программе обращаться к нему? Возможно, она пытается получить общедоступный IP-адрес узла, чтобы определить страну его размещения. Другая возможная причина - проверить, подключён ли узел к Интернету вообще. Обе части информации могут применяться для противодействия анализу и уклонения; соответствующие методы будут подробно рассматриваться на протяжении книги.

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

Рисунок 2-19. DNS-запросы вредоносной программы, перехваченные Wireshark

Легко заметить DNS-запросы к тем же именам узлов, которые обнаружил Fiddler.

Полезно исследовать трафик HTTP и других протоколов подробнее. Чтобы просмотреть веб-трафик, щёлкните запрос HTTP правой кнопкой мыши и выберите Follow > TCP Stream. Вы увидите HTTP-запрос POST, отправленный этим образцом вредоносной программы, как показано на рисунке 2-20.

Рисунок 2-20. HTTP-запрос POST вредоносной программы

Образец отправляет своей инфраструктуре на siguages.ru такие данные, как имя узла жертвы, IP-адрес и уникальный идентификатор. Интересно, что вредоносная программа также отправляет идентификатор своей бот-сети - в данном случае 2209_ubm, - назначенный сети скомпрометированных компьютеров. Этот образец передаёт данные без шифрования, но вредоносные программы могут использовать и зашифрованные каналы связи между жертвой и инфраструктурой управления. Это затрудняет исследование трафика в веб-прокси или таком средстве, как Wireshark. По мере дальнейшего изложения книги мы подробнее рассмотрим некоторые из этих методов и способы их преодоления.

Примечание. В качестве метода уклонения от песочницы многие семейства вредоносных программ перед заражением пытаются определить, подключён ли узел к Интернету. Если вы исследуете вредоносную программу в автономной VM без подключения к Интернету, скорее всего, вам понадобится средство, «подделывающее» сетевые службы, например FakeNet или INetSim. Эти средства кратко рассматриваются в приложении A.

Итоги

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

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

Мы начнём с краткого введения в ассемблерный код - основополагающее понятие обратной разработки PE-файлов. Затем подробно рассмотрим статический анализ кода и такие дизассемблеры, как IDA. Наконец, исследуем особенности динамического анализа кода и отладки с помощью x64dbg.

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

Введение в ассемблерный код

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

В этом разделе вводятся ассемблерный код x86, то есть 32-разрядный, и x86_64, то есть 64-разрядный, который далее будет обозначаться x64, а также некоторые понятия CPU, используемые во всей остальной книге. Сначала рассмотрим основы архитектуры CPU, а затем перейдём к ассемблерным инструкциям.

Регистры CPU

Во время выполнения программы CPU использует регистры - области памяти на физическом кристалле процессора - для хранения данных и отслеживания состояния обработки. Поскольку хранение в памяти гораздо медленнее, CPU старается как можно шире использовать регистры для хранения данных и манипулирования ими. В зависимости от архитектуры процессора каждый регистр способен хранить определённый объём данных. Слово соответствует 16 битам данных. Регистр процессора x86 обычно может хранить одно двойное слово, или dword, то есть 32 бита данных, а регистр процессора x64 - одно четверное слово, или qword, то есть 64 бита данных.

Существует пять основных видов регистров CPU: 1) регистры общего назначения, 2) индексные регистры и регистры-указатели, 3) регистры флагов, 4) сегментные регистры и 5) регистры-индикаторы. Для наших целей наиболее важны первые три, однако двух остальных я коснусь позднее в книге.

Регистры общего назначения

Регистры общего назначения служат для хранения и обработки данных при выполнении общих задач, например арифметических операций и передачи аргументов функций. Каждый регистр общего назначения можно разделить на более мелкие сегменты, содержащие 16 или 8 бит данных. Например, 64-разрядный регистр RAX архитектуры x64 «содержит» четыре дополнительных регистра общего назначения меньшего размера: EAX, последние 32 бита данных RAX; AX, старшие 16 бит EAX; AH, старшие 8 бит EAX; и AL, младшие 8 бит EAX. На рисунке 3-1 показаны регистр RAX и его меньшие сегменты с соответствующими предельными размерами хранилища в битах.

Рисунок 3-1. Структура регистра общего назначения

В таблице 3-1 описаны регистры общего назначения процессоров x86 и x64. Учтите, что описания отражают историческое применение каждого регистра, но это не означает, что регистр обязательно должен использоваться именно так.

Таблица 3-1. Регистры общего назначения x86 и x64

Индексные регистры и регистры-указатели

В индексных регистрах и регистрах-указателях могут храниться как указатели, так и адреса. Они применяются для таких задач, как передача данных памяти, поддержание потока управления и отслеживание стека. Обзор этих регистров приведён в таблице 3-2.

Таблица 3-2. Индексные регистры и регистры-указатели x86 и x64

Регистр флагов

Регистр флагов отслеживает текущее состояние процессора. В общем случае он используется для хранения результатов вычислений и управления работой процессора. «Флаги» - общее название регистра EFLAGS, применяемого в 32-разрядных архитектурах и показанного на рисунке 3-2, и регистра RFLAGS, применяемого в 64-разрядных архитектурах. Эти два регистра работают схожим образом.

Рисунок 3-2. Регистр EFLAGS

Для наших целей наиболее важны два значения флагов: флаг нуля (ZF) и флаг трассировки (TF). ZF имеет длину один бит и устанавливается условной инструкцией. Например, условная инструкция может сравнить два значения; если они равны, ZF устанавливается в 1. TF используется для отладки и позволяет отладчику выполнять инструкции по одной.

Архитектуры CPU x86 и x64. Возможно, вы уже заметили небольшие различия между процессорными архитектурами x86 и x64. В именах регистров CPU используются разные соглашения, например RAX и EAX, а регистры x64 способны хранить на 32 бита больше своих аналогов x86. Ещё одно различие заключается в том, что набор инструкций x64 может использовать дополнительные регистры с R8 по R15, действующие как регистры общего назначения. Поскольку хранение и обработка данных в регистрах процессора намного быстрее доступа к памяти, 64-разрядные процессоры имеют явное преимущество в скорости. В ассемблерном коде вы, скорее всего, увидите, что программы x64 хранят данные и манипулируют ими непосредственно в регистрах CPU, а не используют совместно память и регистры.

Из-за наличия дополнительных регистров 64-разрядные программы, включая вредоносные, часто передают параметры функциям через регистры CPU, в отличие от 32-разрядных программ, помещающих параметры в стек. Мы ещё ненадолго вернёмся к этому далее в главе.

Инструкции x64 и x86

Теперь, рассмотрев основы регистров CPU и стека, начнём изучать различные ассемблерные инструкции, которыми может пользоваться программа.

Операции со стеком

В главе 1 кратко упоминался стек - область памяти, назначенная потоку и используемая для хранения временных данных: переменных, указателей и других объектов, которые больше не понадобятся после завершения выполнения и прекращения потока. Стек работает по принципу «последним вошёл - первым вышел» (LIFO). Это означает, что, когда программа сохраняет в стеке данные, например переменную, она помещается на вершину стека. Чтобы извлечь эту переменную, программе сначала придётся извлечь все остальные данные, находящиеся над ней.

Для помещения данных в стек программа выполняет инструкцию push, проталкивающую их на вершину стека; см. рисунок 3-3. Для извлечения этих данных приложение выполняет инструкцию pop, снимающую их с вершины стека.

Рисунок 3-3. Программа помещает данные на вершину стека

Здесь программа сначала помещает в стек значение Value 1, затем Value 2 и, наконец, Value 3. Теперь на вершине стека находится Value 3. Чтобы извлечь Value 1, программе сначала придётся снять со стека значения Value 3 и Value 2 именно в таком порядке.

Обзор этих инструкций приведён в таблице 3-3.

Таблица 3-3. Инструкции операций со стеком

Большинство инструкций может работать непосредственно с регистрами CPU, а также с адресами памяти. Например, инструкция push ebx помещает в стек данные, которые в данный момент хранятся непосредственно в регистре EBX. Квадратные скобки вокруг имени регистра, например в push [ebx], означают, что инструкция разыменовывает указатель на память, поэтому в стек будет помещено то, что хранится по адресу памяти из EBX. Например, если EBX сейчас содержит значение 0x00406028, являющееся адресом памяти, в стек будет помещено текущее содержимое этого адреса. В дизассемблере, который вскоре будет рассмотрен, такая инструкция обычно записывается как push byte ptr [ebx] или подобным образом, что подсказывает: это указатель на последовательность байтов в памяти.

Арифметические операции

Инструкции манипулирования данными и арифметические инструкции применяются для таких вычислений, как сложение и вычитание. Некоторые арифметические инструкции, например add, принимают два аргумента: первый является целевым операндом, а второй - прибавляемым к нему значением. Другие, например dec, уменьшающая целевой операнд, принимают только один аргумент. Некоторые распространённые инструкции арифметических операций сведены в таблицу 3-4.

Таблица 3-4. Инструкции арифметических операций

Перемещение данных

Программа может перемещать данные в память и регистры и обратно с помощью инструкции mov. Она принимает два аргумента, но только один из них может быть адресом памяти. Например, в ассемблерном коде x86 и x64 программа не может непосредственно перемещать данные с одного адреса памяти на другой. Некоторые распространённые примеры таких инструкций приведены в таблице 3-5.

Таблица 3-5. Примеры инструкции mov

Сравнение значений

Программе довольно часто требуется сравнивать два значения, чтобы направлять поток управления. Инструкции сравнения могут соответствовать операторам if, например if var == 2, но две основные инструкции сравнения - cmp и test. Результат любой из них сохраняется в регистре флага нуля, который позднее используется для направления потока управления. Обзор инструкций cmp и test приведён в таблице 3-6.

Таблица 3-6. Инструкции сравнения

Вам могут встретиться такие инструкции, как test eax, eax, сравнивающие значение EAX с ним самим. Это просто способ проверить, равно ли содержимое регистра, в данном случае EAX, нулю. Когда оба аргумента инструкции test одинаковы, она, по сути, сравнивает аргумент с нулём. Если EAX равен 0, устанавливается флаг нуля.

Хотя cmp и test выглядят чрезвычайно похоже, в принципах их работы есть фундаментальные различия: cmp можно рассматривать как инструкцию sub, а test подобна инструкции and. Все подробности выходят за рамки этой главы.

Инструкции перехода

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

Таблица 3-7. Инструкции перехода

Условные инструкции перехода, например jz и jnz, получают входные данные, проверяя регистр флага нуля. Поскольку cmp и test устанавливают эти флаги, они обычно предшествуют условным переходам.

Инструкции вызова и возврата

Программы выполняют инструкции call, чтобы вызвать функцию Windows API или перейти к целевой функции в коде. Во втором случае call во многом действует как инструкция безусловного перехода. Перед переходом по новому адресу инструкция call помещает в стек текущий адрес, хранящийся в EIP или RIP. Позднее программа может выполнить инструкцию возврата ret, чтобы вернуться к предыдущему месту в коде. Эти инструкции описаны в таблице 3-8.

Таблица 3-8. Инструкции вызова и возврата

Инструкции без операции

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

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

Теперь, рассмотрев основы ассемблерного кода, обратимся к исследованию вредоносного кода посредством статического анализа.

Статический анализ кода

Статический анализ кода - метод исследования кода в статическом состоянии, то есть не во время выполнения, обычно с помощью средства, называемого дизассемблером. Дизассемблер позволяет перемещаться по коду вредоносной программы, выявлять интересующие функции или блоки кода и глубже изучать эти области. Умение эффективно пользоваться дизассемблерами часто отличает начинающих аналитиков вредоносных программ от специалистов среднего и высокого уровня. Допустим, у вас есть неизвестный исполняемый файл, который проявляет в автоматизированных песочницах и VM лишь несколько моделей поведения или даже вообще не работает должным образом. Возможно, он применяет методы обнаружения VM и обхода песочницы. Начинающий аналитик на этом этапе может сдаться. Опытный же специалист, вероятно, загрузит образец в дизассемблер, чтобы определить, на чём сосредоточить дальнейшее расследование.

Как работает дизассемблирование

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

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

Рекурсивное дизассемблирование, или дизассемблирование с учётом потока. Как и линейные дизассемблеры, рекурсивные начинают разбирать код байт за байтом, но приостанавливаются, встретив последовательность управления потоком, например конструкцию if...then или цикл. Дизассемблер следует логике кода и даже может имитировать выполнение условных ветвей подобно тому, как выполнялась бы реально запущенная программа. Этот метод, применяемый такими дизассемблерами, как IDA и Ghidra, создаёт лучшее представление дизассемблированного кода, но работает гораздо медленнее линейного дизассемблирования и всё равно может быть подвержен определённым ошибкам.

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

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

Выбор дизассемблера

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

IDA (hex-rays.com) всегда была одним из самых популярных интерактивных дизассемблеров, и на то есть веские причины. Она способна дизассемблировать файлы множества типов, поддерживает много различных процессорных архитектур и операционных систем и располагает множеством плагинов и сценариев, созданных Hex Rays и сообществом. IDA выпускается в нескольких вариантах, в том числе в бесплатной версии, которой достаточно для многих сценариев обратной разработки.

Ghidra, с другой стороны, является полностью бесплатным интерактивным дизассемблером с открытым исходным кодом. Он реализует многие возможности IDA и некоторые дополнительные, например совместное дизассемблирование, позволяющее нескольким людям работать с одним файлом. Ghidra новее, и на момент написания книги для неё доступно не так много плагинов и сценариев расширения, как для IDA. Однако со временем они появятся. Подобранный список полезных плагинов и сценариев IDA и Ghidra находится по адресу github.com.

У лагерей IDA и Ghidra есть множество сторонников, но в конечном счёте выбор не так уж важен. Освоив понятия ассемблера, вы сможете решить задачу любым из этих средств. В этой главе и на протяжении большей части книги я буду использовать IDA.

Анализ с помощью IDA

Последовательно разберём основной процесс статического анализа кода с помощью IDA.

Примечание. В этом разделе мы будем исследовать в IDA вредоносный файл, который можно скачать с VirusTotal или MalShare по следующему хешу:

SHA256: 30c9a1460615254a4ef791ffeeba53f4a31361c2646b25d3909025178c5a3976

Чтобы открыть подозрительный файл в IDA, выберите File > Open, примите параметры по умолчанию и нажмите OK; см. рисунок 3-4. После этого IDA автоматически проанализирует файл.

Рисунок 3-4. Загрузка нового файла в IDA

Интерфейс IDA содержит несколько вкладок, некоторые из которых представляют элементы файла, которые может потребоваться исследовать; см. рисунок 3-5.

Рисунок 3-5. Интерфейс IDA

На вкладке Imports можно увидеть несколько интересных функций, в том числе функции библиотеки WinHttp; см. рисунок 3-6. Они указывают, что в какой-то момент вредоносная программа может попытаться связаться с сервером в Интернете.

Рисунок 3-6. Список функций на вкладке Imports в IDA

Функция InternetOpenUrlW может использоваться вредоносной программой для подключения к вредоносному серверу в Интернете. Чтобы исследовать вызов этой функции в программе, просто дважды щёлкните её в представлении Imports, а затем нажмите CTRL-X для просмотра перекрёстных ссылок; см. рисунок 3-7. Перекрёстные ссылки - это адреса в коде программы, содержащие выбранный элемент.

Рисунок 3-7. Перекрёстные ссылки на InternetOpenUrlW

Выберите перекрёстную ссылку и нажмите OK, чтобы перейти к месту в коде, где программа вызывает InternetOpenUrlW, как показано на рисунке 3-8.

Рисунок 3-8. Место вызова функции InternetOpenUrlW в коде

Мы пытаемся определить, какой URL открывает вредоносная программа, однако, к сожалению, в этом коде видно немногое, поскольку входные параметры неясны. Видно несколько инструкций push, сохраняющих параметры в стеке, и один из этих параметров - lpszUrl, целевой URL. Если бы мы запустили программу, этот параметр находился бы в стеке по адресу [ebp+lpszUrl]. Но поскольку мы рассматриваем код только статически, параметров в стеке для исследования нет, что усложняет задачу.

Можно было бы проследить код в обратном направлении, пытаясь определить, что в конечном счёте программа помещает в стек как параметр функции InternetOpenUrlW. Иногда это полезно, но хитро устроенная вредоносная программа часто обфусцирует такие данные. Альтернативный способ - загрузить вредоносную программу в отладчик и динамически исследовать стек. Вскоре мы увидим, как это делается. Но сначала обсудим ещё одно полезное средство статического анализа кода.

Анализ с помощью CAPA

CAPA (github.com) - средство с открытым исходным кодом, написанное исследователями Mandiant. Хотя это не полноценный дизассемблер вроде IDA Pro, оно помогает аналитикам быстро понять возможные модели поведения образца вредоносной программы и выявить области кода, заслуживающие дальнейшего исследования. CAPA сканирует PE-файл в поисках таких шаблонов, как строки и определённые ассемблерные инструкции. Такое сканирование извлекает огромное количество сведений и помогает направлять процесс обратной разработки. Чтобы запустить CAPA для целевого исполняемого файла, выполните следующую команду:

Параметр -vv предписывает CAPA предоставить особенно подробные сведения. Обратите внимание, что -vvv возвращает ещё больше сведений, а -v - меньше. На рисунке 3-9 показан пример вывода CAPA.

Рисунок 3-9. Вывод CAPA

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

В подробном режиме CAPA показывает даже адрес, по которому подозрительная функция находится в исполняемом файле. На рисунке 3-10 представлены выявленные CAPA инструкции возможного противодействия VM.

Рисунок 3-10. Возможные инструкции противодействия VM, выявленные CAPA

Конкретная инструкция противодействия VM на рисунке 3-10 - cpuid, ассемблерная инструкция, которую вредоносные программы часто используют для обнаружения среды VM. CAPA нашла адреса в исполняемом файле, по которым вызывается cpuid: 0x140002157, 0x14000217E и 0x140002203. Теперь образец можно загрузить в такой дизассемблер, как IDA Pro, и перейти по этим адресам в исполняемом файле, чтобы быстро найти инструкции cpuid.

На рисунке 3-11 приведён другой пример, в котором CAPA выявила адреса предположительно вредоносного кода.

Рисунок 3-11. Вывод CAPA, показывающий возможное внедрение в процесс

В этом случае CAPA выявила возможный метод внедрения в процесс - внедрение APC, посредством которого вредоносная программа обходит узловые средства защиты и скрытно выполняет вредоносный код.

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

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

Динамический анализ кода

Динамический анализ заключается в исследовании активно выполняющегося кода, что обычно означает его запуск в отладчике. Отладчики похожи на дизассемблеры: они также дизассемблируют код и представляют его пользователю, но обладают дополнительным преимуществом - возможностью динамически выполнять этот код.

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

Выбор отладчика

x64dbg (x64dbg.com) - мощный бесплатный отладчик с открытым исходным кодом для сред Windows. Он обладает широкими возможностями настройки и поддержки сценариев, а сообщество поддерживает множество полезных плагинов. На протяжении книги я буду уделять основное внимание именно x64dbg, но многие отладчики действуют, выглядят и ощущаются очень похоже. Среди альтернатив x64dbg - гораздо более старый OllyDbg, встроенный отладчик IDA Pro и WinDbg.

Примечание. Формально существует две версии x64dbg: x32dbg для отладки 32-разрядных программ и x64dbg для 64-разрядных. Они работают совершенно одинаково, но предназначены для разных архитектур. Как и создатель отладчика, я буду называть программу x64dbg, однако помните: для отладки 32-разрядной программы x86 необходимо использовать версию x32dbg.

Начало сеанса отладки в x64dbg

Чтобы загрузить исполняемый файл в x64dbg, выберите подходящую версию программы, 32- или 64-разрядную, а затем File > Open. Если использовать неверную версию, в нижней части окна отладчика появится полезное сообщение вроде Use x32dbg to debug this file!. Другой вариант - подключить отладчик к уже работающему процессу вредоносной программы, выбрав File > Attach. Недостаток такого подхода в том, что вы можете пропустить критически важные модели поведения, проявившиеся до того, как удалось подключиться к процессу и начать его отладку.

После загрузки программы в отладчик она работает как дочерний процесс отладчика. В большинстве случаев отладчик вызывает функцию DebugActiveProcess, позволяющую подключиться к активному процессу и начать сеанс отладки. Мы вернёмся к этому вызову API в главе 10. А пока рассмотрим наиболее важные области пользовательского интерфейса x64dbg, показанного на рисунке 3-12.

Рисунок 3-12. Отладчик x64dbg

Вкладка CPU

В панели CPU в левой верхней части окна x64dbg в последовательном порядке перечислены инструкции, которые вредоносная программа выполнит или уже выполнила. Здесь можно проходить код строка за строкой либо переходить к более интересным частям. EIP, а для программ x64 - RIP, отмечает инструкцию, которая будет выполнена следующей, как показано на рисунке 3-13.

Рисунок 3-13. Вкладка CPU в x64dbg

Панель регистров CPU

В правой верхней части окна x64dbg находится панель CPU Registers; см. рисунок 3-14. На ней отображаются каждый регистр и флаг и хранящееся в нём текущее значение. Это помогает отслеживать данные и адреса, хранящиеся в регистрах.

Рисунок 3-14. Панель CPU Registers в x64dbg

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

Панель аргументов

Панель Arguments, показанная на рисунке 3-15, находится в средней правой части окна x64dbg.

Рисунок 3-15. Панель Arguments в x64dbg

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

Панель стека

В правой нижней части окна x64dbg находится панель Stack. На ней отображается память стека выполняющегося в данный момент потока; см. рисунок 3-16.

Рисунок 3-16. Панель Stack в x64dbg

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

Панель дампа

В левой нижней части находится панель Dump, показанная на рисунке 3-17.

Рисунок 3-17. Панель Dump в x64dbg

Это представление позволяет динамически исследовать и отслеживать адреса памяти, или дампы. Можно также устанавливать наблюдения, чтобы x64dbg уведомляла о возникновении определённого события, например об изменении конкретного регистра.

Вкладка карты памяти

Наконец, вкладка Memory Map доступна в ряду вкладок в верхней части окна x64dbg. Она очень полезна при динамическом анализе кода, поскольку отображает структуру виртуальной памяти программы и позволяет глубже исследовать каждую область памяти; см. рисунок 3-18.

Рисунок 3-18. Вкладка Memory Map в x64dbg

Одно из важнейших применений панели Memory Map - поиск исполняемого кода в памяти во время распаковки вредоносной программы. Подробнее это и память в целом рассматриваются в главе 17.

Анализ с помощью x64dbg

Далее мы рассмотрим типичный сценарий отладки образца вредоносной программы, чтобы получить общее представление о динамическом анализе кода внутри отладчика. Мы будем анализировать тот же файл, что использовался в разделе «Анализ с помощью IDA» на странице 53.

Отключение ASLR

Как объяснялось в главе 1, рандомизация размещения адресного пространства загружает исполняемый файл вредоносной программы и библиотеки в случайно выбранные области памяти. Хотя это эффективный способ противодействия злоумышленникам, он также мешает динамическому анализу кода, поэтому ASLR следует отключить. Для этого файла есть несколько способов отключения ASLR, но можно воспользоваться CFF Explorer (ntcore.com), поскольку она позволяет сделать это быстро и легко. Просто загрузите образец вредоносной программы в CFF Explorer, выберите категорию Optional Header в левом меню и щёлкните поле DllCharacteristics; см. рисунок 3-19.

Рисунок 3-19. Настройка характеристик DLL файла в CFF Explorer

Возможно, вы узнали необязательный заголовок из главы 1. Одно из его полей, DllCharacteristics, содержит несколько атрибутов исполняемого файла.

Затем в появившемся меню снимите флажок DLL Can Move, как показано на рисунке 3-20.

Рисунок 3-20. Отключение ASLR в CFF Explorer

Наконец, нажмите OK и сохраните изменённый файл командой File > Save.

Выполнение кода

Теперь загрузите файл в x64dbg - точнее, в x32dbg, поскольку это 32-разрядный файл, - выбрав File > Open. После этого в меню Debug появится несколько команд для выполнения и отладки программы; см. рисунок 3-21.

Рисунок 3-21. Меню Debug в x64dbg

Рассмотрим команды по порядку.

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

Run Until Selection. Выполняет программу до достижения вручную выбранного адреса в коде.

Step Into. Позволяет войти в функцию, которая должна быть выполнена, чтобы вручную отладить и исследовать её. Эту операцию обычно называют просто шагом; она будет часто обсуждаться в книге. Сочетание клавиш - F7.

Step Over. Позволяет выполнить функцию с обходом, полностью пропустив её выполнение. Это хороший способ сэкономить время и пропустить неинтересный для анализа код.

Execute Till Return. Выполняет программу до следующей инструкции возврата ret.

Run to User Code. Выполняет программу и останавливается на пользовательском коде. Это одна из самых полезных команд отладки, как мы вскоре увидим.

В меню Advanced есть дополнительные команды отладки. Например, Run (Swallow Exceptions) заставляет отладчик, по сути, игнорировать исключения. Поскольку большое количество исключений может создавать проблемы, а вредоносная программа способна даже намеренно порождать их, чтобы досадить вам, эта команда может избавить от лишних затруднений.

После загрузки файла в отладчик должны завершиться задачи инициализации, например загрузка необходимых библиотек и другие операции ОС Windows. Они нам неинтересны: вместо этого мы хотим перейти к точке входа вредоносного файла, то есть части кода для анализа. Выберите Debug > Run to User Code; см. рисунок 3-22.

Рисунок 3-22. Точка входа Run to User Code

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

Использование программных точек останова

Программные точки останова устанавливаются вставкой особых инструкций CPU, например INT 3 - в шестнадцатеричной форме 0xCC, наиболее распространённой инструкции точки останова, - или INT 2D, в шестнадцатеричной форме 0xCD 0x2D. Помните, что программная точка непосредственно изменяет код выполняющейся программы. Большинство обычных программ это не беспокоит. Однако некоторые вредоносные программы не хотят, чтобы их отлаживали, и пытаются обнаруживать и обходить точки останова.

Чтобы перейти к области кода, выполняющей InternetOpenUrlW, установите точку останова на вызове этой функции. Самый эффективный способ - ввести в строке Command внизу окна x64dbg следующую инструкцию:

См. рисунок 3-23.

Рисунок 3-23. Установка точки останова на вызове функции

Затем выполните образец командой Debug > Run или клавишей F9. Вредоносная программа будет выполняться и остановится на функции InternetOpenUrlW, как показано на рисунке 3-24.

Рисунок 3-24. Точка останова сработала!

Исследовав параметры в панели Arguments, вы увидите в стеке полный URL; см. рисунок 3-25.

Рисунок 3-25. URL в стеке

Интернет-службу iplogger.org можно использовать для регистрации и отслеживания IP-адресов. Вероятно, вредоносная программа применяет её для отслеживания заражённых этим образцом узлов или получения IP-адреса жертвы.

Программные точки останова можно устанавливать на любом адресе, а не только на вызовах функций. Щёлкните нужный адрес на панели CPU правой кнопкой мыши и выберите Breakpoint > Toggle либо нажмите F2. Когда CPU соберётся выполнить инструкции по этому адресу, отладчик приостановится.

Установка аппаратных точек останова и точек останова памяти

Вместо программных точек можно устанавливать аппаратные, реализуемые самим CPU, или точки памяти, реализуемые посредством защиты памяти. Аппаратные точки задаются и хранятся в регистрах CPU DR0, DR1, DR2 и DR3. Их преимущество в том, что они не изменяют код напрямую, поэтому менее инвазивны и несколько труднее обнаруживаются вредоносной программой. Главный недостаток: из-за ограниченного количества регистров DR одновременно можно установить лишь четыре.

Точки останова памяти изменяют атрибуты защиты страницы, вызывая исключение при обращении к ней. Обычно изменяется атрибут PAGE_GUARD. Такие точки особенно полезны для наблюдения за адресами в памяти. Например, если во время выполнения вы обнаружили интересную строку вроде URL или имени файла, точка на адресе строки поможет определить, где и как программа её использует. Недостаток состоит в том, что изменение защиты страниц может мешать работе программы и вызвать сбой при попытке выделить новые страницы или изменить существующие. После срабатывания защита страницы возвращается к состоянию до установки точки. Поэтому, если образец изменит защиту до или после срабатывания, вы можете отменить внесённые им изменения либо он случайно или намеренно отменит вашу точку. Всегда соблюдайте осторожность. Поскольку аппаратные точки и точки памяти часто объединяют, далее термин «аппаратная точка останова» будет обозначать обе разновидности.

Установить аппаратную точку можно несколькими способами.

• На адресе в панели CPU щёлкните правой кнопкой мыши и выберите Breakpoint > Set Hardware on Execution.

• В панели Dump выберите один байт, щёлкните правой кнопкой мыши и наведите указатель на Breakpoint, чтобы выбрать вариант.

• На вкладке Memory Map выделите область памяти, щёлкните правой кнопкой мыши, выберите Memory Breakpoint, а затем нужный вариант.

В таблице 3-9 перечислены виды аппаратных точек и точек памяти.

Таблица 3-9. Виды аппаратных точек останова в x64dbg

Аппаратную точку можно установить на байт, слово или двойное слово. Точка на байте вызовет исключение при обращении именно к нему; для слова и двойного слова исключение сработает при обращении ко всему слову, то есть 2 байтам, или двойному слову, то есть 4 байтам. Точки работают в режимах singleshoot и restore. Точка singleshoot после срабатывания удаляется и больше не срабатывает. Точка restore восстанавливается, становясь постоянной и срабатывая при повторном обращении к адресу.

При анализе вредоносных программ аппаратные точки чаще всего применяются для противодействия методам обнаружения отладчиков и точек останова, а также при ручной распаковке. Такое применение будет рассмотрено в главах 10 и 17.

Исправление и изменение кода

Исправление означает изменение или удаление инструкций программы. В x64dbg щёлкните правой кнопкой мыши адрес изменяемого кода и выберите Binary, как показано на рисунке 3-26.

Рисунок 3-26. Редактирование и исправление кода в x64dbg

Команда Edit позволяет изменить код по этому адресу. Fill with NOPs - удобный способ быстро очистить код: она заполняет адрес памяти инструкциями nop, фактически приказывая программе пропустить данный участок. Например, чтобы удалить из текущего образца вызов InternetOpenUrlW, выделите строку с инструкцией call InternetOpenUrlW и заполните её инструкциями NOP.

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

Трассировка вызовов API с помощью API Monitor

API Monitor (rohitab.com) - прекрасное средство отладки, которым стоит дополнить набор инструментов: оно позволяет трассировать и отслеживать вызовы функций API вредоносной программой. Кроме того, в нём можно устанавливать точки останова на определённых функциях, поэтому оно также действует как простой отладчик.

В окне API Filter в левой верхней части API Monitor можно выбрать API и функции для трассировки, как показано на рисунке 3-27.

Рисунок 3-27. Меню API Filter в API Monitor

Здесь я выбрал все связанные с Интернетом и сетью функции библиотеки Wininet.dll.

Чтобы наблюдать за новым процессом, нажмите Monitor New Process в средней части окна API Monitor, а затем выберите исполняемый файл вредоносной программы. Параметры по умолчанию вполне подходят, поэтому нажмите OK; см. рисунок 3-28.

Рисунок 3-28. Наблюдение за новым процессом в API Monitor

После запуска и нескольких минут работы вредоносной программы окно Summary начнёт заполняться вызовами API, как видно на рисунке 3-29.

Рисунок 3-29. Список вызовов API в API Monitor

Некоторые вызовы могут быть знакомы по предыдущему анализу в x64dbg. Сила API Monitor состоит в том, что она позволяет быстро увидеть интересующие вызовы функций, а также их аргументы и возвращаемые значения. Это чрезвычайно полезно для быстрой оценки возможностей образца либо наблюдения и трассировки подозрительного поведения.

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

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

Итоги

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

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

Обычная, «настоящая» пользовательская среда сильно отличается от песочницы или лаборатории анализа вредоносных программ. У типичного пользователя, скорее всего, установлены распространённые приложения: Microsoft Office, почтовые клиенты, несколько веб-браузеров и так далее. Вероятно, он не использует VM, Wireshark или Procmon и вряд ли установил такие средства анализа вредоносных программ, как IDA Pro, или песочницы вроде Cuckoo. В песочнице или лабораторной среде, напротив, аналитическое программное обеспечение обычно установлено в VM.

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

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

Процессы

Методы перечисления процессов позволяют вредоносной программе обнаруживать VM и песочницы и лучше понимать среду выполнения. Основные функции Windows API, которые она может применять для перечисления процессов, - CreateToolhelp32Snapshot, Process32First и Process32Next. Следующий фрагмент образца перечисляет работающие на узле процессы в поисках целевого процесса VboxTray.exe, распространённого в некоторых VM VirtualBox:

Функция CreateToolhelp32Snapshot создаёт снимок процессов, работающих на узле жертвы, и возвращает его дескриптор 1. Этот дескриптор помещается в стек вместе с указателем на буфер peInfo, где будет храниться вывод функции Process32First 2. Process32First выдаёт сведения о первом работающем на узле процессе в peInfo.szExeFile. После вызова Process32First вредоносная программа сравнивает peInfo.szExeFile с переменной vboxtray_process_name, ранее определённой как VboxTray.exe 3. Присваивание переменной в фрагменте кода не показано. Если имена процессов не совпадают, программа переходит к следующей области кода.

Указатель на буфер и дескриптор снимка процессов снова помещаются в стек при подготовке к следующей функции - Process32Next 4. Она делает то же, что Process32First, но перебирает остальные работающие в системе процессы. После перечисления следующего процесса и сохранения в буфере вредоносная программа снова сравнивает его с vboxtray_process_name. На этот раз, если имена не совпадают, код циклически возвращается к выполнению Process32Next и повторяет действия, пока не перечислит все процессы или не найдёт целевой 5.

Если при анализе вы заметили, что вредоносная программа перечисляет процессы и проверяет конкретное имя вроде VboxTray.exe или Vmtoolsd.exe, это должно вызвать подозрение. Ниже приведены распространённые имена процессов, связанных с VM, которые может искать вредоносная программа.

VMware

• TPAutoConnSvc.exe

• VGAuthService.exe

• VMwareService.exe

• Vm3dservice.exe

• Vmtoolsd.exe

• Vmwaretray.exe

• Vmwareuser.exe

VirtualBox

• VboxControl.exe

• VBoxService.exe

• VboxTray.exe

Некоторые варианты вредоносных программ также ищут типичные средства анализа, например Procmon, Wireshark, Process Explorer и Fiddler, которые могут работать на станции аналитика во время запуска образца. Обнаружив в системе любой из следующих процессов, вредоносная программа может завершиться или предпринять другие действия уклонения:

• autoruns.exe

• fiddler.exe

• ollydbg.exe

• procexp.exe

• procmon.exe

• tcpview.exe

• wireshark.exe

• x64dbg.exe

Часто перед запуском процесса можно просто переименовать исполняемый файл средства. Например, замена имени procmon.exe на nomcorp.exe способна обойти простейшие проверки вредоносной программы. Однако этот приём не сработает, если она проверяет заголовок окна.

Перечисляя процессы и ища определённые имена, некоторые вредоносные программы вместо открытых строк используют хешированные имена, чтобы цель не была очевидна аналитику. Например, сумма MD5 имени процесса fiddler.exe равна 447c259d51c2d1cd320e71e6390b8495. Поэтому при отладке определённого образца или исследовании в дизассемблере вместо fiddler.exe можно увидеть строку 447c259d51c2d1cd320e71e6390b8495. Нетрудно понять, как это замедлит анализ и, возможно, поставит в тупик неопытного аналитика.

Такое хеширование будет подробнее рассмотрено в главе 16. Пока просто помните, что при анализе образца вы можете не увидеть удобных имён процессов открытым текстом; всегда учитывайте возможность хеширования. Это относится не только к процессам, но и к именам файлов, службам и другим строкам, которые может искать вредоносная программа.

Каталоги и файлы

Перечисление каталогов и файлов - ещё один метод обнаружения песочниц и VM. Вредоносная программа может искать определённые файлы и каталоги, связанные с программным обеспечением гипервизора, например VMware Workstation и VirtualBox, или с автоматизированными песочницами, например Cuckoo.

В следующем фрагменте образец вызывает FindFirstFile с целевым путём C:\Windows\System32\drivers\vm*. Он ищет в каталоге драйверов Windows файлы драйверов с префиксом vm, характерным для файлов драйверов VMware Workstation:

После вызова FindFirstFile инструкция test сравнивает возвращённое имя файла с C:\Windows\System32\drivers\vm*. Если результат test равен 0, то есть совпадения нет, код переходит к loc_2, где находится следующий вызов - FindNextFile. Выполняется FindNextFile, и та же инструкция test сравнивает имена файлов. Если она возвращает 0, программа снова переходит к loc_2. FindNextFile продолжит выполняться до совпадения или исчерпания файлов.

Хотя вредоносные программы очень часто перечисляют файлы по множеству причин, наличие FindFirstFile и FindNextFile может означать попытку обнаружить среду анализа. Ниже приведены пути к файлам и каталогам VMware Workstation и VirtualBox, на которые может нацеливаться вредоносная программа.

Файлы VMware

• C:\Windows\System32\drivers\vm*

• C:\Windows\System32\vm*

• C:\Windows\SysWOW64\vm*

Каталоги VMware

• C:\Program Files\VMware\

• C:\Program Files\Common Files\VMware\

Файлы VirtualBox

• C:\Windows\System32\VBox*

• C:\Windows\System32\drivers\VBox*

Каталоги VirtualBox

• C:\Program Files\Oracle\VirtualBox Guest Additions\

Подобно VM, автоматизированные песочницы часто содержат особые папки и файлы, которые вредоносная программа может счесть подозрительными. Например, во многих установках Cuckoo есть сценарии и файлы Analyzer.py и analysis.conf. В некоторых версиях Cuckoo по пути C:\ может находиться даже каталог cuckoo или agent. Помните об этом при анализе уклоняющейся вредоносной программы в автоматизированной песочнице.

Наконец, перечисление каталогов и файлов может использоваться для определения среды выполнения и профилирования цели. Например, образец, нацеленный на определённую организацию или тип системы, способен перечислять файловую систему в поисках каталогов и файлов с названием целевой компании. Такая проверка позволит заражать только системы в области атаки. Хороший пример - упомянутый во введении Stuxnet. В рамках своих тактик эксплуатации Stuxnet ищет на узле жертвы несколько файлов, относящихся к Siemens Step7. Если файлов нет, система не заражается.

Примечание. Некоторые из этих файлов и каталогов можно переименовать или даже удалить, не нарушив среду VM. Подробнее это рассматривается в приложении A.

Общие папки

Для обмена файлами между VM и основной ОС аналитик может настроить общие папки. Они упрощают передачу файлов от основной системы гостевой и обратно, но одновременно дают вредоносной программе ещё одну подсказку, что её анализируют.

Вредоносная программа может перечислять общие папки с помощью функции Windows API WNetGetProviderName, получающей сведения о сетевых ресурсах. Поскольку общие папки VM фактически являются сетевыми ресурсами, вызов этой функции в настроенной на их использование VM VirtualBox может вернуть, например, VirtualBox Shared Folders, что однозначно выдаёт размещение машины на гипервизоре VirtualBox.

Кроме того, поскольку общие папки VM действуют как сетевые диски, их можно выявлять обычными функциями перечисления файлов и папок, например уже рассмотренными FindFirstFile и FindNextFile. Целевым путём для этих функций будет имя сетевого диска VM. Распространённые имена сетевых дисков - \\VboxSrv для VirtualBox и \\vmware-host для VMware Workstation.

Реестр

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

Вредоносная программа вызывает RegOpenKey, чтобы открыть определённый интересующий раздел, а затем RegEnumValue для перечисления всех его значений и данных. Разберём код подробнее.

Сначала программа перемещает значение lpSubKey, представляющее интересующий раздел реестра, в регистр rdx 1. Здесь это HKLM:\HARDWARE\Description\System. Значение rdx используется как параметр последующего вызова RegOpenKeyExA 2. Затем код загружает указатели на структуры lpData 3 и lpValueName 4. После этого вызывается RegEnumValueA 5, сохраняющая возвращённые значения и данные раздела HKLM:\HARDWARE\Description\System соответственно в lpValueName и lpData.

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

Наконец, программа сравнивает подозрительное значение VBOX -1 со значением в буфере lpdata 6. При совпадении она предполагает, что работает в VM VirtualBox, и завершается.

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

В примере функция Windows API RegOpenKey ищет в системе узла раздел HKCU\Software\NewCorp. Если раздел найден, вредоносная программа предполагает, что работает в системе организации NewCorp; в противном случае она завершается.

Реестр можно запрашивать и средствами командной строки Windows, например reg query:

Команда завершится успешно, если раздел существует в системе жертвы, и неудачно в противном случае.

Наконец, вредоносная программа может запрашивать реестр посредством инструментария управления Windows (WMI), PowerShell и других штатных средств Windows, которые рассматриваются в главе 15. Пока главное заключается в том, что существует множество способов запросить реестр. При этом и вредоносное, и обычное программное обеспечение обращается к нему по многим причинам; запрос не всегда означает применение метода профилирования или уклонения. Ниже перечислены разделы реестра, которые вредоносная программа может искать для выявления среды анализа VM.

VMware Workstation

• HKCU:\SOFTWARE\VMware, Inc.

• HKLM:\SOFTWARE\Classes\Applications\VMwareHostOpen.exe

• HKLM:\SOFTWARE\Classes\VMwareHostOpen.AssocFile

• HKLM:\SOFTWARE\Classes\VMwareHostOpen.AssocURL

• HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\VMware User Process

• HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\VMware VM3DService Process

• HKLM:\SOFTWARE\RegisteredApplications\VMware Host Open

• HKLM:\SOFTWARE\WOW6432Node\RegisteredApplications\VMware Host Open

• HKLM:\SYSTEM\CurrentControlSet\Enum\IDE\DiskVMware_Virtual_IDE_Hard_Drive___________00000001\

VirtualBox

• HKLM:\HARDWARE\ACPI\DSDT\VBOX__

• HKLM:\HARDWARE\ACPI\FADT\VBOX__

• HKLM:\HARDWARE\ACPI\RSDT\VBOX__

• HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\VBoxTray

• HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Oracle VM VirtualBox Guest Additions

• HKLM:\SOFTWARE\Oracle\VirtualBox Guest Additions

• HKLM:\SYSTEM\ControlSet001\services\VBoxMouse

• HKLM:\SYSTEM\ControlSet001\services\VBoxSF

• HKLM:\SYSTEM\ControlSet001\services\VBoxService

• HKLM:\SYSTEM\ControlSet001\services\VBoxVideo

• HKLM:\SYSTEM\ControlSet001\services\VBoxGuest

Общие

• HKLM:\HARDWARE\Description\System\BIOS\SystemManufacturer

• HKLM:\HARDWARE\Description\System\BIOS\SystemProductName

• HKLM:\HARDWARE\Description\System\SystemBiosVersion

• HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Store\Configuration\OEMID

• HKLM:\SYSTEM\CurrentControlSet\Control\Class\

Чтобы исследовать эти разделы и получить представление о том, что может искать вредоносная программа, на собственной аналитической VM можно воспользоваться инструментом Windows regedit.exe. Например, исследуя раздел реестра HKLM:\HARDWARE\Description\System на своей аналитической машине, я могу заметить определённые значения и данные, способные заинтересовать вредоносную программу (рис. 4-1).

Рис. 4-1. Описание оборудования в regedit.exe

Очевидные интересующие здесь элементы данных - строки VBOX -1 и Oracle VM VirtualBox. Ещё одна серьёзная подсказка - значение SystemBiosDate, равное 06/23/99, которое указывает на гипервизор VirtualBox. И вновь эти разделы реестра приведены лишь в качестве примеров. Они могут присутствовать или отсутствовать на ваших VM в зависимости от версии гипервизора, установленного программного обеспечения и других факторов.

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

Службы

Службы - это приложения, которые обычно запускаются при загрузке системы и работают в фоновом режиме пользовательского сеанса. Они представляют собой ещё один способ, с помощью которого вредоносная программа может попытаться выявить среду VM или песочницы. Некоторые службы уникальны для определённой марки гипервизора и тем самым выдают его присутствие; кроме того, отдельные службы способны указать на установленные инструменты анализа вредоносных программ. Например, вредоносная программа может искать службу VirtualBox Guest Additions Service, которая свидетельствует о наличии VirtualBox.

Вредоносная программа может запрашивать службы несколькими способами. Один из наиболее распространённых методов состоит в применении функции Windows API EnumServiceStatus или EnumServiceStatusEx, которая возвращает список служб узла и связанные с ними состояния, обычно "работает" или "остановлена". Кроме того, вредоносная программа может использовать функцию OpenService, чтобы открыть дескриптор определённой службы. Если дескриптор успешно получен, то есть служба существует, код возврата будет истинным.

Помимо функций Windows API, вредоносная программа может применять и другие способы перечисления служб. Например, с помощью инструмента командной строки Windows sc можно запросить список служб или определённую службу следующим образом:

Аналогичным образом вредоносная программа может запросить все службы узла посредством инструмента командной строки WMI wmic:

Наконец, поскольку некоторые сведения о службах хранятся в реестре, вредоносная программа может запросить в нём информацию о службах. Если вы видите, что вредоносная программа применяет функции API, связанные со службами, использует такие инструменты, как sc, либо запрашивает реестр в поисках определённых служб гипервизора, возможно, образец пытается обнаружить среду анализа.

Чтобы лучше понять и исследовать службы, работающие на ваших VM и в песочницах, можно воспользоваться штатным приложением Windows services.exe, которое выводит список настроенных в системе служб. На рис. 4-2 показана работающая служба VirtualBox Guest Additions Service, способная сообщить вредоносной программе, что та выполняется в среде VM.

Рис. 4-2. Вывод services.exe

В табл. 4-1 перечислены некоторые распространённые службы, создаваемые VMware и VirtualBox.

Таблица 4-1. Распространённые службы гипервизоров

Установленное программное обеспечение

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

Для поиска установленного ПО вредоносная программа может воспользоваться функцией Windows API, например MsiEnumProducts, либо исследовать раздел реестра HKLM\Software\Microsoft\Windows\Current Version\Uninstall, содержимое которого на моей машине для анализа вредоносных программ показано на рис. 4-3.

Рис. 4-3. Перечисление раздела реестра HKLM\Software\Microsoft\Windows\Current Version\Uninstall

Здесь видны несколько инструментов анализа, а также VirtualBox Guest Additions.

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

Мьютексы

Как объяснялось в главе 1, мьютекс - это объект, который помогает управлять доступом к ресурсам, выступая в некотором роде привратником. У некоторых песочниц и гипервизоров есть уникальные мьютексы, которые могут заинтересовать вредоносную программу. Например, VMware обычно использует мьютексы, имена которых начинаются с VMware, такие как VMwareGuestCopyPasteMutex.

Для поиска определённых значений мьютексов вредоносная программа может применять функцию Windows API CreateMutex или OpenMutex, как в следующем примере:

Вредоносная программа помещает в стек переменную mutex_name, содержащую мьютекс, который она хочет найти (VMwareGuestCopyPasteMutex). Кроме того, она помещает туда ещё два значения, необходимые функции OpenMutex, но не имеющие здесь значения. Затем программа вызывает OpenMutexA и с помощью инструкции test проверяет, успешно или неудачно завершилась эта функция. Если вызов прошёл успешно, в системе существует VMwareGuestCopyPasteMutex, а значит, система, вероятно, работает внутри гипервизора VMware.

Не забывайте, что не всякая деятельность, связанная с мьютексами, является вредоносной. Мьютексы - стандартные объекты Windows, сами по себе не вредоносные и не безвредные.

Если вы заметили, что вредоносная программа перечисляет мьютексы и пытается найти совершенно определённые строки, подобные только что приведённым примерам, возможно, она применяет этот метод обнаружения. Ниже перечислены некоторые мьютексы, способные выдать среду VM.

VMware Workstation

• VMToolsHookQueueLock

• VMwareGuestCopyPasteMutex

• VMwareGuestDnDDataMutex

VirtualBox

• VBoxService

• VBoxTray

Каналы

Канал - это объект Windows, обеспечивающий межпроцессное взаимодействие. Некоторые гипервизоры создают в гостевой ОС уникальные каналы, способные выдать вредоносной программе их присутствие. Для поиска определённых именованных каналов вредоносная программа может вызывать несколько различных функций, например CreateFile и CallNamedPipe.

Отличный способ проверить собственные VM на наличие таких каналов - воспользоваться инструментом Pipelist, входящим в комплект Windows Sysinternals Марка Руссиновича. На рис. 4-4 показан вывод команды pipelist на VM VMware Workstation. Если присмотреться, можно заметить канал vgauth-service, уникальный для VMware.

Рис. 4-4. Вывод команды pipelist на VM VMware Workstation

Ниже перечислены некоторые распространённые каналы, которые могут находиться на ваших VM.

VMware Workstation

• Vmmemctl

• vgauth-service

VirtualBox

• VBoxTray

• VBoxTrayIPC

• VBoxGuest

• VBoxVideo

• VBoxMouse

• VBoxMiniRdr

Устройства и драйверы

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

Вредоносная программа может перечислять объекты устройств и драйверов с помощью двух функций Windows: NtOpenDirectoryObject и NtQueryDirectoryObject. Следующий код показывает эти функции в действии:

Как видно, дескриптор каталога \Driver загружается в регистр rcx 1 с помощью инструкции lea, или загрузки эффективного адреса. Инструкция lea вычисляет адрес операнда и загружает его в целевой регистр. Далее следует вызов NtOpenDirectoryObject, открывающий \Driver для подготовки к последующему вызову функции NtQueryDirectoryObject 2. Затем NtQueryDirectoryObject 4 запрашивает объекты каталога \Driver и сохраняет список объектов в ранее указанном буфере 3. После этого вредоносная программа просматривает буфер в поисках определённых драйверов, часто используемых в VM. Устройства можно запрашивать тем же способом.

Чтобы лучше понять содержимое диспетчера объектов Windows, можно просмотреть его непосредственно на своих VM Windows с помощью инструмента WinObj из Sysinternals. На рис. 4-5 показаны некоторые связанные с VirtualBox драйверы, установленные на моей аналитической VM и отображённые в WinObj. Можете самостоятельно исследовать их в своей аналитической системе.

Рис. 4-5. Исследование драйверов с помощью WinObj

Ниже перечислены некоторые распространённые драйверы гипервизоров VMware Workstation и VirtualBox.

VMware Workstation

• vm3dmp

• vm3dmp-debug

• vm3dmp-stats

• vm3dmp-sloader

• vmci

• vmhgfs

• VMMemCtl

• vmmouse

• vmrawdsk

• vmusbmouse

• vsock

VirtualBox

• VBoxGuest

• VBoxMouse

• VBoxSF

• VBoxVideo

• VBoxWddm

А вот некоторые распространённые устройства.

VMware Workstation

• VMCIGuestDev

• VMCIHostDev

• vm3dmpDevice

• vmci

• vmmemctl

VirtualBox

• VBoxGuest

• VBoxMiniRdr

Имена пользователей и узлов

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

Некоторые вредоносные программы способны воспользоваться этим, перечисляя учётные записи пользователей и получая имя узла системы, а затем целенаправленно разыскивая типовые имена пользователей, например Administrator, User или John, либо имена узлов Cuckoo, Test, Desktop, Workstation или Lab. Часто проверяется и TequilaBoomBoom - имя узла, которое одно время использовала служба песочницы VirusTotal.

Примечание. Настраивайте VM и среды песочниц с нетиповыми именами пользователей и узлов. Старайтесь применять значения, которые использовал бы реальный конечный пользователь или корпоративная среда, либо выбирайте имена случайным образом.

Параметры языка и региона

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

• получить язык раскладки клавиатуры;

• перечислить языковые параметры самой системы, например язык интерфейса;

• получить региональные параметры узла.

Первый метод, пожалуй, наиболее распространён. Функция Windows GetKeyboardLayout возвращает активный язык клавиатуры узла, а GetKeyboardLayoutList - полный список всех языков клавиатуры, установленных на узле.

Получить языковые параметры узла можно несколькими функциями Windows. Например, GetUserDefaultUILanguage возвращает язык пользовательского интерфейса вошедшего в систему пользователя. GetSystemDefaultUILanguage возвращает язык системы, а точнее язык, на котором установлена ОС. Наконец, GetProcessPreferredUILanguages выводит языки, которые могут использовать выполняемые пользователем процессы. Вот сколько вариантов!

Региональные параметры узла отличаются от параметров языка клавиатуры и пользовательского интерфейса тем, что представляют собой набор связанных с языком настроек для определённой комбинации языка и страны. В региональные параметры могут входить, например, форматы отображения валюты и даты/времени, а также идентификатор языка. Функции Windows API GetSystemDefaultLCID и GetUserDefaultLCID возвращают региональные сведения, которые можно применять для профилирования узла или пользователя. У процессов и потоков также могут быть собственные региональные параметры, запрашиваемые вредоносной программой посредством функции GetThreadLocale.

В образце вредоносной программы вы, скорее всего, увидите вызов одной из упомянутых функций, например GetKeyboardLayout, а затем сравнение с несколькими значениями, представляющими идентификаторы языков Windows. Следующий псевдокод демонстрирует этот метод в действии:

Этот образец вызывает функцию GetKeyboardLayout и сравнивает результат со значением 0x419, которое является шестнадцатеричным идентификатором русского языка. Если используется данный идентификатор, вредоносная программа выполняет TerminateProcess.

В табл. 4-2 перечислены некоторые идентификаторы языков Windows.

Таблица 4-2. Распространённые идентификаторы языков

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

Сведения о версии операционной системы

Перед заражением машины жертвы вредоносной программе часто требуется определить, работает ли на ней определённая ОС. Например, Stuxnet заражал только компьютеры с Windows XP, поскольку его авторы знали, что на целевых объектах Windows XP применяется для управления программируемыми логическими контроллерами Siemens. Образец, способный работать только в определённой версии Windows, может попытаться распознать ОС до заражения узла, чтобы случайно не вызвать его сбой. Например, если вредоносная программа содержит код эксплойта, который работает только в конкретной подверсии Windows, такой как Windows 7 Service Pack 1, но вызывает нестабильность системы в Windows 7 Service Pack 2, ей может потребоваться сначала определить подверсию ОС жертвы, чтобы предотвратить непреднамеренный сбой, способный предупредить жертву о её присутствии.

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

Целевую ОС и её версию можно перечислить несколькими способами посредством Windows API. Эту задачу выполняет функция GetVersionEx вместе со своей близкой родственницей GetVersion, как показано ниже:

Функция GetVersionExA принимает буфер в качестве аргумента. После вызова GetVersionExA возвращённые сведения об ОС будут сохранены в этой области памяти. Инструкция lea загружает адрес буфера [ebp-0A0h] в регистр eax, после чего адрес буфера помещается в стек инструкцией push eax.

Далее образец должен определить размер данных, возвращаемых вызовом функции GetVersionExA. Эти данные будут храниться в структуре с именем VersionInformation. Образец задаёт размер структуры VersionInformation как 9C, что в шестнадцатеричном виде равно 156 байтам.

Наконец, образец вызывает GetVersionExA (call GetVersionExA), чтобы получить версию ОС, а позднее проверяет эти сведения, сравнивая dwMajorVersion со значением 4, представляющим очень старую версию Windows. Для масштаба: номер версии Windows XP равен 5! По существу, этот образец проверяет, насколько стара версия Windows на данном узле.

В табл. 4-3 приведена часть значений dwMajor и dwMinor для версий ОС.

Таблица 4-3. Версии ОС dwMajor и dbMinor

Итоги

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

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

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

Файлы cookie, кеш и история браузера

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

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

У каждого браузера есть стандартные расположения cookie, файлов кеша и истории просмотра, которые вредоносная программа может попытаться перечислить. Ниже приведены некоторые наиболее распространённые.

Chrome

• C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default

• C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\Cache

• C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\History

Firefox

• C:\Users\<user>\AppData\Local\Mozilla\Firefox\Profiles

• C:\Users\<user>\AppData\Roaming\Mozilla\Firefox\Profiles

Internet Explorer

• C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Cookies

• C:\Users\<user>\AppData\Local\Microsoft\Windows\Temporary Internet Files

• C:\Users\<user>\AppData\Local\Microsoft\Windows\WebCache

• C:\Users\<user>\AppData\Local\Microsoft\Internet Explorer\Recovery

Edge

• C:\Users\<user>\AppData\Local\Packages\<package name>\AC\MicrosoftEdge\User\

• C:\Users\<user>\AppData\Local\Packages\<package name>\AC\MicrosoftEdge\Cache\

Разумеется, этот список не исчерпывающий, а расположения могут меняться в зависимости от используемых версий ОС Windows и браузера.

Если вы заметили, что вредоносная программа перебирает эти файлы, возможно, вызывая такие функции Windows, как FindFirstFile и FindNextFile, она может пытаться обнаружить среду анализа. Кроме того, программа способна использовать FindFirstUrlCacheEntry и FindNextUrlCacheEntry, которые последовательно перечисляют записи кеша браузера. Однако эти API относятся только к кешам браузеров Microsoft. И вновь способ перечисления будет в значительной степени зависеть от используемого браузера и его версии.

В старых браузерах и их версиях для хранения cookie, кеша и истории обычно используется множество небольших файлов, а в современных - базы данных. Если cookie, кеш и история браузера хранятся в файлах баз данных, вредоносная программа может попытаться взаимодействовать с ними напрямую. Например, в исполняемом файле вредоносной программы или адресном пространстве памяти её процесса можно обнаружить статические строки, ссылающиеся на определённые каталоги браузера, такие как C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\History, а вслед за ними такой запрос к базе данных:

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

Последние файлы Office

Последние файлы Office - ещё один хороший способ определить, работает ли вредоносная программа в аналитической лаборатории. Реальный конечный пользователь, скорее всего, открывал множество файлов в приложениях Microsoft Office, и Windows ведёт их учёт. Например, при открытии документа в Word файл добавляется в список последних файлов Office.

Сведения о последних файлах Office находятся в разделе реестра HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\<Office_Version_Number>, в определённом подразделе с именем Excel, Word, Powerpoint и так далее. Дополнительная информация может храниться в каталоге файловой системы C:\Users\<user>\AppData\Roaming\Microsoft\Office\Recent. Если вы заметили, что вредоносная программа перечисляет этот раздел реестра или путь к папке с помощью любой из ранее упомянутых функций Windows для перечисления файлов и реестра, вполне возможно, она пытается найти последние документы Office и определить, используется ли узел жертвы "настоящим" конечным пользователем.

Пользовательские файлы и каталоги

У обычного пользователя, вероятно, имеется множество файлов в различных пользовательских каталогах системы: Documents, Pictures, Desktop и других. С помощью методов перечисления файлов, описанных в главе 4, вредоносная программа может перебрать эти каталоги, чтобы определить, принадлежит ли узел реальному пользователю. Обнаружив отсутствие пользовательской активности в данных каталогах, программа может заключить, что выполняется в песочнице или среде анализа, и предпринять действия по уклонению.

Фоновый рисунок рабочего стола

Один особенно изобретательный способ обнаружения аналитических машин состоит в проверке текущего фонового рисунка: настоящие пользователи склонны заменять стандартный фон Windows. Для этого вредоносная программа может просто проверить значение реестра Wallpaper по адресу HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Desktop\General\WallpaperSource. Если пользователь всё ещё применяет стандартный фоновый рисунок Windows, значение WallpaperSource будет содержать путь к нему, находящийся где-то в каталоге C:\Windows\. Если же пользователь установил собственный фон рабочего стола, WallpaperSource, скорее всего, будет содержать пользовательский каталог и имя изображения, например C:\Users\<user>\Pictures\my_wallpaper.jpg.

Окна рабочего стола

Некоторые варианты вредоносных программ подсчитывают активные окна рабочего стола или ищут определённые окна. Они могут воспользоваться функцией GetForegroundWindow, чтобы проверить, меняется ли окно переднего плана, то есть активное в данный момент. Поскольку я набираю этот текст в LibreOffice, сейчас именно эта программа является моим активным окном переднего плана. У настоящего пользователя активное окно, скорее всего, будет меняться довольно часто. Например, я могу свернуть LibreOffice, отдохнуть от письма и посмотреть в Chrome ролики с кошками на YouTube. В среде автоматизированной песочницы для анализа вредоносных программ активное окно, вероятно, почти не меняется. Некоторые варианты вредоносных программ знают об этом и могут использовать данное свойство для обнаружения системы анализа. В следующем примере программа проверяет, изменилось ли окно переднего плана через пять секунд:

Сначала вредоносная программа вызывает GetForegroundWindow, которая возвращает дескриптор текущего окна переднего плана и сохраняет его в буфере по адресу [ebx+WindowHandle]. Затем программа вызывает функцию Sleep, приостанавливающую образец на пять секунд. После этого она во второй раз вызывает GetForegroundWindow и сравнивает значения дескрипторов, полученные двумя вызовами, с помощью cmp dword ptr ds:[ebx+WindowHandle], eax. Если дескрипторы совпадают, то есть окно переднего плана не изменилось, процедура вновь выполняет цикл. Образец может продолжать цикл бесконечно, потенциально полностью избегая анализа в автоматизированной песочнице, либо выполнить несколько итераций, а затем завершиться. Оба сценария создают интересную проблему для песочницы анализа вредоносных программ. К счастью, многие современные песочницы имитируют действия пользователя, чтобы сорвать этот метод. Некоторые даже способны работать в интерактивном режиме, позволяющем непосредственно взаимодействовать с вредоносной программой внутри песочницы, что также помогает обходить подобную тактику.

В качестве альтернативы образец может использовать функцию EnumWindows, которая возвращает количество открытых окон на рабочем столе пользователя. Windows создаёт множество объектов окон по разным причинам, поэтому в обычной пользовательской среде это число будет довольно большим. Например, когда я выполнил EnumWindows в своей личной системе, она вернула значение 97 окон! В среде анализа песочницы оно, скорее всего, окажется существенно меньше. Следующий фрагмент кода демонстрирует применение функции EnumWindows:

EnumWindows принимает параметр, который, по существу, служит указателем на буфер для хранения результата вызова функции (push ebx). После вызова EnumWindows инструкция pop eax извлекает указатель из буфера ebx со стека в eax. Вредоносная программа сравнивает значение EnumWindows, теперь хранящееся в eax, с 20, и, если количество открытых окон меньше этого значения или равно ему, образец завершает работу. Здесь предполагается, что в песочнице анализа вредоносных программ одновременно будет активно не более 20 окон.

Помимо перечисления количества активных окон в системе жертвы или определения того, меняется ли окно переднего плана, вредоносная программа может активно искать окно определённого приложения. Это полезно по двум причинам. Во-первых, образец может искать открытые окна с приложениями, которыми обычно пользуются конечные пользователи: продуктами Microsoft Office, почтовыми программами, браузерами и так далее. Если открыто достаточно таких приложений, программа может обоснованно предположить, что выполняется не в лаборатории аналитика. Во-вторых, образец способен искать определённые инструменты анализа вредоносных программ, подобно тому, что описано в разделе "Процессы" главы 4. Например, он может искать открытые окна, содержащие строки Procmon, Fiddler или Wireshark, обычно вызывая функцию EnumWindows или FindWindow. Как и при поиске определённого процесса, он перебирает открытые окна и сравнивает заголовок каждого со строкой, а результат может подсказать ему, что проводится анализ.

Взаимодействие с мышью и клавиатурой

Обычные конечные пользователи почти всегда перемещают указатель по экрану с помощью мыши, независимо от того, просматривают ли они интернет, редактируют документ или играют в видеоигру. Некоторые вредоносные программы способны обнаруживать эту активность посредством GetCursorPos, которая возвращает координаты указателя мыши пользователя. Следующий псевдокод показывает, как это может выглядеть на практике:

Сначала вредоносная программа вызывает функцию GetCursorPos и сохраняет полученные координаты указателя мыши в буфере CursorPos1. Затем она вызывает функцию Sleep, которая приостанавливает её выполнение на 30 секунд, после чего вновь вызывает GetCursorPos. Наконец, программа сравнивает два полученных значения координат указателя и, если они совпадают, то есть указатель не двигался, завершает работу. Вероятно, вы понимаете, почему это эффективный способ уклонения от автоматизированных песочниц: указатель вряд ли будет двигаться сам по себе, если, конечно, песочница не спроектирована для имитации настоящего пользователя.

Ещё один похожий метод состоит в том, что перед выполнением вредоносного кода программа ожидает нажатия определённых кнопок мыши или заданного количества щелчков. В 2012 году FireEye опубликовала исследовательскую статью "Hot Knives Through Butter: Evading File-based Sandboxes" об использовании этого метода семейством вредоносных программ Upclicker. Для наблюдения за действиями мыши Upclicker устанавливал её перехватчик, благодаря чему вредоносная программа могла перехватывать и отслеживать всю активность мыши и ожидать определённых событий. Вот как это может выглядеть в коде:

Сначала образец помещает в стек параметр jump_location: по этому адресу программа перейдёт при наступлении определённого события мыши. Другой параметр, 0E в шестнадцатеричном виде, или 14 в десятичном, указывает SetWindowsHookExA перехватывать действия мыши. Вызов SetWindowsHookExA предписывает программе перейти к коду по адресу jump_location, когда пользователь-жертва нажмёт кнопку мыши.

Для краткости этот код упрощён. В действительности вредоносная программа, скорее всего, реализовала бы дополнительную логику и предпринимала действие только при определённых событиях мыши, например при щелчке левой кнопкой, как в случае Upclicker. Подробнее прочитать об Upclicker и одновременно получить хорошее введение в уклонение от песочниц можно в отчёте FireEye по адресу https://media.blackhat.com/us-13/US-13-Singh-Hot-Knives-Through-Butter-Evading-File-based-Sandboxes-WP.pdf.

Эта магия перехвата работает не только с мышью. Вредоносная программа может также перехватить клавиатуру, передав функции SetWindowsHookEx значение 0Dh, то есть 13 в десятичном виде, а затем ожидать нажатия определённой клавиши перед полным выполнением. Перехват подробнее рассматривается в главах 8 и 12. В качестве альтернативы программа может вызвать функцию GetAsyncKeyState для наблюдения за нажатиями клавиш.

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

Примечание. Чтобы имитировать среду настоящего конечного пользователя, придайте аналитическим VM и песочницам максимально правдоподобный вид. Полезно сменить фоновый рисунок и посетить несколько сайтов, чтобы заполнить каталоги cookie и кеша. Даже открытие дополнительных окон и перемещение мыши по экрану может помочь избежать некоторых из этих методов обнаружения, пусть при этом вы и будете чувствовать себя немного глупо.

Время работы системы

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

Проверить время работы системы можно несколькими способами, как посредством Windows API, так и с помощью вспомогательных команд. Пожалуй, самый распространённый способ - функция Windows API GetTickCount, возвращающая время работы системы в миллисекундах. Такт создаётся генератором тактовых импульсов процессора, который отвечает за отсчёт времени и координацию инструкций. При выключении или перезагрузке системы значение GetTickCount, по существу, сбрасывается в 0. Следующий код использует GetTickCount, чтобы проверить, была ли система включена в течение 20 минут:

Сначала образец перемещает шестнадцатеричное значение 124F80, равное десятичному 1200000, в регистр ebx. Оно представляет 1 200 000 миллисекунд, или 20 минут. Затем программа вызывает GetTickCount и сравнивает возвращённое число тактов со значением в ebx. Если значение GetTickCount меньше значения ebx, то есть система включена менее 20 минут, образец завершает работу.

Вредоносная программа может получить время работы системы и с помощью командной строки Windows. Среди вариантов - команда sysinfo, возвращающая список сведений о системе, включая время работы; бинарный файл uptime.exe, входящий в большинство версий Windows; и команда net statistics workstation. Наконец, программа может вызвать WMIC и получить время работы командой wmic os get lastbootuptime.

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

Итоги

В этой главе мы рассмотрели несколько изобретательных и скрытных способов, которыми вредоносная программа может перечислять среду и искать свидетельства реальной пользовательской активности. Многие из этих методов обнаружения пользователя можно сорвать, просто спроектировав среду анализа так, чтобы она выглядела правдоподобной для вредоносной программы. Некоторые изменения, например замена стандартного фонового рисунка Windows и добавление нескольких записей в историю просмотра, реализуются легко. Другие способы противодействия методам обнаружения рассматриваются в приложении A. Обратите внимание также, что некоторые продвинутые песочницы имеют встроенную защиту от многих из этих методов.

В следующей главе мы разберём, как уклоняющаяся вредоносная программа может перечислять сведения об оборудовании системы и сетевых устройствах, чтобы обнаруживать среду анализа VM.

Сведения об оборудовании, например скорость ЦП и объём выделенной оперативной памяти, а также сетевые конфигурации, такие как MAC- и IP-адреса сетевых интерфейсов узла, могут указать вредоносной программе, что она работает в лабораторной среде. Кроме того, программа способна использовать эти сведения для установления контекста своей среды выполнения. В этой главе мы обсудим методы, с помощью которых вредоносная программа может собирать такую информацию и уклоняться от обнаружения.

Конфигурации оборудования и устройств

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

ЦП

Поскольку виртуализированные ЦП выглядят несколько иначе, чем их физические аналоги, вредоносная программа часто проверяет процессор узла, чтобы определить контекст выполнения. Получить сведения об оборудовании ЦП можно несколькими способами. Один из наиболее распространённых подходов - вызов функции GetSystemInfo для получения значения dwNumberOfProcessors, обозначающего количество процессоров в системе. В современных компьютерных системах почти всегда больше одного процессора и процессорного ядра. Чтобы определить, работает ли она на виртуальной машине, вредоносная программа может проверить, меньше ли у узла двух процессорных ядер:

В этом псевдокоде образец определяет структуру systemInfo, а затем вызывает GetSystemInfo. Структура - это тип данных, позволяющий объединить другие данные под одним именем. Все сведения, возвращённые функцией GetSystemInfo, будут сохранены в структуре systemInfo. Затем вредоносная программа исследует содержащееся в ней значение dwNumberOfProcessors и, если numProcessors меньше 2, завершает работу.

Аналогичным образом образец может вызвать следующие функции, чтобы получить сведения, по которым можно судить о среде выполнения:

GetLogicalProcessorInformation

: Возвращает сведения о ядрах процессора.

GetNativeSystemInfo

: Возвращает сведения, подобные результату GetSystemInfo, но обычно вызывается 64-разрядными приложениями.

IsProcessorFeaturePresent

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

Для перечисления ЦП можно также использовать блок среды процесса. Напомним из главы 1, что структура PEB состоит из указателей на другие структуры в памяти, содержащие сведения о выполняющемся в данный момент процессе. Следующий код показывает, как вредоносная программа может искать в PEB сведения о ЦП:

Образец перемещает адрес PEB, хранящийся в fs:[0x30], в регистр eax, а затем помещает в регистр edx определённое смещение PEB, которое интересует вредоносную программу ([eax+0x64]). По смещению 0x64 в структуре PEB хранится количество процессорных ядер, настроенных в системе. Если процессорное ядро одно, вредоносная программа завершает работу, переходя к функции terminate_process.

Примечание. Для 64-разрядных процессов адрес PEB находится в регистре gs по адресу gs:[0x60], поэтому обращайте внимание и на вредоносные программы, ссылающиеся на этот адрес.

Оперативная память

В современных компьютерах обычно установлено не менее 4 Гбайт оперативной памяти, однако в некоторых средах анализа вредоносных программ и песочницах такого объёма может не быть. Если установленная память не достигает порога в 4 Гбайт или похожего значения, вредоносная программа может предположить, что работает в виртуальной среде. Для проверки она вызывает функцию Windows GetPhysicallyInstalledSystemMemory, возвращающую объём системной памяти:

Здесь образец вызывает функцию GetPhysicallyInstalledSystemMemory с параметром TotalMemoryInKilobytes, в котором будет сохранено возвращённое функцией значение общего объёма системной памяти. После вызова программа сравнивает TotalMemoryInKilobytes со значением 4194302, то есть 4 194 302 Кбайт, или 4 Гбайт. Если объём системной оперативной памяти меньше 4 Гбайт, образец переходит к terminate_process и удаляет себя.

Жёсткие диски

Большинству современных компьютеров выделяются сотни гигабайт дискового пространства. Вредоносная программа может запросить ёмкость жёстких дисков и, если значение окажется ниже определённого порога, решить, что работает в виртуальной среде. Обычно порог составляет 40, 60 или 80 Гбайт, но с ростом средней ёмкости хранилищ это число может увеличиваться.

Для сбора сведений о жёстких дисках и их ёмкости чаще всего используются функции Windows GetDiskFreeSpace и GetDiskFreeSpaceEx. Помимо уклонения, у вредоносной программы мало причин запрашивать место на жёстком диске, поэтому такие функции должны послужить для вас тревожным признаком. Простой способ обойти эту тактику уклонения - увеличить размер дисков VM более чем до 40 Гбайт, а ещё лучше до 80 Гбайт.

В Windows существует множество малоизвестных и редко применяемых функций API. Один из примеров - функция IsNativeVhdBoot:

Если IsNativeVhdBoot возвращает не 0, система была загружена с виртуального жёсткого диска, что указывает на VM. Обратите внимание, что функция IsNativeVhdBoot работает только в Windows 8 и более новых версиях.

Конфигурации мониторов

У обычного современного компьютера, скорее всего, имеется монитор высокого разрешения, а иногда и несколько, чего нельзя сказать о большинстве VM и песочниц. Некоторые вредоносные программы специально проверяют количество используемых мониторов и, обнаружив, скажем, только один, могут сделать вывод, что находятся в среде анализа. Для этого программа способна вызвать функцию Windows API GetSystemMetrics, возвращающую определённую переменную SM_CMONITORS, которая представляет количество используемых мониторов. Другой вариант - функция EnumDisplayMonitors: она не возвращает общее количество напрямую, а выполняет функцию обратного вызова для каждого монитора. Функция обратного вызова - всего лишь способ выполнить задачи для каждого вызывающего её объекта, в данном случае монитора.

С помощью тех же функций вредоносная программа может проверять разрешение экрана. Типичное разрешение невиртуализированной системы конечного пользователя довольно высоко, например 1600 x 900. Если разрешение экрана аналитической машины ниже, скажем 1152 x 864, вредоносная программа может это отметить.

Функция GetSystemMetrics

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

- SM_CMONITORS: количество настроенных мониторов;

- SM_CMOUSEBUTTONS: количество кнопок мыши; возвращает 0, если мышь не установлена;

- SM_CXSCREEN: ширина экрана в пикселях;

- SM_CYSCREEN: высота экрана в пикселях;

- SM_MIDEASTENABLED: настройка ближневосточных языков; возвращает ненулевое значение, если система настроена на иврит или арабский;

- SM_MOUSEPRESENT: наличие мыши; возвращает 0, если она не установлена;

- SM_NETWORK: наличие сети; если сеть имеется, устанавливается младший значащий бит, а если нет, биты сбрасываются.

USB-контроллеры

Многие VM настроены на применение старой версии протокола USB, например 1.1 или 2.0, либо вообще не имеют устройства USB-контроллера. Поскольку в большинстве современных невиртуализированных систем есть хотя бы один USB-контроллер с актуальной версией USB-устройства, это может послужить вредоносной программе хорошей подсказкой.

В Windows имеется полезный API специально для перечисления USB-устройств и параметров: Winusb.dll. Если вы заметили, что вредоносная программа пытается импортировать эту DLL и использовать её функции, это серьёзный признак чего-то подозрительного.

Таблицы микропрограмм

Большинство системного оборудования сопровождается низкоуровневым программным обеспечением, известным как микропрограмма. Микропрограмма вдыхает жизнь в оборудование: без неё оно не смогло бы взаимодействовать с ОС или другими программами. Windows ведёт учёт микропрограмм в таблицах, которые также содержат сведения о производителе и модели связанного оборудования. Вредоносная программа может использовать их для выявления данных, относящихся к гипервизору.

Рассмотрим таблицу микропрограмм. На рис. 6-1 показан вывод бесплатного инструмента NirSoft FirmwareTablesView в моей VM.

Рис. 6-1. Таблицы микропрограмм, отображённые в FirmwareTablesView

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

В столбце Firmware можно увидеть тип каждой таблицы микропрограмм, также называемый сигнатурой поставщика: ACPI, SMBIOS или Raw. Некоторым функциям, например GetSystemFirmwareTable и EnumSystemFirmwareTables, для получения таблиц необходима сигнатура поставщика. Следующий код показывает, как вредоносная программа вызывает EnumSystemFirmwareTables для исследования таблиц ACPI:

Позднее вредоносная программа будет искать в буфере с таблицами микропрограмм связанные с гипервизорами строки, такие как Oracle, Vbox, VirtualBox, VMware и VMware, Inc.

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

Вредоносная программа вызывает функцию NtQuerySystemInformation с несколькими важными параметрами. Первый, SystemInformationLength ([ebp+Length]), задаёт размер буфера, который примет данные, возвращённые вызовом. Второй, SystemFirmwareTableInformation (eax), является указателем на этот буфер. Третий параметр, 76, представляет интересующий программу класс системных сведений SystemFirmwareTableInformation. После вызова NtQuerySystemInformation и сохранения структуры таблицы микропрограмм в буфере программа может перечислить его содержимое в поисках сведений, относящихся к гипервизору.

Обратите внимание, что класс данных SystemFirmwareTableInformation не документирован Microsoft, поэтому открытой информации о нём немного. Microsoft сохраняет некоторые функциональные возможности внутренними, вероятно, чтобы ими нельзя было легко злоупотребить, однако авторы вредоносных программ и исследователи неизбежно их находят. Conix Cybersécurité составила полный список классов данных, возвращаемых NtQuerySystemInformation, по адресу https://github.com/conix-security/zer0m0n/blob/master/src/driver/include/nt/structures/SYSTEM_INFORMATION_CLASS.h.

Другие аппаратные устройства

Среди других конфигураций оборудования, которые вредоносная программа может использовать для получения сведений о своей среде, можно назвать приводы CD или DVD, звуковые карты и параметры звука, подключённые принтеры либо их отсутствие, а также последовательные порты. Некоторые из этих параметров мы дополнительно рассмотрим в приложении A, однако вредоносная программа способна перечислить любые конфигурации оборудования в системе жертвы, поэтому включить их все в книгу невозможно.

Далее мы обратим внимание на связанные с сетью сведения, которые вредоносная программа может использовать для выявления среды VM или песочницы.

Артефакты, связанные с сетью

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

Конфигурации IP-адресов

Вредоносной программе может потребоваться IP-адрес узла по ряду причин, прежде всего чтобы определить, работает ли узел в песочнице или лаборатории анализа. Стандартный диапазон IP-адресов внутренних сетей VirtualBox - 192.168.56.X. Стандартный диапазон IP для VMware Workstation - 192.168.X.X, причём последние два октета выбираются случайным образом, например 192.168.5.100 или 192.168.187.101. Диапазон зависит от версии установленного гипервизора. Если IP-адрес системы жертвы входит в эти диапазоны, вредоносная программа может либо решить, что это VM, либо подвергнуть систему дальнейшей проверке.

Получить IP-адрес узла можно простым применением функции GetAdaptersAddresses:

Как и многие функции Windows API, GetAdaptersAddresses принимает ряд параметров. В данном случае push edx помещает в стек адрес буфера AdapterAddresses, в котором будут храниться все данные об адресах, возвращённые вызовом функции. Следующие три инструкции помещают в стек параметры reserved, flags и family. Важнее всего параметр family, содержащий значение 2, которое предписывает GetAdaptersAddresses возвращать только сведения IPv4. В табл. 6-1 приведены определения всех значений параметра family.

Таблица 6-1. Значения параметра family функции GetAdaptersAddresses

Затем вредоносная программа вызывает функцию GetAdaptersAddresses. Позднее код перемещает значение AdapterAddresses.FirstUnicastAddress в eax, а переменную bad_ip_address - в edx. Переменная FirstUnicastAddress является частью AdapterAddresses и содержит первый IP-адрес структуры. В bad_ip_address находится IP-адрес, с которым проводится проверка. Предположим, что это значение 192.168.56.2, указывающее на сеть VirtualBox. Вредоносная программа сравнивает FirstUnicastAddress с bad_ip_address посредством cmp eax, edx, проверяя, имеет ли система жертвы адрес 192.168.56.2. Если данный IP присутствует в структуре AdapterAddresses, программа переходит к функции terminate_process и завершает работу.

Помните, что IP-адреса системы можно перечислить множеством способов. Некоторые функции напрямую запрашивают сведения об интерфейсах, а другие применяют более обходной метод, например перечисляют таблицы IP-сети. Сведения об IP-адресах можно также запросить средствами Windows, такими как WMI, PowerShell и командная строка. Любая вредоносная программа, разыскивающая внутренний IP-адрес узла, должна вызывать подозрение, поскольку она может применять метод обнаружения.

Конфигурации домена

Вредоносная программа может попытаться перечислить домен узла жертвы, чтобы убедиться, что цель находится в определённой компании или сети, либо отсеять среды анализа. В данном случае домен - просто логическая группа систем в сети. Компьютер, которым вы пользуетесь на работе, вероятно, входит в домен, имя которого связано с названием вашей компании. Обычно этот домен является и частью имени узла системы, то есть имени устройства в сети. Например, если вы работаете в Evil Corp, домен может называться evil.corp, а имя узла - your.computer.evil.corp.

Перечисление домена может быть отличной тактикой уклонения. Например, если система жертвы не связана с доменом либо присоединённый домен не соответствует основной цели вредоносной программы, она может завершить работу во избежание анализа или изменить поведение. Распространённые функции Windows API для перечисления домена узла - GetComputerName и DsGetDcName.

Помимо функций Windows API, вредоносная программа может запрашивать следующие разделы реестра, где способен храниться домен системы:

• HKCU\Volatile Environment

• HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

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

Конфигурации MAC-адресов

Адрес управления доступом к среде, или MAC-адрес, представляет собой уникальный идентификатор, назначаемый всему компьютерному сетевому оборудованию. MAC-адрес состоит из цифр длиной 3 байта, представляющих производителя устройства, за которыми следуют ещё 3 байта, относящиеся к аппаратному устройству данного узла (рис. 6-2).

Рис. 6-2. Структура MAC-адреса

На рис. 6-2 приведён пример MAC-адреса 00:50:56:62:9A:12. Первые 3 байта (00:50:56) представляют идентификатор производителя, в данном случае VMware, а последние 3 байта - этот конкретный адаптер.

Вредоносная программа может запросить MAC-адреса узла, чтобы узнать, использует ли он сетевое оборудование определённого производителя. У каждого элемента сетевого оборудования есть и собственный выделенный MAC-адрес, поэтому эти сведения можно применять также для выбора жертв. Пример - получившая теперь широкую известность атака на цепочку поставок под названием ShadowHammer, произошедшая в 2019 году. Злоумышленники использовали список заранее выбранных MAC-адресов, чтобы нацелиться на конкретные компьютеры и заразить их.

Для получения списка MAC-адресов узла вредоносная программа может вызвать функцию Windows API GetAdaptersAddresses. Затем она сравнивает список с жёстко заданным набором MAC-адресов и заражает систему, только если находит сетевое устройство с совпадающим адресом. После вызова GetAdaptersAddresses тем же способом, который я описал в разделе "Конфигурации IP-адресов" на с. 109, программа проверяет значение PhysicalAddress структуры AdapterAddresses, содержащее MAC-адреса узла:

Позднее вредоносная программа помещает данные в стек инструкциями вроде mov [ebp+var_38], 0B203B000h. Эти данные представляют часть MAC-адреса, который программа будет сравнивать с MAC-адресами жертвы.

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

VMware Workstation

• 00:50:56...

• 00:0C:29...

• 00:05:69...

VirtualBox

• 08:00:27...

Примечание. Чтобы обойти этот метод обнаружения, измените MAC-адреса своих VM и песочниц.

Внешний IP-адрес и подключение к интернету

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

Во-вторых, вредоносная программа может использовать внешний IP-адрес узла или состояние подключения к интернету для обнаружения среды анализа. Например, если внешний IP принадлежит шлюзу популярной виртуальной частной сети (VPN), такой как NordVPN или ExpressVPN, либо выходному узлу TOR, программа может сделать вывод, что её анализируют. В конце концов, если кто-то использует TOR или VPN, он наверняка аналитик вредоносных программ, верно? Кроме того, песочницы и среды анализа часто намеренно работают автономно, поэтому при полном отсутствии внешнего IP-адреса программа может предположить, что находится в лабораторной среде.

Этот метод можно реализовать несколькими способами, но, пожалуй, самый распространённый - просто отправить веб-запрос службе определения IP, например WhatIsMyIP.com или IPLocation.net. Это законные службы, которые сообщают вызывающему узлу его внешний IP-адрес и сведения о географическом местонахождении. Если при запуске вредоносной программы в аналитической песочнице или лаборатории вы видите HTTP-запросы к подобным сайтам, это сигнал, что программа, возможно, пытается определить внешний IP-адрес или местонахождение узла. Вот как это может выглядеть:

Сначала образец перемещает значение lpszServerName, содержащее домен icanhazip.com, в регистр ecx для дальнейшего использования 1. Функция InternetConnectA принимает множество параметров, но важны среди них nServerPort 2, который указывает порт для обращения образца к домену, в данном случае порт 80, или HTTP, и сам домен, теперь хранящийся в ecx 3. Наконец, программа вызывает InternetConnectA 4. По существу, код образца обращается к домену icanhazip.com по HTTP, чтобы получить внешний IP-адрес узла.

Связанный метод состоит в простой отправке DNS- или HTTP-запроса поставщику сетевой службы. Подойдёт любой поставщик, но часто используется Google.com. Если образец отправляет запрос веб-серверу и не получает данных либо получает неправильные данные, он может сделать вывод, что подвергается анализу. Следующий образец пытается обратиться к Google.com, а затем проверяет, соответствует ли ответ обычному ответу сервера:

После попытки обратиться к Google.com посредством InternetConnectA образец помещает в стек параметры функции InternetReadFile, включая dwNumberOfBytesToRead 1, где находится количество байтов, которое следует прочитать из ответа веб-сервера, то есть 9, и lpBuffer 2, являющийся указателем на данные, возвращаемые InternetReadFile. Затем образец вызывает InternetReadFile 3, которая читает первые 9 байт ответа Google, предположительно <!doctype. Наконец, код сравнивает значение <!doctype с фактическим ответом, сохранённым в lpBuffer 4. Если ответы различаются, образец может заключить, что система не подключена к интернету или, возможно, анализируется в песочнице.

В современных вредоносных программах этот метод проверки внешнего IP встречается нередко, поэтому обращайте на него внимание. Если при анализе образца вы видите исходящие HTTP- или DNS-запросы к таким сайтам, как WhatIsMyIP.com, или к поставщикам служб, например Google.com либо AWS.Amazon.com, есть вероятность, что программа применяет этот метод обнаружения VM. Следует обращать внимание и на следующие сайты:

• api.ipify.org

• checkip.amazonaws.com

• checkip.dyndns.com

• icanhazip.com

• ip-api.com

• ip.anysrc.net

• ipecho.net

• ipinfo.io

• iplocation.net

• myexternalip.com

• myipaddress.com

• showipaddress.com

• whatismyip.com

• whatismyipaddress.com

• wtfismyip.com

Состояния TCP-соединений

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

Эта тактика предусматривает применение функции Windows API GetTcpTable, которая возвращает таблицу с текущим состоянием последних TCP-соединений системы, подобную результату запуска netstat.exe на узле. Такая таблица может выглядеть как табл. 6-2.

Таблица 6-2. Примеры TCP-соединений

На автономной машине анализа или в песочнице, скорее всего, не будет установленных удалённых TCP-соединений, подобных приведённым в третьей и четвёртой строках табл. 6-2.

Разумеется, вредоносная программа может также воспользоваться для этого штатными средствами Windows, например уже упомянутой netstat.exe. При исследовании вредоносной программы обращайте внимание на попытки перечислить сведения о состояниях TCP посредством функций Windows или штатных инструментов системы.

Открытые порты

В некоторых песочницах открыты порты, обычно используемые для обмена данными между гипервизором и VM, где запускается вредоносная программа. Например, песочница Cuckoo с открытым исходным кодом по умолчанию открывает для связи TCP-порт 8000.

Чтобы перечислить эти открытые порты, вредоносная программа может вызвать описанные ранее функции, например GetTcpTable. Если она увидит порт 8000 в состоянии LISTENING или ESTABLISHED, то может предположить, что выполняется в среде песочницы Cuckoo. Более продвинутая вредоносная программа способна даже отправить данные на открытый порт и проверить его поведение, примерно как специалист по тестированию на проникновение при зондировании цели. В зависимости от ответа открытого порта образец либо продолжит обычную работу, либо предпримет действия по уклонению.

Итоги

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

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

Обнаружение аномалий анализа и среды выполнения

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

Пути запуска, имена файлов и аргументы

Когда вредоносную программу отправляют в автоматизированную песочницу для запуска и анализа, ей часто присваивается типовое имя вроде sample.exe или malware.exe либо хеш-значение наподобие b3126a1de5401048f5a6ea5a9192126fc7482ff0. Кроме того, она может запускаться из типового каталога, такого как C:\Users\<user>\Downloads или C:\Users\<user>\Desktop, а не из каталога, предусмотренного автором, например временного. Некоторые вредоносные программы способны распознавать эти аномалии. Так, образец может вызвать функцию GetModuleFileName, чтобы вернуть собственное имя, или PathFindFileName, чтобы получить полный путь запуска. Следующий образец вызывает GetModuleFileName и проверяет, не занесено ли его имя файла в список блокировки:

Этот образец вызывает функцию GetModuleFileNameA 1 с тремя параметрами: буфером для хранения возвращённого имени вредоносного файла (fileNameBuffer), размером буфера (size) и целевым модулем (esi). Если целевой модуль равен null, им является выполняющийся в данный момент процесс.

Затем код вызывает функцию wcsstr 2 с двумя параметрами: заблокированным именем файла (blocklist1) и указателем на буфер, в котором хранится имя вредоносного файла, возвращённое GetModuleFileName. Образец сравнивает собственное имя файла со значением из списка блокировки. Если результат равен 0, то есть возвращённое имя не совпадает с заблокированным, программа переходит к следующему сравнению. Она продолжает перебирать список заблокированных имён 3. Найдя совпадение, программа предполагает, что её анализируют.

Вместо типового имени песочницы и аналитики иногда переименовывают вредоносный файл в его хеш-значение, обычно в формате MD5, SHA-1 или SHA256. Когда вы загружаете вредоносную программу из такого репозитория, как VirusTotal, её имя будет иметь вид хеша, например b3126a1de5401048f5a6ea5a9192126fc7482ff0. Перед запуском аналитик или песочница могут просто добавить к нему расширение типа файла: b3126a1de5401048f5a6ea5a9192126fc7482ff0.exe. Хеш содержит заданное количество символов: например, 32 символа у MD5 и 40 у SHA-1. Вредоносная программа может подсчитать символы в своём имени и, если их ровно 32 или 40 плюс символы расширения, предположить, что выполняется в среде анализа.

Кроме того, вредоносная программа может исследовать путь запуска и имя файла и сравнивать их с исходными путём и именем, предусмотренными автором. Например, вредоносный документ Microsoft Word способен попытаться загрузить исполняемый файл из интернета и сохранить его в каталоге C:\Users\<user>\AppData\Roaming с именем abc.exe. Если аналитик получит этот исполняемый файл без исходного документа Word и запустит его из каталога C:\Users\<user>\Downloads под именем evil.exe, образец может заметить, что работает из аномального расположения с неизвестным именем, и предпринять действия по уклонению.

Наконец, вредоносная программа может исследовать аргументы своей командной строки. Некоторые песочницы добавляют в процесс собственные аргументы, например -force, -analysis или -debug. Проверяя их наличие, программа способна обнаружить, что работает внутри песочницы, и соответствующим образом изменить поведение. Вариант этого метода - выполнение только при наличии определённых аргументов командной строки. Если программа запущена без них, как может произойти при запуске в автоматизированной песочнице, она способна прекратить полное выполнение или продемонстрировать другие функциональные возможности. Например, образцу evil.exe может требоваться аргумент командной строки do_stuff:

Без аргумента do_stuff вредоносная программа может неправильно работать в среде анализа. Обычно этот метод предусматривает предварительный вредоносный исполняемый файл или сценарий, который запускает основной исполняемый файл с правильными аргументами. В таком случае вам, возможно, придётся провести ручной анализ и обратную разработку, чтобы определить ожидаемые аргументы командной строки.

Чтобы обойти многие проверки имени файла и пути запуска, которые может применять вредоносная программа, можно просто переименовать файл в случайное слово или фразу и запустить его из каталога, где вредоносные программы часто выполняются, например из временного каталога (C:\Users\<username>\AppData\Roaming\). Здесь также важно понимать полную цепочку атаки: программа может искать определённый путь или аргумент, а быстрый способ узнать его - исследовать все артефакты атаки.

Загруженные модули

Некоторые песочницы и инструменты анализа загружают модули в адресное пространство памяти выполняющегося вредоносного процесса, чтобы изменить поведение программы или перехватить её код. В данном случае модуль обычно представляет собой DLL-файл, который по разным причинам загружается или внедряется в целевой процесс. Чтобы определить, какие модули загружены в её пространство памяти, вредоносная программа может перечислить их с помощью функций Windows API Module32First, Module32Next и GetModuleHandle и выявить аномалии.

Module32First и Module32Next применяются для перебора всех модулей, загруженных в вызывающий процесс, подобно тому как Process32First и Process32Next служат для перечисления процессов. Функция GetModuleHandle, напротив, просто принимает имя модуля в качестве параметра и возвращает его дескриптор, если модуль загружен. Вредоносная программа может использовать её для проверки жёстко заданного списка имён модулей:

Сначала образец помещает в стек адрес строки sbiedll.dll, а затем вызывает GetModuleHandleA. Если возвращённое значение равно 0, то есть данный модуль не загружен в пространство памяти программы, код переходит к loc_2, где теми же инструкциями проверяет модуль vmcheck.dll. Два искомых этой программой модуля - это Sandboxie (sbiedll.dll), популярное приложение-песочница, и vmcheck.dll, модуль, часто загружаемый в гостевой системе Virtual PC.

Примечание. Этот метод может применяться и по другим причинам, например для поиска средств защиты от вредоносных программ, обнаружения и реагирования на конечных точках (EDR) и других защитных инструментов. Мы обсудим это в части IV.

Аномальные строки в памяти

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

Сначала образец определяет переменную hashedString. Эта строка представляет собой просто хеш-сумму SHA-1 строки HookLibraryx86.dll, о которой я вскоре расскажу подробнее. Затем образец вызывает функцию ReadProcessMemory с несколькими параметрами, важнейшие из которых - дескриптор процесса (hProcess), базовый адрес, с которого следует начать чтение памяти внутри процесса (lpBaseAddresss), буфер для приёма прочитанных данных (lpBuffer) и количество байтов, читаемых из памяти (nSize). В данном случае программа читает собственный процесс. После чтения и сохранения данных в буфере образец вычисляет их хеш алгоритмом SHA-1. Наконец, он вызывает memcmp, чтобы сравнить хешированные данные буфера с исходной хешированной строкой.

Вредоносная программа может искать аномалии во всём адресном пространстве своей памяти либо нацелиться на определённую область. Значением lpBaseAddress может быть любой базовый адрес в адресном пространстве процесса программы.

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

Перехваченные функции и проверки ускорения

Автоматизированные песочницы анализа вредоносных программ и некоторые аналитические инструменты могут перехватывать и изменять определённые функции при выполнении вредоносной программы, чтобы обходить отдельные попытки уклонения. Одна из часто перехватываемых функций - Sleep, которую вредоносная программа использует, чтобы оставаться бездействующей и не позволить автоматизированной песочнице успешно её проанализировать, поскольку песочницы нередко работают лишь несколько минут. Например, песочница способна изменить параметр функции Sleep, сократив время сна с 5 минут до 30 секунд. Вредоносная программа может проверить, не вмешиваются ли в работу Sleep, поместив её между двумя функциями измерения времени, например GetTickCount. Этот метод называется проверкой ускорения:

Образец вызывает GetTickCount, а затем Sleep на 30 000 миллисекунд, то есть 30 секунд. После этого он вызывает GetTickCount во второй раз, вычитает первый результат из второго и сохраняет разность в eax (sub eax, edi). Наконец, вредоносная программа сравнивает значение в eax с 29 000 миллисекунд - минимальным ожидаемым временем, которое должно было пройти. Если автоматизированная песочница или инструмент вмешались в работу функции Sleep, значения GetTickCount не будут пропорциональны ожидаемому промежутку, что подскажет вредоносной программе: что-то не так.

Применение показателей производительности и времени

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

Инструкция rdtsc

Read Time-Stamp Counter, или rdtsc, - специальная ассемблерная инструкция с несколькими вариантами применения, включая наблюдение за производительностью и сбор показателей. При выполнении rdtsc на ЦП сохраняется текущее количество тактов процессора, которое можно позднее сопоставить со значением другой инструкции rdtsc. Разность двух значений равна количеству тактов, прошедших с момента первой инструкции.

У VM есть проблема с инструкцией rdtsc. Когда её выполняет программа, работающая на виртуальном процессоре, тот должен передать инструкцию "настоящему" процессору - аппаратному ЦП, на котором работает основная ОС. Передача rdtsc настоящему ЦП и обратно создаёт задержку, что, в свою очередь, увеличивает количество тактов. Увидев, что возвращённое число тактов выше, чем в невиртуализированной системе, вредоносная программа может сделать вывод, что работает внутри VM.

Чтобы лучше понять, как вредоносная программа применяет этот метод, рассмотрим фрагмент ассемблерного кода дизассемблированного образца:

Образец использует инструкцию rdtsc, чтобы получить текущее число тактов, и сохраняет значение в буфере rdtsc_1. Затем он выполняет ещё одну rdtsc и вычитает результат из исходного значения (sub eax, [ebp+rdtsc_1]). Полученное значение позволяет определить, укладывается ли время выполнения в порог невиртуализированного процессора.

Иногда вредоносная программа действует хитрее, чем при помощи двух простых команд rdtsc, и некоторые семейства выполняют несколько итераций rdtsc, чтобы получить более точное значение. В следующем разделе мы рассмотрим ещё несколько вариантов её применения.

Измерение времени выполнения функций

Учитывая временные различия между невиртуализированными и виртуализированными процессорами, некоторые вредоносные программы выполняют функцию или инструкцию и сравнивают время её выполнения с базовым показателем настоящего невиртуализированного процессора. Если инструкции выполняются медленнее базового уровня, программа может решить, что работает в VM.

Один из методов состоит в размещении вызова функции Windows API или инструкции между двумя функциями GetTickCount и сравнении результатов. Длительная задержка между двумя вызовами GetTickCount может указать вредоносной программе, что её выполняют и анализируют.

Существует множество вариантов этого метода, включая применение таких инструкций, как rdtsc и cpuid, вместо функций Windows API вроде GetTickCount. Главный вывод: всякий раз, заметив применение вредоносной программой функций или инструкций измерения времени с последующей операцией сравнения, исследуйте его подробнее.

Счётчики производительности

ЦП ведёт счётчики производительности, представляющие количество инструкций, выполненных с определённого момента времени. Они могут законно применяться для сбора показателей производительности, но вредоносная программа способна использовать их для обнаружения сред VM. Функция QueryPerformanceCounter запрашивает счётчик производительности процессора и возвращает текущее значение. QueryPerformanceFrequency возвращает частоту счётчика - фиксированное значение, представляющее общую производительность процессора. Когда эти инструкции выполняются в VM, возвращённые функциями значения могут быть несколько ниже, чем в невиртуализированной системе, демонстрируя влияние виртуальных процессоров на производительность.

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

Злоупотребление виртуальным процессором

Виртуальные процессоры внутри VM могут интерпретировать и выполнять некоторые ассемблерные инструкции таким образом, который выдаёт вредоносной программе присутствие VM. В этом разделе мы углубимся в то, как программа "злоупотребляет" такими виртуальными процессорами, неправильно применяя инструкции или эксплуатируя недостатки их архитектуры.

Методы Red Pill и No Pill

Red Pill и No Pill - два хорошо известных метода, которыми вредоносные программы обнаруживают виртуальные среды. Оба проверяют структуры данных процессора на значения, характерные для VM. В современных средах анализа эти методы часто неэффективны, поэтому в современных вредоносных программах применяются редко, но знать о них всё же полезно.

В методе Red Pill вредоносная программа выполняет ассемблерную инструкцию Store Interrupt Descriptor Table, или sidt, которая записывает значение регистра таблицы дескрипторов прерываний в память, а затем проверяет его. Таблица дескрипторов прерываний (IDT) - структура данных, используемая процессором для определения правильного ответа на исключения и прерывания. Исключения сообщают процессору, что с инструкцией что-то не так, а прерывания позволяют ему при необходимости реагировать на событие с более высоким приоритетом. Если вредоносная программа работает в VM, пятый байт регистра IDT будет содержать определённое значение, указывающее на это.

Метод Red Pill реализуется просто:

Инструкция sidt [eax] сохраняет в буфере содержимое регистра IDT длиной 6 байт. Код читает значение и выполняет сравнение с пятым байтом буфера [eax+5]. При работе в VM пятый байт регистра IDT будет равен FF в шестнадцатеричном виде.

Метод No Pill использует инструкцию Store Local Descriptor Table, или sldt, чтобы сохранить регистр локальной таблицы дескрипторов (LDT) в памяти. Поскольку обычные приложения Windows не используют LDT, значение этого регистра должно быть равно 0. Однако в некоторых гипервизорах регистр LDT содержит ненулевое значение, способное подсказать вредоносной программе, что она работает в VM. Как и Red Pill, метод No Pill больше не действует должным образом в современных песочницах и гипервизорах.

Порты ввода-вывода

Порт ввода-вывода (IO-порт) - способ обмена данными между физическим оборудованием машины и работающим на нём программным обеспечением. Некоторые гипервизоры используют IO-порты для связи основной ОС с гостевой. Например, VMware применяет IO-порт VMX. Исследование Cisco Talos показало, что вредоносная программа может выявлять порт VMX и тем самым определять работу в среде VMware. Следующий ассемблерный код показывает, как это может выглядеть на практике:

Этот образец загружает значение VMXh в регистр eax, а затем магическое значение 2EF36D4Ch в регистр ebx. Это магическое значение может быть любым шестнадцатеричным числом и здесь не имеет значения. Затем код загружает в сегмент регистра dx значение VX, или 5658 в шестнадцатеричном виде, то есть номер порта VMX. Наконец, вредоносная программа выполняет in eax, dx, где ассемблерная инструкция in пытается обратиться к IO-порту. Если на узле работает гипервизор VMware Workstation, инструкция вернёт магическое число, что, скорее всего, заставит образец завершить работу или предпринять другие действия по уклонению. На невиртуализированном узле возвращённое значение было бы равно 0.

Подобно Red Pill и No Pill, данный конкретный метод довольно стар и уже исправлен в современных версиях VMware. Однако важно понимать его и сходные методы на случай, если вы анализируете вредоносную программу, которая использует его или один из вариантов.

Инструкция cpuid

Ассемблерная инструкция cpuid возвращает сведения о процессорах узла, например их возможности и производителя. Вне VM выполнение cpuid при значении EAX, равном 0, вернёт что-то вроде Genuineintel для процессоров Intel или AuthenticAMD для AMD. При выполнении cpuid внутри VM нередко возвращается имя гипервизора. Для VMware это строка VMwareVMware, а для VirtualBox - VBoxVBoxVBox.

Если перед выполнением cpuid задать EAX равным 1, функция вернёт гораздо больше сведений в виде 31-битного блока в регистрах ECX и EDX. Тридцать первый бит регистра ECX будет равен 0, если ЦП системы физический, и 1, если система использует виртуальный ЦП, что указывает на среду VM. Вот фрагмент ассемблерного кода образца, применяющего данный метод:

Здесь вредоносная программа задаёт eax равным 1 (inc eax), и это значение применяется как параметр следующей инструкции cpuid. После выполнения cpuid программа выполняет инструкцию bt (bit test), чтобы переместить 31-й бит ecx в регистр флага переноса - особый регистр ЦП, способный хранить значения 0 или 1 и обычно используемый при сложении и вычитании. Наконец, образец проверяет регистр флага переноса (jc), и, если тот равен 1, программа заключает, что работает в VM, и завершает работу.

Примечание. Wikipedia - отличный справочный источник по сведениям о процессоре и битам возможностей, возвращаемым cpuid. См. https://en.wikipedia.org/wiki/CPUID.

Неподдерживаемые наборы инструкций

Вредоносная программа может применить cpuid, чтобы узнать, поддерживает ли процессор определённый набор инструкций. Например, 23-й бит регистра EDX показывает, поддерживает ли процессор набор SSE - набор необычных ассемблерных инструкций, обычно используемых для обработки графики и научных вычислений. Некоторые современные гипервизоры поддерживают такие наборы, как SSE, но не все! Для вредоносной программы это может стать явным признаком работы в VM или песочнице.

Некоторые вредоносные программы вместо методичного исследования вывода cpuid просто пытаются выполнить такие инструкции:

Инструкция movdqa (Move Aligned Double Quadword) применяется для перемещения данных в регистры XMM и из них, то есть регистры набора инструкций SSE. В данном коде movdqa перемещает данные, на которые ссылается eax, в регистр xmm0, а затем ещё раз в xmm1. После этого данные переносятся обратно из регистров XMM в eax. Если код вызывает ошибку или вредоносная программа аварийно завершается, образец может предположить, что выполняется в виртуализированной среде.

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

Другой пример экзотической инструкции - vpcext, которая вызывает ошибку при выполнении вне гипервизора Windows Virtual PC. Однако внутри Virtual PC инструкция выполняется успешно и устанавливает регистр EBX равным 0. Следующий код выполняет vpcext, а затем инструкцией test проверяет, равен ли ebx нулю:

Флаг трассировки и другие методы

Флаг трассировки - восьмой бит регистра EFLAGS в наборе инструкций Intel x86. Если включить его до вызова другой инструкции, будет инициировано исключение. В среде VM гипервизор эмулирует поведение флага трассировки. В зависимости от используемого гипервизора эмуляция может быть неправильной или неполной, из-за чего флаг будет проигнорирован и сообщит вредоносной программе, что она работает в VM. Впервые этот метод был обнаружен в реальных атаках в 2021 году исследователями подразделения Unit 42 компании Palo Alto.

Похоже, новые способы обнаружения VM, подобные методу флага трассировки, находят каждые несколько лет. У большинства есть общая черта: они злоупотребляют тем, как по замыслу должны работать ЦП и его архитектура, вынуждая гипервизор вести себя неожиданным или прежде неизвестным образом и в конечном счёте раскрывая лежащую в основе VM. Аналитики вредоносных программ должны следить за актуальными сведениями о таких методах, чтобы распознавать их применение.

Риски применения методов обнаружения

Как вы увидели в этой и предыдущих главах, реализация функциональных возможностей обнаружения VM и инструментов анализа может принести авторам вредоносных программ множество преимуществ. Почему же автор может отказаться от них? Одна из причин состоит в том, что эти методы способны фактически повысить вероятность обнаружения вредоносной программы защитным ПО или аналитиком. Чем больше подозрительных функций Windows API или инструкций она выполняет, тем выше вероятность, что такие аномалии поведения будут замечены.

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

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

Итоги

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

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

Самозавершение

Простой и эффективный способ избежать анализа - самозавершение. Вредоносная программа может просто вызвать такие функции Windows API, как TerminateProcess или ExitProcess, и отдать команду на завершение собственному процессу:

Сначала этот псевдокод вызывает собственную внутреннюю функцию enumerate_reg_keys, чтобы перечислить некоторые связанные с VM разделы реестра, рассмотренные в главе 4. Подробности функции здесь не показаны. Затем, если is_vm возвращает истинное значение, вредоносная программа запрашивает дескриптор собственного процесса (GetCurrentProcess) и завершает себя вызовом TerminateProcess. Таким же образом, с несколькими несущественными отличиями, можно применять функцию ExitProcess. Иногда программа даже вызывает обе функции, чтобы гарантировать успешное завершение.

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

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

Отложенное выполнение

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

Вызовы функции Sleep

Пожалуй, самая распространённая форма отложенного выполнения - простой вызов вредоносной программой функции Sleep из Windows API. Sleep, как и её родственница SleepEx, принимает параметр, представляющий время сна в миллисекундах. Следующий ассемблерный фрагмент показывает вызов функции Sleep образцом:

В данном случае переданный Sleep параметр 493E0h - время в шестнадцатеричном виде, представляющее 300 000 миллисекунд, или 5 минут.

Примечание. Дополнительные сведения о функции Sleep и её применении вредоносной программой см. в главе 7.

Чтобы обойти этот метод, можно установить точки останова на вызовах функций Sleep и SleepEx, а затем изменить передаваемый им параметр dwMilliseconds. Можно также заменить инструкции Sleep на nop либо перепрыгнуть через них в отладчике. Однако эти решения не всегда надёжны: продвинутая вредоносная программа способна вычислить системное время до и после вызовов Sleep, чтобы проверить правильность выполнения функции! Наконец, многие современные песочницы умеют перехватывать вызовы Sleep и изменять их, резко сокращая общее время сна образца.

Тайм-ауты

Вредоносная программа может пойти менее традиционным путём и задержать своё выполнение с помощью таких средств Windows, как ping.exe, вызывая тайм-аут. Такой подход часто работает лучше сна, поскольку песочницам сложнее в него вмешаться. Ещё одно преимущество - возможное запутывание процесса анализа, ведь аналитику придётся выяснять, почему образец вызывает определённое приложение.

В следующем фрагменте образец выполняет ping.exe, чтобы отправить Google 1000 эхо-запросов. В зависимости от скорости сетевого соединения это может создать длительную задержку или даже привести к тайм-ауту песочницы и прекращению анализа:

Вредоносная программа может также вызвать инструмент Windows timeout.exe, обычно применяемый в пакетных сценариях для приостановки обработки команд, и тем самым задержать выполнение. Обращайте внимание на вызов программой инструментов такого типа. С помощью анализа кода и отладки выясняйте, зачем вредоносная программа может демонстрировать подобное поведение.

Временные и логические бомбы

Во временной бомбе вредоносная программа задаёт определённое время выполнения, например конкретную дату или время суток. Так, образец может содержать встроенный код, который выполняется только в 9 часов утра каждого дня, раз в неделю по субботам либо 26 декабря 2024 года в 17:55. Если песочница или аналитик вручную не зададут дату либо время, чтобы обманом заставить программу запуститься, образец не выполнит вредоносный код.

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

Следующий упрощённый псевдокод демонстрирует метод временной бомбы, при котором образец получает текущую системную дату и сравнивает её с жёстко заданной, в данном случае 2024 годом:

Если вредоносная программа определит, что сейчас 2024 год или более ранний, она не станет выполняться.

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

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

Фиктивный код и бесконечные циклы

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

В этом простом цикле for значение ecx увеличивается на 1, а затем сравнивается с самим собой. Если оно равно себе самому, а оно будет равно, цикл повторяется. Такой простой код приостановит выполнение вредоносной программы на неопределённый срок или по меньшей мере до тех пор, пока песочница не завершит работу либо разочарованный аналитик не уничтожит процесс.

Аналогичным образом некоторые вредоносные программы многократно вызывают функции Windows API, чтобы затянуть анализ. Например, программа может вызывать RegEnumKey для перечисления всего реестра узла, что займёт значительное время. Другой вариант - повторный вызов LoadLibrary для несуществующих библиотек. При написании этой книги я анализировал образец банковского трояна Dridex, который выполнял GetProcAddress более пяти миллионов раз, разрешая адреса функций, никогда им не используемых (рис. 8-1). Это затягивает анализ, поглощает ценные ресурсы памяти и ЦП песочницы и иногда приводит к сбою.

Рис. 8-1. Задержка анализа многократным выполнением GetProcAddress

Известно также, что Dridex выполняет OutputDebugString в бесконечном цикле, что даёт тот же эффект, что и подход с GetProcAddress. Функция OutputDebugString подробнее рассматривается в главе 10.

Механизмы закрепления для задержки выполнения

Зачастую вредоносная программа пытается закрепиться на узле жертвы, чтобы "пережить" выключения и перезагрузки системы, однако закрепление служит также отличной тактикой отложенного выполнения. Программа может настроить механизм закрепления в форме запланированной задачи на узле жертвы, чтобы выполнить полезную нагрузку только после определённого события или промежутка времени. Несколько способов закрепления рассматриваются в главе 15.

Принудительные перезагрузки и выходы из системы

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

Вредоносная программа способна вызвать перезагрузку или выключение с помощью таких функций, как InitiateShutdown, InitiateSystemShutdown и InitiateSystemShutdownEx. Все три работают сходным образом и принимают несколько ключевых аргументов, например параметр, определяющий выключение либо перезагрузку узла, и значение тайм-аута, представляющее длительность периода между вызовом функции и перезагрузкой или выключением. Ещё одна функция API, которую может применить вредоносная программа, - ExitWindows либо родственная ExitWindowsEx, добавляющая возможность вывести пользователя из системы вместо простой перезагрузки или выключения узла. Наконец, систему можно выключить также посредством WMI, PowerShell или встроенного инструмента Windows shutdown.exe.

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

Приманки и шум

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

API hammering

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

Для этой цели можно злоупотребить почти любой функцией Windows API. Среди встречавшихся мне примеров - printf, функция C, выводящая символы в вызывающее приложение, и TlsGetValue. Вредоносная программа на рис. 8-2 вызвала TlsGetValue подряд более 30 000 раз!

Рис. 8-2. Вредоносная программа применяет API hammering, многократно вызывая TlsGetValue

Семейства Nymaim и Trickbot применяют методы API hammering, как описано в публикациях Joe Security (https://www.joesecurity.org). По меньшей мере один вариант Nymaim выполняет более полумиллиона безвредных вызовов функций Windows API, если образец обнаруживает работу в среде VM или песочницы! Как вы можете представить, это генерирует огромный объём данных в журнале песочницы. Некоторые песочницы, неспособные обработать такой объём, скорее всего, досрочно завершат анализ.

Однако многие современные песочницы умеют обнаруживать API hammering и отмечают такое поведение как подозрительное либо вовсе прекращают регистрировать сомнительную функцию. Песочница может также изменить поведение выполняющегося образца или предпринять другие действия, чтобы API hammering не мешал анализу. Но оставленный незамеченным, этот метод способен серьёзно нарушить способность песочницы оценивать вредоносную программу.

Создание ненужных процессов

Подобно API hammering, создание ненужных процессов - метод перегрузки песочниц и аналитиков. Вредоносная программа на рис. 8-3 создаёт несколько сотен процессов с именами <xxxx>.tmp, чтобы скрыть настоящую активность.

Рис. 8-3. Вредоносная программа создаёт большое количество "фиктивных" процессов

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

Ложный сетевой обмен

Некоторые варианты вредоносных программ отправляют фиктивный или ложный сетевой трафик, пытаясь скрыть настоящий вредоносный обмен. Применением этого метода хорошо известно семейство Formbook. Formbook подключается к случайно выбранному списку из нескольких ложных веб-адресов и одного настоящего адреса командного сервера (C2), что может запутать аналитиков и песочницы. В некоторых случаях ложные адреса являются настоящими доменами и способны увести аналитика по неверному пути. На рис. 8-4 показано, как Formbook подключается к нескольким ложным адресам C2 посредством обычных HTTP-запросов GET.

Рис. 8-4. Formbook подключается к ложным адресам C2

Как видно, весь трафик выглядит почти одинаково, но только одно из этих соединений ведёт к настоящему серверу C2.

Примечание. Вредоносную программу Formbook можно загрузить из VirusTotal или MalShare по следующему хешу файла:

SHA256: 08ef1473879e6e8197f1eadfe3e51a9dbdc9c892e442b57a3186a64ecc9d1e41

Противодействие перехвату

Многие песочницы и инструменты анализа вредоносных программ используют перехват API, или просто перехват, для изучения поведения. При этом в пространство памяти вредоносной программы внедряется фрагмент кода, называемый перехватчиком. Он перехватывает вызовы функций API, перенаправляет их другой функции или изменяет поведение, а затем передаёт исходной функции. Зачастую этот перехватчик является модулем, обычно в форме DLL, который наблюдает за выполняющимся образцом (рис. 8-5).

Рис. 8-5. Песочница перехватывает выполняющийся вредоносный процесс

В этом примере песочница перехватила процесс выполняющейся вредоносной программы посредством внедрения DLL, то есть DLL перехвата песочницы. Песочница изменяет первые несколько байтов перехватываемой функции внутри user32.dll и вставляет инструкцию перехода jmp. Теперь все вызовы функции в библиотеке user32.dll будут переходить к коду перехватчика в DLL песочницы. Установленный перехватчик позволяет песочнице перехватывать вызовы функций и наблюдать за ними, а также потенциально изменять параметры вызова или возвращаемые значения.

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

В этом перехваченном коде вставленная инструкция перехода гарантирует, что при вызове вредоносной программой функции ReadFile поток выполнения перед исполнением настоящего кода ReadFile будет передан коду перехватчика песочницы (hook_code). Такой тип перехвата называется встроенным. Для внедрения встроенных перехватчиков в целевые процессы песочницы применяют метод под названием внедрение в процесс. Внедрение и различные типы перехвата подробнее рассматриваются в главе 12.

Некоторые аналитические инструменты, например API Monitor и отдельные подключаемые модули отладчиков, используют перехватчики в сходных целях. Один из примеров - популярный инструмент ScyllaHide, позволяющий обходить методы противодействия отладке во вредоносных программах. ScyllaHide подробнее рассматривается в главе 10. В этом разделе мы углубимся в некоторые способы, которыми вредоносная программа способна обнаруживать и обходить перехват и наблюдение.

Обнаружение перехвата

Перед выполнением вредоносная программа, скорее всего, попытается определить, не перехвачена ли она песочницей или аналитическим инструментом, сканируя собственную память в поисках внедрённых модулей перехвата. В главе 7 вы видели, как программа может вызвать такие функции, как Module32First и Module32Next, чтобы перечислить загруженные модули. Для обнаружения перехвата образец может отслеживать, какие модули он должен загрузить, и, если при перечислении обнаружит аномальный загруженный модуль, предположить, что его перехватывают или иным образом наблюдают за ним.

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

Сначала код получает дескриптор ntdll.dll и адрес NtAllocateVirtualMemory. Затем он вызывает ReadProcessMemory, чтобы исследовать первый байт функции NtAllocateVirtualMemory. Если первый байт является инструкцией перехода, шестнадцатеричным E9, вредоносная программа предполагает, что NtAllocateVirtualMemory перехвачена и за ней наблюдает песочница либо аналитический инструмент.

Мы ещё вернёмся к этому методу в разделе "Выполнение невыровненных вызовов функций" на с. 140.

Удаление перехвата

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

Во-первых, вредоносная программа может вручную выгрузить все подозрительные модули, то есть внедрённые DLL перехвата, которые, по её оценке, загружены в адресное пространство процесса. Обнаружив аномальный модуль, она может вызвать функцию FreeLibrary. Параметром FreeLibrary служит дескриптор библиотечного модуля, который программа хочет выгрузить.

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

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

В этом коде вредоносная программа получает адрес (GetProcAddress) библиотеки и функции, с которых хочет удалить перехват, в данном случае NtAllocateVirtualMemory, а затем вызывает VirtualProtect, подготавливая функцию к изменению и предоставляя ей разрешения на выполнение, чтение и запись. После этого программа копирует (memcpy) четыре байта (\x4c\x8b\xd1\xb8) в начало кода целевой функции. Это стандартные исходные неперехваченные байты, которые находились бы в целевой функции до перехвата песочницей. Наконец, программа вновь вызывает VirtualProtect, чтобы вернуть исходные разрешения памяти.

Некоторые песочницы знают, что вредоносная программа может попытаться удалить установленные перехватчики функций, и следят за этим. Подобно тому как программа сканирует память своего процесса в поисках признаков перехвата, песочницы способны периодически проверять, на месте ли их перехватчики, и при необходимости заменять их. Либо они могут наблюдать за поведением удаления перехватов, в частности за вызовами ReadProcessMemory, WriteProcessMemory, memcpy, FreeLibrary и других функций.

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

Обход перехвата

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

Выполнение невыровненных вызовов функций

При невыровненном вызове вредоносная программа косвенно вызывает функции, перепрыгивая через код перехватчика песочницы и фактически полностью его пропуская. Обычно программа вызывает функцию Windows API, например ReadFile, инструкцией call (call ReadFile). Она переходит к началу ReadFile внутри модуля kernel32.dll и выполняет код. Однако если ReadFile перехвачена песочницей, сначала выполнится код перехватчика, как обсуждалось ранее. В следующем фрагменте в функцию внедрён перехватчик:

Чтобы реализовать невыровненный вызов, вредоносная программа может напрямую перейти к адресу 0x77000005 инструкцией jmp 0x77000005 либо прибавить 5 байт к базовому адресу, как в jmp 0x77000000 + 0x5, вместо обычного вызова ReadFile. Так она пропустит перехватывающую инструкцию jmp по адресу 0x77000000 и непосредственно выполнит настоящий код ReadFile, начинающийся с 0x77000005.

Одно затруднение состоит в том, что вредоносная программа должна явно указать адрес функции, а значит, заранее его знать. Один из способов получить адрес - вызвать GetProcAddress, как в следующем упрощённом ассемблерном коде:

Образец вызывает GetProcAddress, чтобы получить адрес нужной целевой функции, а затем сохраняет значение в address (mov address, eax). Адрес указывает на начало функции, где программа проверяет наличие перехватчиков. Затем она сравнивает код по адресу с шестнадцатеричным значением 0E9h, одним из ассемблерных кодов операции jmp. Если код операции присутствует, программа переходит к функции skip_hook, которая добавляет к адресу целевой функции 5 байт и сохраняет указатель на конечный адрес в EAX (lea eax, [address+5]). Наконец, код переходит к новому адресу (jmp eax), обходя перехватчик.

Вызов низкоуровневых и необычных функций

Чтобы обойти перехват в песочницах и аналитических инструментах, некоторые вредоносные программы вызывают низкоуровневые функции Native API, пытаясь избежать чаще перехватываемых высокоуровневых вызовов. Например, программа может напрямую вызвать NtProtectVirtualMemory вместо VirtualProtect, стремясь обойти перехватчики последней.

В качестве альтернативы вредоносная программа способна даже выполнять прямые системные вызовы в ядро, обходя обычные процедуры вызова WinAPI. Системные вызовы обсуждались в главе 1. Некоторые песочницы могут не наблюдать прямые обращения к ядру, и это оставляет слепые зоны в их аналитических отчётах. Поскольку данный метод также применяется для обхода средств защиты конечных точек, мы подробно вернёмся к нему в главе 13.

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

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

Сокеты

Большинство современных приложений Windows используют высокоуровневые библиотеки сетевого обмена, такие как WinINet (Wininet.dll), WinHTTP (Winhttp.dll) и URLMon (Urlmon.dll). Они же относятся к библиотекам интернет-обмена, чаще всего загружаемым вредоносными программами; фактически их использует большинство примеров в этой книге. Главное преимущество этих библиотек для авторов вредоносных программ состоит в простоте применения и реализации.

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

В этом простом примере образец создаёт сокет (sock) с параметрами, задающими IPv4 (AF_INET), ориентированные на соединение байтовые потоки (1) и протокол TCP (6). Затем программа пытается подключиться к удалённому серверу (connect), указывая sock и указатель на таблицу sockaddr, где находятся сведения об удалённой службе, например имя узла и номер TCP-порта. Наконец, программа отправляет данные (send) удалённому серверу, указывая указатель data, содержащий предназначенные для отправки сведения.

Подробности устройства и работы сокетов выходят за рамки книги. Дополнительные сведения о сокетах и всех возможных параметрах можно найти в MSDN.

Ручная загрузка библиотек и вызов функций

Вредоносная программа может также вручную загружать библиотеки Windows, не полагаясь на стандартный загрузчик. Как вы, возможно, помните из главы 1, обычный способ загрузки библиотек приложениями Windows состоит в применении таких функций, как LoadLibrary. LoadLibrary отображает запрошенную библиотеку в память, обеспечивая быстрый и простой процесс загрузки, всю тяжёлую работу в котором выполняет ОС. Обратная сторона этой простоты в том, что песочницы и другие аналитические инструменты могут легко реализовать в библиотеке перехватчики вызовов функций.

Чтобы обойти их, вредоносная программа способна вручную отобразить файл библиотеки в адресное пространство своего процесса посредством NtMapViewOfSection, как показано в упрощённом псевдокоде:

В этом примере вредоносная программа использует NtCreateFile, чтобы получить дескриптор файла C:\Windows\System32\Ntdll.dll, то есть библиотеки, которую хочет загрузить. Затем программа создаёт объект раздела посредством NtCreateSection и ссылается на ранее полученный дескриптор файла. Объект раздела - область памяти, которая может совместно использоваться другими процессами и предоставляет способ отображения файла в эту память. После создания объекта раздела вредоносная программа отображает в него файл ntdll.dll с помощью NtMapViewOfSection. Переменная process_handle представляет целевой процесс, куда будет отображён файл. В данном случае это собственный процесс вредоносной программы.

Другой сходный метод состоит в чтении файла с диска, а не в отображении в память. Чтобы прочитать ntdll.dll с диска, вредоносная программа может вызвать ReadFile или NtReadFile и передать имя целевого файла в качестве параметра. В любом из двух методов после отображения или чтения библиотеки в память программа способна выполнить нужные функции переходом к адресам в целевой библиотеке либо их вызовом. Обратите внимание, что в готовом виде эти методы не сработают и потребуют дополнительных действий от вредоносной программы, например правильного определения смещений вызываемых функций внутри DLL.

Создание собственных функций

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

Инструментарий противодействия перехвату

Существуют и инструменты, написанные специально для противодействия перехвату. Один из примеров - проект с подходящим названием anticuckoo (https://github.com/therealdreg/anticuckoo), который различными методами обнаруживает возможный перехват песочницей. Кроме того, инструмент позволяет пользователям эксплуатировать песочницу, изменяя код перехваченной функции и, возможно, повреждая стек памяти, что приводит к сбою песочницы. Судя по всему, проект больше не поддерживается, но он служит хорошим примером исследования противодействия перехвату песочниц. Дополнительные сведения об этом методе приведены в содержательной публикации "Prevalent Threats Targeting Cuckoo Sandbox Detection and Our Mitigation" по адресу https://www.fortinet.com/blog/threat-research/prevalent-threats-targeting-cuckoo-sandbox-detection-and-our-mitigation.

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

Обход анализа в песочнице

Из-за автоматизированной природы песочницы уязвимы для тактик уклонения на метауровне, под которым я подразумеваю уровень самого продукта-песочницы, а не его реализации или лежащей в основе ОС. Например, некоторые песочницы ограничивают размер отправляемых файлов, поэтому авторы могут просто искусственно увеличить вредоносный файл и обойти их. Другие песочницы не умеют обрабатывать определённые типы файлов или сценарии. Всё чаще вредоносные файлы доставляются по электронной почте в зашифрованном виде, а пароль для расшифровки находится в тексте письма. Конечный пользователь может с радостью ввести пароль, расшифровать файл и запустить вредоносную программу, но для песочницы это намного сложнее!

Кроме того, некоторые песочницы плохо наблюдают за определёнными типами файлов. На момент написания книги многие коммерческие песочницы и проекты с открытым исходным кодом не полностью поддерживают Microsoft .NET, кроссплатформенную среду разработки для Windows. Поскольку .NET реализует собственные функции, отличающиеся от функций штатных Windows API и NT API, такие песочницы могут пропустить важные подробности поведения и функциональных возможностей вредоносной программы.

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

Нарушение ручного исследования

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

Чтобы завершить целевой процесс, вредоносная программа может обойти дерево процессов посредством CreateToolhelp32Snapshot, Process32First и Process32Next, как вы видели в главе 4. Затем она способна вызвать OpenProcess, чтобы получить дескриптор процесса-жертвы, а следом TerminateProcess. Следующий ассемблерный пример показывает, как образец может завершить удалённый процесс:

В этом фрагменте вредоносная программа вызывает OpenProcess с параметрами, представляющими идентификатор целевого процесса, здесь wireshark.exe, значение InheritHandle, не имеющее здесь значения, и dwDesiredAccess, то есть права доступа к процессу, запрашиваемые вредоносным процессом. В данном случае программа запрашивает права доступа 1, или шестнадцатеричное 0x1, что соответствует PROCESS_TERMINATE и позволяет вызывающему процессу, то есть вредоносной программе, завершить другой процесс (wireshark.exe). Разумеется, Wireshark здесь всего лишь пример. При наличии правильных разрешений вредоносная программа способна запросить и завершить любой процесс.

Примечание. Иногда переименование исполняемого файла инструмента анализа перед запуском обманывает простую вредоносную программу, применяющую данный метод. Например, переименование wireshark.exe в krahseriw.exe может помешать вредоносной программе "увидеть" этот процесс и тем самым предотвратить его завершение. Однако решение сработает не во всех случаях.

Ещё одна тактика - дезориентация аналитика. Один интересный исследованный мной образец создаёт каталог в C:\Users\<user>\AppData\Local\Temp. Программа присваивает каталогу случайно сгенерированное числовое имя, например 21335493, и записывает в него временные файлы, необходимые для своих функциональных возможностей. Чтобы защитить каталог, программа постоянно перечисляет все открытые окна, специально разыскивая те, в которых упоминается имя временного каталога, и при совпадении отправляет окну запрос на завершение.

Вот упрощённый псевдокод этого метода в действии:

Этот образец использует EnumWindows для перечисления всех окон рабочего стола, а затем в цикле перебирает текст их заголовков с помощью GetWindowText, разыскивая строку 21335493. Если код находит окно, содержащее этот текст, вредоносная программа вызывает функцию PostMessage с параметром WM_CLOSE, принудительно закрывая окно. Теперь, если аналитик попытается открыть временный каталог 21335493, скажем в Проводнике, окно автоматически закроется прежде, чем он успеет исследовать содержимое.

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

Эксплуатация гипервизора и побег из VM

Последний метод этой главы можно считать высшей формой уклонения от песочницы и VM: эксплуатация самого гипервизора или полный побег из него. Хотя во вредоносных программах это встречается редко, метод время от времени применялся в реальных атаках, а в таких продуктах, как VMware и VirtualBox, обнаруживались отдельные уязвимости. Один примечательный пример - Cloudburst, эксплойт, разработанный Immunity Inc. в 2009 году и затрагивавший определённые версии гипервизоров VMware. Воспроизведение специально созданного видеофайла в Windows VM эксплуатировало недостаток функций отображения VMware и потенциально позволяло выполнить код в самой основной ОС.

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

Примечание. Я говорю "теоретически", поскольку всегда существует вероятность уязвимостей нулевого дня и неизвестных неопубликованных ошибок в коде гипервизора, которые потенциально способна эксплуатировать вредоносная программа. Анализ всегда сопряжён с риском, но, на мой взгляд, преимущества его перевешивают. В приложении A мы обсудим несколько шагов, позволяющих работать в максимально безопасной среде.

Меры противодействия уклонению

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

Песочницы способны предупреждать аналитиков о попытках обнаружения и уклонения, открывая окно во внутреннее устройство вредоносной программы и позволяя правильно отреагировать. Многие подобные методы можно обойти вручную: подключить процесс к отладчику, установить точки останова на интересующих вызовах функций и изменить код вредоносной программы в самом отладчике либо дизассемблере. Вызовы можно заменить на nop, перепрыгнуть через них или изменить посредством манипулирования параметрами функций либо возвращаемыми значениями, как объяснялось в главе 3. Наконец, многие методы обходятся правильной настройкой VM и гипервизора. Как это сделать, я расскажу в приложении A.

Итоги

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

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

Нарушение работы дизассемблеров

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

Например, байты e8 8c 45 0a 90 можно дизассемблировать в инструкцию call. Удаление первого байта (e8) привело бы к совершенно другой дизассемблированной инструкции. В этом распространённом подходе противодействия дизассемблированию, известном как метод постороннего байта, в программу вставляются посторонние байты, чтобы запутать процесс дизассемблирования. Рассмотрим следующий фрагмент:

В правом столбце показаны несколько дизассемблированных инструкций, в среднем - составляющие их байты, а в левом - смещения адресов. Эти дизассемблированные инструкции не имеют особого смысла. Например, здесь есть инструкция перехода при нуле (jz) с целевым адресом loc_402109 + 1. Такой переход произойдёт всегда, поскольку предшествующая jz инструкция mov устанавливает eax равным 0, но код переходит ко второму байту следующей инструкции, то есть байту 8b. Кроме того, код содержит инструкцию call по адресу, которого в данном исполняемом файле даже не существует: файл находится в диапазоне адресов 0x00402xxx, а не 0x900xxxxx. Рассмотрим внимательнее.

Как объяснялось в главе 3, дизассемблер не всегда умеет отличить код от данных. Это означает, что при преобразовании байтов в код получившийся код в действительности может быть данными или наоборот. Инструкция call 0x900a4590 состоит из байтов e8 8b 45 0a 90. Первый байт, e8, представляет инструкцию call в наборе инструкций x86. Если его убрать, останутся 8b 45 0a 90. В x86 эта последовательность байтов эквивалентна следующему коду:

Здесь имеется инструкция mov, которая перемещает хранящееся в стеке по адресу ebp+10 значение в eax, а затем инструкция nop. Такой код имеет гораздо больше смысла, чем исходный вызов (call 0x900a4590). Следовательно, первый байт (e8), по-видимому, является посторонним байтом, добавленным в код лишь для того, чтобы запутать дизассемблеры.

С этим можно справиться, переопределив неверный код или данные. В IDA можно нажать клавиши C и D: C преобразует данные в код, а D - код в данные. В Ghidra, как ни странно, всё наоборот: нажмите C, чтобы преобразовать код в данные, поскольку здесь C означает "очистить байты кода", и D, чтобы преобразовать данные в код, поскольку D означает "дизассемблировать".

Если выбрать в IDA ложную инструкцию call и нажать D, она будет разбита на данные, как показано ниже:

Обратите внимание: то, что прежде было кодом, теперь является байтами данных, начинающимися с 1. Если теперь выбрать значения байтов, начиная со смещения 0040210A, не захватывая байт e8, и до 0040210D, а затем нажать C для преобразования в код, получится следующее:

Вредоносная программа перемещает 0x00 в eax, чтобы обнулить eax, а затем использует условный переход (jz); как отмечалось ранее, код всегда выполнит этот переход. Однако теперь он перепрыгивает через посторонний байт (e8) и вместо него выполняет инструкции mov и nop. Вредоносная программа хитро вставила посторонний байт, чтобы обмануть дизассемблер и заставить его считать байт частью исходной инструкции call!

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

Обфускация потока управления

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

Для добавления такой обфускации авторы применяют специализированные обфускаторы кода, предназначенные именно для этой цели, либо упаковщики вредоносных программ, которые подробно рассматриваются в главе 17. Изучим некоторые распространённые способы обфускации потока управления. В конце раздела мы обсудим несколько общих стратегий работы с такими тактиками.

Ненужные переходы

Авторы вредоносных программ могут добавлять ненужные инструкции перехода, чтобы разбить код на небольшие блоки (рис. 9-1).

Рис. 9-1. Ненужные инструкции перехода

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

Обфускаторы могут также заставлять код часто переходить вперёд и назад, затрудняя последовательное отслеживание, как в следующем примере:

Этот код перескакивает между разными областями исключительно ради создания путаницы. Сначала он переходит к loc_402B20, затем назад к loc_402A30, а после снова вперёд к loc_402B65, создавая трудную для отслеживания логику потока управления.

Ненужный код

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

Рис. 9-2. Взаимозаменяемые блоки кода

Это не влияет на поведение вредоносной программы, но создаёт сложности для специалистов по обратной разработке.

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

Код просто увеличивает регистр ecx на 1, помещает значение в стек, уменьшает его на 1 и снова помещает в стек. Очевидно, он не служит никакой полезной цели.

Уплощение потока управления

Уплощение потока управления - метод обфускации, который сжимает последовательность условных блоков кода в единый блок. Обычно это достигается посредством инструкций switch, направляющих поток управления. На рис. 9-3 показана программа до уплощения потока управления.

Рис. 9-3. Программа до применения уплощения потока управления

Эта программа представляет обычный необфусцированный код. В блоке кода 1 есть условная инструкция, которая перейдёт в одно из двух мест, блок кода 2 или 3. После обработки алгоритмом уплощения потока управления программа могла бы выглядеть скорее как на рис. 9-4.

Рис. 9-4. Программа после применения уплощения потока управления

На рис. 9-3 блок кода 1 отвечал за условную инструкцию, которая приводила к переходу либо к блоку 2, либо к блоку 3. В уплощённом коде центральный диспетчерский блок 1 отвечает за условную инструкцию, но также отслеживает, куда код должен "течь" дальше. После того как диспетчер направляет поток управления к блоку кода, управление возвращается диспетчеру, который направляет поток далее. Диспетчер усложняет дизассемблированный код, затрудняя аналитику понимание его назначения и следующего направления выполнения.

Непрозрачные предикаты

Непрозрачный предикат (рис. 9-5) - значение, известное автору программы, но неизвестное самой программе или дизассемблеру во время выполнения. Например, создатель программы, в нашем случае автор вредоносной программы, знает, что определённое выражение даст конкретное значение, однако ни мы, специалисты по обратной разработке, ни наши дизассемблеры этого не знаем.

Рис. 9-5. Непрозрачный предикат в действии

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

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

Злоупотребление указателем возврата

Ещё один способ обфусцировать поток управления - инструкции возврата (ret). Например, если программа выполняет функцию B, то, достигнув её конца, функция B выдаст инструкцию ret, чтобы вернуться к родительской функции A. Но прежде чем функция B сможет вернуться, программа должна знать адрес возврата. Поэтому до выполнения функции B этот адрес помещается в стек, а при выполнении ret извлекается оттуда. Следующий ассемблерный код демонстрирует это:

Код выполняет инструкцию push, помещая returnAddress в стек, а затем ret, которая извлекает returnAddress со стека и возвращает поток управления родительской функции.

Вредоносная программа может злоупотреблять работой указателей возврата, имитируя инструкцию call или jmp. Поместив адрес в стек, а затем выполнив ret, программа заставит поток управления выполнить код по новому адресу возврата. Это способно запутать некоторые дизассемблеры и в целом затрудняет аналитику отслеживание кода.

Злоупотребление обработчиком SEH

Вредоносная программа может воспользоваться и обработчиком структурированных исключений (SEH), который хранит ряд адресов фрагментов кода, отвечающих за обработку исключений в приложениях Windows. Когда приложение вызывает исключение, его поток управления передаётся по одному из адресов, сохранённых в SEH.

Вредоносная программа способна злоупотребить SEH, создав новый обработчик исключений, указывающий на вредоносный код. Когда программа намеренно вызывает исключение в своём коде, поток управления передаётся коду, на который ссылается обработчик. Поэтому для правильной обратной разработки аналитик должен знать, где программа установила обработчик исключений и куда тот указывает. Рассмотрим пример:

В центре внимания этого блока находится fs:[0], который, по существу, указывает на текущий обработчик исключений. Вредоносная программа заменяет код обработчика по умолчанию указателем на вредоносный код (evil.429D8C). После того как программа вызовет исключение, поток управления передастся по адресу evil.429D8C. Поскольку здесь не используются инструкции jmp, ret или call, неподготовленному взгляду трудно проследить такую передачу, поэтому обращайте внимание на код, ссылающийся на fs:[0]. Кроме того, после него часто встречается инструкция div, которая может означать, что программа пытается вызвать исключение деления на ноль. SEH и этот конкретный блок кода подробнее рассматриваются в главе 11.

Злоупотребление указателем функции

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

Образец перемещает адрес смещения функции sub_4511D5 в переменную var_26 в стеке. Затем он применяет инструкцию call, ссылаясь на переменную var_26, которая содержит адрес нужной целевой функции (sub_4511D5).

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

Меры противодействия обфускации потока управления

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

Во-вторых, пошаговое выполнение кода в отладчике может полностью изменить ситуацию; обычно оно значительно облегчает понимание кода и потока управления. Отладчик можно применять вместе с дизассемблером и устанавливать точки останова по адресам кода, который вы понимаете не полностью. Например, при обнаружении постороннего байта отладчик поможет выяснить происходящее. Именно поэтому некоторые аналитики предпочитают дизассемблер со встроенным отладчиком, такой как IDA Pro, но отдельные дизассемблер и отладчик тоже отлично подойдут. Я обычно сочетаю x64dbg с Ghidra или IDA.

В-третьих, можно попытаться определить обфускатор, применённый к вредоносной программе. Например, инструменты Detect It Easy (DIE) и Exeinfo PE пытаются выявить возможные обфускаторы и упаковщики, рассматриваемые в главе 17. После идентификации обфускатора или упаковщика небольшое исследование принципов его работы может подсказать, как обратить преобразование; возможно, существует даже общедоступный деобфускатор! Некоторые инструменты пытаются обобщённо деобфусцировать код и устранить часть сложности, но, по моему опыту, они работают не очень хорошо и способны оставлять пробелы в коде или неправильно его интерпретировать. Наконец, различные дизассемблеры склонны разбирать код несколько по-разному. Если вы в основном используете IDA, попробуйте Ghidra или другой дизассемблер и посмотрите, не окажется ли результат понятнее.

В конечном счёте работа с противодействием дизассемблированию требует знания и опыта работы с языком ассемблера, и ничто их не заменит. Изучение ассемблера x86, x64 или архитектуры исследуемой вредоносной программы и дальнейшее развитие навыков помогут быстрее распознавать применяемые методы противодействия дизассемблированию и обфускации кода.

Обфускация вызовов API и строк

В этом разделе вы узнаете, как вредоносная программа может обфусцировать вызовы функций Windows API и строки, скрывая свои намерения от аналитиков.

Примечание. В этом разделе описаны методы обфускации, относящиеся именно к противодействию дизассемблированию и защите от статического анализа, тогда как в главе 16 рассматриваются более общие методы обфускации. Обфускация вызовов API и строк может также применяться для обхода средств защиты конечных точек, например защитного ПО, но эта тема подробнее обсуждается в части IV.

Динамическое разрешение функций API

Динамическое разрешение функций API - получение программой во время выполнения адреса функции, которую она хочет вызвать, вместо включения функции в таблицу адресов импорта (IAT). В этом может помочь функция Windows API GetProcAddress. Она получает процедурный адрес функции внутри заданного модуля и принимает два параметра: дескриптор модуля, где находится целевая функция, и имя самой функции. Иногда GetProcAddress предшествует вызов LoadLibrary, который загружает содержащий целевую функцию модуль. Рассмотрим это на практике:

Сначала образец помещает в стек имя модуля, содержащего целевую функцию, в данном случае kernel32.dll, и вызывает LoadLibraryA, которая загружает библиотеку в адресное пространство процесса. LoadLibraryA возвращает дескриптор модуля kernel32.dll, сохраняемый в eax, после чего тот помещается в стек (push eax). Далее код помещает в стек имя целевой функции IsDebuggerPresent и вызывает GetProcAddress. Этот вызов возвращает адрес целевой функции и сохраняет его в eax. Наконец, вредоносная программа выполняет инструкцию call с целью eax, тем самым вызывая IsDebuggerPresent. Как видно, метод добавляет уровень обфускации вызова функции.

Таблицы переходов и косвенные вызовы API

Вызовы API можно обфусцировать таблицами переходов - структурами данных, сопоставляющими адреса внешних библиотек. Таблицы переходов способны одновременно обфусцировать поток управления и затруднять статический анализ кода. На рис. 9-6 показано, как такая таблица может выглядеть в действии.

Рис. 9-6. Таблица переходов в действии

В этом упрощённом примере основной код вредоносной программы выполняет инструкции call по различным адресам, представляющим функции Windows API, которые программа хочет вызвать. Затем поток управления передаётся таблице переходов, которая здесь, по существу, является списком дальнейших инструкций call, использующих GetProcAddress для получения процедурного адреса целевой функции Windows API и последующего её вызова. Например, когда вредоносная программа хочет вызвать WriteFile, она вызывает sub_2082A2B0, которая переходит к таблице, а та, в свою очередь, получает адрес WriteFile в библиотеке kernel32.dll.

Таблица переходов может быть простым списком инструкций call:

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

Вредоносная программа может также применять косвенные вызовы API. Подобно таблицам переходов, адреса функций динамически разрешаются и сохраняются в памяти или регистрах ЦП для последующего использования. Затем программа вызывает функцию инструкцией call по адресу вместо имени. Это видно в следующем упрощённом примере 64-разрядного кода:

Код использует косвенные вызовы для обфускации функций. Сначала он перемещает имя нужной целевой функции (CryptEncrypt) в rdx, а имя связанного модуля (hModule), в котором в случае этих функций находится kernel32.dll, - в другой параметр. Затем код вызывает GetProcAddress, чтобы получить адрес CryptEncrypt, и помещает его в стек (mov [rbp-39], rax) для дальнейшего использования. Процедура повторяется ещё дважды для функций CryptDecrypt и WriteFile.

После сохранения адресов целевых функций в стеке код позднее может вызвать их по адресам следующим образом:

Эта инструкция call вызовет функцию, хранящуюся в стеке по адресу rbp-39, которой оказывается CryptEncrypt, применяемая для шифрования данных. Такой вызов добавляет уровень обфускации для исследователей, вручную выполняющих обратную разработку кода.

Строки в стеке

Строки в стеке - строки, которые вредоносная программа динамически строит в стеке памяти. Они добавляют уровень обфускации исполняемого файла и делают статический анализ немного более трудоёмким:

Этот фрагмент содержит несколько инструкций mov, представляющих перемещение данных в стек. Интересно, что они побайтно перемещают шестнадцатеричные значения в буфер (ebp+file). Если преобразовать значения в ASCII клавишей R в IDA либо выбрав в Ghidra Щелчок правой кнопкой > Convert > Char, строку в стеке можно деобфусцировать следующим образом:

Теперь можно сделать более обоснованное предположение о том, что вредоносная программа делает с этими данными. Она создаёт в стеке строку (evil.dll) и вызывает LoadLibraryA, которая загружает вредоносный DLL-файл в процесс программы. Это форма внедрения в процесс - метода, подробно рассматриваемого в части IV.

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

Другой инструмент для деобфускации строк в стеке, Pestr (https://pev.sourceforge.io), запускается почти так же. Оба инструмента достаточно просты, чтобы быстро применить их до начала обратной разработки, и могут сэкономить время при анализе кода вредоносной программы, реализующей базовую обфускацию строк.

Хеширование данных

Авторы могут обфусцировать функциональные возможности вредоносной программы посредством хеширования данных - разновидности одностороннего кодирования, которое принимает данные и преобразует их во что-то другое, не подлежащее обратному преобразованию. Семейство программ-вымогателей Maze использует хорошо известный алгоритм хеширования ROR-13 для обфускации вызовов функций Windows API, как показано в следующем коде:

Инструкция mov во второй строке помещает в стек хеш ROR-13 7C0DFCAAh, соответствующий GetProcAddress. Аналогичным образом хеш 0EC0E4E8Eh представляет функцию LoadLibraryA и помещается в стек в строке 8. Вредоносная программа обфусцирует вызовы GetProcAddress и LoadLibraryA, используя хеши вместо имён функций. Должна существовать функция, отвечающая за интерпретацию хешей и загрузку адресов целевых функций, в данном случае sub_4011A0, но она не показана в предыдущем коде, а подробности выходят за рамки главы. Однако метод хорошо документирован, например в публикации "Windows API Hashing in Malware" по адресу https://www.ired.team/offensive-security/defense-evasion/windows-api-hashing-in-malware.

Просто просматривая код, трудно понять происходящее, поскольку имена функций хешированы и потому нечитаемы. К счастью, во многих дизассемблерах есть специальные возможности или подключаемые модули для автоматического выявления потенциально хешированных имён функций. В моём случае подключаемый модуль IDA apihashes сумел правильно распознать и аннотировать данные, хешированные ROR-13. Хеширование подробнее рассматривается в главе 16.

Итоги

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

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

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

Применение функций Windows API для доступа к PEB

Как вы узнали в главе 1, блок среды процесса (PEB) - структура, содержащая указатели на сведения в памяти о выполняющемся в данный момент процессе. PEB включает несколько указателей, относящихся к противодействию отладке; они перечислены в табл. 10-1.

Таблица 10-1. Члены PEB, относящиеся к противодействию отладке

Посредством API Windows предоставляет программам огромный объём сведений о своём внутреннем устройстве. Единственное назначение некоторых функций Windows API - сообщить вызывающей программе, подключён ли отладчик, и вредоносная программа легко может этим воспользоваться, заставив функции запросить PEB и определить наличие отладки. Более того, программа способна злоупотребить некоторыми функциями API, чтобы обманом заставить Windows раскрыть подключённый отладчик.

В этом разделе мы рассмотрим несколько распространённых способов, которыми вредоносная программа может применять Windows API и NT API для выявления аналитика, отлаживающего её код. Позднее в главе вы увидите, как программа способна напрямую запросить PEB, поэтому важно иметь хотя бы базовое представление о соответствующих членах структуры.

IsDebuggerPresent и CheckRemoteDebuggerPresent

Одна из самых известных и простых функций Windows для обнаружения отладчиков - IsDebuggerPresent. Она возвращает ненулевое значение, если текущий процесс отлаживается, и 0 в противном случае. Функция CheckRemoteDebuggerPresent возвращает те же сведения, но в виде True или False. Следующий пример показывает возможное применение:

Здесь в стек помещаются два параметра: дескриптор целевого процесса, в данном случае собственного вредоносного процесса hProcess, а затем указатель на переменную, которая примет возвращённые сведения (DebuggerPresent). После вызова CheckRemoteDebuggerPresent возвращённое значение True или False сохраняется в переменной DebuggerPresent. Как вы увидите далее, это одни из самых простых для обхода методов обнаружения отладчика.

NtQueryInformationProcess

Чтобы обнаружить отладчик, CheckRemoteDebuggerPresent вызывает системную функцию NtQueryInformationProcess - низкоуровневую функцию Windows NT, способную возвращать множество различных сведений о системе. NtQueryInformationProcess можно вызвать и напрямую. Она принимает несколько параметров, включая ProcessHandle, то есть дескриптор целевого процесса, и значение ProcessInformationClass, определяющее тип возвращаемых сведений. При обнаружении отладчика значение ProcessInformationClass будет равно 7, или ProcessDebugPort. Ненулевое значение указывает, что процесс в данный момент выполняется под управлением отладчика.

В качестве альтернативы автор может указать класс ProcessInformationClass ProcessDebugFlags (1F). Если процесс отлаживается, флаги отладки будут установлены, что выдаст её вредоносной программе. Наконец, отладчик способен раскрыть и информационный класс ProcessDebugObjectHandle (1E).

NtQuerySystemInformation

NtQuerySystemInformation - функция Windows NT, которую можно использовать, как нетрудно догадаться, для запроса системных сведений. Она способна возвращать множество разных типов данных, а особенно важна для наших целей структура SYSTEM_KERNEL_DEBUGGER_INFORMATION. В ней содержатся два важных значения для обнаружения отладчика: KdDebuggerEnabled и KdDebuggerNotPresent; оба можно применять для выявления отладчика ядра, подключённого к вызывающему процессу. Отладчики ядра - специализированные инструменты для отладки низкоуровневого программного обеспечения, иногда используемые и для анализа вредоносных программ. Если KdDebuggerEnabled возвращает ненулевое значение либо KdDebuggerNotPresent возвращает 0, это может указать вредоносной программе на присутствие отладчика ядра.

OutputDebugString

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

Образец задаёт код ошибки 5 с помощью SetLastError, затем вызывает OutputDebugString со случайной строкой testing123. После этого программа вызывает GetLastError, чтобы получить последний код ошибки, и сравнивает его с кодом предыдущего вызова SetLastError. Если OutputDebugString выполнилась успешно и без ошибки, код GetLastError должен остаться равным 5, а значит, присутствует отладчик. Это старый метод, но вредоносные программы время от времени всё ещё пытаются его применять.

CloseHandle и NtClose

Если образец отлаживается и пытается вызвать функцию CloseHandle или NtClose с недействительным дескриптором, будет вызвано исключение EXCEPTION_INVALID_HANDLE. После этого оно передастся обработчику исключений отладчика, сообщив вредоносной программе, что она отлаживается. Следующий простой код демонстрирует метод:

Код вызывает NtClose с недействительным дескриптором в качестве параметра. При выполнении это вызовет исключение и сообщит вредоносной программе, что она отлаживается.

NtQueryObject

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

Первый параметр функции, Handle, - дескриптор объекта, сведения о котором запрашиваются. Второй параметр, NtQueryObject, принимает значение ObjectInformationClass, сообщающее функции тип возвращаемых данных. Третий параметр, ObjectInformation, принимает указатель на область хранения возвращённых данных.

Если вы видите, что вредоносная программа вызывает NtQueryObject, передаёт значение ObjectInformationClass, равное 3 (ObjectAllTypesInformation), а затем исследует буфер ObjectInformation в поисках строк наподобие DebugObject, можно с достаточной уверенностью сказать, что она пытается выявить отладчик.

Флаги кучи

PEB содержит указатели на структуру кучи памяти процесса, известную как куча процесса, по адресу 0x18 (0x30 для 64-разрядных процессов). Куча содержит различные члены, являющиеся указателями на дополнительные данные; два из них, Flags и ForceFlags, указывают на блок данных, предоставляющий ядру Windows сведения о памяти кучи процесса. В Windows 7 и более новых версиях, если процесс отлаживается, значение члена Flags равно 0x40000062, а ForceFlags - 0x40000060. Чтобы обнаружить отладчик, вредоносная программа может попытаться прочитать эти значения в структуре кучи вызовом RtlQueryProcessHeapInformation или RtlQueryProcessDebugInformation либо прочитать PEB вручную, как будет описано в следующем разделе.

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

Прямой доступ к PEB

Вместо использования описанных в предыдущем разделе функций Windows вредоносная программа может напрямую обращаться к PEB и читать его, как показано в следующем ассемблерном коде:

Чтобы получить адрес PEB для чтения, вредоносная программа перемещает адрес fs:0x30 в eax. Как вы, возможно, помните из главы 1, fs:0x30 - адрес начала PEB. Затем программа сравнивает значение 1 со значением eax+0x2, то есть полем BeingDebugged структуры PEB. Если оно равно 1, к процессу, вероятно, подключён отладчик, и вредоносная программа может соответствующим образом отреагировать.

Другой пример ручного чтения PEB связан с NtGlobalFlag, расположенным в байте 0x68 PEB и содержащим сведения о создании куч памяти. Когда процесс запускается под управлением отладчика, значение NtGlobalFlag равно 0x70, поэтому вредоносная программа может прочитать его в PEB для быстрой проверки отладчика.

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

Проверки времени

В главе 7 проверки времени описывались именно в контексте обнаружения песочниц и сред VM, но их можно применять и для выявления отладчиков. Три распространённых временных метода - GetTickCount, инструкция rdtsc и проверки системного времени.

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

Аналогичным образом можно применять инструкцию rdtsc. Размещая её в разных частях кода, вредоносная программа способна по временным характеристикам ЦП определить, отлаживается ли она (см. снимок x64dbg на рис. 10-1).

Рис. 10-1. Вредоносная программа применяет rdtsc как метод противодействия отладке

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

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

Системные артефакты

Вредоносная программа может обнаружить отладчик по таким системным артефактам, как окна рабочего стола, разделы реестра и загруженные модули. В этом разделе мы кратко рассмотрим каждый из них; полезно также вернуться к части II, где рассказывалось о поиске программой подобных артефактов.

Поиск окон отладчиков

В главе 5 обсуждалось, как вредоносная программа может обнаруживать инструменты аналитика посредством таких функций, как FindWindow, которая находит окно рабочего стола, и EnumWindows, перечисляющая открытые окна. Эти функции можно использовать и специально для поиска окон отладчиков. Например, программа может вызвать FindWindow, чтобы перечислить открытые окна с названиями отладчиков, такими как x64dbg, OllyDbg или Immunity Debugger. На рис. 10-2 показано, как вариант программы-вымогателя Satan ищет открытые окна OllyDbg.

Рис. 10-2. Вредоносная программа Satan ищет окна, связанные с OllyDbg

Перечисление загруженных модулей

При подключении вредоносной программы к отладчику тот может загрузить модули в её адресное пространство; например, отладчик WinDbg способен загрузить библиотеку dbghelp.dll. Вредоносная программа может найти подозрительный модуль, вызвав функцию GetModuleHandle и передав имя модуля, например dbghelp.dll, в качестве параметра. В качестве альтернативы она может перечислить все загруженные модули посредством Module32First и Module32Next, а затем найти определённое имя.

Поиск процессов отладчиков

Вредоносная программа способна также перечислить выполняющиеся на узле процессы в поисках отладчиков. Для этого она может вызвать CreateToolhelp32Snapshot, Process32First и Process32Next, а затем специально искать распространённые имена процессов отладчиков, например ollydbg.exe, x64dbg.exe или ida64.exe.

Проверка родительских процессов

Чтобы обнаружить отладчик, вредоносная программа может проверить свой родительский процесс. Если она работает внутри отладчика, родительским будет его процесс. Обнаружив выполнение в качестве дочернего процесса отладчика, например x64dbg.exe, вредоносная программа определит, что её отлаживают.

Определить родительский процесс можно несколькими способами. Один подход - получить собственный идентификатор процесса (GetCurrentProcessId), сделать снимок всех выполняющихся процессов (CreateToolhelp32Snapshot) и с помощью Process32First и Proces32Next найти собственное имя. После обнаружения процесса структура снимка будет содержать запись th32ParentProcessID, представляющую идентификатор родительского процесса.

Аналогичным образом вредоносная программа способна создать дочерний процесс посредством CreateProcess, сделав свой исходный процесс родительским для нового. Затем дочерний процесс может вызвать DebugActiveProcess с родительским процессом в качестве параметра. Если родительский, то есть исходный вредоносный, процесс уже отлаживается, функция выдаст исключение наподобие STATUS_PORT_ALREADY_SET, сообщив программе о подключённом отладчике.

Обнаружение точек останова и ловушки

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

Обнаружение отладчиков с помощью точек останова

Когда отладчик достигает в программе инструкции точки останова, например одной из самых распространённых int 3, выполнение останавливается в соответствующем месте кода. Это происходит потому, что инструкция вызывает в программе исключение прерывания, которое в конечном счёте передаёт управление отладчику. Однако если программа не отлаживается, инструкция точки останова вызывает EXCEPTION_BREAKPOINT, и поток управления передаётся стандартному обработчику исключений программы.

Это отличный способ проверить наличие отладки. Если вредоносная программа выполняет int 3 без отладчика, будет вызвано EXCEPTION_BREAKPOINT и запустится обработчик исключений. Разумеется, верно и обратное. Если EXCEPTION_BREAKPOINT не вызывает обработчик, программа может сделать вывод, что отлаживается. Рассмотрим следующий упрощённый псевдокод:

Псевдокод содержит простую конструкцию try...catch. Вредоносная программа пытается выполнить инструкцию int 3 1, и, если оператор успешно возвращается без вызова обработчика исключений, предполагает, что работает в отладчике. Если же инструкция вызывает исключение 2, программа может уверенно считать, что к отладчику не подключена.

Обнаружение и обход программных точек останова

Вредоносная программа способна напрямую обнаруживать точки останова посредством их сканирования. В следующем ассемблерном примере она сканирует код в поисках инструкции int 3, то есть шестнадцатеричного 0xCC:

Образец пытается определить, установил ли аналитик программную точку останова на функции WriteProcessMemory. Сначала он перемещает адрес WriteProcessMemory в регистр ebx. Затем сравнивает значение 0xCC, инструкцию точки останова int 3, с первым байтом в ebx, то есть началом функции WriteProcessMemory, где будет находиться точка останова. Обнаружив программную точку, вредоносная программа может попытаться перезаписать или удалить её.

Некоторые методы обнаружения можно преодолеть применением необычных инструкций точек останова. Такая возможность есть во многих отладчиках. В x64dbg просто перейдите к Options > Settings > Engine и задайте нужную инструкцию в поле Default Breakpoint Type, как показано на рис. 10-3.

Рис. 10-3. Настройка стандартного типа точки останова в x64dbg

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

Обнаружение и обход аппаратных точек останова и точек останова памяти

Подобно программным, аппаратные точки позволяют аналитикам перехватывать вызовы функций, останавливаться на интересном поведении и в целом управлять выполнением вредоносной программы. Поскольку аппаратные точки реализованы в регистрах ЦП (DR0 - DR3), а не в виде инструкций, программа может сканировать эти регистры. Если любой из них содержит данные, точнее адрес памяти, вредоносная программа может предположить, что установлена аппаратная точка, и предпринять действия по уклонению, например очистить регистры, тем самым фактически удалив точки. Один способ найти аппаратные точки - функция GetThreadContext либо Wow64GetThreadContext для 64-разрядных программ:

В этом псевдокоде, адаптированном из https://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide, вредоносная программа определяет новую структуру CONTEXT (context) - структуру Windows для хранения состояния ЦП и связанных данных процесса. Она необходима для хранения данных регистров отладки DR0 - DR3, которые вскоре будут проверены. Далее программа указывает, что GetThreadContext должна вернуть CONTEXT_DEBUG_REGISTERS. Затем она получает дескриптор текущего потока (HANDLE) и вызывает GetThreadContext, которая сохраняет CONTEXT_DEBUG_REGISTERS текущего потока в структуре context. Наконец, образец проверяет наличие данных в регистрах отладки. Если они ненулевые, проверка возвращает true, сообщая вредоносной программе об аппаратной точке останова, установленной отладчиком.

Затем программа может полностью удалить все обнаруженные аппаратные точки посредством SetThreadContext или Wow64SetThreadContext для 64-разрядной вредоносной программы. Добавление следующих строк к предыдущему примеру фактически очистит регистры отладки и тем самым удалит аппаратные точки аналитика:

Наконец, вредоносная программа способна обнаруживать точки останова памяти с помощью функции ReadProcessMemory. Установка такой точки изменяет страницу памяти, поэтому, если программа вызывает ReadProcessMemory для подозрительной страницы и получает неожиданное значение вроде PAGE_NOACCESS или PAGE_GUARD, она может сделать вывод, что на странице установлена аппаратная точка останова. Другой способ добиться того же эффекта - выполнить VirtualQuery, VirtualQueryEx или NtQueryVirtualMemory. Подробнее точки останова памяти обсуждаются в следующем разделе.

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

Применение защиты страниц памяти для обнаружения точек останова

Защита страницы памяти - специальный флаг Windows для доступа к памяти. При выделении новых страниц программа может добавить флаг PAGE_GUARD как своего рода систему сигнализации о доступе. Когда программа или другая программа обращается к этой области памяти, вызывается исключение STATUS_GUARD_PAGE_VIOLATION. Если программа работает под управлением отладчика, PAGE_GUARD часто ведёт себя немного иначе, поскольку исключение обрабатывает отладчик, и обычное исключение не вызывается.

Вредоносная программа может воспользоваться этим, установив защиту для определённых страниц памяти. Если к ним обращаются извне отладчика, то есть программа не отлаживается, исключение вызывается обычным образом. Если же исключения нет, в зависимости от используемого отладчика и его настроек это может сообщить вредоносной программе об отладке. Для установки защиты страниц программа может вызвать VirtualProtect со значением PAGE_GUARD (0x100). Следующий код показывает вызов VirtualAlloc с заданным параметром:

Код вызывает VirtualAlloc со значением flNewProtect, равным 0x104, то есть сочетанием защит 0x100 (PAGE_GUARD) и 0x4 (READ/WRITE). Выделение памяти и VirtualAlloc подробнее рассматриваются в части IV, особенно в главе 17.

Применение ловушек точек останова

Вредоносная программа может вставить в код инструкции точек останова, например int 3 и int 2d, чтобы заставить отладчик часто останавливаться и создать множество проблем аналитику. Постоянные остановки превращают отладку в головную боль. Намеренно размещённые во вредоносной программе инструкции точек останова иногда называют ловушками.

На рис. 10-4 показан образец Dridex в x64dbg, использующий метод ловушек int 3.

Рис. 10-4. Образец Dridex применяет ловушку противодействия отладке на основе точки останова

Показанный код Dridex выполняет две инструкции int 3, увеличивает eax, выполняет ещё две int 3, а затем продолжает цикл. Функция повторяется 13 512 раз (cmp eax, 13512), что способно вызвать у аналитика серьёзное раздражение.

Часто обойти такой метод ловушки трудно. Лучший подход - определить проблемные инструкции и удалить их патчем. Как в случае этого образца Dridex, вредоносная программа может создать цикл инструкций точек останова с помощью jmp, jnz, jz и так далее; тогда для обхода поведения потребуется удалить патчем или изменить инструкцию цикла.

Необработанные исключения

Вредоносная программа может установить обработчик исключений верхнего уровня, называемый фильтром необработанных исключений, чтобы проверить наличие отладчика. Он получает приоритет над другими обработчиками, например стандартным SEH: сначала программа вызывает SetUnhandledExceptionFilter, позволяя вызывающей программе стать обработчиком верхнего уровня, а затем UnhandledExceptionFilter, принудительно выполняя обработчик. Если вредоносная программа не отлаживается, исключение передастся новому обработчику. Если отлаживается, новый обработчик вызван не будет, а исключение получит отладчик, что сообщит программе о работе внутри него.

Чтобы справиться с методом, можно перехватить вызовы SetUnhandledExceptionFilter и UnhandledExceptionFilter с помощью точек останова или перехватчиков и изменить вызовы либо полностью удалить их из кода патчем. Обработка исключений подробнее рассматривается в главе 11.

Контрольные суммы, хеширование разделов и самовосстановление

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

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

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

Эксплуатация отладчика, вызов сбоя и вмешательство в его работу

Иногда самый эффективный метод противодействия отладке - прямое вмешательство в работу отладчика, приводящее к сбою или непредсказуемому поведению. Как и любое программное обеспечение, отладчики могут содержать ошибки, позволяющие вредоносной программе мешать анализу, вызывать сбой отладчика или, возможно, даже самой операционной системы. Известный пример - ошибка в OllyDbg 1.1: вредоносная программа могла вызвать функцию OutputDebugString и передать %s в качестве параметра; OllyDbg не умел обрабатывать это значение, что приводило к сбою выполняющегося образца и предотвращало дальнейшую отладку.

Возможно, несколько менее агрессивна функция BlockInput, которой вредоносная программа способна злоупотребить для вмешательства в работу аналитических инструментов. BlockInput принимает лишь один параметр, fBlockIt. Если он равен 1, события мыши и клавиатуры будут заблокированы для всех приложений, что может серьёзно помешать отладке. Обнаружив ручное исследование или работу под управлением отладчика, вредоносная программа может просто вызвать BlockInput как механизм самозащиты. К счастью, метод легко обойти сочетанием Ctrl+Alt+Delete, которое выведет из процедуры BlockInput. Можно также изменить вызов в отладчике, задав параметр fBlockIt равным 0 вместо 1.

Наконец, вредоносная программа может использовать NtSetInformationThread, чтобы скрыть выполнение кода от отладчика или вовсе вызвать его сбой. Передав функции NtSetInformationThread значение ThreadInformationClass ThreadHideFromDebugger, в шестнадцатеричном виде 0x11, программа способна скрытно выполнить код, из-за чего аналитик потеряет контроль над образцом. Кроме того, если вредоносная программа выполнит инструкцию точки останова, например int 3, в скрытно выполняемом коде, её процесс навсегда зависнет в отладчике. Этот метод в контексте скрытного выполнения кода рассматривается в главе 11.

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

Блокирование отладки и методы противодействия подключению

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

Для подключения к выполняющемуся образцу отладчик обычно вызывает функцию Windows DebugActiveProcess. Если процесс уже отлаживается, функция завершится неудачно. Вредоносная программа способна этим воспользоваться, просто выступив собственным отладчиком. Она может создать дочерний процесс и назначить родительский процесс отладчиком. При попытке подключить отладчик к дочернему процессу аналитик получит досадное исключение STATUS_PORT_ALREADY_SET, означающее, что процесс уже отлаживается.

Чтобы преодолеть метод, можно подключить отладчик к родительскому процессу и установить точку останова на WaitForDebugEvent. После срабатывания вы можете принудить процесс, действующий как отладчик, отключиться от дочернего вызовом функции DebugActiveProcessStop.

Примечание. Дополнительные сведения об этом методе см. в исследовательской работе Марка Винсента Ясона "The Art of Unpacking". Работа старая, но всё ещё очень актуальна: https://www.blackhat.com/presentations/bh-usa-07/Yason/Whitepaper/bh-usa-07-yason-WP.pdf.

Вредоносная программа может также изменять распространённые функции отладчика, чтобы предотвратить отладку; именно так действует семейство GuLoader. При подключении к процессу отладчик вызывает функции DbgBreakPoint и DbgUiRemoteBreakin, которые, по существу, позволяют использовать точки останова внутри отлаживаемой программы. GuLoader изменяет DbgBreakPoint, удаляя код операции int 3 и заменяя его инструкциями nop, что фактически нарушает функцию. Аналогичным образом GuLoader изменяет DbgUiRemoteBreakin, добавляя недействительную инструкцию call, которая в конечном счёте вызовет исключение и, возможно, приведёт к сбою отлаживаемой вредоносной программы. CrowdStrike написала отличную статью о GuLoader; дополнительные сведения об этих методах см. по адресу https://www.crowdstrike.com/blog/guloader-malware-analysis/.

Другие методы противодействия отладке

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

Некоторые способы я решил не описывать, поскольку они необычны или сложны в реализации. Например, отдельные семейства вредоносных программ, в частности руткиты, могут напрямую исследовать свои блоки EPROCESS в поисках признаков подключённого отладчика, но это встречается довольно редко. Другие методы подвержены ошибкам. Например, вредоносная программа может проверить свои привилегии отладки, попытавшись вызвать OpenProcess для системного процесса, такого как csrss.exe. Если она получает дескриптор процесса, то может сделать вывод, что отлаживается, но это не всегда верно. Ещё один пример - применение флага трассировки, особого флага в регистрах EFLAGS и RFLAGS, способного выдать присутствие отладчика. Оба метода могут давать ложные срабатывания, сложнее в реализации и потому используются не столь широко.

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

Противодействие методам противодействия отладке

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

Прежде чем углубляться в исследование вредоносной программы, я всегда просматриваю образец в инструменте статического анализа и сортировки PE-файлов, таком как PEStudio или PE-bear. Подобные инструменты позволяют исследовать импорты и строки файла, которые могут помочь выявить библиотеки и вызовы функций, связанные с противодействием отладке. Я также применяю такие инструменты, как CAPA, описанный в главе 3.

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

Существуют отличные инструменты автоматизации обхода методов противодействия отладке. Пожалуй, самый популярный - ScyllaHide (https://github.com/x64dbg/ScyllaHide), подключаемый модуль для x64dbg и других отладчиков. Он способен скрыть отладчик от вредоносной программы, динамически изменяя её код и перехватывая подозрительные функции, чтобы обойти многие способы обнаружения отладчика и противодействия ему (рис. 10-5).

Рис. 10-5. Меню ScyllaHide в x64dbg

Чтобы включить в ScyllaHide функцию противодействия противодействию отладке, просто установите рядом с ней флажок, а затем выберите Apply и OK. При наведении указателя на каждый параметр появятся дополнительные сведения. Я часто включаю весь левый столбец параметров, и это редко вызывает проблемы. При этом, хотя большинство параметров можно безопасно включать, некоторые способны нарушить работу образца, возможно вызвав сбой или неожиданное поведение. Поэтому пользуйтесь ими осторожно.

HyperHide (https://github.com/Air14/HyperHide) предоставляет многие из тех же возможностей, что ScyllaHide, однако всегда полезно иметь в своём арсенале несколько инструментов. На рис. 10-6 показаны возможности HyperHide по противодействию противодействию отладке.

Рис. 10-6. Меню HyperHide в x64dbg

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

Итоги

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

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

Функции обратного вызова

Функции обратного вызова - определяемые приложением функции, которые запускаются определённым событием и используются как входные данные для других функций. Например, функция Windows API EnumDisplayMonitors применяет функции обратного вызова для перечисления мониторов, настроенных на узле. При вызове EnumDisplayMonitors мониторы перечисляются по одному, а сведения о каждом, например размер экрана, передаются функции обратного вызова. Программа определяет эту функцию и может направить её к любому нужному коду.

Вредоносная программа способна злоупотреблять такими функциями, как EnumDisplayMonitors, создавая собственный обратный вызов и направляя его на вредоносный код, как показано на рис. 11-1. Затем этот код будет выполнен вызывающей функцией (EnumDisplayMonitors), что обфусцирует поток управления в качестве метода противодействия дизассемблированию и отладке и даже может привести к тому, что аналитик потеряет контроль над вредоносной программой в отладчике. Кроме того, метод способен запутать некоторые автоматизированные песочницы.

Рис. 11-1. Пример функции обратного вызова с EnumDisplayMonitors

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

Теоретически метод способен работать почти с любой функцией Windows API, использующей обратные вызовы, а таких несколько, но я обнаружил, что многие функции, которыми может злоупотреблять вредоносная программа, начинаются с Enum, например EnumDateFormatsEx, EnumSystemLanguageGroups и EnumChildWindows.

Обратные вызовы TLS

Как объяснялось в главе 1, поток - последовательность инструкций, работающая внутри процесса. Локальное хранилище потока (TLS) позволяет каждому выполняющемуся потоку программы иметь собственную версию переменной, к которой все остальные потоки обращаются с уникальным значением. Например, если глобальная переменная var определена в TLS, каждый поток процесса может хранить в ней своё значение. В таком случае var выступает как своего рода имя глобальной переменной, но с уникальным значением для каждого потока.

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

Примечание. Чтобы следовать материалу раздела, загрузите образец из VirusTotal или MalShare по следующему хешу:

SHA256: e4bd2245b1f75abf37abd5a4b58e05f00886d56a5556080c4331847c7266b5b6

Для выявления вредоносной программы, которая может применять обратные вызовы TLS, можно воспользоваться одним из множества статических анализаторов исполняемых файлов, например моим любимым PEStudio. В PEStudio есть вкладка TLS Callbacks, где перечислены все зарегистрированные в исполняемом файле обратные вызовы и их адреса. Например, наш вредоносный файл на рис. 11-2 содержит два обратных вызова TLS.

Рис. 11-2. Обратный вызов TLS, отображённый в PEStudio

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

Чтобы лучше понять, как функции обратного вызова TLS могут запутывать аналитиков и направлять их по ложному пути, а также научиться работать с использующей их вредоносной программой, рассмотрим образец в отладчике. Я применяю x64dbg, но подойдёт любой сходный отладчик.

Во-первых, обнаружив в образце обратные вызовы TLS, например посредством PEStudio, всегда убеждайтесь, что отладчик настроен останавливаться на таких функциях. В противном случае отладчик выполнит обратный вызов и может не остановиться на нём, а вы, скорее всего, никогда не поймёте, что тот запускался. Чтобы x64dbg останавливался на обратном вызове TLS, выберите Options > Preferences > Events и убедитесь, что установлен флажок TLS Callbacks, как показано на рис. 11-3.

Рис. 11-3. Включение точек останова на обратных вызовах TLS

После подключения образца к отладчику можно запустить его обычным образом клавишей F9, и отладчик остановится на функции обратного вызова TLS, как показано на рис. 11-4.

Рис. 11-4. Срабатывание точки останова TLS

Теперь отладчик приостановлен по адресу функции обратного вызова TLS, который, скорее всего, является входом во вредоносный код, предназначенный для скрытного выполнения, как показано на рис. 11-5.

Рис. 11-5. Код обратного вызова TLS

Обратите внимание, что обратные вызовы TLS не всегда столь явно зарегистрированы и отображаются в инструментах статического анализа. Записи TLS хранятся в блоке среды потока (TEB), структуре данных со сведениями о выполняющемся в данный момент потоке; освежить знания можно по главе 1. Вредоносная программа способна изменять собственный TEB во время выполнения, возможно манипулируя обратными вызовами TLS и динамически добавляя либо удаляя их. Тем самым авторы могут скрыть обратные вызовы TLS, чтобы те выполнялись ещё более незаметно и уклонялись от инструментов анализа.

Обработка структурированных исключений

Как следует из названия, обработчик структурированных исключений (SEH) - механизм обработки исключений приложениями Windows. Всякий раз, когда программа Windows сталкивается с исключением, она вызывает SEH. Разработчики могут выбрать выполнение определённого кода при возникновении исключения посредством записи SEH. Например, если программа выдаёт ошибку из-за отсутствия требуемого файла, разработчик может указать вывести всплывающее окно с сообщением: "Требуемый файл не существует!" Такая инструкция часто имеет форму последовательности try...catch или try...except. Программа пытается выполнить код, а при неудаче по какой-либо причине выполняется catch, то есть исключение.

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

Адрес обработчика хранится в специальном регистре ЦП FS, или GS для 64-разрядных приложений, который указывает на TEB. В структуре TEB значение fs:[0] содержит текущий кадр SEH, указывающий на первую запись SEH в стеке. Эта структура показана на рис. 11-6.

Рис. 11-6. Цепочка связанного списка SEH

Обратите внимание, что регистр FS указывает на адрес TEB, который, в свою очередь, содержит указатель на первую запись SEH в стеке. Запись SEH содержит адрес следующей записи цепочки, а также адрес обработчика исключения, то есть кода, который будет выполнен при его возникновении.

Когда программа добавляет новую запись SEH в цепочку в стеке, сначала она должна поместить в стек адрес нового обработчика, а затем адрес предыдущего. Это выглядит следующим образом:

После помещения адресов нового и предыдущего обработчиков в стек инструкция mov fs:[0], esp настраивает новый обработчик. Когда в программе возникнет новое исключение, HandlerAddress станет первым, кто на него отреагирует.

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

Примечание. Чтобы следовать примеру, загрузите образец из VirusTotal или MalShare по следующему хешу:

SHA256: d52f0647e519edcea013530a23e9e5bf871cf3bd8acb30e5c870ccc8c7b89a09

Вам также понадобится отладчик, например x64dbg.

Помните, что этот образец является вариантом программы-вымогателя, поэтому обязательно соблюдайте меры предосторожности. Можно воспользоваться некоторыми советами из приложения A.

Сначала переименуйте файл, добавив расширение .exe, например evil.exe, и откройте его в x64dbg. Это 32-разрядный файл, поэтому потребуется 32-разрядная версия программы. В этот момент выполнение будет приостановлено. Выберите Debug > Run to User Code, чтобы перейти к началу кода вредоносной программы. Теперь вы должны находиться в точке входа, показанной на рис. 11-7.

Рис. 11-7. Точка входа вредоносной программы в x64dbg

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

Сначала вредоносная программа перемещает адрес evil.429D8C в eax и помещает его в стек. Адрес содержит вредоносный код, который будет выполнен обработчиком исключения. Затем программа помещает в стек текущее значение fs:[0], указывающее на самую верхнюю запись SEH. После этого значение esp, то есть указатель стека, перемещается в fs:[0], фактически добавляя адрес нового обработчика.

Чтобы вызвать обработчик и скрытно выполнить его код, вредоносная программа должна принудительно создать исключение. Для этого она очищает регистр eax посредством xor, а затем выполняет инструкцию mov, которая пытается переместить значение из ecx по адресу, хранящемуся в eax. Поскольку сейчас eax равен 0, это приводит к ошибке EXCEPTION_ACCESS_VIOLATION в x64dbg, показанной на рис. 11-8.

Рис. 11-8. Исключение, принудительно вызванное вредоносной программой

Поток управления передаётся обработчику, содержащему вредоносный код, как показано на рис. 11-9.

Рис. 11-9. Передача потока управления обработчику, содержащему вредоносный код

Однако, если явно не указать отладчику останавливаться на коде обработчика, он выполнится слишком быстро и мы не успеем его исследовать. Поэтому установим точку останова на коде командой bp 00429D8C в отладчике. Теперь при продолжении выполнения образец остановится на вредоносном коде обработчика, как показано на рис. 11-9. Если вы уже прошли эту точку, возможно, придётся завершить образец и запустить заново, не забыв установить точку останова на 00429D8C.

Если бы мы не знали о злоупотреблении SEH и не исследовали код внимательно, то, скорее всего, полностью пропустили бы это выполнение. Поскольку многие дизассемблеры могут не учитывать SEH, мы также не увидели бы переход при статическом анализе кода.

Кроме непосредственного изменения цепочки SEH вредоносная программа может злоупотребить ею посредством функции KiUserExceptionDispatcher, принимающей адрес обработчика исключений в качестве параметра. Программа способна передать функции произвольный адрес, добавив новый обработчик в текущую цепочку. Затем, принудительно вызвав исключение описанным способом, она скрытно выполнит вредоносный код.

При анализе использующей эти методы вредоносной программы полезно наблюдать за цепочкой SEH. Сделать это можно двумя способами. В x64dbg есть вкладка SEH со списком цепочки, но, по моему опыту, она не всегда надёжна. Лучше добавить наблюдение за изменениями fs:[0]. Тогда вы будете получать предупреждение, когда вредоносная программа манипулирует данными, хранящимися в регистре или по адресу fs:[0]. Для этого перейдите на вкладку Watch под окном CPU, щёлкните правой кнопкой мыши, выберите Add, а затем введите fs:[0] (рис. 11-10).

Рис. 11-10. Добавление выражения наблюдения в x64dbg

Добавив наблюдение, щёлкните его правой кнопкой мыши и выберите Changed. Теперь программа будет приостанавливаться при каждом изменении значения fs:[0], как показано на рис. 11-11.

Рис. 11-11. Срабатывание выражения наблюдения

VEH и 64-разрядный SEH

Ещё один важный механизм обработки исключений в Windows - векторная обработка исключений (VEH), расширение SEH для приложений Windows x86. VEH иногда используется вместе с SEH в 32-разрядных приложениях, но имеет над ним приоритет: если в приложении возникает исключение, VEH попытается обработать его раньше SEH.

Подобно SEH, вредоносная программа может злоупотреблять VEH. Например, она способна вызвать функцию Windows API AddVectoredExceptionHandler или RtlAddVectoredExceptionHandler; обе регистрируют новую запись VEH. Функции принимают параметр PVECTORED_EXCEPTION_HANDLER, представляющий функцию, которая будет вызвана после возникновения исключения. Затем вредоносная программа может намеренно вызвать исключение, в результате чего сработает VEH и выполнится вредоносный код. Если вы видите вызов этих функций, стоит исследовать код глубже и проверить, не применяется ли VEH для скрытного выполнения.

В приложениях x64 SEH, иногда называемый x64 SEH, реализован в виде таблицы, хранящейся в PE-заголовке исполняемого файла. Таблица содержит описания всей обработки исключений программы. Кроме того, x64 SEH использует метод, известный как раскрутка стека, который выполняется в режиме ядра и предусматривает извлечение адресов из стека для продолжения выполнения по другому адресу в нём. Раскрутка стека выходит за рамки книги, однако её эксплуатация встречается редко: таблица x64 SEH хранится в заголовке файла, что затрудняет вмешательство в цепочки, а раскрутка происходит в режиме ядра, тогда как большинство вредоносных программ работает в пользовательском режиме. Важно также отметить, что VEH может быть реализован в 64-разрядных приложениях, поэтому сценарий злоупотребления VEH применим и к вредоносным программам x64.

Скрытые потоки

Windows API предоставляет функцию NtSetInformationThread, которую можно использовать для задания приоритета потока. У неё есть параметр THREADINFOCLASS, или ThreadInformationClass, указывающий на структуру, которая может содержать несколько значений, одно из которых особенно интересно: ThreadHideFromDebugger. Если его установить, поток кода перестанет отправлять события отладки отладчику, то есть будет, по существу, проходить незаметно. Это позволяет вредоносной программе обойти подключённые аналитиком отладчики и скрытно выполнить код. Самый простой способ преодолеть метод - искать вызовы NtSetInformationThread и устанавливать на них точки останова. После срабатывания измените параметры функции или просто удалите вызов из кода патчем.

Сходный метод уклонения связан с функцией NtCreateThreadEx, у которой есть особый флаг THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER, позволяющий скрыть вновь созданный поток от отладчика. Как нетрудно догадаться, это может создавать проблемы для аналитика, поскольку код будет выполняться вне непосредственной области видимости отладчика. Обращайте внимание на вызов NtCreateThreadEx с включённым флагом THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER, шестнадцатеричное значение 0x4.

Внедрение в процесс

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

Итоги

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

Чтобы слиться с целевой средой, современные уклоняющиеся угрозы должны оставаться скрытыми на заражённом узле. Два применяемых ими метода - внедрение в процесс и манипулирование образом процесса. Внедрение предусматривает вставку и выполнение злонамеренного кода внутри другого процесса вместо прямого выполнения, тогда как манипулирование образом предполагает вмешательство в образы процессов и злоупотребление способом их обработки Windows. Вредоносная программа может также использовать методы внедрения, чтобы вставить перехватчики в целевой процесс. Перехват позволяет ей перехватывать вызовы функций API, наблюдать за ними или манипулировать ими, помогая оставаться незамеченной.

Мы начнём главу с различных форм внедрения в процессы. Затем обсудим двух близких родственников этого метода - манипулирование образом процесса и перехват DLL и совместимости (shim hijacking) - вместе с различными способами перехвата. В конце главы мы кратко рассмотрим меры противодействия атакам такого типа.

Внедрение в процесс

Существует несколько причин, по которым вредоносная программа может захотеть реализовать внедрение в процесс.

Сокрытие от средств защиты и исследователей

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

Имитация нормального поведения

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

Срыв попыток отладки

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

Повышение привилегий

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

Перехват данных посредством перехватчиков

: Внедрение кода перехвата в процесс позволяет вредоносной программе перехватывать и изменять вызовы Windows API либо перехватывать конфиденциальные данные.

Рассмотрим различные методы внедрения подробнее, начав с того, как вредоносная программа выбирает целевой процесс.

Случайные и определённые целевые процессы

В зависимости от цели вредоносная программа может внедрить код в случайный или специально выбранный процесс. Например, некоторые программы внедряют вредоносный код в несколько произвольных процессов узла, чтобы обеспечить собственное выживание. Вредоносная программа может просто перечислить все процессы посредством Process32First и Process32Next, а затем попытаться открыть целевой и получить его дескриптор посредством OpenProcess. Если процесс успешно открывается с текущим уровнем привилегий, программа внедряет туда свой код. Однако такой подход не слишком скрытен.

Более незаметный способ - внедрить код в определённые целевые процессы, например широко известные и распространённые процессы Windows, либо в процессы, позволяющие вредоносной программе достичь конкретной цели. Например, некоторые варианты семейства Formbook внедряют код в связанные с браузерами процессы, пытаясь вынюхать конфиденциальные данные, такие как учётные сведения веб-сайтов.

Некоторые вредоносные программы способны внедрять код даже в собственный процесс - метод, известный как самовнедрение, - или в созданный ими дочерний процесс. Такие виды внедрения часто происходят при распаковке, когда программа расшифровывает, или распаковывает, полезную нагрузку в памяти, а затем внедряет её в дочерний процесс. Распаковка подробнее рассматривается в главе 17. А пока разберём одну из самых простых и распространённых форм: внедрение шелл-кода.

Внедрение шелл-кода

Внедрение шелл-кода, также известное как прямое внедрение, - один из старейших методов. Как следует из названия, он предусматривает внедрение шелл-кода, разновидности позиционно-независимого машинного кода. После внедрения вредоносная программа может оставаться скрытой, выполняя злонамеренный код непосредственно из памяти процесса-жертвы. Принцип работы показан на рис. 12-1.

Рис. 12-1. Метод внедрения шелл-кода

Чтобы внедрить шелл-код, сначала вредоносная программа должна открыть дескриптор объекта целевого процесса вызовом OpenProcess либо напрямую вызвать эквивалент Native API NtOpenProcess. У OpenProcess есть два важных параметра: dwDesiredAccess и dwProcessId. dwDesiredAccess представляет права доступа, запрашиваемые вызывающим процессом, а dwProcessId - идентификатор целевого процесса. Прототип OpenProcess выглядит следующим образом:

Получив дескриптор объекта целевого процесса, вредоносная программа вызывает VirtualAlloc, чтобы выделить в нём память для внедряемого шелл-кода. В качестве альтернативы она может вызвать VirtualAllocEx или NtAllocateVirtualMemory. Наиболее важные параметры VirtualAlloc - lpAddress и dwSize, представляющие соответственно начальный адрес и размер выделяемой области памяти. Прототип функции выглядит так:

После выделения вредоносная программа записывает злонамеренный код в свежую область памяти посредством WriteProcessMemory либо эквивалента Native API NtWriteVirtualMemory. У WriteProcessMemory несколько важных параметров: hProcess, дескриптор процесса, в который выполняется запись; lpBaseAddress, указатель на базовый адрес записи; lpBuffer, указатель на область памяти с записываемыми данными; и nSize, количество байтов, записываемых в память целевого процесса. Прототип функции:

Наконец, после записи злонамеренного кода в целевой процесс вредоносная программа готова выполнить его в контексте процесса. Для этого она вызывает CreateRemoteThread, либо NtCreateThreadEx или RtlCreateUserThread, создавая удалённый поток в контексте процесса и выполняя его. Самые важные параметры CreateRemoteThread - hProcess, дескриптор целевого процесса, и lpStartAddress, начальный адрес выполняемого кода. Прототип функции:

Обратите внимание: это лишь один из множества способов внедрения и выполнения шелл-кода. Поток этого метода и вызываемые функции (OpenProcess, VirtualAlloc, WriteProcessMemory и так далее) являются базовыми строительными блоками нескольких методов, которых мы коснёмся в главе. Помните также, что многие перечисленные функции взаимозаменяемы с другими. Например, вместо WriteProcessMemory вредоносная программа может вызвать Native API NtWriteVirtualMemory, а вместо CreateRemoteThread - NtCreateThreadEx.

Для отслеживания внедрения я предпочитаю API Monitor: он позволяет быстро увидеть, как программа внедряет код, и даже извлечь внедрённый код. С его помощью можно также исследовать параметры каждого вызова функций в удобном для чтения формате.

Примечание. В следующем разделе я буду использовать вредоносный исполняемый файл, который можно загрузить из VirusTotal или MalShare по следующему хешу:

SHA256: c39e675a899312f1e812d98038bb75b0c5159006e8df7a715f93f8b3ac23b625

На рис. 12-2 показан результат загрузки образца в API Monitor и фильтрации функций OpenProcess, VirtualAlloc и WriteProcessMemory.

Рис. 12-2. Внедрение шелл-кода, зафиксированное в API Monitor

Как видно, образец начинает с вызова OpenProcess с разрешением STANDARD_RIGHTS_ALL и несколькими другими правами доступа, затем многократно вызывает VirtualAlloc, чтобы выделить память в целевом процессе. После этого вредоносная программа записывает туда код посредством WriteProcessMemory и выполняет его, вызывая CreateRemoteThread.

Если исследовать буфер третьего вызова WriteProcessMemory, можно увидеть, что вредоносная программа записывает в целевой процесс данные, похожие на шелл-код (рис. 12-3).

Примечание. Требуется некоторая практика, но шелл-код можно распознать, исследуя данные и разыскивая байты распространённых ассемблерных инструкций, например 8b ec, что преобразуется в mov ebp, esp. Дополнительные инструкции ассемблера приведены в главе 3.

Рис. 12-3. Шелл-код, внедрённый в целевой процесс

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

Поскольку данные чисто преобразуются в ассемблерный код, они действительно похожи на шелл-код. Я не стану подробнее разбирать его здесь, однако при анализе этого образца попытался бы понять назначение кода, глубже исследовав его в дизассемблере, а затем динамически в отладчике. Обратите внимание: в некоторых обстоятельствах дизассемблер может ошибочно распознать код как данные. Чтобы освежить в памяти проблему различения кода и данных, вернитесь к блоку "Дизассемблирование" на с. 51. Возможно, вам придётся "заставить" дизассемблер читать его как код.

Перед тем как продолжить, стоит отметить ещё кое-что, внедрённое в целевой процесс. Если исследовать буфер первого вызова WriteProcessMemory, вы увидите ссылку на kernel32.dll (рис. 12-4).

Рис. 12-4. Строка KERNEL32.DLL, записанная в память

Это указывает, что образец может применять и другой метод внедрения - внедрение DLL, которое мы сейчас рассмотрим.

Внедрение DLL

Хотя внедрение DLL - ещё одна распространённая форма внедрения в процесс, не позволяйте названию ввести вас в заблуждение. При такой атаке вредоносная программа физически не внедряет DLL в целевой процесс; вместо этого она записывает в него путь к находящемуся на диске вредоносному DLL-файлу, а затем принуждает процесс загрузить и выполнить DLL от её имени. Метод показан на рис. 12-5.

Рис. 12-5. Метод внедрения DLL

Сначала вредоносная программа сохраняет вредоносный DLL-файл на диск. Затем, как при внедрении шелл-кода, она вызывает OpenProcess, чтобы получить дескриптор выбранного целевого процесса, и использует VirtualAlloc для выделения памяти внутри него. После этого WriteProcessMemory записывает в процесс расположение DLL-файла. Наконец, чтобы заставить процесс-жертву загрузить DLL, вредоносная программа получает процедурный адрес LoadLibrary, а затем вызывает CreateRemoteThread, задав параметр lpStartAddress равным этому адресу. При выполнении удалённого потока целевой процесс вызывает LoadLibrary и тем самым загружает вредоносную DLL. В псевдокоде это выглядит так:

Программа вызывает WriteProcessMemory, чтобы записать путь к вредоносной DLL, malicousDllName, в целевой процесс victimProcess. Затем она вызывает GetModuleHandle, а следом GetProcAddress, получая процедурный адрес функции LoadLibraryA. Наконец, вредоносная программа вызывает CreateRemoteThread, передавая адрес LoadLibraryA и путь к вредоносной DLL в качестве параметров. Это заставляет процесс-жертву загрузить вредоносную DLL и выполнить код в новом потоке.

Одна проблема традиционного внедрения DLL для авторов состоит в том, что библиотека должна загружаться с диска посредством стандартных процедур Windows. Средства защиты конечных точек наблюдают за такими процедурами и легко их замечают. Более скрытный подход - рефлективное внедрение DLL.

Рефлективное внедрение DLL

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

Первые шаги довольно похожи на стандартное внедрение DLL. Вредоносная программа получает дескриптор процесса-жертвы посредством OpenProcess и выделяет память в нём посредством VirtualAlloc. Однако вместо записи только пути к DLL программа копирует всю вредоносную библиотеку в память целевого процесса. Затем она передаёт поток управления только что внедрённой DLL, например с помощью CreateRemoteThread, который выполняет внедрённый начальный загрузчик DLL.

Этот загрузчик - собственный код, который должен воспроизвести обычный процесс загрузки DLL в Windows. На высоком уровне он выполняет следующие шаги:

1. Загрузчик вычисляет расположение собственного образа в памяти и выполняет его перемещения относительно базового адреса, то есть выравнивает жёстко заданные адреса в исполняемом коде по текущему расположению в памяти. Кроме того, загрузчик находит PEB внедрённой DLL.

2. Загрузчик разбирает таблицу экспорта kernel32.dll, чтобы найти адреса LoadLibrary, GetProcAddress, VirtualAlloc и других основных функций.

3. Теперь вредоносная DLL успешно загружена внутри процесса-жертвы и готова к работе. Для выполнения вредоносного кода программа обычно вызывает функцию из таблицы экспорта DLL, например показанную на рис. 12-6.

Рис. 12-6. Экспортируемая функция DLL

Показанная вредоносная программа сгенерирована популярным инструментом тестирования на проникновение Cobalt Strike и имеет ReflectiveLoader@4 в качестве стандартной экспортируемой функции. После её вызова выполняется вредоносный код.

На рис. 12-7 показана типичная атака рефлективного внедрения DLL.

Рис. 12-7. Метод рефлективного внедрения DLL

На рисунке выполняющаяся вредоносная программа загружает полезную нагрузку DLL с контролируемого злоумышленником промежуточного сервера 1, после чего та временно сохраняется в пространстве памяти вредоносного процесса 2. Обратите внимание: метод не всегда зависит от удалённого промежуточного сервера, но мы вскоре к этому вернёмся. Затем начальный загрузчик внедряется в целевой процесс вместе с DLL 3 и выполняется вредоносной программой. Загрузчик вручную проводит процесс загрузки DLL, а затем вызывает экспортируемую функцию внедрённой библиотеки, которая выполняет вредоносный код в контексте целевого процесса 4. Подробнее прочитать о рефлективном внедрении у автора метода можно по адресу https://github.com/stephenfewer/ReflectiveDLLInjection.

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

Сходный метод, иногда называемый рефлективным внедрением шелл-кода, предусматривает преобразование DLL в шелл-код с последующим внедрением в целевой процесс. Я не стану рассматривать его дальше, поскольку он объединяет уже знакомые вам методы, но дополнительные сведения доступны по адресу https://github.com/monoxgas/sRDI.

Опустошение процесса

Опустошение процесса, иногда называемое RunPE, заменой процесса или внедрением в опустошённый процесс, предусматривает удаление отображения кода из памяти целевого процесса и последующее отображение там вредоносного кода. Этот метод несколько отличается от уже рассмотренных, поскольку обычно не связан с произвольным удалённым процессом. Вместо этого вредоносная программа запускает новый процесс, часто доверенный исполняемый файл вроде нашего любимого Calculator.exe, удаляет отображение законного кода и отображает вредоносный в приостановленном состоянии, после чего выполняет его. Это скрывает вредоносный код от любопытных глаз средств защиты конечных точек и исследователей, маскируя его под нормальный процесс. Метод показан на рис. 12-8.

Рис. 12-8. Метод опустошения процесса

Образец начинает с создания нового процесса посредством CreateProcess, а затем устанавливает флаг создания CREATE_SUSPENDED, не показанный на схеме, запуская новый процесс в приостановленном состоянии. Далее вредоносная программа "опустошает" его, удаляя отображение законного кода функцией NtUnmapViewOfSection. Затем она выделяет новую область памяти для вредоносного кода посредством VirtualAlloc и записывает, то есть отображает, туда полезную нагрузку с помощью WriteProcessMemory. Наконец, программа вызывает SetThreadContext и ResumeThread, соответственно направляя текущий поток к только что внедрённому коду и возобновляя выполнение потока, что запускает вредоносный код.

Рассмотрим метод на практике на примере варианта программы-вымогателя Satan (SHA256: cbbd2bd6f98bd819f3860dea78f812d5c180fd19924cef32e94Bd7f6929023779). Снимок API Monitor на рис. 12-9 показывает, как образец, вариант семейства Satan, применяет опустошение процесса.

Рис. 12-9. Образец вредоносной программы применяет опустошение процесса

Обратите внимание, что программа запускает новый процесс посредством CreateProcessW из исполняемого файла на диске (financialz.exe) в приостановленном состоянии (CREATE_SUSPENDED), как только что обсуждалось. Затем она многократно вызывает NtWriteVirtualMemory, отображая данные в новый целевой процесс. Более глубокое исследование этого вызова в API Monitor показывает, что образец записывает в целевой процесс PE-файл, а затем вызывает NtResumeThread для его выполнения (рис. 12-10).

Рис. 12-10. PE-заголовок в памяти

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

Перехват потока

Перехват потока предусматривает открытие выполняющегося потока в процессе-жертве, запись в него вредоносного кода и принуждение процесса выполнить этот код. Перехват использует многие функции метода опустошения, но есть несколько заметных отличий. Для выполнения перехвата вредоносная программа вызывает OpenThread, указывая идентификатор потока в качестве параметра, а затем SuspendThread либо Wow64SuspendThread для 64-разрядных процессов, чтобы приостановить поток-жертву. Когда тот оказывается в приостановленном состоянии, программа посредством VirtualAlloc и WriteProcessMemory соответственно выделяет память в целевом процессе и записывает туда вредоносный код. Наконец, она вызывает SetThreadContext, передавая поток управления от текущего приостановленного потока только что внедрённому коду, а затем ResumeThread для выполнения кода.

Внедрение APC

Асинхронный вызов процедуры (APC) - возможность Windows, позволяющая ставить различные задачи в очередь и выполнять их в контексте работающего потока. Программа может вызвать функцию QueueUserAPC, передав дескриптор потока и указатель на код, который хочет выполнить, чтобы добавить задачу в очередь APC. Внедрение APC злоупотребляет этой функциональностью для скрытного выполнения кода и потенциального повышения привилегий.

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

Вредоносная программа пользуется APC, пытаясь внедрить вредоносный код в другие процессы посредством постановки в очередь. Атака показана на рис. 12-11.

Рис. 12-11. Метод внедрения APC

Сначала вредоносная программа обычным способом получает дескриптор целевого процесса-жертвы (OpenProcess) и записывает в процесс предназначенный для выполнения вредоносный код (VirtualAlloc и WriteProcessMemory). Затем она открывает целевой поток вызовом OpenThread, после чего выполняет QueueUserAPC либо NtQueueApcThread, чтобы поставить в очередь новую задачу APC. Когда поток получает от операционной системы запрос прерывания, вредоносный код выполняется.

Вариант метода создаёт новый процесс в приостановленном состоянии, подобно опустошению, и записывает в него вредоносный код. Затем программа ставит в очередь функцию APC и возобновляет поток. После возобновления выполняется вредоносный код. В этот момент программа может завершить исходный процесс, поскольку полезная нагрузка теперь работает в новом и способна остаться незамеченной средствами защиты конечных точек и ничего не подозревающими конечными пользователями. Эта атака, зафиксированная в API Monitor, показана на рис. 12-12.

Рис. 12-12. Вредоносная программа применяет вариант метода внедрения APC

Этот образец использует внедрение APC для выполнения вредоносного кода в контексте процесса iexplore.exe. В данном случае программа запускает iexplore.exe (CreateProcessA) вместо перехвата другого процесса (OpenProcess).

Атомная бомбардировка

Последний метод внедрения в процессы, который мы рассмотрим в этой главе, называется атомной бомбардировкой. У него есть общие черты с внедрением APC, однако в нём задействованы атомы, то есть ссылки на определённые фрагменты данных, например строки. Атомы хранятся в структуре операционной системы, называемой таблицей атомов, и у каждого атома есть уникальный идентификатор. Атомы часто применяются при межпроцессном взаимодействии для согласования действий между процессами. Например, процесс A может создать атом, чтобы указать на доступность определённого фрагмента данных, а процесс B может воспользоваться этим атомом для обращения к данным.

Таблицы атомов бывают глобальными, то есть доступными из любого выполняющегося в системе процесса, и локальными, доступными только одному определённому процессу. Чтобы добавить данные в глобальную таблицу атомов, приложение вызывает функцию GlobalAddAtom; чтобы добавить атом в локальную таблицу, оно вызывает AddAtom. При атомной бомбардировке эти таблицы используются не по назначению для временного хранения вредоносного кода. Такая атака показана на рис. 12-13.

Рис. 12-13. Метод атомной бомбардировки

На высоком уровне этот метод создаёт новый глобальный атом (GlobalAddAtom) в глобальной таблице атомов и сохраняет в нём вредоносный шелл-код 1. Затем он использует постановку APC в очередь (NtQueueApcThread) 2, чтобы принудить процесс-жертву выполнить GlobalGetAtomName 3. После того как процесс-жертва извлечёт атом, сохранённый в таблице шелл-код можно выполнить в контексте этого процесса 4.

Подведение итогов по внедрению в процессы

Как вы уже увидели, многие методы внедрения в процессы используют одни и те же вызовы функций API и ведут себя сходным образом. Почти во всех случаях вредоносная программа создаёт процесс либо открывает дескриптор целевого процесса, выделяет память и записывает или отображает код в целевой процесс, а затем принуждает внедрённый код выполняться в контексте этого процесса. Общая схема приведена на рис. 12-14. Особая благодарность исследователю вредоносных программ Карстену Хану (Karsten Hahn), чья работа вдохновила автора на создание этого рисунка.

Рис. 12-14. Сводка действий и вызовов API при внедрении в процессы

Теперь, рассмотрев разные методы внедрения в процессы, перейдём к другому способу, применяемому в сходных целях, манипулированию образом процесса.

Манипулирование образом процесса

Манипулирование образом процесса злоупотребляет как стандартной процедурой создания процессов Windows, так и принципами работы средств защиты конечных точек, прежде всего антивредоносного программного обеспечения. Чтобы защищать систему от атак, такое программное обеспечение должно знать, когда запускается новый процесс, и отслеживать его подозрительное поведение. Здесь вступает в действие функция API PsSetCreateProcessNotifyRoutineEx. При создании нового процесса эта функция отправляет уведомление средству защиты конечной точки, после чего оно исследует и сканирует исходный исполняемый файл, запустивший процесс. Если антивредоносная программа обнаруживает во входном файле вредоносный код, она может поместить файл в карантин и завершить все связанные с ним процессы. Проблема заключается в том, что PsSetCreateProcessNotifyRoutineEx вызывается не в точный момент создания процесса, а при создании и выполнении первых нескольких потоков в его контексте. В результате у вредоносной программы появляется удобное окно возможностей для изменения исходного исполняемого файла до того, как его успеют просканировать средства защиты.

Манипулирование процессами также связано с вмешательством в механизм создания процессов Windows, описанный в главе 1. В сущности, Windows обычно вызывает такую функцию, как NtCreateUserProcess, которая работает в режиме ядра, обрабатывает детали создания процесса, а затем отображает его в память, выполняя следующие шаги:

1. Получает дескриптор исполняемого файла, например посредством вызова CreateFile.

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

3. Создаёт объект процесса вызовом NtCreateProcessEx с параметром, ссылающимся на только что созданный объект секции, и отображает объект процесса в память в виде нового процесса.

4. Выполняет процесс, вызывая NtCreateThreadEx для создания и запуска нового потока.

Рассмотрим, как разные методы манипулирования процессами вмешиваются в эти шаги.

Process Herpaderping

У метода process herpaderping забавное название, но очень мощное действие. Он вводит в заблуждение операционную систему и антивредоносные решения, вмешиваясь в механизм создания процессов Windows. Работа метода показана на рис. 12-15.

Рис. 12-15. Метод process herpaderping

Сначала вредоносная программа создаёт на диске новый файл, получает его дескриптор и оставляет этот дескриптор открытым 1. Она записывает в пустой файл вредоносный исполняемый код, а затем создаёт для файла объект секции 2. Далее программа создаёт процесс с использованием нового объекта секции 3. Теперь вредоносный код отображён в память, но ещё не выполняется. До этого момента подход следует стандартным этапам загрузки PE-файла в Windows, однако дальше начинается самое интересное.

Вредоносная программа изменяет либо удаляет вредоносный код из созданного на диске файла 4. Затем она запускает новый поток (NtCreateThreadEx), который выполняет находящийся в памяти вредоносный код, и закрывает дескриптор открытого файла. В этот момент срабатывает упомянутый ранее обратный вызов PsSetCreateProcessNotifyRoutineEx, и средства защиты конечной точки приступают к проверке вредоносного файла. Но поскольку теперь файл фактически уже не содержит вредоносного кода, антивредоносная программа ошибочно считает, что всё в порядке. Как антивредоносное программное обеспечение, так и сама Windows предполагают, что файл на диске нельзя или не следует изменять, когда он уже отображён в память и выполняется внутри процесса. Process herpaderping пользуется такими предположениями для выполнения вредоносного кода. Подробнее об этом методе можно прочитать у его автора по адресу https://jxy-s.github.io/herpaderping/. Чтобы испытать метод самостоятельно, изучите доказательство концепции по адресу https://github.com/jxy-s/herpaderping.

Process Doppelganging

Process doppelganging, впервые представленный на конференции Black Hat 2017 исследователями безопасности Юджином Коганом (Eugene Kogan) и Талом Либерманом (Tal Liberman), представляет собой метод манипулирования, использующий транзакционную NTFS для сокрытия выполнения вредоносного кода. Термин doppelganging происходит от слова doppelganger, которым обычно называют человека, имеющего поразительное сходство с кем-то другим.

Транзакционная NTFS была разработана для добавления в NTFS, стандартную файловую систему Windows, дополнительных возможностей и поддержки, например сохранения целостности файлов и улучшенной обработки ошибок. Она позволяет использовать транзакции, которые отслеживают изменения файловой системы и при необходимости могут быть отменены. Такие действия, как удаление файла, сначала происходят виртуально. Если запрос на удаление завершается успешно, транзакция фиксируется и файл действительно удаляется. Если же запрос приводит к ошибке, транзакция откатывается и никаких действий не происходит. В конечном счёте транзакции призваны предотвращать несогласованность и повреждение данных вследствие системного сбоя или другого неожиданного события.

Новый файл, созданный с использованием транзакций, обычно недоступен извне процесса, который в данный момент с ним взаимодействует; в такой ситуации к нему не могут обратиться даже некоторые антивредоносные решения. Поэтому транзакции способны предоставить безопасное место, где вредоносный файл может временно скрываться. Кроме того, поскольку транзакционные файлы можно "откатить" к предыдущему состоянию, средства защиты конечных точек легко ввести в заблуждение. Именно поэтому process doppelganging оказывается эффективным. Работа метода показана на рис. 12-16.

Рис. 12-16. Метод process doppelganging

Эта вредоносная программа создаёт новую транзакцию NTFS с помощью CreateTransaction и открывает существующий исполняемый файл посредством CreateFileTransacted 1. Для достижения того же результата она могла бы вместо этого вызвать функции более низкого уровня, например ZwCreateTransaction, RtlSetCurrentTransaction и ZwCreateFile. Затем вредоносная программа записывает свой код в существующий PE-файл (WriteFile), заменяя исходный код исполняемого файла 2. Далее она выполняет CreateProcess либо NtCreateProcessEx, чтобы создать новый процесс, передавая расположение нового вредоносного PE-файла, двойника, в качестве параметра 3. После того как PE-файл отображён в память и вредоносный процесс запущен, программа намеренно откатывает исходную транзакцию NTFS (RollbackTransaction), возвращая файл в первоначальное состояние до заражения 4. Когда антивредоносное программное обеспечение получает уведомление о создании процесса и сканирует его исполняемый файл на диске, уже слишком поздно: исходный исполняемый файл успел вернуться в невредоносное состояние.

С момента первой публикации process doppelganging в 2017 году появилось несколько разновидностей этого метода. Один из вариантов, названный исследователями Malwarebytes transacted hollowing, объединяет опустошение процесса с process doppelganging. См. публикацию «Process Doppelgänging Meets Process Hollowing in Osiris Dropper». Как и при doppelganging, вредоносная программа создаёт новый процесс для внедряемой полезной нагрузки. Однако вместо её непосредственного внедрения программа создаёт процесс в приостановленном состоянии и отображает вредоносный код в память, как при опустошении процесса. Это наглядный пример того, как результаты исследований безопасности впоследствии становятся для авторов вредоносных программ отправной точкой при создании новых методов.

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

Подмена образа и маскировка процесса

Подмена образа процесса (process reimaging) сходна с описанными ранее методами в том, что для обхода средств защиты она опирается на манипулирование уже выполняющимся процессом. Для подмены образа вредоносная программа изменяет свой атрибут FILE_OBJECT, содержащий путь к её исполняемому файлу на диске, так, чтобы он указывал на безвредный законный исполняемый файл. Метод основан на несогласованности обработки FILE_OBJECT в Windows, из-за которой некоторые антивредоносные продукты слишком доверяют пути, сохранённому в FILE_OBJECT вредоносного процесса. Дополнительные сведения приведены в публикации McAfee «In NTDLL I Trust - Process Reimaging and Endpoint Security Solution Bypass» и в репозитории ProcessReimaging на GitHub.

Маскировка процесса (process ghosting) больше всего похожа на process herpaderping. Вредоносная программа создаёт файл и просит Windows перевести его в состояние ожидания удаления. Поскольку между переводом файла в это состояние и фактическим удалением может пройти некоторое время, программа успевает записать в файл вредоносный исполняемый код и создать для него объект образа, скопировав содержимое файла в память, прежде чем Windows удалит файл. Наконец, вредоносная программа создаёт процесс с объектом образа уже удалённого файла и выполняет его. Пока файл ожидает удаления, Windows не позволяет средствам защиты конечных точек, например антивредоносным программам, читать и исследовать его, поэтому они фактически не видят содержащийся в нём вредоносный код. Подробнее об этом методе можно прочитать в публикации «What You Need to Know About Process Ghosting».

Теперь перейдём к ещё одной паре методов внедрения и скрытого выполнения кода.

Перехват DLL и механизмов совместимости

Перехват - общее название методов, предусматривающих вмешательство в нормальный поток выполнения программы либо манипулирование механизмом запуска программ в Windows с целью выполнения несанкционированного кода. В частности, перехват DLL использует порядок загрузки необходимых библиотек законными исполняемыми файлами для внедрения вредоносной DLL. Перехват механизмов совместимости (shim hijacking) задействует прикладные механизмы совместимости Windows, то есть небольшие библиотеки, перехватывающие вызовы API, чтобы внедрять код в выполняющийся процесс. Рассмотрим оба метода подробнее.

Перехват DLL

Всем приложениям Windows в определённый момент приходится загружать DLL-файлы. У большинства приложений есть своего рода манифест, где перечислены все необходимые DLL и места их хранения на диске. Этот манифест входит в порядок поиска DLL приложения. К числу других возможных мест поиска относятся каталог установки приложения по умолчанию, например C:\Program Files\CoolApplication, где находится его основной исполняемый файл, и каталоги Windows, содержащие стандартные DLL Windows, например %SystemRoot%\system32.

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

Пример такой атаки встречается в семействе вредоносных программ Qbot. Один из вариантов Qbot доставлялся жертве вместе с несколькими файлами, прежде всего вредоносной DLL WindowsCodecs.dll, копией старой, но законной версии калькулятора Windows calc.exe и библиотекой 7533.dll. В IAT файла calc.exe присутствовал любопытный импорт, выделенный на рис. 12-17.

Рис. 12-17. Необычный импорт в файле calc.exe, доставленном вариантом Qbot

После запуска приложение calc.exe начинает с текущего местоположения искать WindowsCodecs.dll, настоящая версия которой представляет собой законный безвредный вспомогательный компонент Windows. Поскольку автор вредоносной программы "услужливо" поместил WindowsCodecs.dll рядом с calc.exe, вредоносная версия DLL внедряется в calc.exe, после чего выполняется её код. Эта атака показана в Procmon на рис. 12-18.

Рис. 12-18. Боковая загрузка вредоносного файла WindowsCodecs.dll

Этот экспорт временной шкалы Procmon показывает, как жертва запускает уязвимый файл calc.exe (Process Start), тот загружает вредоносный файл WindowsCodecs.dll (Load Image), а библиотека, в свою очередь, выполняет ещё одну полезную нагрузку (regsvr32.exe 7533.dll). Автор вредоносной программы знает, что именно эта старая версия calc.exe уязвима для перехвата DLL, поскольку она слепо загружает и выполняет любую библиотеку с именем WindowsCodecs.dll, находящуюся в её рабочем каталоге. Весьма изобретательно!

Перехват механизмов совместимости

Платформа Microsoft Application Compatibility поддерживает механизмы совместимости приложений (application shimming), благодаря которым программное обеспечение, разработанное для старых версий Windows, может работать в более новых версиях операционной системы. Разработчики применяют такие механизмы, чтобы исправлять программы без переписывания или повторной компиляции кода. Однако они полезны не только разработчикам: для вредоносных программ это также мощный способ внедрения кода. С их помощью вредоносная программа может перехватывать вызовы API и изменять их параметры. Когда пользователь запускает приложение, Windows активирует подсистему совместимости и проверяет, установлены ли для этого приложения какие-либо исправления совместимости. Вредоносная программа может злоупотребить этим поведением посредством механизма InjectDLL, который, как следует из названия, внедряет модуль DLL в приложение. После запуска исполняемого файла приложения вредоносная DLL также загружается в образ приложения-жертвы и выполняется.

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

После установки механизма совместимости на узле жертвы его база данных размещается в C:\Windows\AppPatch\Custom либо, для 64-разрядных приложений, в C:\Windows\AppPatch\AppPatch64\Custom\Custom64 в виде одного или нескольких файлов .sdb. Пример такого файла показан на рис. 12-19.

Рис. 12-19. Файл .sdb, установленный в системе Windows

Установленные механизмы совместимости обычно имеют запись реестра в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom либо HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB, как показано на рис. 12-20.

Рис. 12-20. Записи базы данных совместимости в реестре

Во время расследования подозрительные файлы .sdb можно подробнее изучить с помощью удачно названного инструмента SDB Explorer, который бесплатно доступен по адресу https://ericzimmerman.github.io/ и показан на рис. 12-21.

Рис. 12-21. Исследование файла .sdb в SDB Explorer

Как видно из этого вывода, файл, по-видимому, применяет механизмы совместимости к chrome.exe, explorer.exe, firefox.exe и iexplore.exe. Также видно, что он использует функцию InjectDll и ссылается на DLL-файл spvc32loader.dll. На основании этих сведений можно предположить, что механизм нацелен на процессы браузеров и пытается внедрить вредоносную DLL в соответствующее адресное пространство памяти при первом запуске процесса браузера.

Хороший пример перехвата механизмов совместимости описан в отчёте Mandiant о группе FIN7. Группа сумела установить бэкдор Carbanak и закрепиться на заражённых конечных точках, зарегистрировав новую базу данных совместимости и исправив законный исполняемый файл Windows services.exe. Services.exe является критически важным системным процессом и всегда запускается при загрузке Windows. Когда выполняется services.exe, активируется механизм совместимости и запускает вредоносную полезную нагрузку Carbanak. Полное описание атаки приведено по адресу https://www.mandiant.com/resources/fin7-shim-databases-persistence.

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

Перехват функций

Как описано в главе 8, перехват функций (hooking) - это метод перехвата, наблюдения и возможного изменения вызовов функций Windows. Он применяется как во вредоносных, так и в законных целях. Например, перехват могут использовать следующие программы:

• Безвредные приложения, в том числе механизмы совместимости, чтобы изменять или исправлять код либо наблюдать за системой или другими приложениями.

• Песочницы и другие средства анализа вредоносных программ, чтобы отслеживать их поведение.

• Средства защиты конечных точек, такие как антивредоносные программы и системы обнаружения и реагирования на конечных точках (EDR).

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

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

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

Перехват и внедрение с помощью SetWindowsHookEx

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

В этом примере функции SetWindowsHookEx в качестве параметров передаются несколько переменных. Параметр idHook может принимать множество разных значений, каждое из которых обозначает системное событие, подлежащее наблюдению и перехвату. Например, значения WH_MOUSE и WH_MOUSE_LL, причём в примере используется последнее, перехватывают связанные с мышью события, такие как щелчки. Ещё два перехватчика, часто применяемых вредоносными программами, WH_KEYBOARD и WH_KEYBOARD_LL, перехватывают события клавиатуры.

Параметр hmod обозначает имя загруженного модуля, содержащего вредоносный код, который будет выполнен при наступлении события мыши. В данном примере вредоносная программа вызывает LoadLibrary, загружая вредоносную библиотеку evil.dll в процесс-жертву. Параметр lpfn представляет указатель на код, выполняемый при событии мыши. Здесь выполняемой вредоносной функцией является находящаяся в evil.dll функция Function_1.

Наконец, параметр dwThreadId обозначает идентификатор конкретного потока, за которым следует наблюдать. Если программа, вызывающая SetWindowsHookEx, хочет следить лишь за одним потоком одного приложения, она может указать здесь его идентификатор. Чтобы следить за всеми потоками, вызывающая программа присваивает этому параметру значение 0.

Итак, вредоносный файл evil.dll загружается и выполняется внутри процесса-жертвы при каждом обнаруженном событии мыши. Поскольку вредоносная программа может скрываться и ожидать строго определённого события, например заданного количества щелчков мышью или нажатия конкретной клавиши, такая атака способна быть очень скрытной. Однако этот метод довольно стар, и современные версии Windows умеют предотвращать подобные атаки. Кроме того, такое поведение крайне подозрительно и, вероятно, приведёт в действие средства защиты конечной точки. Более того, именно этот пример почти наверняка сделает систему очень нестабильной: загружать DLL при каждом событии мыши неразумно. Тем не менее варианты метода всё ещё встречаются в современных вредоносных программах, поэтому о нём важно знать.

Встроенный перехват

Одна из самых распространённых форм перехвата в пользовательском пространстве - встроенный перехват (inline hooking). Он основан на внедрении кода в целевой процесс и одновременном изменении перехватываемой законной функции так, чтобы она принудительно переходила к внедрённому коду. Сначала процесс, желающий перехватить другой, целевой процесс, должен внедрить в него код одним из описанных ранее методов; одним из самых распространённых является внедрение DLL. Затем первый процесс изменяет нужную функцию в адресном пространстве целевого процесса, заставляя её указывать и переходить к внедрённому коду перехвата. Когда целевой процесс выполняет эту функцию, поток управления передаётся от исходного кода к коду перехвата, который может наблюдать за вызовами исходной функции, перехватывать их или изменять. Метод встроенного перехвата показан на рис. 12-22.

Рис. 12-22. Метод встроенного перехвата API

Приложение вызывает функцию WinAPI NtCreateFile, расположенную внутри ntdll.dll. В нормальной ситуации после этого выполнялся бы код NtCreateFile из ntdll.dll. Однако библиотека ntdll.dll была изменена, а её законный код перезаписан инструкцией перехода, поэтому теперь программа вместо него переходит к коду перехвата и выполняет его. После выполнения вредоносного кода поток управления возвращается в ntdll.dll, а затем в исходное приложение.

Предположим, система заражена образцом вредоносной программы, который хочет перехватывать и отслеживать все вызовы NtCreateFile в процессе-жертве, например firefox.exe. Внедрив вредоносную DLL перехвата в firefox.exe, программа должна изменить модуль ntdll.dll в адресном пространстве процесса-жертвы. Она находит функцию NtCreateFile внутри ntdll.dll и перезаписывает первые 5 байт, чтобы вместо настоящего кода NtCreateFile происходил переход к внедрённой вредоносной DLL. Часто перезаписывают именно 5 байт, поскольку это типичный размер инструкции перехода. За первым байтом E9, обозначающим инструкцию перехода, следуют 4 байта адреса памяти, к которому нужно перейти. Для изменения кода функции в целевом процессе первый процесс может вызвать WriteProcessMemory либо memcpy. В следующем блоке показаны первые байты законной функции NtCreateFile в ассемблере x64:

После изменения вредоносной программой функция NtCreateFile может выглядеть следующим образом; обратите внимание на переход к вредоносному коду:

Вместо инструкции jmp переход к коду перехвата можно выполнить с помощью инструкций push и ret:

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

Для этого используется трамплин, который представляет собой простой переход обратно к исходной функции, как показано на рис. 12-23.

Рис. 12-23. Трамплин встроенного перехватчика

Трамплины часто реализуют такой инструкцией, как call NtCreateFile+5. После выполнения кода перехвата, в данном случае внутри внедрённой DLL, эта инструкция передаёт поток управления обратно настоящей функции NtCreateFile, пропуская первые 5 байт изменённого файла ntdll.dll, где находится вставленная инструкция jmp.

При анализе вредоносной программы на встроенный перехват могут указывать вызовы трёх функций. Сначала программа вызывает ReadProcessMemory, чтобы прочитать первые байты кода функции, которую она хочет перехватить внутри целевого процесса. Затем вызывается VirtualProtect, чтобы изменить разрешения целевой области памяти и подготовить её к записи инструкции перехода к вредоносному коду, внедрённому в целевой процесс. Наконец, вредоносная программа вызывает WriteProcessMemory, записывая инструкцию перехода в код целевой функции.

ПРИМЕЧАНИЕ. Ещё одним методом перехвата в пользовательском пространстве является перехват IAT, при котором таблица адресов импорта целевого процесса изменяется так, чтобы указывать на код перехвата, а не на код исходной функции. Однако современные вредоносные программы редко используют перехват IAT, поскольку средства защиты узла легко его обнаруживают, поэтому подробно рассматривать этот метод мы не будем.

Меры противодействия внедрению в процессы и перехватчиков

По мере того как в новых вредоносных программах появляются методы внедрения и перехвата либо исследователи обнаруживают и публикуют их, Microsoft по возможности противодействует им с помощью встроенных средств защиты. Например, предотвращение выполнения данных (Data Execution Prevention), появившееся в Windows XP, стремится помешать вредоносной программе выполнять внедрённый код, отмечая области памяти как неисполняемые. AppLocker, представленный в Windows 7, не позволяет выполнять несанкционированные исполняемые файлы, к которым могут относиться и внедрённые DLL. Control Flow Guard, выпущенный в Windows 8.1, предназначен для обнаружения изменений потока управления кодом другого процесса, часто происходящих при внедрении в процессы. Наконец, Arbitrary Code Guard (ACG), добавленный в Windows 10, стремится не допустить изменения вредоносной программой кода законных процессов и тем самым предотвращает некоторые виды внедрения в процессы и перехватчиков.

Кроме того, дополняющие средства защиты, такие как EDR и антивредоносное программное обеспечение, могут наблюдать за подозрительными процессами и обнаруживать или предотвращать некоторые виды внедрения. Однако следует помнить, что не всякое внедрение вредоносно: множество безвредных законных приложений используют его по разным причинам, поэтому продуктам защиты конечных точек бывает трудно отличить добро от зла. В главе 13 будут рассмотрены некоторые из этих средств защиты и способы, которыми вредоносные программы пытаются их обойти.

Итоги

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

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

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

Основы защиты конечных точек

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

Краткая история технологий защиты конечных точек

Программное обеспечение для защиты конечных точек восходит к ранней эпохе вредоносных программ, 1970-м и 1980-м годам. В то время такие средства уместно называли антивирусами (AV), поскольку большинство видов вредоносного программного обеспечения было широко известно как вирусы. Ранние вредоносные программы были относительно просты, а антивирусы всего лишь искали в файлах определённые вредоносные шаблоны. Обычно такие программы создавали энтузиасты.

В конце 1980-х и начале 1990-х годов вредоносные программы начали усложняться, и для противодействия растущей угрозе появились коммерческие разработчики антивирусов, в том числе Norton, Kaspersky и McAfee. Их продукты предлагали более совершенные возможности, чем любительские антивирусы: сканирование в реальном времени, эвристическое обнаружение и автоматическое обновление сигнатур.

Вынужденные приспосабливаться к развитию технологий, авторы вредоносных программ создавали всё более сложные и скрытные образцы, способные обходить традиционные антивирусы. В ответ поставщики антивирусных решений стали разрабатывать гораздо более мощное программное обеспечение, которое далее я буду называть антивредоносным, а также продукты, называемые платформами защиты конечных точек (EPP). EPP представляют собой более комплексное решение для защиты узла и включают функции, отсутствующие в традиционных антивредоносных средствах, например встроенные программные межсетевые экраны и предотвращение вторжений на узле. Позднее появились решения для обнаружения и реагирования на конечных точках (EDR), более совершенные средства безопасности, предоставляющие видимость активности конечной точки в реальном времени и позволяющие командам безопасности быстро обнаруживать угрозы и реагировать на них.

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

Антивредоносное программное обеспечение

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

Обнаружение по хешам

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

Главная проблема метода заключается в том, что файлы уже должны быть известны антивредоносному программному обеспечению. Если файл новый и отсутствует в базе данных, программа не может обнаружить его, по крайней мере посредством одного лишь анализа хеша. Согласно пресс-релизу Kaspersky от 15 декабря 2020 года, в течение того года ежедневно создавалось около 360 000 новых вредоносных файлов. Очевидно, это создаёт проблему для обнаружения по хешам, поскольку антивредоносные средства просто не способны за ними поспевать.

Обнаружение по сигнатурам

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

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

Эвристическое обнаружение

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

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

Облачные песочницы анализа

Пропускать каждый системный файл через механизм эмуляции было бы слишком затратно, поэтому некоторые современные поставщики антивредоносных решений вместо этого используют облачные песочницы анализа. Если файл остаётся неклассифицированным даже после проверки по хешам и сигнатурам, а также эвристического обнаружения, его отправляют в облачную среду поставщика для выполнения в песочнице и дальнейшего анализа. Облачные песочницы представляют собой разновидность коллективной защиты: все заказчики, использующие такое антивредоносное программное обеспечение, получат уведомление о вредоносности определённого файла, даже если никогда прежде его не встречали. Рассмотренные механизмы обнаружения сведены на рис. 13-1.

Рис. 13-1. Типичные механизмы обнаружения антивредоносного программного обеспечения

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

Ограничения и сложности

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

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

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

Наконец, хотя антивредоносное программное обеспечение предназначено для обнаружения и искоренения угроз на конечной точке, оно не проектировалось с учётом расследования после компрометации или восстановления контекста. Современные сложные атаки часто состоят из множества этапов цепочки с применением нескольких методов и компонентов, а одно антивредоносное средство способно оставить слепые зоны, особенно в сложной корпоративной среде. Здесь в дело вступает EDR.

Обнаружение и реагирование на конечных точках

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

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

Кратко заглянем внутрь и посмотрим, как работает EDR. Обычно решение состоит из нескольких компонентов в пользовательском пространстве и пространстве ядра, а также агрегатора журналов и механизма анализа. Начнём с компонентов пользовательского пространства.

Компоненты пользовательского пространства

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

На рис. 13-2 показано, как EDR перехватывает вредоносную программу.

Рис. 13-2. Процесс EDR перехватывает вредоносную программу с помощью модуля

Исполняемый файл вредоносной программы malware.exe вызывает функцию WinAPI из kernel32.dll, которая затем обращается к ntdll.dll. В обычной ситуации ntdll.dll выполнила бы системный вызов в пространство ядра. Но установленное средство EDR перехватывает ntdll.dll посредством ранее внедрённой библиотеки edr_hook.dll. Благодаря этому EDR может решить, разрешить вызов API, заблокировать его или даже завершить процесс. Если активность API признана безвредной, EDR позволяет вызову продолжить обычный путь к ядру.

Современные антивредоносные средства и EDR могут перехватывать, среди прочего, следующие распространённые функции:

• Операции с памятью, например NtProtectVirtualMemory и NtReadVirtualMemory, чтобы отслеживать фиксацию памяти и изменения защиты, в частности узнавать о переводе области памяти в режим чтения, записи и выполнения (RWX), что может указывать на готовящийся запуск кода из этой области.

• Функции создания и завершения процессов, например NtCreateProcessEx, NtCreateUserProcess и NtTerminateProcess, чтобы EDR мог наблюдать за вновь созданными процессами и устанавливать в них перехватчики.

• Функции загрузки библиотек, например LdrLoadDll, чтобы EDR мог наблюдать, как подозрительные процессы загружают новые библиотеки и модули.

• Функции, обычно применяемые для внедрения в процессы, например NtOpenProcess, NtCreateThread, NtResumeThread, NtUnmapViewOfSection и NtMapViewOfSection, чтобы EDR мог отслеживать попытки внедрения кода и перехватчиков.

• Операции записи в файлы, например NtWriteFile, которые часто используют программы-вымогатели и другие разрушительные вредоносные программы.

• Функции, пытающиеся устанавливать сетевые соединения, например InternetOpen и InternetConnect, чтобы EDR мог отслеживать подозрительный сетевой обмен.

Перехват вызовов функций API - лишь один из способов наблюдения за системой. Некоторые продукты EDR также собирают системные данные из других источников, например с помощью трассировки событий Windows (Event Tracing for Windows, ETW), механизма журналирования и диагностики, входящего в состав Windows с 2007 года. ETW умеет собирать и регистрировать данные из множества источников, включая процессы пользовательского пространства и драйверы ядра, поэтому этот механизм весьма полезен и для получения данных EDR. Подробнее о нём можно прочитать в документации Microsoft.

Для выявления подозрительной активности агенты EDR могут использовать систему оценки угроз. Рассмотрим показанный на рис. 13-3 сценарий атаки.

Рис. 13-3. Многоэтапная атака

Сначала злоумышленник отправляет целевому пользователю специально подготовленное фишинговое письмо с вложенным вредоносным документом Microsoft Office. Вредоносный код документа Office запускает PowerShell для связи с промежуточным сервером, на котором размещена полезная нагрузка злоумышленника ransomware.exe, а затем загружает и выполняет её в памяти. После этого программа-вымогатель начинает шифровать файлы на жёстком диске жертвы.

Продукт EDR присваивает оценку каждому событию этой атаки. Предположим, документ Office, запустивший команду PowerShell, получает значение угрозы 35, соединение с подозрительным сервером - 20, а загрузка и выполнение неизвестного исполняемого файла - 30. Если максимальная оценка угрозы условно равна 100, а любое значение выше 75 считается вредоносным, то последовательность событий с суммарной оценкой 85 побудит EDR выполнить такие действия, как завершение процессов Office и PowerShell либо разрыв сетевых соединений с удалённым сервером. Само выполнение программы-вымогателя, вероятно, получит высокую оценку угрозы, поскольку такая программа создаёт множество операций записи в файлы. Кроме того, связанные с событиями метаданные будут переданы в центральное хранилище и обработчик журналов, что позволит EDR анализировать атаку в контексте всей корпоративной инфраструктуры.

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

Компоненты пространства ядра

В пространстве ядра решения EDR в основном представлены драйверами или модулями ядра, то есть фрагментами скомпилированного кода, выполняемого в адресном пространстве ядра. Драйверы ядра EDR опираются на обратные вызовы, функции, регистрируемые компонентами ядра для получения уведомлений о конкретных событиях. Например, чтобы наблюдать за появлением новых процессов, драйвер ядра EDR регистрирует процедуру обратного вызова посредством функции ядра PsSetCreateProcessNotifyRoutine. Когда процесс создаётся или завершается, драйвер EDR получает уведомление и может соответствующим образом отреагировать, вероятно, задействовав компонент пользовательского пространства для внедрения перехватчиков в новый процесс и начала наблюдения. Эта схема показана на рис. 13-4.

Рис. 13-4. Внедрение перехватчика EDR

В этом примере драйвер ядра EDR получает через PsSetCreateProcessNotifyRoutine, не показанную на рисунке, уведомление о создании нового процесса malware.exe 1. Драйвер EDR поручает агенту EDR в пользовательском пространстве edr_agent.exe 2 внедрить перехватчик в новый процесс 3. Теперь EDR наблюдает за malware.exe.

Ниже перечислены ещё несколько обратных вызовов, которые может использовать EDR, и обстоятельства их срабатывания:

• PsSetCreateThreadNotifyRoutine срабатывает при создании или удалении любого нового потока.

• PsSetLoadImageNotifyRoutine(Ex) срабатывает, когда процесс загружает образ, например модуль DLL, в память либо когда загружается новый драйвер.

• IoWMISetNotificationCallback срабатывает при событиях инструментария управления Windows (WMI).

• CmRegisterCallback(Ex) срабатывает, когда любой выполняющийся поток изменяет реестр Windows.

• FsRtlRegisterFileSystemFilterCallbacks срабатывает при определённых операциях файловой системы.

• IoRegisterBootDriverCallback срабатывает при инициализации нового драйвера ранней загрузки. Такие драйверы запускаются при загрузке системы, поэтому этот обратный вызов может использоваться антивредоносными средствами и EDR для обнаружения руткитов и буткитов, задействующих загрузочный драйвер. Подробнее о руткитах рассказано в главе 14.

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

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

ПРИМЕЧАНИЕ. Возможно, вы заметили, что EDR внедряет модули в другие процессы, устанавливает перехватчики вызовов API и драйверы в пространстве ядра, а это пугающе похоже на вредоносную программу! Действительно, EDR выглядит подозрительно похожим на разновидность вредоносных программ, называемую руткитами. Подробнее методы и компоненты руткитов рассматриваются в главе 14.

Журналирование и анализ

Ранее упоминалось, что одна из обязанностей агента EDR - передавать события и связанные с ними данные на центральный сервер журналирования, где их можно дополнительно анализировать и сохранять для будущих расследований. Этот процесс показан на рис. 13-5.

Рис. 13-5. Агент EDR собирает данные с нескольких конечных точек для анализа

Как видно на рисунке, агенты EDR, работающие на разных конечных точках корпоративной инфраструктуры, передают данные агрегатору журналов EDR. Данные обрабатываются и анализируются с помощью различных специфичных для поставщика методов, благодаря чему продукт EDR может, например, обнаруживать более масштабные атаки. Используя эту телеметрию, некоторые продукты даже способны "научиться" понимать нормальное поведение конкретной корпоративной среды и лучше отличать типичные действия конечных пользователей от вредоносной активности. Многие современные решения EDR также могут собирать журналы из множества разных источников, чтобы наблюдать за всей ИТ-инфраструктурой организации. Такие решения иногда называют платформами расширенного обнаружения и реагирования (XDR). XDR умеют собирать и анализировать данные из клиентских конечных точек, серверов, сетевых устройств, приложений и облачных вычислительных сред. Далее в книге термин EDR будет также обозначать XDR.

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

Выявление средств защиты конечных точек

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

Пример вывода этой команды:

В системе автора активным антивредоносным продуктом оказался Microsoft Defender. В выводе используется устаревшее название Windows Defender; с тех пор продукт был переименован в Microsoft Defender.

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

В главе 4 обсуждалось, как вредоносная программа перечисляет выполняющиеся на узле процессы, чтобы обнаруживать песочницы и виртуальные машины. То же самое она может делать для выявления защиты. Например, программа способна вызвать функции Windows API CreateToolhelp32Snapshot, чтобы создать "снимок" всех процессов на узле жертвы, а затем перебрать их посредством Process32First и Process32Next. После этого можно искать подозрительные имена процессов, например MsMpEng.exe, стандартный антивредоносный процесс Windows 10 и 11, AvastSvc.exe, исполняемый процесс продукта Avast, либо любой процесс со строкой falcon в имени, который может относиться к продукту CrowdStrike Falcon EDR. Так вредоносная программа определяет, какие средства защиты присутствуют на узле.

К наиболее популярным поставщикам и продуктам anti-malware и EDR относятся:

• CrowdStrike Falcon EDR: CSFalcon*.exe.

• ESET Smart Security: Ekrn.exe.

• Kaspersky: Avp.exe.

• Malwarebytes: Mbam.exe.

• McAfee Endpoint Security: masvc.exe.

• Sophos: SavService.exe.

• Symantec Endpoint Protection: ccSvcHst.exe.

• VMware Carbon Black: cb.exe.

• Microsoft Defender for Endpoint, ранее Windows Defender: MsMpEng.exe.

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

В качестве альтернативы можно эффективно сканировать узел в поисках файлов, драйверов и ключей реестра, связанных с anti-malware и EDR. На рис. 13-6 показан вывод Procmon для образца вредоносной программы, который запрашивает ключи реестра, соответствующие распространённым поставщикам антивредоносных решений.

Рис. 13-6. Вредоносная программа ищет в реестре названия продуктов anti-malware и EDR

Например, антивредоносный продукт Kaspersky устанавливается в каталог вроде C:\Program Files (x86)\Kaspersky Lab\Kaspersky Total Security, а также размещает на узле несколько драйверов, видимых в каталоге C:\System32\drivers. Эти артефакты могут выдать вредоносной программе его присутствие, как показано на рис. 13-7.

Рис. 13-7. Установленные драйверы Kaspersky

Существует ряд исследовательских проектов, например Antivirus-Artifacts, каталогизирующих различные артефакты, которые продукты защиты конечных точек создают на узле. Такие ресурсы полезны и исследователям, и авторам вредоносных программ.

Наконец, уже выполняющаяся на узле вредоносная программа может искать признаки того, что anti-malware или EDR установили в неё перехватчики. Например, программа способна перечислять загруженные модули с помощью Module32First и Module32Next, как описано в главе 7, либо искать в памяти своего процесса признаки перехвата, как при обходе перехватчиков песочницы из главы 8. Эти перехватчики могут выдать конкретный защитный продукт.

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

Активный обход средств защиты конечных точек

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

Отключение защиты узла

Грубый, но действенный способ уклониться от безопасности конечной точки - просто отключить её. Перечислив работающие на узле продукты безопасности, вредоносная программа может вывести их из строя несколькими способами. Во-первых, она способна попытаться завершить процессы приложений, включая процессы anti-malware и EDR, процессы и службы Windows Security Center и любые межсетевые экраны, например встроенный межсетевой экран узла Windows, посредством функции TerminateProcess либо таких инструментов, как PowerShell или командная строка Windows.

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

Команда net stop WinDefend завершает процесс Microsoft Defender, а команды REG ADD изменяют реестр, отключая службу наблюдения Microsoft Defender в реальном времени, службу AntiSpyware и антивирусный загрузочный драйвер WdBoot. Все они являются критически важными компонентами стандартной антивредоносной защиты Windows.

Некоторые вредоносные программы просто пытаются удалить защитное программное обеспечение с узла с помощью таких команд PowerShell:

Первая команда PowerShell использует WMI для перечисления установленного на узле программного обеспечения и целенаправленно ищет антивредоносный продукт ESET; вторая команда удаляет его.

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

Однако у этих методов есть подвох: в зависимости от рабочей среды вредоносной программе могут потребоваться высокоуровневые привилегии, чтобы завершать процессы и службы anti-malware, изменять конфигурацию реестра и приоритеты процессов и удалять программное обеспечение. В таком случае перед отключением средств защиты конечной точки программа должна повысить свои привилегии. Способы сделать это рассматриваются в разделе "Повышение привилегий для уклонения от защиты" на странице 248 оригинала.

Добавление исключений anti-malware

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

Для применения метода первоначальный дроппер или загрузчик создаёт исключение на узле жертвы, а после его активации развёртывает полезную нагрузку в исключённый каталог. В Microsoft Defender вредоносная программа может создать исключение с помощью следующей команды PowerShell:

Эта команда добавляет в anti-malware исключение для пути C:\Malware\DoNotScanThisDirectory\.

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

Отключение других средств безопасности

Помимо anti-malware, EDR и других защитных средств, вредоносная программа может отключать прочие функции безопасности системы. Хотя они не всегда непосредственно предотвращают атаки, их отключение способно снизить общий уровень безопасности узла и сделать его более уязвимым для последующих атак.

Например, вредоносная программа может отключить службу Windows Update, отвечающую за периодическое обновление Windows и исправление ошибок и уязвимостей. Если злоумышленник незаметно отключит эту службу, со временем общая безопасность узла ухудшится, оставив систему открытой для дальнейших атак. Чтобы отключить службу посредством PowerShell, вредоносная программа может выполнить следующую команду:

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

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

Вредоносная программа также может отключать не связанные с безопасностью инструменты, которые способны её разоблачить. Например, она может завершить и отключить диспетчер задач Windows, чтобы осторожные пользователи не заметили подозрительные выполняющиеся процессы, либо отключить редактор реестра, мешая опытному системному администратору выявить вредоносные артефакты в реестре.

В Windows существует множество политик и параметров, которые злоумышленник способен изменить для ослабления безопасности; это лишь несколько примеров. Главное заключается в том, что злоумышленник может не пытаться полностью отключить средства защиты конечной точки вроде anti-malware и EDR, а выбрать менее прямой подход и внести небольшие изменения в систему для достижения цели. Однако это палка о двух концах: чем сильнее вредоносная программа меняет систему, тем выше вероятность её обнаружения.

Ослепление защиты путём снятия перехватчиков

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

Здесь особенно заметна игра в кошки-мышки между авторами вредоносных программ и средствами защиты узлов. Программное обеспечение защиты конечной точки наблюдает за вредоносной программой и внедряет в неё перехватчики. Вредоносная программа ищет их, снимает или пытается обойти иным способом. В ответ продукты защиты проверяют, не были ли их перехватчики сняты, и цикл продолжается. Однако у защиты конечной точки здесь есть некоторое преимущество. Если программа пытается удалить перехватчики, EDR или anti-malware могут с определённой уверенностью считать процесс вредоносным, поскольку законных причин для снятия перехватчиков практически не существует.

Как упоминалось ранее, средства защиты конечных точек могут дополнять традиционное наблюдение на основе перехватчиков другими источниками системных данных, например ETW. Эти источники тоже можно ослепить разными способами; уже существует значительный объём исследований по ослеплению ETW. Один из способов заключается в перехвате или исправлении EtwEventWrite, функции, критически важной для работы ETW.

Эксплуатация уязвимостей в средствах защиты узла

Anti-malware, EDR и другие защитные продукты разрабатываются людьми, а люди совершают ошибки, поэтому в их коде неизбежно появляются дефекты, способные привести к уязвимостям, которые злоумышленники могут эксплуатировать. Публично сообщалось не о многих попытках атаковать защитные инструменты, но такая возможность существует всегда, особенно у злоумышленников, располагающих ресурсами и навыками для поиска ошибок. Быстрый поиск в базе уязвимостей MITRE CVE (https://cve.mitre.org) обнаруживает ряд публичных уязвимостей в антивредоносных продуктах, показанных на рис. 13-8.

Рис. 13-8. Уязвимости в антивредоносных продуктах по данным MITRE

В списке присутствуют уязвимости, обнаруженные в антивредоносных механизмах продуктов Watchdog, Kaspersky и F-Secure. Большинство из них относится к отказу в обслуживании (DoS): специально подготовленный код может аварийно завершить антивредоносный механизм или иным образом снизить его эффективность.

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

Пассивный обход средств защиты конечных точек

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

Обход наблюдения

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

Anti-malware и EDR наблюдают за различными вызовами Windows API для выявления вредоносной активности, поэтому одной из мер обхода являются прямые системные вызовы, то есть обращения из пользовательского режима в адресное пространство ядра в обход обычной процедуры. В частности, когда программа вызывает функцию API в пользовательском режиме, операционная система выполняет системный вызов в ntosknrl.exe, чтобы обратиться к коду функции, как показано на рис. 13-9.

Рис. 13-9. Обычное поведение системного вызова

Однако вместо обычной процедуры вызова Windows API и NT API вредоносная программа может выполнить системный вызов напрямую, как показано на рис. 13-10.

Рис. 13-10. Прямой системный вызов

Системные вызовы следуют базовому шаблону, называемому заглушкой системного вызова (syscall stub). Назначение заглушки - передать поток выполнения из пользовательского режима в режим ядра, где фактически находится код вызываемой функции. Далее показана заглушка системного вызова для функции NtAllocateVirtualMemory.

Самая важная часть заглушки - строка mov eax, 18, где 18 представляет номер системной службы (SSN), также называемый номером системного вызова или идентификатором syscall. Этот номер сопоставляется с кодом функции, в данном случае NtAllocateVirtualMemory, которая будет вызвана в режиме ядра. Следующая по важности часть - инструкция syscall, имеющая шестнадцатеричное представление 0F 05. Она использует SSN в регистре eax, чтобы направить поток выполнения к соответствующей функции ядра. После возврата и завершения системного вызова инструкция ret передаёт поток управления обратно основному коду программы.

ПРИМЕЧАНИЕ. Рассмотренные до сих пор заглушки системных вызовов относятся к архитектуре x64. В программах x86 часто используется другой вызов, sysenter. Его заглушки очень похожи:

Инструкция mov edx, esp перемещает SSN, хранящийся в ESP, в EDX и передаёт его инструкции sysenter, имеющей шестнадцатеричное представление 0F 34. Обратите внимание, что вызовы sysenter встречаются и в некоторых программах x64.

Чтобы выполнить прямой системный вызов и избежать перехватчиков EDR или anti-malware, вредоносной программе достаточно знать SSN нужной функции и напрямую вызвать syscall. Звучит просто, но автор сталкивается с несколькими препятствиями. Главное из них заключается в том, что SSN функций меняются в зависимости от версии Windows и уровня исправлений целевого узла. Обойти проблему можно несколькими способами. Один из вариантов - извлекать SSN из загруженной в память ntdll.dll, как показано на рис. 13-11.

Рис. 13-11. Заглушки системных вызовов в загруженном модуле ntdll.dll

На рис. 13-11 показано, как выглядят загруженные в память заглушки системных вызовов ntdll.dll. Обратите внимание на выделенные SSN некоторых экспортируемых функций ntdll.dll. Вредоносная программа может исследовать загруженные в память модули, найти соответствующие заглушки и определить необходимый SSN. Получив SSN нужной функции, она создаёт собственные заглушки системных вызовов, обходя стандартный вызов через ntdll.dll. Следующий код показывает применение системных вызовов, точнее sysenter, в варианте Remcos (SHA256: 45cd8dd797af4fd769eef00243134c46c38bd9e65e15d7bd2e9b834d5e8b3095):

Этот образец Remcos определяет SSN нужных функций, перебирая файл ntdll.dll на диске, что в коде не показано. Затем он вызывает функцию со стандартной заглушкой sysenter. В частности, Remcos пытается скрытно внедрить код в другой процесс, выполняя прямые вызовы sysenter для функций NtMapViewOfSection, NtWriteVirtualMemory, NtResumeThread и других.

Одна из проблем подхода состоит в том, что системные вызовы исходят не из предназначенного для них модуля ntdll.dll. Для средств защиты конечных точек, ищущих такую аномалию, это явный признак. Более скрытный вариант, иногда называемый косвенным системным вызовом, заключается в повторном использовании системных вызовов из ntdll.dll вместо создания собственных заглушек. Для этого вредоносная программа находит в ntdll.dll адрес заглушки нужной функции. Затем, например, вместо вызова NtMapViewOfSection она реализует инструкцию jmp, непосредственно переходящую к этой заглушке внутри ntdll.dll.

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

Уклонение посредством системных вызовов - увлекательная тема. Если вы хотите узнать больше, автор рекомендует следующие материалы:

• Usman Sikander, «AV/EDR Evasion Using Direct System Calls (User-Mode vs. Kernel-Mode)», Medium, 11 марта 2022 года.

• Cornelis, «Red Team Tactics: Combining Direct System Calls and sRDI to bypass AV/EDR», Outflank, 19 июня 2019 года.

• Red Team Notes, «Calling Syscalls Directly from Visual Studio to Bypass AVs/EDRs», без даты.

Обход обнаружения по сигнатурам

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

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

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

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

Этот блок просто присваивает регистру eax значение 0, а затем устанавливает его равным 1. Сравните со следующим кодом:

Он также устанавливает eax в 0, но с помощью инструкции xor, а не mov, а затем присваивает eax значение 1 инструкцией inc вместо add. Если бы это был настоящий вредоносный код, антивредоносное средство могло бы иметь сигнатуру одного из блоков, но не другого. Разумеется, в реальных условиях код был бы намного сложнее.

Мутация может происходить динамически во время выполнения либо применяться к самому файлу вредоносной программы. Мутация во время выполнения начинается после запуска программы в системе жертвы. Она может динамически изменять код в памяти, уклоняясь от защиты, которая сканирует память в поисках вредоносных шаблонов. Мутация самого файла происходит до доставки жертве. Автор может пропустить код через механизм мутации, выпускающий уникальные варианты одной программы для доставки разным жертвам. Упаковщики, подробно рассматриваемые в главе 17, могут обеспечивать как мутацию во время выполнения, так и статическую мутацию файла. После прохождения вредоносной программы через механизм упаковки её код обфусцируется, и она выглядит отличной от всех прочих вариантов того же семейства.

Хорошим примером мутации служит похожее на вирус семейство программ-вымогателей Virlock. При запуске Virlock (SHA256: 7a92e23a6842cb51c9959892b83aa3be633d56ff50994e251b4fe82be1f2354c) в системе жертвы программа расшифровывает в памяти три экземпляра самой себя и сохраняет их на диск в виде файлов. Все три экземпляра отличаются от любых других образцов Virlock и имеют разные сигнатуры. Благодаря этому программа остаётся незамеченной, по крайней мере антивредоносными механизмами, основанными на хешах и простых сигнатурах файлов.

Использование необычных языков программирования

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

ожидают встретить более типичный вредоносный код, например на C или C++. Кроме того, многие из этих необычных языков можно использовать в разных операционных системах. Например, программа, написанная для Windows, может работать и в macOS или Linux, если в системе жертвы установлены необходимые библиотеки. Это делает вредоносную программу более устойчивой к различиям операционных систем.

Использование необычных языков - не новый метод. Ранние вредоносные программы часто писались на C, но затем авторы начали применять платформу .NET, например C#, которая до сих пор остаётся очень популярной. Однако anti-malware и другие средства защиты наверстали отставание, поэтому авторы адаптируются и всё чаще используют другие языки. Python, очень распространённый язык сценариев, стал чаще встречаться во вредоносных программах как в виде сценариев, так и исполняемых файлов. Автору достаточно написать вредоносный сценарий Python .py, который можно выполнить в любой системе с подходящими библиотеками Python. Такие инструменты, как Py2Exe и PyInstaller, способны даже преобразовать сценарий Python в исполняемый файл, который злоумышленник разворачивает на компьютере жертвы подобно обычному PE-файлу. Поскольку написать вредоносный сценарий Python и превратить его в исполняемый файл довольно просто, этот подход снижает порог входа для авторов вредоносных программ.

Nim (https://nim-lang.org), называющий себя "статически типизированным компилируемым языком системного программирования", также набирает популярность среди авторов вредоносных программ. В частности, Nim использовала группа, стоявшая за печально известным банковским трояном Trickbot. См. статью Лоуренса Абрамса «TrickBot’s BazarBackdoor Malware is Now Coded in Nim to Evade Antivirus». Потенциально применение Nim помогало программе обходить антивирусную защиту.

Go, иногда называемый Golang, - язык с открытым исходным кодом от Google. На нём проще программировать, чем на некоторых других компилируемых языках, например C, поэтому неудивительно, что он тоже всё чаще используется во вредоносных программах. Rust (https://www.rust-lang.org) - ещё один язык, набирающий популярность в разработке вредоносного программного обеспечения. В сущности, практически любой язык программирования или сценариев можно применять в злонамеренных целях, поэтому этот раздел мог бы стать очень длинным. Даже PowerShell всё чаще используется авторами вредоносных программ. Аналитикам и специалистам по защите следует следить за языками, применяемыми в современных образцах.

Злоупотребление доверием к сертификатам и цифровой подписью

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

Хранилище доверия сертификатов - репозиторий, где Windows хранит сертификаты подписывающих лиц, которым доверяет. Хранилище доверия Windows можно просмотреть в приложении certmgr, находящемся в C:\Windows\System32, как показано на рис. 13-12.

Рис. 13-12. Просмотр хранилища доверия Windows в certmgr

Авторы вредоносных программ могут подписать код доверенным сертификатом несколькими способами. Во-первых, проникнув в сеть доверенной компании, злоумышленник способен выпустить действительные сертификаты и подписать ими собственную вредоносную программу либо похитить сертификаты и использовать их для цифровой подписи кода. Такое происходило неоднократно, например в 2022 году, когда у Nvidia были украдены сертификаты подписи кода. См. статью Питера Арнца «Stolen Nvidia Certificates Used to Sign Malware - Here’s What to Do». Сертификаты подписи кода иногда даже продаются в даркнете.

Во-вторых, при определённых обстоятельствах вредоносный код можно вставить в ранее подписанный исполняемый файл, не аннулируя сертификат. Этот метод был представлен исследователями на конференции Black Hat в 2016 году. См. отчёт Deep Instinct Research Team «Certificate Bypass: Hiding and Executing Malware from a Digitally Signed Executable».

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

Злоупотребление ограничениями механизма защиты

Как упоминалось ранее, перед anti-malware, а также EDR со встроенными антивредоносными возможностями стоит сложная задача: обеспечить высокий уровень обнаружения и одновременно сохранить удобство конечного пользователя. Прежде всего средство должно успешно обнаруживать вредоносный код и при этом ограничивать ложные срабатывания. Кроме того, сканирование и наблюдение должны быть прозрачны для конечного пользователя. Они не должны настолько влиять на работу, чтобы система становилась непригодной или нестабильной. Хитрые авторы вредоносных программ могут воспользоваться этими ограничениями различными способами, например отложенным выполнением и бомбардировкой памяти.

Подобно тому как некоторые вредоносные программы используют отложенное выполнение для уклонения от обнаружения в песочнице, о чём говорилось в главе 8, они могут "переспать" механизм сканирования anti-malware. Один из способов - дождаться истечения определённого количества миллисекунд. Например, после 600 000 миллисекунд, то есть 10 минут, образец выполняет вредоносный код. Поскольку механизм эмуляции или песочницы anti-malware может иметь ограничение времени, не позволяющее бесконечно анализировать большой файл и расходовать ценные системные ресурсы, этот метод иногда помогает вредоносной программе проскользнуть незамеченной.

Бомбардировка памяти (memory bombing), термин из книги Уриэля Косаева и Нира Иегошуа Antivirus Bypass Techniques (Packt, 2021), предусматривает выделение вредоносной программой чрезмерно больших областей в адресном пространстве своего процесса. Поскольку anti-malware приходится учитывать потребление системных ресурсов, включая процессор и память, он может лишь бегло просканировать такую большую область или вовсе её проигнорировать, оставив вредоносный код незамеченным. Обратите внимание, что метод может быть эффективен и против песочниц.

Маскировка под безопасный файл

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

• Подмена имени файла. Автор просто называет вредоносный файл именем распространённого системного файла или законного приложения, например explorer.exe или PowerPoint.exe, либо слегка изменяет имя, например expl0rer.exe. Также можно заменить расширение вредоносного файла на более безобидное, например переименовать .exe в .jpg.

• Подмена метаданных файла. Автор подделывает метаданные вредоносного файла, например указывает "Microsoft" в качестве издателя или названия компании. Сходный приём заключается в повторном использовании значков законных программ. Например, вредоносная программа может взять логотип Microsoft Word, чтобы файл выглядел подлинным.

• Проведение атак социальной инженерии. Автор обманом заставляет пользователя выполнить вредоносную программу, например отправляет целевому пользователю письмо с вредоносным файлом important_invoice.pdf. Сходный приём заключается в двойных расширениях. По умолчанию Windows не показывает расширения файлов, поэтому financials.xls.exe будет отображаться просто как financials.xls. Это может заставить ничего не подозревающего пользователя запустить вредоносный исполняемый файл.

Хотя маскировка относительно проста и дёшева в реализации, она бывает весьма эффективной. Исследователи ESET сообщали, что группа Sandworm доставляла жертвам на Украине вредоносную программу, замаскированную под компонент дизассемблера IDA Pro и собственное защитное программное обеспечение ESET. См. статью Келли Джексон Хиггинс «Sandworm APT Trolls Researchers on its Trail as it Targets Ukraine». Другой примечательный пример - вредоносные программы, имитирующие документы авторитетных организаций, например сведения Всемирной организации здравоохранения о COVID-19, о чём в 2022 году сообщила Proofpoint. См. публикацию Эндрю Нортерна и соавторов «Nerbian RAT Using COVID-19 Themes Features Sophisticated Evasion Techniques».

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

Повышение привилегий для уклонения от защиты

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

Обход контроля учётных записей пользователей

Контроль учётных записей пользователей (UAC) - механизм защиты Windows, предназначенный для предотвращения выполнения несанкционированными приложениями кода с высокими привилегиями. Когда приложение запрашивает административный доступ, системный администратор должен подтвердить запрос, как показано на рис. 13-13.

Рис. 13-13. Типичное всплывающее окно UAC

После согласия администратора уровень целостности процесса приложения повышается до высокого. Самые распространённые уровни целостности, высокий, средний, низкий и системный, определяют, что процесс может и не может делать в системе. Процессы высокой целостности выполняются в повышенном режиме и имеют доступ к объектам, которым назначены более низкие уровни. Процессы средней целостности работают с правами обычного пользователя; это значение по умолчанию для большинства процессов. Процессы низкой целостности имеют минимальные привилегии и обычно применяются для приложений вроде веб-браузеров, которым из соображений безопасности следует работать в среде, похожей на контейнер. Процессы системной целостности необходимы для стабильности операционной системы; к ним относятся диспетчер управления службами services.exe и процесс подсистемы Windows csrss.exe. По замыслу процессы с более низкой целостностью не могут изменять данные процессов более высокой целостности.

На рис. 13-14 показан фрагмент Process Hacker, который удобно выделяет процессы в соответствии с повышением привилегий и уровнями целостности.

Рис. 13-14. Уровни целостности процессов в Process Hacker

Сам Process Hacker (ProcessHacker.exe) выделен оранжевым, либо тёмно-серым в этой книге, что означает повышенные привилегии и работу в режиме высокой целостности. Explorer.exe выделен розовым, средне-серым, обозначающим системный процесс. Остальные, более обычные процессы, например Excel и Блокнот, окрашены жёлтым, светло-серым, то есть являются процессами средней целостности с правами стандартного пользователя.

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

Ряд встроенных утилит Windows предназначен для запуска с повышенными разрешениями. Одна из них - msconfig.exe, простой инструмент настройки Windows, позволяющий системным администраторам, среди прочего, менять параметры загрузки Windows, службы и задачи автозапуска. Обычно приложения, запрашивающие повышенные разрешения, вызывают окно UAC; по умолчанию его должны подтвердить даже пользователи с правами администратора. Однако при запуске из учётной записи администратора msconfig.exe автоматически повышается до процесса высокой целостности без запроса UAC. Кроме того, утилита позволяет запускать другие инструменты, которые затем также работают в контексте высокой целостности без запроса. К сожалению для msconfig.exe, злоумышленник способен воспользоваться этим поведением и выполнить простой обход UAC. В меню Tools программы msconfig.exe пользователь выбирает Command Prompt и нажимает Launch, как показано на рис. 13-15.

Рис. 13-15. Запуск командной строки из msconfig.exe

Затем без запроса разрешения UAC запускается новая командная строка с уровнем целостности родительского процесса msconfig.exe. Новый процесс cmd.exe показан в Process Hacker на рис. 13-16.

Рис. 13-16. Процесс cmd.exe, запущенный с высокой целостностью

Обратите внимание, что привилегии процесса повышены (Elevated: Yes), а его уровень целостности высок. Пользователь обошёл UAC, выполнив процесс, который должен работать в контексте высокой целостности и при стандартной конфигурации Windows не вызывает запрос UAC, а затем запустив командную строку, унаследовавшую высокий уровень целостности. Теперь командная строка работает от имени администратора и может выполнять команды с высокими привилегиями. Сходный практический пример встречается в семействе Trickbot, злоупотребляющем свойством автоматического повышения утилиты Windows WSReset.exe. См. статью Арнольда Осипова «Trickbot Trojan Leveraging a New Windows 10 UAC Bypass».

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

Перехват DLL

Из главы 12 вы узнали, что вредоносная программа может злоупотреблять уязвимостями перехвата в законных приложениях, внедряя вредоносную DLL и скрытно выполняя код. Такая атака также эффективно обходит UAC. Возвращаясь к примеру msconfig.exe: если бы утилита была уязвима для перехвата DLL и позволяла загрузить вредоносную библиотеку вместо законной, вредоносная DLL выполнялась бы в контексте высокопривилегированного приложения msconfig.exe. Все окна UAC появлялись бы под видом msconfig.exe, что могло бы обманом заставить пользователя дать согласие и разрешить вредоносному коду работать с более высокими привилегиями, чем было бы возможно иначе.

В отчёте Fox-IT и NCC Group 2016 года «Mofang: A Politically Motivated Information Stealing Adversary» исследователи описали подобную атаку группы Mofang. Она злоупотребляла законным приложением Windows migwiz.exe, заставляя его загружать DLL cryptbase.dll. Злоумышленники перехватили эту библиотеку, и migwiz.exe, по умолчанию выполняющийся в повышенном состоянии, загружал вредоносную версию cryptbase.dll, эффективно обходя определённые механизмы UAC.

Злоупотребление COM

Компонентная объектная модель (COM) - часть Windows API, обеспечивающая межпроцессное взаимодействие. Основной строительный блок COM - объект COM, состоящий из данных и функций, управляющих доступом к ним, которые называются интерфейсами. Сервер объекта COM предоставляет интерфейсы клиентам COM, а клиенты обращаются через них к серверу. Объекты серверов COM часто представлены файлами .dll или .exe. У каждого серверного объекта есть уникальный идентификатор класса (CLSID), 128-разрядная строка из ряда цифр и символов. Такие строки часто отображаются в фигурных скобках, например {4E5FC2F8-8C44-6776-0912-CB15617EBC13}. Через мгновение это станет важно.

Ряд объектов COM имеет свойство COMAutoApproval, указывающее, что объект не требует от пользователя явного разрешения входящих в него функций повышения привилегий. В Windows список объектов COM с этим свойством можно посмотреть в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UAC\COMAutoApprovalList. Список в системе автора показан на рис. 13-17.

Рис. 13-17. Просмотр объектов COM с включённым COMAutoApproval

В типичной системе Windows 10 этот список содержит более 100 объектов! Как нетрудно представить, вредоносная программа может злоупотреблять некоторыми из них, чтобы

обойти UAC. Например, интерфейсы некоторых объектов COM содержат функции, способные выполнять произвольный код. Интерфейс COM может предоставлять функцию ExecuteCommand, принимающую на вход произвольную команду. Это показано в следующем псевдокоде:

Вредоносная программа инициализирует COM (CoInitialize) и создаёт экземпляр COM (CoCreateInstance) объекта VulnerableComObject. После инициализации объекта программа вызывает уязвимый метод ExecuteCommand, предоставляемый и экспортируемый объектом COM, передавая command в качестве параметра. Поскольку объект COM работает с высокими привилегиями, последующая команда также выполняется с высокими привилегиями. В данном случае команда копирует исполняемый файл вредоносной программы в каталог System32, что обычно вызвало бы запрос UAC.

Это упрощённая версия метода, но похожие приёмы применялись в реальных атаках. Хорошо изученный проект UACME подробно описывает один из вариантов этого метода и множество других.

Изменение реестра

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

В таком случае вредоносная программа может попытаться изменить значение раздела HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA с установленного по умолчанию 1 на 0, фактически отключив запросы UAC на узле. Установка значения 0 для HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin также отключает запросы UAC для действий администратора.

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

Олицетворение и манипулирование токенами доступа

Каждому выполняющемуся в системе процессу назначается токен доступа, унаследованный от родительского процесса, чей токен, в свою очередь, наследуется от запустившей его учётной записи пользователя. Токен доступа учётной записи представляет права и привилегии пользователя. Токенам процессов можно назначать различные привилегии. Например, SeBackupPrivilege позволяет пользователю или процессу создавать резервные копии файлов и каталогов, SeLoadDriverPrivilege разрешает процессу загружать драйвер ядра, а SeShutdownPrivilege - выключать систему.

Чтобы получить дополнительные привилегии, вредоносная программа может продублировать токен другого процесса. Метод часто называют кражей токена или олицетворением токена. Программа вызывает DuplicateToken либо DuplicateTokenEx, создавая копию токена, назначенного другому процессу, а затем вызывает ImpersonateLoggedOnUser, передавая дубликат в качестве параметра. Так вредоносная программа получает разрешения исходного токена. Кроме того, она может вызвать CreateProcessWithToken, чтобы запустить совершенно новый процесс и назначить ему разрешения продублированного токена.

ПРИМЕЧАНИЕ. В качестве альтернативы вредоносная программа может изменить собственный токен и назначить ему новые привилегии. Одна из особенно желанных привилегий - SeDebugPrivilege, позволяющая процессу исследовать и изменять процессы, принадлежащие другим учётным записям, вплоть до учётной записи System. Если низкопривилегированному процессу разрешено манипулировать системными процессами, он потенциально может внедрять и выполнять код в их контексте, полностью обходя механизмы UAC либо по меньшей мере обманом заставляя пользователей разрешать повышенные действия через UAC.

Для получения SeDebugPrivilege вредоносная программа вызывает OpenProcessToken, открывая токен доступа своего процесса, а затем AdjustTokenPrivileges, передавая SeDebugPrivilege как параметр. Однако один лишь запрос привилегии не означает, что операционная система её предоставит. Запрашивать и получать это разрешение могут только ранее повышенные процессы, поэтому вредоносная программа уже должна выполняться в повышенном состоянии. Обычно она сначала применяет один из рассмотренных ранее методов обхода UAC, а затем выдаёт себе SeDebugPrivilege для дальнейшего доступа к системным процессам.

Извлечение и повторное использование учётных данных

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

Один из методов извлечения учётных данных - исследование памяти процесса службы подсистемы локального центра безопасности (LSASS), управляющей политиками безопасности и аутентификацией. По своей природе процесс lsass.exe содержит в адресном пространстве памяти конфиденциальные данные, а именно учётные данные для входа и токены безопасности. В современных версиях Windows эти сведения обфусцированы, например посредством хеширования, но в особых обстоятельствах могут присутствовать в открытом виде. Исследуя память lsass.exe, вредоносная программа может найти и извлечь привилегированные учётные данные и токены, а затем попытаться повторно использовать их для повышения собственных привилегий.

Существуют инструменты, автоматизирующие этот процесс. Один из известных примеров, Mimikatz, извлекает учётные данные и другую конфиденциальную информацию из памяти системы жертвы. Хотя Mimikatz существует с 2011 года, он до сих пор активно обновляется и часто применяется в реальных атаках. Некоторые платформы атак, например Cobalt Strike, даже имеют встроенные инструменты, подобные Mimikatz.

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

Эксплуатация уязвимостей для повышения привилегий

Наконец, некоторые вредоносные программы пытаются эксплуатировать уязвимости для повышения привилегий. Особой популярностью у злоумышленников пользуются уязвимости локального повышения привилегий (LPE), позволяющие повысить права в системе, к которой программа уже имеет низкоуровневый доступ. Примечательный относительно недавний пример - уязвимость CVE-2021-36934, получившая название HiveNightmare и затрагивавшая Windows 10 и некоторые версии Windows 11. HiveNightmare использует проблему контроля доступа в определённых каталогах Windows. Внутри находятся кусты реестра с конфиденциальными данными, например сохранёнными учётными данными, которые обычно недоступны непривилегированным пользователям. Однако, эксплуатируя уязвимость, злоумышленник может обратиться к резервным копиям этих данных в службе теневого копирования томов Windows (VSS), механизме резервного копирования, хранящем копии файлов и других данных. В уязвимых версиях Windows злоумышленник способен создать специальную полезную нагрузку, эксплуатирующую недостаток контроля доступа, получить незаблокированные копии конфиденциальных кустов реестра и использовать сохранённые учётные данные для повышения привилегий. Эксплойт показан на рис. 13-18; его код доступен в репозитории HiveNightmare.

Рис. 13-18. Эксплойт HiveNightmare в действии

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

Рис. 13-19. Успешная эксплуатация HiveNightmare

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

Рассмотрев некоторые способы обхода средств защиты конечных точек, перенесём внимание на обход механизмов сетевой защиты.

Обход средств сетевой защиты

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

Современные средства сетевой защиты

Как и рынок защиты узлов, рынок сетевой защиты переполнен названиями продуктов и сокращениями. На фундаментальном уровне существует лишь несколько типов современных средств сетевой защиты. В этой главе основное внимание уделяется NIDS, NDR и защите электронной почты:

• Системы обнаружения сетевых вторжений (NIDS). Эти продукты наблюдают за входящим и исходящим сетевым трафиком в поисках признаков вредоносной активности. Подобно anti-malware, NIDS могут основываться на сигнатурах, аномалиях либо сочетать оба подхода. Сигнатурные методы NIDS ищут подозрительные сигнатуры

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

• Системы сетевого обнаружения и реагирования (NDR). Это сетевой эквивалент EDR. NDR представляет собой более современное решение, чем NIDS, и в некотором отношении стремится заменить его. NDR использует анализ сетевого трафика в реальном времени для выявления потенциальных атак, обнаружения угроз, например вредоносных программ, проходящих через сеть, и реагирования на подозрительное поведение. Телеметрию NDR и узлового EDR можно объединить в систему расширенного обнаружения и реагирования (XDR), позволяющую аналитикам и исследователям отслеживать атаки как на сетевом уровне, так и на уровне конечных точек.

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

Теперь начнём рассматривать способы, которыми вредоносная программа пытается обходить эти средства.

Обфускация и сокрытие сетевого трафика

Для обхода NIDS и NDR современная вредоносная программа должна применять обфускацию или шифрование, чтобы замаскировать сетевой трафик. Некоторые программы пытаются скрыться от сетевой защиты при загрузке дополнительных полезных нагрузок или модулей, используя зашифрованные сетевые протоколы HTTPS, Secure File Transfer Protocol (SFTP) или Secure Shell (SSH). Известно даже применение вредоносными программами зашифрованного средства защиты конфиденциальности Tor для сокрытия сетевой активности. Такой метод наблюдался у семейства Bashlite, также известного как Gafgyt, при обмене с инфраструктурой C2. Следует помнить, что само использование Tor и других редко применяемых протоколов и служб может служить явным признаком вредоносной активности. Хотя метод действительно способен помешать сетевой защите и исследователям изучить подозрительный трафик, он не означает, что вредоносная программа останется полностью незамеченной.

Другой пример тактики - туннелирование DNS, злоупотребляющее протоколом системы доменных имён (DNS) для сокрытия такого трафика, как загрузка файлов, эксфильтрация данных из сети или обмен C2. Поскольку DNS является фундаментальным протоколом, на котором работает интернет, туннелирование может остаться совершенно незаметным для сетевого наблюдения и защиты. На рис. 13-20 показано, как оно выглядит.

Рис. 13-20. Туннелирование DNS

Начнём с заражённого узла, на котором скрывается троян удалённого доступа (RAT). Он связывается со своим сервером C2 evil.com и нуждается в специальных инструкциях, получаемых через туннель DNS. RAT отправляет DNS-запрос своему серверу C2 36128.evil.com, где поддомен 36128 представляет случайную числовую строку. Затем запрос передаётся рекурсивному DNS-серверу, локальному серверу, обслуживающему DNS-запросы. Для домашних пользователей и малых компаний им может быть сервер интернет-провайдера, а для организации - внутренний сервер, к которой относится узел.

После этого рекурсивный DNS-сервер обращается к авторитетному DNS-серверу, являющемуся источником достоверных сведений о домене. Когда новый веб-сайт развёртывается у поставщика услуг размещения, тот выступает авторитетным DNS-сервером для домена. В качестве альтернативы любой владелец приобретённого доменного имени может организовать собственный авторитетный DNS-сервер. В данном случае RAT на заражённом узле в конечном итоге связывается с авторитетным DNS-сервером домена evil.com, которым владеет автор вредоносной программы.

Получив DNS-запрос, сервер C2 отправляет ответ. Однако в данном случае он содержит закодированную команду, простую строку execute. Команда может быть обфусцирована простым алгоритмом вроде Base64 или даже зашифрована и спрятана в одной из записей DNS-ответа. Для туннелирования DNS часто используются записи TXT, CNAME, ресурсные записи (RR) и записи NULL. Они выходят за рамки книги и далее не рассматриваются.

Получив DNS-ответ, RAT на заражённом узле декодирует встроенную строку и обрабатывает команду execute, предположительно выполняя вредоносную команду. По умолчанию DNS не шифруется, но из-за его повсеместного применения и сложности полного наблюдения такая атака способна проскользнуть мимо сетевой защиты.

Известно также применение вредоносными программами собственных платформ C2 с новыми способами сетевого обмена. Такие платформы могут использовать общедоступные службы GitHub, Pastebin, Telegram или даже X для сокрытия трафика и команд. Обычно этот трафик не только зашифрован, но и способен остаться совершенно незамеченным, поскольку выглядит нормально. Один из примеров обнаружили исследователи ESET: группа Turla злоупотребляла учётной записью Бритни Спирс в Instagram для сокрытия серверов C2. См. статью «Carbon Paper: Peering into Turla’s Second Stage Backdoor». Группа разместила на странице Спирс закодированный текст, представлявший URL с адресом сервера C2. Вредоносные программы в ранее заражённых Turla системах следили за её профилем Instagram, искали эти шаблоны и извлекали адреса серверов C2. Затем программа декодировала адрес и получала дополнительные команды из инфраструктуры злоумышленника.

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

Сокрытие инфраструктуры с помощью геозон

Геозонирование (geofencing) означает использование географического положения как фактора, определяющего поведение вредоносной программы. В сущности, полезная нагрузка выполняется лишь тогда, когда целевой узел находится внутри определённой географической границы, например в конкретной стране. Геозоны также могут мешать механизмам сканирования и аналитикам выявлять и исследовать вредоносный сервер. Например, когда средство защиты электронной почты запускает вредоносное вложение в песочнице, та может заметить попытку программы связаться с неизвестным доменом в интернете. После этого песочница способна попытаться "просканировать" или проверить сервер, чтобы определить его истинную природу и классифицировать как законный либо вредоносный.

Методы геозонирования позволяют вредоносному серверу предотвращать такое поведение. Запрашивая местоположение системы или исследователя, проверяющего инфраструктуру, сервер скрывается от незваных гостей. Например, автор вредоносной программы в Китае может целенаправленно атаковать жертв в Германии. Весь трафик к серверу C2 не с немецких IP-адресов блокируется, что мешает автоматическим сканерам и исследователям без немецкого IP изучить его. Сервер может даже показывать системам не из Германии вводящие в заблуждение сведения: например, перенаправлять любой трафик с ненемецких адресов на совершенно другой безвредный сайт. Сходный метод выявили исследователи Proofpoint: группа TA547 применяла геозоны, выдавая полезную нагрузку только определённым целям. См. статью «The First Step: Initial Access Leads to Ransomware». Полезные нагрузки размещались на серверах, но доступ и загрузка разрешались только жертвам из определённых стран.

Создание новой инфраструктуры с помощью DGA

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

Обойти проблему можно, динамически создавая новые адреса C2 с помощью алгоритмов генерации доменов (DGA), состоящих из клиентского и серверного компонентов. Вредоносная программа, в данном случае клиент, использует встроенный код DGA для создания новых доменных имён. Сервер C2 применяет тот же алгоритм и получает новое имя, идентичное созданному клиентом. DGA основан на том, что клиентская и серверная части генерируют предсказуемые доменные имена. Алгоритм должен получать одно и то же имя на обеих сторонах, но оставаться достаточно непредсказуемым, чтобы исследователи и инструменты анализа не могли угадать следующие домены. Применение DGA показано на рис. 13-21.

Рис. 13-21. Работа DGA

Сначала вредоносная программа создаёт новое доменное имя посредством кода DGA, встроенного в исполняемый файл. После выполнения алгоритма она получает домен evil-01.tk, а тот же алгоритм в инфраструктуре C2 также создаёт evil-01.tk 1. Затем автор развёртывает новый сервер по адресу evil-01.tk 2. Вредоносная программа подключается к уже работающему серверу C2 по этому доменному имени 3.

По истечении заранее заданного времени, например восьми часов, вредоносная программа создаёт новый домен evil-02.cn 4. В свою очередь, сервер генерирует

то же доменное имя, которое затем развёртывается 5. Наконец, вредоносная программа подключается к нему 6. К этому моменту первый сервер evil-01.tk, скорее всего, уже отключён. Цикл повторяется, пока алгоритм не исчерпает доступные домены. Мощный метод DGA позволяет авторам вредоносных программ создавать сотни или тысячи новых доменных имён для серверов C2, превращая выявление и добавление доменов в списки блокировки средствами безопасности и исследователями в игру "ударь крота".

Применение Fast Flux

Fast flux - метод уклонения, в значительной степени используемый ботнетами, сетями заражённых систем под управлением злоумышленника. По мере заражения жертв определённым вариантом вредоносной программы заражённые узлы, боты, добавляются в ботнет. Злоумышленники используют ботнеты для разных целей: рассылки спама, проведения фишинговых атак и распределённых атак отказа в обслуживании (DDoS), а также различных видов мошенничества. Fast flux позволяет задействовать ботов как прокси-серверы для сокрытия и защиты серверов C2 и другой инфраструктуры.

Для применения метода злоумышленник приобретает доменное имя, а затем быстро меняет связанный с ним IP-адрес, чтобы при каждом посещении жертва направлялась на другой IP размещения. Быстрая смена адресов настраивается циклически (round-robin), что представляет собой законный способ балансировки клиентских запросов к веб-серверу. Сократив время жизни (TTL) IP-адресов до нескольких минут или даже меньше, злоумышленник создаёт более неуловимую инфраструктуру. Сетевой защите становится труднее выявлять и блокировать вредоносный трафик, а правоохранительным органам и другим исследователям - определять всю инфраструктуру. Практическая схема fast flux показана на рис. 13-22.

Рис. 13-22. Метод fast flux, реализованный в ботнете

Сначала жертва выполняет вредоносную программу на компьютере, и та хочет установить HTTP-соединение с доменом злоумышленника evil.com. Но прежде домен evil.com необходимо разрешить в IP-адрес. Жертва отправляет DNS-запрос 1, а evil.com с помощью контролируемого автором вредоносной программы авторитетного DNS-сервера разрешается в адрес 59.111.180.193 2. Затем программа отправляет HTTP-запрос на 59.111.180.193 3, принадлежащий ботнету и назначенный боту 1. Выступая прокси-сервером, бот 1 перенаправляет HTTP-запрос серверу доставки вредоносной программы 4, который затем передаёт полезную нагрузку жертве 5.

Через несколько минут новая жертва, заражённая той же программой, отправляет DNS- и HTTP-запросы для evil.com, как и первая. Но теперь DNS-сервер возвращает IP-адрес 97.66.36.178, поскольку злоумышленник уже изменил связанный с доменом адрес. Этот IP сопоставлен боту 2, который аналогично пересылает HTTP-запрос промежуточному серверу вредоносной программы и доставляет полезную нагрузку второй жертве. Поскольку IP меняется очень часто и распределён по ботнету, который может представлять паутину из многих тысяч систем, определить инфраструктуру злоумышленника, другие узлы ботнета, серверы распространения и C2 становится трудно.

Fast flux применяется не только в ботнетах, но и у пуленепробиваемых хостеров (BPH), поставщиков веб-хостинга, обслуживающих менее добросовестные виды деятельности вроде онлайн-азартных игр и спама либо незаконные операции, например организованную преступность. Обычно BPH находятся в странах, где подобная активность не подвергается тщательному контролю, остаётся незамеченной или терпимой, а требования правоохранительных органов об отключении вредоносной инфраструктуры не исполняются. BPH могут предлагать услуги fast flux киберпреступным группам и другим клиентам.

Существует связанный метод double fast flux, при котором быстро меняется не только IP-адрес вредоносного домена, но и IP-адрес одного или нескольких авторитетных DNS-серверов злоумышленника. Это добавляет дополнительный уровень защиты и сложности для исследователей и сетевых защитных средств.

Очень немногие рассмотренные в этой главе методы эффективны сами по себе. Современные атаки с вредоносными программами часто сочетают несколько способов для проникновения к цели, как показано далее.

Многоэтапные и сложные атаки

Как упоминалось ранее, некоторые современные средства защиты, например EDR, используют систему оценки угроз или другие аналитические методы для выявления подозрительного поведения. В раннюю эпоху вредоносные программы обычно доставлялись одним вредоносным файлом. Он содержал все функции, необходимые для заражения жертвы и выполнения дальнейших действий, задуманных автором. Но для успешного обхода современной защиты конечных точек и сети авторам приходится применять более сложный многоэтапный подход. Создание сложных цепочек из множества шагов затрудняет защитным средствам понимание происходящего и принятие соответствующих мер. Такая атака показана на рис. 13-23.

Рис. 13-23. Сложная многоэтапная атака

Сначала автор доставляет жертве вредоносный документ. После открытия файл выполняет встроенный код JavaScript, который, в свою очередь, запускает обфусцированный код PowerShell. Код PowerShell связывается с промежуточным сервером злоумышленника и загружает загрузчик Loader.exe. Загрузчик отвечает за обращение к другому удалённому серверу и загрузку вредоносной полезной нагрузки Payload.exe.

Защитным средствам сложнее проследить такие разрозненные события. Вместо оценки поведения одного исполняемого файла механизм трассировки событий и анализатор EDR должны исследовать множество событий из разных источников, прежде чем признать активность вредоносной. Чтобы ещё сильнее усложнить атаку, автор может добавить процедуры ожидания. Например, команда PowerShell ждёт два часа перед загрузкой исполняемого загрузчика, тот спит четыре часа перед загрузкой файла полезной нагрузки, а полезная нагрузка ожидает ещё восемь часов перед обращением к серверу C2. Механизму трассировки приходится учитывать многочасовые промежутки между событиями.

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

Итоги

В этой главе обсуждались многие распространённые способы, которыми вредоносные программы активно и пассивно обходят узловые средства защиты вроде anti-malware и EDR, а также сетевые механизмы, например NIDS. Мы подробно рассмотрели, как программа перечисляет артефакты узла жертвы для выявления защиты и как может активно ей противодействовать. Кроме того, мы изучили повышение привилегий, позволяющее более скрытно проскальзывать мимо защитных средств. В следующей главе вы узнаете о руткитах, разновидности низкоуровневых вредоносных программ, чьи методы можно считать высшей формой уклонения от защиты.

В этой главе даётся вводный обзор руткитов на основе ядра и некоторых методов, которыми они уклоняются от защиты и манипулируют системой. Глава не претендует на исчерпывающее описание руткитов или их анализа, но рассматривает тактики, на которые следует обращать внимание при исследовании низкоуровневых вредоносных программ.

Основы руткитов

Автор вредоносной программы может использовать компоненты руткита по многим причинам:

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

• Обход защиты. Некоторые руткиты активно вмешиваются в средства защиты конечных точек вроде EDR и anti-malware и ослепляют их. Например, перенаправляя вызовы функций, они также могут скрывать и защищать свои файлы и процессы от исследователей.

• Низкоуровневый доступ к устройствам и драйверам. Некоторые руткиты перехватывают запросы и команды, направляемые драйверам ядра и оборудованию и исходящие от них. Один из примеров - Moriya, перехватывающий, изменяющий и скрывающий сетевой трафик в обоих направлениях заражённого узла. См. статью «Operation TunnelSnake» за май 2021 года.

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

Модули и драйверы ядра

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

• Драйверы устройств. Пожалуй, самый распространённый тип драйверов ядра. Драйверы устройств обеспечивают интерфейс между Windows и базовыми аппаратными устройствами системы, например клавиатурами, мышами и принтерами. Они взаимодействуют с оборудованием напрямую либо опосредованно.

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

• Драйверы мини-фильтров. Подобно драйверам фильтров, мини-фильтры обрабатывают операции ввода-вывода. Они появились в более современных версиях Windows для повышения производительности и упрощения разработки и совместимости. Злоумышленники также могут использовать их не по назначению.

ПРИМЕЧАНИЕ. Хотя все драйверы ядра являются модулями, не все модули ядра представляют собой драйверы. Однако для простоты в этой главе термины "модуль" и "драйвер" будут использоваться как взаимозаменяемые.

Загруженные модули ядра в Windows можно просмотреть в похожем на диспетчер процессов инструменте, например Process Hacker, как показано на рис. 14-1.

Рис. 14-1. Просмотр загруженных модулей ядра в Process Hacker

Чтобы посмотреть загруженные модули ядра в Process Hacker, щёлкните системный процесс правой кнопкой мыши, выберите Properties, а затем вкладку Modules. На рис. 14-1 видны некоторые установленные в системе автора драйверы ядра, например драйверы расширенного интерфейса конфигурации и управления питанием (ACPI) и драйверы дисплея, включая загрузочный драйвер VGA.

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

Компоненты руткита

Обычно у руткита два компонента: процесс в пользовательском пространстве и драйвер ядра, получающий от него инструкции. Почти всегда всё начинается с исполняемого файла пользовательского пространства, который необходимо развернуть и выполнить на узле жертвы. После этого вредоносный процесс загружает драйвер в пространство ядра. Упрощённая высокоуровневая схема установки руткита показана на рис. 14-2.

Рис. 14-2. Процесс установки руткита

Сначала жертве доставляется исполняемый дроппер malware.exe, который после запуска расшифровывает встроенный вредоносный драйвер ядра rootkit.sys. Дроппер настраивает и выполняет драйвер как службу, завершая установку руткита в пространство ядра. Вскоре мы обсудим это подробнее. Код процесса пользовательского пространства содержит большую часть основных функций вредоносной программы, а компонент ядра маскирует и защищает пользовательский процесс в системе, устанавливает низкоуровневые перехватчики для сокрытия артефактов в памяти и на диске и ослепляет средства защиты конечных точек и исследователей.

Некоторые функции только что установленного руткита показаны на рис. 14-3.

Рис. 14-3. Основные функции руткита

Этот руткит может скрывать свой исполняемый файл пользовательского пространства malware.exe, а также передавать команды драйверу ядра rootkit.sys 1. Компоненты руткита в пользовательском пространстве часто взаимодействуют со своими аналогами в пространстве ядра

путём отправки запросов через такую функцию WinAPI, как DeviceIOControl, позволяющую процессу пользовательского пространства передать управляющий код, то есть инструкцию, драйверу пространства ядра. Кроме того, руткит способен устанавливать перехватчики и перехватывать вызовы API из пользовательского пространства 2, обмен между другими компонентами ядра и драйверами устройств 3 и даже напрямую изменять память ядра 4. Все эти методы станут понятнее по мере продвижения по главе. Но сначала сделаем шаг назад и обсудим, как вообще устанавливаются руткиты.

Установка руткита

В прошлом руткиты встречались чаще, но в поздних версиях Windows Microsoft реализовала защитные меры, затрудняющие внесение изменений, необходимых для установки вредоносных компонентов ядра. Тем не менее существуют способы обхода этой защиты, поэтому подобные атаки иногда всё ещё происходят. Рассмотрим недавний реальный пример, HermeticWiper.

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

Один конкретный образец HermeticWiper был подписан сертификатом, похищенным у законной компании Hermetica Digital Ltd., что потенциально позволяло обходить определённые средства защиты конечных точек. Этот метод обсуждался в главе 13. При первом запуске образец записывает на диск новый файл .sys, имя которого состоит из четырёх символов, например bpdr.sys. Это законный драйвер компании EaseUS, обычно предназначенный для изменения размера и разбиения дисков, но, как мы вскоре увидим, его можно использовать не по назначению. Поскольку на момент атаки файл был подписан действительным сертификатом, он мог обходить такие средства Windows, как обязательная проверка подписи драйверов.

Затем для получения специальных разрешений на загрузку драйверов HermeticWiper пытается получить SeLoadDriverPrivilege. Эту привилегию может получить только процесс, уже работающий с высоким уровнем прав, поэтому большинству вредоносных программ сначала приходится применить повышение привилегий, например обход UAC, чтобы получить права администратора или системы, а затем вызвать такую функцию, как AdjustTokenPrivileges, что обсуждалось в главе 13. Получив необходимые привилегии, HermeticWiper создаёт новую службу посредством CreateServiceW и запускает её с помощью StartServiceW. Создание и выполнение службы - один из самых распространённых способов загрузки нового драйвера ядра как в законных, так и во вредоносных целях. Это также можно сделать из командной строки Windows:

Команда создаёт новую службу evil, указывает входной параметр C:\Users\Public\evil.sys, путь к загружаемому вредоносному драйверу, и тип kernel, обозначающий установку драйвера ядра. После этого службу можно запустить следующей командой:

Ниже приведён вывод выполнения этих команд в Windows:

Поскольку драйвер HermeticWiper, по крайней мере на момент атаки, был законным и подписан действительным центром, его установка в пространство ядра, вероятно, не вызвала бы проблем, а встроенные механизмы Windows были бы обойдены. Если бы действительной подписи не было, при запуске службы возникла бы следующая ошибка:

После успешной установки вредоносной службы управление принимает диспетчер служб Windows, загружая драйвер в адресное пространство ядра. Теперь компонент вредоносной программы в пользовательском пространстве может взаимодействовать с драйвером в пространстве ядра посредством DeviceIOControl и передавать ему команды. Так HermeticWiper использует законный в остальных отношениях драйвер EaseUS для записи данных на диск, уничтожая их и делая заражённые системы неработоспособными.

ПРИМЕЧАНИЕ. Драйверы ядра не всегда загружаются с помощью служб. Существуют и другие методы, включая вызов функции NT API NtLoadDriver.

Такое злоупотребление законными драйверами представляет собой разновидность метода Bring Your Own Vulnerable Driver, который рассматривается далее.

ИССЛЕДОВАНИЕ HERMETICWIPER. Автор рекомендует изучить HermeticWiper в аналитической виртуальной машине. Образец можно найти на VirusTotal или Malshare (SHA256: 1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591). Запустите образец с правами администратора и обязательно запишите его поведение в Procmon. Попробуйте определить, куда HermeticWiper записывает файл драйвера на диске, как загружает драйвер и как взаимодействует с ним посредством кодов DeviceIOControl.

Дополнительные сведения о HermeticWiper:

- Deepen Desai и Brett Stone-Gross, «HermeticWiper & Resurgence of Targeted Attacks on Ukraine», Zscaler, 24 февраля 2022 года.

- Editor, «ESET Research: Ukraine Hit by Destructive Attacks Before and During the Russian Invasion with HermeticWiper and IsaacWiper», ESET, 1 марта 2022 года.

- Hasherezade, Ankur Saini и Roberto Santos, «HermeticWiper: A Detailed Analysis of the Destructive Malware That Targeted Ukraine», Malwarebytes, 4 марта 2022 года.

- Thomas Roccia, «Security Infographics: Overview of HermeticWiper», SecurityBreak, 29 августа 2020 года.

Атаки BYOVD

Атаки Bring Your Own Vulnerable Driver (BYOVD, иногда просто BYOD) используют законные подписанные драйверы как своего рода прокси для взаимодействия с ядром, отключения механизмов безопасности или загрузки отдельного неподписанного вредоносного драйвера ядра. Автор вредоносной программы ищет законный драйвер, уже подписанный действительным центром, а значит, проверенный операционной системой Windows, который можно поместить в систему жертвы во время атаки. Кроме того, в драйвере должна быть уязвимость, позволяющая выполнять низкоуровневые вредоносные действия. Для её эксплуатации руткит часто передаёт команды уязвимому драйверу из процесса пользовательского пространства, например посредством DeviceIOControl.

Примечательный пример такой атаки - руткит FudModule, предположительно применявшийся северокорейской группой Lazarus. По данным исследователей ESET, FudModule использует уязвимый подписанный драйвер Dell с уязвимостью CVE-2021-21551, позволявшей Lazarus записывать данные в память ядра. Точнее, уязвимость активировалась специально подготовленной инструкцией, передаваемой драйверу через DeviceIOControl. В результате злоумышленники успешно отключали несколько защитных механизмов Windows, фактически ослепляя защиту конечных точек перед последующими этапами атаки. Подробнее см. статью Петера Калная «Amazon-Themed Campaigns of Lazarus in the Netherlands and Belgium».

Другой пример вредоносной программы, применяющей BYOVD, - семейство программ-вымогателей BlackByte. По данным Sophos, BlackByte злоупотребляет уязвимым драйвером законного продукта MSI AfterBurner, инструмента настройки видеокарт. Уязвимость CVE-2019-16098 позволяла операторам BlackByte взаимодействовать с ядром и отключать продукты EDR на узле, завершая связанные с ними процессы. Подробнее см. статью Андреаса Клопша «Remove All the Callbacks - BlackByte Ransomware Disables EDR Via RTCore64.sys Abuse».

Третий пример - семейство ZeroCleare, обнаруженное исследователями IBM X-Force IRIS. Оно злоупотребляло уязвимым драйвером VirtualBox vboxdrv.sys, который позволял выполнять шелл-код в памяти ядра и устанавливать вредоносный драйвер. Подробнее об атаке можно прочитать в отчёте IBM «New Destructive Wiper ZeroCleare Targets Energy Sector in the Middle East».

К сожалению, существуют и другие недавние примеры злоупотребления уязвимыми драйверами для отключения и ослепления защиты конечных точек, загрузки дополнительных вредоносных драйверов ядра или иного выполнения вредоносного кода в привилегированных областях операционной системы. Поскольку эти драйверы законны и подписаны, полностью предотвратить такие атаки в настоящее время трудно. Для отслеживания уязвимых драйверов существует отдельный проект Living Off The Land Drivers, сокращённо LOLDrivers. Если вы хотите узнать больше об атаках BYOVD, посетите сайт проекта.

ПРИМЕЧАНИЕ. Не всякое применение BYOVD связано с руткитами. Например, некоторые вредоносные программы используют уязвимый драйвер лишь для выполнения функций ядра или низкоуровневых действий, которые иначе были бы запрещены.

Теперь, получив представление о том, как злоумышленники обходят защиту Windows для установки руткитов, рассмотрим поведение руткитов на узле жертвы и манипулирование системой ради сокрытия. Начнём со старого метода, DKOM.

Прямое манипулирование объектами ядра

Прямое манипулирование объектами ядра (DKOM) предусматривает непосредственное изменение данных в памяти ядра. Это тонкая задача, поскольку при неправильном выполнении

она может привести к аварийному завершению операционной системы. Но при правильном применении DKOM даёт вредоносной программе огромные возможности. Один из примеров - сокрытие процессов.

Посредством DKOM руткит может скрывать свои процессы пользовательского пространства и модули ядра от средств защиты конечных точек и специалистов по компьютерной криминалистике, изменяя структуры данных EPROCESS своих процессов в памяти ядра. Возможно, вы помните из главы 1, что структуры EPROCESS образуют двусвязный список выполняющихся на узле процессов. Некоторые средства защиты и анализа опираются на них для наблюдения за аномальными процессами и их исследования.

Чтобы применить этот вид DKOM, вредоносный модуль пространства ядра вызывает такую функцию, как PsLookupProcessByProcessID, и получает указатель на структуру EPROCESS собственного компонента пользовательского пространства. Затем программа изменяет элементы прямой ссылки (flink) и обратной ссылки (blink) структуры EPROCESS, исключая её из цепочки. Нормальные неизменённые структуры до исключения показаны на рис. 14-4.

Рис. 14-4. Двусвязные структуры EPROCESS до исключения

Обратите внимание, что структуры EPROCESS связаны элементами flink и blink.

На рис. 14-5 показано, что происходит, когда руткит изменяет структуры EPROCESS, исключая свой вредоносный процесс в центре.

Рис. 14-5. Структуры EPROCESS после исключения

Обратите внимание, что и flink, и blink структуры EPROCESS вредоносного процесса указывают обратно на неё саму, фактически отсоединяя процесс от нормальной цепочки EPROCESS.

Следующий код представляет сокращённую версию проекта HideProcess и показывает, как вредоносная программа выполняет описанные действия:

Сначала код определяет переменные Previous, хранящую указатель blink текущего процесса 1, и Next, хранящую его указатель flink 2. Затем значения LIST_ENTRY переписываются так, чтобы указывать на себя. Строка Current->Blink = (PLIST_ENTRY)&Current->Flink присваивает текущему указателю blink значение указателя flink 3. Строка Current->Flink = (PLIST_ENTRY)&Current->Flink обеспечивает, чтобы flink процесса указывал на себя 4. В сущности, это разрывает цепочку EPROCESS, скрывая процесс от средств управления процессами, например диспетчера задач, и некоторых инструментов криминалистического исследования, что может улучшить уклонение от защиты конечных точек.

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

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

"Устаревший" перехват в ядре

Подобно вредоносным программам пользовательского пространства, использующим встроенный перехват и перехват IAT для наблюдения за вызовами функций, их перехвата и изменения, вредоносная программа пространства ядра может применять несколько видов перехватчиков для проведения атак. Рассмотрим наиболее распространённые, начиная с существующего десятилетиями перехвата SSDT.

ПРИМЕЧАНИЕ. Методы этого раздела когда-то относились к самым распространённым как у руткитов, так и у продуктов защиты конечных точек. Но, как и DKOM, они утратили популярность благодаря защите, реализованной Microsoft в современных версиях Windows. Тем не менее важно понимать их основы: иногда вредоносные программы всё ещё применяют эти или сходные тактики, а знание помогает лучше разобраться в современных методах руткитов.

Перехватчики SSDT

Таблица дескрипторов системных служб (SSDT), или таблица диспетчеризации, содержит массив идентификаторов системных вызовов и соответствующих указателей на функции ядра. В 32- и 64-разрядных операционных системах они различаются, но здесь мы не будем углубляться в детали. Как обсуждалось в главах 1 и 13, когда процесс пользовательского пространства вызывает функции Windows API и NT API, функция в конечном итоге выполняет системный вызов в ядро. Рассмотрим чтение файла на диске посредством NtReadFile. Должна произойти следующая базовая последовательность:

1. Программа в пользовательском пространстве вызывает NtReadFile. Она инициирует системный вызов, ссылаясь на идентификатор syscall, соответствующий функции NtReadFile.

2. Системный вызов заставляет процессор переключиться из пользовательского режима в режим ядра и передаёт запрос и идентификатор обработчику syscall.

3. Обработчик обращается к SSDT, получает адрес функции ядра NtReadFile, экспортируемой из ntoskrnl.exe, и выполняет её.

4. Поскольку NtReadFile вызывается для чтения файла с диска, она должна взаимодействовать с драйверами ядра, например со стеком дисковых драйверов. Здесь задействуется диспетчер ввода-вывода.

5. Диспетчер ввода-вывода отправляет соответствующим драйверам инструкции в виде пакетов запросов ввода-вывода (IRP), и те выполняют действия, запрошенные NtReadFile, например чтение определённого файла на диске. Диспетчер ввода-вывода и IRP рассматриваются далее в этой главе.

6. После обработки запроса драйверами результат возвращается исходной вызывающей программе в пользовательском пространстве.

Теперь, поняв основы использования SSDT, можно увидеть, как вредоносная программа внедряет в неё перехватчик и перенаправляет запросы к вредоносному коду. Пример с функцией NtReadFile показан на рис. 14-6.

Рис. 14-6. Перехватчик SSDT для NtReadFile

Руткит изменяет указатель функции NtReadFile внутри SSDT, перенаправляя запрос к вредоносному модулю ядра. Затем руткит перехватывает и изменяет вызов NtReadFile. Позднее он может направить вызов к исходному коду функции NtReadFile внутри ntoskrnl.exe.

У автора вредоносной программы может быть много причин для перехвата SSDT. Например, перехватчик NtReadFile способен не позволить средствам защиты конечных точек и исследователям прочитать собственные вредоносные файлы и код программы. Другой метод перехвата ядра, встроенные перехватчики ядра, применяется по сходной причине.

Встроенные перехватчики ядра

Встроенный перехват применяется вредоносными программами не только в пользовательском пространстве, как обсуждалось в главе 12, но и в функциях ядра. Для установки перехватчиков руткит пытается изменить код функции внутри ntoskrnl.exe. Подобно только что рассмотренному примеру SSDT, руткит может перехватить NtReadFile, вставив в код функции инструкцию перехода и перенаправив поток управления к коду вредоносного модуля ядра, как показано на рис. 14-7.

Рис. 14-7. Встроенный перехватчик ядра для NtReadFile

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

MmProtectMdlSystemAddress - функция ядра, устанавливающая тип защиты памяти для списка дескрипторов памяти (MDL), структуры с диапазоном адресов памяти. У функции два параметра: MemoryDescriptorList, изменяемый диапазон адресов, и константа защиты, например PAGE_READWRITE, переводящая MDL в доступный для записи режим.

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

Теперь перейдём к перехвату IRP, ещё одному виду перехвата ядра, который, как известно, применяется руткитами.

Перехватчики IRP

Когда программам пользовательского пространства необходимо взаимодействовать с драйверами ядра, они делают это через диспетчер ввода-вывода. Обмен главным образом осуществляется пакетами запросов ввода-вывода (IRP), объектами из структур данных, содержащих сведения о запросе и действиях, которые следует выполнить. IRP передаются между вызывающей программой и драйверами ядра, но могут использоваться и для обмена между драйверами. Например, драйверу USB-клавиатуры необходимо взаимодействовать с драйвером контроллера USB, а диспетчер ввода-вывода помогает организовать этот обмен. Связь показана на рис. 14-8.

Рис. 14-8. Работа IRP

Программа вызывает CreateFile, чтобы открыть дескриптор файла на диске. В конечном итоге она выполняет системный вызов в ядро ntoskrnl.exe. Здесь подключается диспетчер ввода-вывода, отправляя IRP драйверу файловой системы, который обработает операцию. На последнем, не показанном на рисунке этапе драйвер возвращает состояние операции диспетчеру ввода-вывода, а тот передаёт его вызывающей программе.

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

Таблица 14-1. Коды IRP

Каждый установленный в ядре драйвер содержит таблицу обработчиков IRP, называемую таблицей основных функций, или таблицей функций IRP. В ней находятся указатели на код обработчиков определённых IRP; этот код может располагаться в самом драйвере либо другом драйвере или модуле. Далее показана таблица функций IRP драйвера FLTMGR:

Этот вывод создан с помощью Volatility, инструмента криминалистического исследования и анализа памяти. Хотя криминалистика памяти не рассматривается в книге, такие методы могут стать отличным дополнением к анализу вредоносных программ, особенно руткитов. В этом примере использован модуль driverirp Volatility.

Первый столбец вывода содержит код IRP. Во втором и третьем находятся соответственно указатель на связанную функцию-обработчик и модуль с её кодом. Здесь драйвер указывает на обработчики, которые сам содержит.

Чтобы перехватить и изменить обмен ввода-вывода и получить над ним контроль, вредоносный драйвер ядра может попытаться перехватить IRP. Одна из причин - скрытие и защита артефактов программы на конечной точке путём перехвата функций IRP, ссылающихся на эти артефакты на диске. Именно так действует руткит Autochk (SHA256: 28924b6329f5410a5cca30f3530a3fb8a97c23c9509a192f2092cbdf139a91d8): он перехватывает IRP_MJ_CREATE внутри драйвера FLTMGR, чтобы обрабатывать IRP, ссылающиеся на его вредоносные файлы на диске, как показано на рис. 14-9.

Рис. 14-9. Перехватчик IRP для NtReadFile

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

Заметили что-нибудь подозрительное? В первой строке FLTMGR.SYS заменён на autochk.sys. Все IRP MJ_CREATE, предназначенные драйверу FLTMGR, вместо этого направляются к вредоносному коду обработчика в драйвере руткита autochk.sys. Подробнее о некоторых методах руткита можно прочитать в анализе Autochk.

У авторов вредоносных программ есть несколько вариантов установки перехватчика IRP. Один подход заключается в замене исходного указателя на код обработчика в драйвере-жертве указателем на вредоносный код. Другой вариант - применить описанный ранее встроенный перехват, перезаписав первые несколько байт законной функции-обработчика инструкцией перехода к вредоносному коду.

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

Перехват IRP посредством фильтрации

Вместо грубого перехвата драйверов ядра ради обработки и изменения IRP руткит может зарегистрировать драйвер фильтра или мини-фильтра. Представленные в начале главы драйверы фильтров и мини-фильтров можно "подключить" к устройству и добавить в стек его драйверов, чтобы перехватывать IRP по мере их прохождения вниз по стеку. Рассмотрим процесс подробнее.

ПРИМЕЧАНИЕ. Драйверы фильтров, иногда называемые устаревшими драйверами фильтров, и драйверы мини-фильтров относятся к фильтрам, но работают совершенно по-разному. Подробности различий выходят за рамки книги.

Каждое подключённое к системе аппаратное устройство имеет связанный иерархический стек драйверов, обеспечивающий обмен между устройством и операционной системой, как показано на рис. 14-10.

Рис. 14-10. Обмен диспетчера ввода-вывода со стеками драйверов

Каждый драйвер в стеке выполняет определённую роль и служит интерфейсом между драйверами перед ним и после него. Кроме того, когда диспетчер ввода-вывода отправляет IRP определённому устройству, пакет проходит через иерархический стек устройства, последовательно пересекая каждый драйвер. Если у одного из них есть обработчик конкретного IRP, драйвер предпринимает соответствующее действие. Стрелки на рис. 14-10 обозначают обмен между драйверами посредством IRP.

Драйверы фильтров предназначены для вставки в стек и добавления функций. Их можно размещать в разных позициях, называемых высотами (altitudes), или даже на самой вершине стека, где они способны перехватывать любые IRP, предназначенные этому стеку, как показано на рис. 14-11.

Рис. 14-11. Драйвер фильтра, добавленный на вершину стека драйверов

Руткит может зарегистрировать новый драйвер фильтра и "вставить" его на вершину стека, получив возможность видеть и перехватывать все входящие IRP. После перехвата вредоносная программа решает отбросить пакет или изменить его. Так руткит может использовать фильтр для защиты собственных файлов. Например, он регистрирует драйвер, наблюдающий за запросами ввода-вывода к этим файлам и перехватывающий их, а затем изменяет запросы или полностью отбрасывает, фактически скрывая файлы от исследователей и инструментов анализа. EDR и другие средства защиты конечных точек иногда используют драйверы фильтров по той же причине: для защиты своих файлов от вредоносных программ.

Чтобы реализовать драйвер фильтра, руткит сначала загружает его в память ядра, возможно, методами из раздела "Установка руткита" на странице 269 оригинала. Фильтр должен указать, какой обмен IRP ему интересен, настроив обработчики соответствующих пакетов. Например, если вредоносная программа хочет перехватывать MJ_CREATE, она должна реализовать это в таблице функций IRP драйвера фильтра.

Вредоносная программа может злоупотреблять мини-фильтрами, зарегистрировав собственный посредством FltRegisterFilter либо перехватив существующий. Известны современные образцы с таким поведением. При анализе кода драйвера руткита обратите внимание, вызывает ли программа FltRegisterFilter для регистрации собственного мини-фильтра. Также проверьте вызовы FltGetFilterFromName, FltEnumerateFilters и FltEnumerateInstances: возможно, программа перечисляет другие мини-фильтры на узле, готовясь к перехвату. Практическая реализация мини-фильтров подробнее описана в статье Рахула Дева Трипати «Storage Device Restriction Using a Minifilter Driver Approach».

Устаревшие драйверы фильтров устанавливаются иначе. Подробности выходят за рамки книги, но дополнительную информацию можно найти в руководстве по драйверам фильтров файловой системы и отличной публикации Ротема Салинаса «Fantastic Rootkits and Where to Find Them».

Злоупотребление обратными вызовами ядра

Злоупотребление обратными вызовами ядра - ещё один более современный подход некоторых руткитов. Напомним обсуждение главы 13: обратный вызов позволяет модулю ядра получать уведомления о системных событиях и выполнять действие при их наступлении. Например, драйверу может понадобиться узнать о запуске процесса в пользовательском пространстве, и тогда он реализует PsSetCreateProcessNotifyRoutine, как некоторые продукты EDR. После регистрации обратного вызова драйвер получает уведомление в виде IRP при создании процесса и может выполнить код обработчика события.

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

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

Столбец Type показывает тип обратного вызова, Callback - адрес обработчика, а Module - зарегистрировавший его модуль ядра. Большинство записей являются нормальными законными вызовами. Однако подозрительный модуль comp.sys зарегистрировал интересный обработчик PsSetCreateThreadNotifyRoutine. Как упоминалось ранее, он срабатывает при создании нового потока процессом пользовательского пространства. Обратите также внимание, что адрес его кода сильно отличается от адресов законных обработчиков, например 0xfffff6050d26ccc0 против 0xfffff80af3afb210.

Сходный подход применял руткит DirtyMoe. Он использовал обратные вызовы ядра для скрытного внедрения вредоносного кода во вновь создаваемые потоки пользовательского пространства. Подробнее см. статью Мартина Хлумецкого «DirtyMoe: Rootkit Driver».

Печально известный руткит Necurs, появившийся в 2014 году, настраивает обратный вызов реестра CmRegisterCallback, разновидность обратного вызова драйвера фильтра, уведомляющую его о любом обращении к разделу реестра службы. Если исследователь или программа пытается открыть этот раздел, попытка завершается неудачей. Следующий упрощённый псевдокод показывает, как вредоносный драйвер регистрирует обратный вызов реестра и злоупотребляет им:

Сначала код определяет функцию обратного вызова RegistryCallback, которая выполняется при наступлении события 1. Позднее руткит задаёт обратный вызов реестра, передавая его имя RegistryCallback и контекст, указатель на структуру со сведениями о вызове функции 5. Поскольку обработчик срабатывает при взаимодействии программ с реестром Windows, структура контекста содержит важные данные: конкретное действие с реестром, например открытие раздела или запись данных, и цель действия, то есть затронутый раздел либо значение.

Когда программа выполняет действие с реестром, например вызывает RegOpenKeyExA, исполняется вредоносный код обратного вызова руткита. Затем руткит

проверяет, равно ли событие CM_EVENT_REGISTRY_KEY_OPEN, что означает открытие раздела реестра 2, а затем сравнивает затронутый раздел с HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\evil, который вредоносная программа использует для закрепления на узле 3. Если имя совпадает, руткит пытается помешать программе или исследователю изучить раздел 4. Среди прочих способов он может временно удалить собственный раздел и позднее создать его заново либо внедрить вредоносный код в вызывающий процесс и перехватить функцию, чтобы не позволить вызову завершиться успешно.

ПРИМЕЧАНИЕ. CmRegisterCallback теперь устарела; современная версия функции называется CmRegisterCallbackEx. Однако принципы работы остались прежними.

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

Буткиты

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

Одна из конкретных разновидностей - буткит UEFI, иногда называемый руткитом UEFI, который работает внутри Unified Extensible Firmware Interface, специализированной микросхемы хранения на материнской плате. UEFI содержит низкоуровневое программное обеспечение, выполняемое до запуска операционной системы и обеспечивающее интерфейс между её ядром и различными микропрограммными устройствами системы. Поскольку UEFI запускается раньше операционной системы, внедрившаяся в микросхему вредоносная программа дольше остаётся незамеченной и может пережить переустановку или восстановление ОС.

Примечательный пример буткита UEFI - CosmicStrand. В июле 2022 года исследователи Kaspersky сообщили, что этот буткит глубоко внедрялся в системы, а возможным вектором входа была аппаратная уязвимость. Он поражал разные системы с определёнными моделями материнских плат Asus и Gigabyte, захватывал загрузчик ядра Windows и внедрял вредоносный код в память ядра. Подробнее см. статью Global Research & Analysis Team (GreAT) Kaspersky «CosmicStrand: The Discovery of a Sophisticated UEFI Firmware Rootkit».

Другой пример - платформа MosaicRegressor, также обнаруженная Kaspersky. Она включала компонент руткита UEFI, захватывавший процесс загрузки Windows и записывавший на диск исполняемый файл, который скрытно запускался при загрузке. Если файл удаляли, после перезагрузки он снова записывался на диск, обеспечивая высокую устойчивость. Подробнее см. статью Марка Лехтика, Игоря Кузнецова и Юрия Паршина «Lurking in the Shadows of UEFI».

По сравнению с традиционными вредоносными программами пользовательского пространства буткиты относительно редки. Однако они могут быть не настолько редкими, как кажется. Благодаря низкоуровневому доступу к узлу они способны сохраняться незамеченными даже в хорошо защищённых средах. Если мы не умеем обнаруживать такой код, то не знаем о его существовании, а значит, буткиты могут быть встроены в большее количество систем, чем нам известно. Но не всё потеряно. Завершим главу обсуждением встроенной защиты Windows от руткитов и буткитов.

Защита от руткитов

Microsoft реализовала несколько средств защиты от руткитов, два важнейших из которых - PatchGuard и обязательная проверка подписи драйверов (DSE). PatchGuard, также известный как защита исправлений ядра (KPP), появился в 2005 году в x64-версиях Windows XP и ослабляет действие многих рассмотренных методов, включая перехват SSDT и IDT и многочисленные формы DKOM. PatchGuard периодически проверяет целостность структур памяти ядра и выясняет, не были ли они изменены. При обнаружении изменения PatchGuard принудительно вызывает сбой ядра, результат которого показан на рис. 14-12.

Рис. 14-12. Сбой проверки безопасности ядра, вызванный PatchGuard

Однако PatchGuard не неуязвим для обхода. Поскольку память ядра сканируется периодически, при правильном подборе времени вредоносная программа может очень быстро изменить её и вернуться в "чистое" состояние до проверки целостности. Для запуска проверки операционная система вызывает функцию API ядра KeBugCheckEx, которую некоторые вредоносные программы, как известно, перехватывают, не позволяя проверке успешно выполниться. Кроме того, встречались случаи эксплуатации вредоносными программами PatchGuard и связанных компонентов. Один из примеров - GhostHook, использовавший уязвимость в реализации низкоуровневого API Intel Processor Trace и потенциально позволявший остаться незаметным для PatchGuard. Метод довольно сложен и здесь подробно не рассматривается; дополнительные сведения приведены в публикации Касифа Декеля «GhostHook - Bypassing PatchGuard with Processor Trace Based Hooking».

Ещё два относительно недавних примера обхода PatchGuard - InfinityHook, злоупотребляющий API ядра NtTraceEvent, и ByePg, захватывающий структуру ядра HalPrivateDispatchTable. Они обходят PatchGuard разными способами. Однако Microsoft быстро исправляет некоторые известные уязвимости, вынуждая авторов вредоносных программ адаптироваться.

Другое средство Microsoft - обязательная проверка подписи драйверов (DSE), иногда называемая обязательной цифровой подписью, выпущенная для Windows Vista x64 и более новых версий. DSE обеспечивает загрузку в память ядра только предварительно проверенных подписанных драйверов. Теоретически законные драйверы разрешаются, а подозрительные неподписанные блокируются. Ранее в главе вы прочитали, как вредоносная программа обходит эту защиту с помощью вредоносного драйвера ядра, подписанного законным сертификатом, или метода BYOVD. Microsoft рекомендует противодействовать проблеме посредством списков известных уязвимых драйверов. После сообщения об уязвимости или активном злоупотреблении драйвер добавляется в список блокировки и больше не может быть установлен. В поздних версиях Windows функцию можно принудительно включить параметром безопасности Microsoft Vulnerable Driver Blocklist. Основные проблемы состоят в возможной блокировке некоторых законных драйверов и защите только от уже известных вредоносных драйверов.

Наконец, ранний запуск антивредоносного программного обеспечения (ELAM) - функция некоторых средств защиты конечных точек, оберегающая процесс загрузки Windows. ELAM отвечает за загрузку компонентов ядра anti-malware до других сторонних компонентов. Благодаря этому антивредоносное средство успевает правильно загрузиться и запуститься до того, как руткит или другая устойчивая вредоносная программа получит возможность выполниться. ELAM может хорошо защищать от руткитов. Но поскольку драйверы ELAM загружаются лишь на более поздних этапах загрузки, одной этой функции может быть недостаточно против буткитов.

Для защиты от буткитов и руткитов UEFI можно включить Secure Boot. Доступная на большинстве современного оборудования функция не позволяет вредоносному коду захватить процесс загрузки Windows. При запуске Secure Boot проверяет целостность драйверов микропрограммы UEFI и самой операционной системы, прежде чем разрешить системе полностью загрузиться. Это обеспечивает уровень защиты на случай внедрения вредоносной программы в микросхему UEFI. В большинстве версий Windows Secure Boot необязателен, но в Windows 11 требуется. Однако, как у любого механизма безопасности, в разных реализациях Secure Boot существуют уязвимости, которые может эксплуатировать вредоносная программа. Например, в 2020 и 2022 годах о нескольких таких уязвимостях сообщали исследователи Eclypsium.

В завершение отметим, что многие средства Windows от руткитов, например PatchGuard и DSE, предназначены только для x64, то есть 64-разрядных, версий Windows. Поэтому x86, 32-разрядные, версии потенциально остаются открытыми для множества опасных низкоуровневых вредоносных программ. К счастью, именно потому, что эти средства безопасности не включены в режиме x86, EDR и anti-malware могут применять те же методы во благо, наблюдая за конечной точкой и защищая её.

Итоги

В этой главе были рассмотрены основы руткитов: работа модулей ядра, установка вредоносных модулей и обход злоумышленниками таких мер, как обязательная подпись драйверов. Мы обсудили распространённые методы, включая DKOM, перехват ядра, перехват IRP и злоупотребление обратными вызовами ядра. Вы познакомились с буткитами и увидели, как вредоносная программа пространства ядра обходит встроенные механизмы Windows вроде PatchGuard. Но глава лишь коснулась поверхности темы руткитов и манипулирования ядром, поэтому для дальнейшего изучения автор рекомендует материалы приложения C. В следующей главе рассматривается, как современные вредоносные программы уклоняются от защиты конечных точек и исследователей посредством "бесфайловых" методов и противодействия криминалистическому анализу.

Бесфайловая вредоносная программа, иногда называемая резидентной в памяти, не создаёт и не изменяет файлы на жёстком диске; вместо этого её артефакты находятся только в памяти. В более широком смысле термин "бесфайловая атака" означает, что вся цепочка атаки или по крайней мере значительная её часть обходится без файлов. Такие атаки затрудняют обнаружение вредоносной программы узловыми средствами защиты вроде anti-malware и усложняют анализ специалистам по компьютерной криминалистике, пытающимся понять масштаб и последствия. Они применяют такие методы, как внедрение в процессы, описанное в главе 12, и Living Off The Land Binaries (LOLBins), которые рассматриваются далее в этой главе.

Противодействие криминалистике (anti-forensics) - класс методов, с помощью которых злоумышленник пытается скрыть или удалить следы атаки и помешать будущим расследованиям. Он может приказать вредоносной программе завершиться и убрать следы из памяти, удалить или повредить файлы на диске, очистить либо изменить журналы и доказательства и даже полностью уничтожить систему жертвы. Всё это делается ради затруднения будущего расследования. Противодействие криминалистике будет рассмотрено далее; сначала подробнее изучим бесфайловые атаки.

Как работают бесфайловые атаки

Традиционные угрозы часто опираются на запись файлов на диск, тогда как бесфайловая вредоносная программа выполняется полностью или почти полностью в памяти, оставляя на узле жертвы как можно меньше следов. На рис. 15-1 показана гипотетическая, но реалистичная бесфайловая атака.

Разберём её по шагам. Сначала автор вредоносной программы отправляет жертве письмо с вредоносным документом Microsoft Word. Пользователь охотно открывает документ, как часто бывает, после чего выполняется встроенный сценарий Visual Basic for Applications (VBA), код, который можно встраивать в законные документы для автоматизации частых задач, но которым нередко злоупотребляют в более злонамеренных целях. Сценарий VBA вызывает встроенную утилиту Windows certutil.exe, загружающую закодированный сценарий PowerShell с промежуточного сервера злоумышленника. После загрузки certutil декодирует его, и сценарий выполняется через powershell.exe. Код PowerShell записывает в реестр Windows команды, которые будут запущены после перезагрузки. Вскоре пользователь выключает ноутбук на вечер и уходит домой.

Рис. 15-1. Бесфайловая атака

Перенесёмся на 12 часов вперёд, когда пользователь включает ноутбук перед новым рабочим днём. При загрузке системы выполняется вредоносный код, сохранённый в реестре. Он содержит обфусцированную команду PowerShell, которая загружает ещё один сценарий с промежуточного сервера злоумышленника. Сценарий внедряется в работающий процесс PowerShell, не оставляя файлов на диске. Загруженный код содержит байткод, формирующий в памяти исполняемый файл, который затем внедряется в новый процесс malware.exe. Полезная нагрузка представляет собой разновидность похитителя информации и начинает собирать конфиденциальные данные узла.

Атака может казаться чрезмерно сложной, но для людей с опытом анализа бесфайловых атак она вполне реалистична. В сценарии применяются несколько интересных методов. Во-первых, вредоносная команда записывается и хранится в реестре. Бесфайловая программа иногда сохраняет там команды, код или параметры конфигурации, чтобы не создавать новые файлы на диске. Поскольку реестр хранится на диске в проприетарном двоичном формате и доступен для чтения человеком только после загрузки в память, это всё равно считается бесфайловым методом. Подробнее см. врезку "Парадокс бесфайловых атак". Вредоносную программу, скрывающуюся в реестре, иногда называют резидентной в реестре; это подкатегория бесфайловых программ, к которой мы вскоре вернёмся. Выполненная из реестра команда PowerShell также полностью в памяти загружает и запускает вредоносный код.

Во-вторых, вызванные в атаке утилиты Windows, в частности certutil.exe и powershell.exe, можно отнести к LOLBins, законным инструментам, встроенным в Windows или иным образом уже доступным в целевой системе. Эти утилиты применяются для обычных задач системного администрирования и обслуживания, но ими также легко злоупотреблять для выполнения несанкционированного кода и сокрытия вредоносных действий. Бесфайловые атаки часто используют LOLBins, некоторые из которых позволяют вредоносной программе выполнять код в памяти.

ПАРАДОКС БЕСФАЙЛОВЫХ АТАК. Бесфайловые и резидентные в памяти атаки не всегда действительно обходятся без файлов или находятся только в памяти. Как отмечалось ранее, можно возразить, что реестр существует на диске, а значит, атака, сохраняющая в нём вредоносные команды, не является по-настоящему бесфайловой. Технически это верно. Но содержимое кустов реестра нечитаемо на диске и становится доступным только после загрузки в память, поэтому метод всё равно относят к бесфайловым. Кроме того, многим таким атакам нужен первоначальный вектор, например фишинговое письмо с вредоносным вложением Microsoft Office, как в описанном сценарии. Хотя атака не полностью бесфайловая, поскольку существуют письмо и документ Word, большая часть цепочки целиком находится в памяти.

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

Закрепление и резидентная в реестре вредоносная программа

В только что описанной бесфайловой атаке программа записала команду PowerShell в реестр и настроила её автоматический запуск при следующей загрузке. Реестр Windows может предоставить вредоносной программе безопасное место для сокрытия, поскольку обнаружить её там маловероятно, по крайней мере человеку, не знающему точно, что искать. Кроме того, anti-malware и другие средства защиты конечных точек могут быть не настроены на поиск вредоносного кода в реестре.

Этот метод - один из способов закрепления, то есть сохранения вредоносной программы на заражённом узле даже после перезагрузки системы. Для этого программа может использовать

любую из нескольких тактик, но здесь мы сосредоточимся на закреплении через реестр, поскольку оно непосредственно связано с резидентными в реестре вредоносными программами.

Run и RunOnce - специальные разделы реестра, вызываемые при входе пользователя в систему. Они могут указывать на исполняемые файлы, сценарии и даже принимать параметры командной строки. Эти разделы находятся по следующим путям:

• HKLM\Software\Microsoft\Windows\CurrentVersion\Run

• HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run

• HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

Разделы Run вызываются при каждом входе пользователя, а RunOnce - только один раз, при следующем входе. Каждый раздел состоит из имени и значения, представляющего выполняемую команду или файл. Манипулируя этими разделами, автор может запускать вредоносную программу и связанные команды непосредственно из реестра. Для демонстрации автор добавил в HKLM\Software\Microsoft\Windows\CurrentVersion\Run новое значение Evil. Оно показано на рис. 15-2 и может просматриваться и редактироваться через regedit.exe.

Рис. 15-2. Добавление нового вредоносного значения Run в реестр

Это значение просто вызывает powershell.exe и выполняет команду pause. Теперь при каждом входе автора в систему появляется окно PowerShell. Очевидно, автор вредоносной программы предпочёл бы сделать что-нибудь вредоноснее, чем показывать окно при каждом входе. Например, он может выполнить более сложную команду:

Когда пользователь входит в Windows, команда загружает сценарий PowerShell evil.ps1 с удалённого веб-сервера evil.com и выполняет его непосредственно в памяти. Здесь мы больше не будем разбирать эту команду, поскольку PowerShell подробнее рассматривается далее в главе. Важно помнить, что вредоносная программа легко скрывает команды и код в реестре, а разделы Run и RunOnce - один из способов. В табл. 15-1 приведён неполный список других разделов Run и мест закрепления в реестре.

Таблица 15-1. Разделы реестра, которые вредоносная программа может использовать для закрепления

Это лишь самая вершина айсберга механизмов закрепления. Описанные разделы Run относятся к наиболее распространённым бесфайловым методам, но существуют и другие. Дополнительные сведения приведены на сайте MITRE ATT&CK.

Living Off The Land Binaries

Теперь перейдём к другому методу, которым вредоносная программа может запускать бесфайловые атаки, LOLBins. Причин вызывать LOLBin несколько:

• Обход ограничений приложений, например AppLocker. AppLocker - механизм безопасности Windows, запрещающий выполнение нежелательных приложений. Вредоносная программа может обойти его, используя системные двоичные файлы как прокси.

• Уклонение от обнаружения. EDR, anti-malware и другие средства защиты конечных точек менее тщательно проверяют LOLBins, поскольку те часто имеют цифровую подпись и, следовательно, проверены самой операционной системой. Кроме того, многие LOLBins позволяют выполнять вредоносный код в памяти, что дополнительно усиливает уклонение.

• Сокрытие в шуме. В повседневной работе системные администраторы используют множество LOLBins, поэтому разработать надёжную логику обнаружения их вредоносного применения трудно; объём создаваемого ими шума усложняет аналитикам поиск нужных событий.

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

Классификация LOLBins довольно субъективна. Некоторые специалисты утверждают, что это законные приложения, которыми злоумышленники могут злоупотреблять неожиданным образом. Однако такое определение исключило бы приложения, используемые "ожидаемым" способом, например cmd.exe для удаления файла. Автор придерживается понимания, более близкого к сути выражения "жить за счёт местности": злоумышленник может и будет использовать всё доступное, без учёта ожидаемого или неожиданного применения. По мнению автора, LOLBin - любое широко доступное приложение или инструмент, которым можно злоупотребить. Рассмотрим, как это делается с помощью кода VBA и макросов.

Вредоносные программы на основе макросов VBA

Методы living off the land часто начинаются с заражённого документа, запускающего цепочку атаки LOLBin. Обычно, хотя и не всегда, это документы Microsoft Word или Excel, а вредоносный код представлен макросами VBA. Изначально макросы предназначались для автоматизации распространённых пользовательских задач в документе, но злоумышленники также применяют их для развёртывания дополнительных вредоносных программ.

ПРИМЕЧАНИЕ. На момент написания книги злоупотребление макросами VBA заметно сократилось. Теперь Microsoft Office по умолчанию запрещает выполнение макросов из документов, полученных из недоверенных источников, поэтому реализовать такой вектор стало сложнее. Однако злоумышленники могут обходить ограничения либо использовать другие форматы документов, например Rich Text Format (RTF) и Portable Document Format (PDF), для достижения сходного результата.

Код макроса VBA весьма мощный: он способен даже импортировать DLL Windows и вызывать функции WinAPI. Например, инструмент Cobalt Strike применяет макрос внутри документа Microsoft Office, чтобы внедрить шелл-код в работающий процесс и загрузить дополнительную полезную нагрузку, называемую beacon, с вредоносного веб-сервера. Ниже приведён код промежуточного макроса Cobalt Strike, немного изменённый ради читаемости и краткости:

Здесь происходит многое, поэтому разберём код по блокам. Сначала он определяет массив байтов, который после преобразования в шестнадцатеричный формат оказывается вредоносным шелл-кодом 1. Затем проверяется, является ли среда Windows 32- или 64-разрядной, и выбирается соответствующий каталог, System32 для 32-разрядной архитектуры или SysWOW64 для 64-разрядной, откуда вызывается утилита rundll32.exe 2. Код запускает экземпляр rundll32.exe посредством CreateProcessA 3, а затем вызывает VirtualAllocEx, выделяя внутри процесса область памяти 4 того же размера, что массив шелл-кода.

Далее цикл for записывает каждый байт шелл-кода во вновь выделенную область посредством WriteProcessMemory 5. Наконец, макрос вызывает CreateRemoteThread и выполняет внедрённый шелл-код в контексте rundll32.exe 6. Если вы помните главу 12, то можете распознать внедрение шелл-кода.

Утилита rundll32.exe - одна из многочисленных LOLBins в среде Windows. Вскоре вы узнаете о ней подробнее. Здесь промежуточный загрузчик Cobalt Strike использует rundll32.exe как своего рода суррогат вредоносного кода, скрывая код внутри процесса и потенциально уклоняясь от средств защиты конечных точек и назойливых аналитиков безопасности.

Далее обсудим другой способ маскировки вредоносного кода посредством злоупотребления законными утилитами Windows, System Binary Proxy Execution.

Прокси-выполнение через системные двоичные файлы

System Binary Proxy Execution - метод выполнения кода через законную и часто подписанную цифровой подписью утилиту Windows. Одна из причин такого проксирования - обход блокировки приложений вроде AppLocker. Атака также помогает вредоносной программе оставаться незаметной для защиты конечных точек, например anti-malware. Метод может злоупотреблять следующими типами файлов:

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

• Двоичные файлы, не входящие в Windows по умолчанию, но всё равно очень распространённые. Например, PSExec, популярный инструмент системного администрирования, и ProcDump, средство создания дампа памяти целевого процесса. Эти утилиты могут присутствовать или отсутствовать в среде жертвы до атаки, поэтому перед вызовом их, возможно, придётся перенести в целевую систему. Далее в этой книге они не рассматриваются.

Начнём с нескольких наиболее часто используемых LOLBins для прокси-выполнения.

Rundll32

Rundll32, уже встречавшаяся вам в примере с Cobalt Strike, представляет собой важный двоичный файл, который многие приложения Windows используют для выполнения кода из DLL. Если приложению требуется определённая DLL, но оно не загружает её напрямую, например посредством LoadLibrary, оно может вызвать rundll32.exe и конкретную экспортируемую функцию:

Как видите, rundll32 принимает два параметра: имя и путь к DLL-файлу, в данном случае library.dll, и экспортируемую функцию, которая будет выполнена, ExportedFunction. Вредоносная программа также может злоупотребить rundll32.exe, чтобы выполнить код из вредоносной DLL:

Поскольку операционная система Windows и различные легитимные процессы очень часто запускают rundll32, её нередко используют как суррогатный процесс для вредоносного кода. В примере с промежуточным загрузчиком Cobalt Strike этот процесс создавался, в него внедрялся шелл-код, после чего он служил контейнером для вредоносного кода и выполнял его.

Regsvr32

Regsvr32 представляет собой исполняемый файл для регистрации и отмены регистрации модулей DLL. Вредоносная программа может использовать regsvr32, чтобы выполнять свой код в контексте подписанного двоичного файла regsvr32.exe или даже загружать и исполнять вредоносный код с удалённого сервера.

Семейство вредоносных программ Emotet известно применением LOLBins в своей цепочке атаки. Полезная нагрузка одного из вариантов Emotet (SHA256: d642109e621c6758027c2fc0e5ea3d1126963a001ab1858b95f82e09403943bd) доставлялась через вредоносные документы Microsoft Excel, которые загружали несколько полезных нагрузок и модулей, а затем выполняли их посредством regsvr32.exe. Эта цепочка атаки показана на рис. 15.3, снимке экрана Joe Sandbox.

Рис. 15.3. Дерево процессов Emotet в Joe Sandbox

Другой примечательный пример применения regsvr32 представляет собой атаку со странным названием Squiblydoo. Она также использует DLL среды выполнения компонентов сценариев Windows scrobj.dll, которая обычно служит для исполнения локальных COM-скриптлетов. Объединяя возможности regsvr32.exe и scrobj.dll, вредоносная программа Squiblydoo загружает вредоносный COM-скриптлет непосредственно из интернета и выполняет его:

Эта команда загружает вредоносный сценарий script.sct с http://evil.kz, а затем выполняет его с помощью scrobj.dll, всё время скрываясь внутри адресного пространства процесса regsvr32.exe и работая исключительно в памяти. Если точнее, ключ /s указывает regsvr32.exe не показывать сообщение жертве, что было бы нежелательно для злоумышленника. Ключ /i передаёт следующую за ним строку, http://evil.kz..., функции DllInstall внутри scrobj.dll.

Этот метод работает потому, что функция DllInstall в файле scrobj.dll принимает URL и без проверки загружает и выполняет файл сценария. Подробнее о методе Squiblydoo можно прочитать в репозитории MITRE Cyber Analytics Repository (CAR): car.mitre.org.

Mshta

Mshta применяется для выполнения файлов HTML Application (.hta), то есть файлов сценариев, которые могут содержать HTML, VBScript, JavaScript и сценарии других типов. HTA-файлы предоставляют графический интерфейс посредством HTML, а программную логику приложения реализует код сценария. Вредоносные программы часто используют mshta.exe для загрузки и выполнения файлов с удалённых серверов, как в следующем примере из распространяющего вредоносную программу файла Microsoft Excel:

Один конкретный образец вредоносной программы (SHA256: 03f03a3f36c87d8cb7cd5f8ce6e324917253eeca4f3ea164f35242146e26e2b1) вызывает mshta.exe через rundll32.exe, показывая, как в некоторых атаках несколько LOLBins объединяются в цепочку. На рис. 15.4 представлен отчёт Joe Sandbox (joesandbox.com).

Рис. 15.4. Цепочка атаки LOLBin в отчёте об анализе Joe Sandbox

В этом анализе песочницы видно, как документ Microsoft Excel создаёт процесс rundll32.exe, вероятно посредством встроенного кода VBA или сходного метода, а тот затем вызывает mshta.exe, чтобы загрузить и выполнить файл, размещённый на mediafire.net.

BITSAdmin

Служба фоновой интеллектуальной передачи Background Intelligent Transfer Service (BITS) предназначена для передачи файлов на веб-серверы и файловые ресурсы и обратно. BITS можно настраивать в виде "заданий", автоматически управляющих сопутствующими операциями передачи файлов: отслеживающих использование сети, задержку и размеры файлов, а также позволяющих приостанавливать и возобновлять передачу. Приложение BITSAdmin, bitsadmin.exe, служит для управления BITS.

Вредоносные программы могут злоупотреблять BITS, чтобы загружать и выполнять полезные нагрузки с удалённых серверов. Следующая команда создаёт новое задание передачи файлов с именем myjob и высоким приоритетом, затем загружает файл malicious.exe с домена evil.uk, сохраняя его в каталоге C:\Users\AppData\Roaming:

InstallUtil

InstallUtil представляет собой компонент платформы Windows .NET, который операционная система и другие приложения используют для установки серверных ресурсов и служб. Вредоносная программа также может применять его для вызова исполняемых файлов и DLL. Следующая команда выполняет evil.dll в контексте installutil.exe:

На узле может быть установлено много версий .NET, поэтому вместо version здесь указывалась бы конкретная версия, например v4.0.30319. Как и многие LOLBins, installutil.exe часто применяется системными администраторами в законных целях, поэтому предотвратить такое несанкционированное использование трудно, особенно если для этого придётся ограничить способы выполнения администраторами своей работы. Лучше либо ограничить группы пользователей, которым разрешено запускать эту утилиту, либо, по меньшей мере, отслеживать её применение этими группами и регулярно просматривать журналы.

Certutil

Двоичный файл certutil.exe входит в компонент Windows Certificate Services и позволяет отображать сведения о цифровых сертификатах, проверять, настраивать и устанавливать их. Злоумышленники могут использовать его несколькими интересными способами. Например, вредоносный документ Microsoft Excel (SHA256: d009299a787cf9b7995827014e72525038eecd3e1f99820d66854fc865d39047) загрузил с удалённого сервера и выполнил полезную нагрузку Lokibot следующей командой:

Эта команда вызывает certutil, загружает исполняемый файл Zcldxvqciopgykje.exe с веб-сервера 45.155.165.63 и выполняет его.

Вредоносная программа также может использовать certutil для кодирования или декодирования файла:

Ключ -encode предписывает certutil закодировать файл в Base64; Base64 будет рассмотрен в главе 16. Такое кодирование может служить грубым способом сокрытия файла на диске или обфускации данных перед их эксфильтрацией из сети для обхода средств сетевой защиты. Certutil является отличным примером многоцелевого LOLBin.

Windows Script Host

В состав Windows входят несколько встроенных утилит Windows Script Host (WSH) для выполнения языков сценариев, например VBScript (файлы .vbs и .vbe) и JavaScript (файлы .js и .jse). К WSH относятся такие утилиты, как wscript.exe и cscript.exe. Их можно вызывать из командной строки или создавать как новый процесс и использовать для выполнения файлов сценариев разных типов. Писать сценарии гораздо проще, чем, например, создавать исполняемый файл на C++, чем и пользуются некоторые вредоносные программы. В одном из примеров документ Microsoft Word (SHA256: ccc8d5aa5d1a682c20b0806948bf06d1b5d11961887df70c8902d2146c6d1481) со встроенным кодом сохраняет на диск JavaScript-файл и выполняет его посредством wscript.exe следующей командой:

При выполнении этот сценарий загружает образец семейства вредоносных программ OriginLogger. Данный вредоносный документ входит в многоэтапную атаку, которая позднее также вызывает mshta.exe.

Двоичный файл wscript.exe позволяет выполнять файлы сценариев непосредственно из альтернативных потоков данных NTFS (Alternate Data Streams, ADS), рассматриваемых далее в этой главе. Пока достаточно знать, что вредоносная программа способна прятать файлы внутри ADS, фактически скрывая их от посторонних глаз и некоторых средств защиты конечных точек. Чтобы выполнить файл сценария, скрытый в другом файле посредством ADS, используют следующую команду:

Сценарии в целом выходят за рамки этой книги, однако следует помнить, что современные угрозы часто применяют такие языки, как JavaScript и VBScript, которые легко выполняются в Windows встроенными интерпретаторами сценариев.

Командная строка Windows и другие утилиты

Встроенная командная строка Command Prompt (cmd.exe), являющаяся стандартной утилитой командной строки Windows, широко используется как в законных, так и во вредоносных целях. Например, вредоносная программа может применять её для завершения процессов, удаления файлов, изменения конфигурации системы и удаления резервных копий. Некоторые используемые ею команды также можно было бы отнести

к атакам с применением LOLBins, поскольку cmd.exe часто служит для выполнения других утилит. Вредоносная программа нередко вызывает Command Prompt, создавая новый процесс, например посредством CreateProcess, и передавая ему нужную команду в качестве параметра.

Пожалуй, чаще всего Command Prompt используют для непосредственного выполнения других файлов и приложений. Это может выглядеть примерно как следующий код, вызывающий исполняемый файл flashplayer.exe:

В табл. 15.2 перечислены другие команды и утилиты, которыми иногда злоупотребляют вредоносные программы. Этот перечень ни в коем случае не исчерпывающий, поскольку через cmd.exe можно вызвать множество команд.

Таблица 15.2. Утилиты и команды, которые могут использовать вредоносные программы

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

PowerShell

Применение PowerShell является одним из наиболее распространённых методов living off the land среди современных угроз. PowerShell представляет собой встроенную в Windows платформу, с помощью которой как законные пользователи системы, так и вредоносные программы могут выполнить практически любую задачу администрирования или настройки Windows. Возможности PowerShell обеспечиваются множеством команд, называемых командлетами. PowerShell построена на платформе .NET, предоставляющей разработчикам Windows множество библиотек для создания новых приложений. PowerShell можно использовать интерактивно через командную строку, однако вредоносные программы часто запускают её как автоматизированный сценарий или однострочную команду посредством Windows API, например через CreateProcess.

Реализация загрузочных команд

Один из самых распространённых способов применения PowerShell во вредоносных программах представляет собой cradle, то есть команду, обычно однострочную, которая загружает дополнительную вредоносную программу или модули с промежуточного сервера, а иногда ещё и сразу выполняет эти файлы. Вот один из возможных вариантов такой загрузочной команды:

Разберём эту команду PowerShell. Сначала она использует командлет Invoke-WebRequest, отправляющий HTTP- или HTTPS-запрос удалённому веб-серверу. В качестве входных данных командлет принимает адрес веб-сервера и путь к каталогу загружаемого файла zzl2.cab. Наконец, флаг -OutFile задаёт путь к каталогу и имя, под которым нужно сохранить файл. Вредоносный файл zzl2.cab будет сохранён в каталоге профиля пользователя, обозначенном переменной среды $ENV:UserProfile, под именем crypt.dll. Поскольку PowerShell построена на .NET, она имеет прямой доступ к многочисленным методам и классам .NET и может ими пользоваться:

В этой команде флаг -exec указывает PowerShell обойти действующие политики выполнения, которые могли бы помешать запуску команды. Политики выполнения PowerShell настраиваются в Windows для запрета определённых действий PowerShell, однако иногда обходятся довольно легко. IEX является сокращением от Invoke-Expression, выполняющего предшествующую ему строку как команду. Следующая часть команды, выражение (New-Object Net.WebClient).DownloadString, создаёт новый объект .NET WebClient с методом DownloadString. Это ещё один способ, которым вредоносная программа может отправлять веб-запросы удалённому серверу и загружать полезную нагрузку. Данная нагрузка будет загружена с http://www.evil.cn и выполнена непосредственно в памяти. Подробнее о загрузочных командах PowerShell см. gist.github.com и gist.github.com.

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

Обфускация PowerShell

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

Один из простых методов обфускации заключается во вставке в команду символов +:

Символы могут быть как строчными, так и прописными, поэтому следующая команда PowerShell по-прежнему допустима:

Однако читать её уже немного труднее.

Кроме того, символы можно переставлять, как в следующем примере:

Числа в фигурных скобках обозначают позиции символов X, E и I после перестановки, поэтому в итоге они образуют IEX.

Наконец, PowerShell допускает данные в кодировке Base64, поэтому вполне можно передать закодированную команду вроде этой:

Кодирование Base64 будет рассмотрено в главе 16. А пока обратимся к ещё одной связанной с PowerShell возможностью, которую вредоносные программы могут использовать в своих интересах.

Запросы к WMI

Как вы, возможно, помните из предыдущих глав, Windows Management Instrumentation (WMI) позволяет системным администраторам управлять данными и автоматизировать операции в Windows. В Windows 7 и более ранних версиях для вызова WMI использовалась консоль Windows Management Instrumentation Console (WMIC), но в современных версиях она объявлена устаревшей. Теперь гораздо чаще WMI вызывают посредством PowerShell, где есть несколько встроенных командлетов компонентов для взаимодействия с WMI. Один из примеров, Get-CimInstance, представляет собой командлет, которым вредоносная программа также может запрашивать объекты WMI. Чтобы собрать сведения о системе, например определить, является ли она виртуальной машиной или песочницей, вредоносная программа может выполнить непосредственно из PowerShell следующие команды:

Эти команды запрашивают через WMI сведения о процессоре, BIOS и диске системы. В следующем выводе по сведениям BIOS видно, что система работает в VirtualBox:

Другие интересные объекты для запросов, ThermalZoneTemperature и Win32_Fan, возвращают соответственно текущую температуру процессора и скорость вентилятора:

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

WMI представляет собой обширную тему, и вредоносные программы могут вызывать её другими способами, например напрямую через интерфейсы WMI вроде IwbemServices.ExecQuery, но это выходит за рамки книги и далее не рассматривается. Вместо этого перейдём ещё к одному методу living off the land и бесфайловых атак: применению динамически компилируемого кода.

Динамически компилируемый код

Вредоносные программы всё чаще используют динамически компилируемый код. После доставки жертве такой код компилируется и выполняется из памяти, что может помочь атаке остаться незамеченной средствами защиты конечных точек. Этот метод часто сопровождается применением компонента-дроппера. Дроппер может быть доставлен жертве, например встроенным в электронное письмо, а после выполнения в системе жертвы загрузить вредоносный код с сервера в интернете. Такой код часто зашифрован или обфусцирован. После успешной загрузки полезной нагрузки на узел жертвы она расшифровывается, а затем компилируется в памяти уже имеющимся в целевой системе компилятором. В современные версии Windows по умолчанию входят несколько компиляторов, в том числе компиляторы .NET msbuild.exe и csc.exe. Возможный ход такой атаки показан на рис. 15.5.

Рис. 15.5. Атака с динамической компиляцией кода

Атака начинается с загрузочной команды PowerShell, которая скачивает нескомпилированный код .NET с удалённого сервера, возможно одним из описанных ранее в этой главе способов. Затем сценарий PowerShell вызывает csc.exe, чтобы скомпилировать и выполнить код .NET в памяти.

Другой компилятор, msbuild.exe, относится к Microsoft Build Engine (MSBuild), "платформе для сборки приложений Windows". Она принимает на вход проекты (.proj) или файлы проектов на основе XML, компилирует их и выполняет в процессе сборки. Подробно этот метод здесь не рассматривается; больше о нём можно узнать из статьи Тары Гулд и Гейджа Меле "Threat Actors Use MSBuild to Deliver RATs Filelessly" по адресу anomali.com.

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

Следует учитывать, что в Windows существуют и другие методы динамической компиляции кода, например применение компиляторов C CGG/MinGW или aspnet_compiler.exe для компиляции кода ASP.NET. Эти компиляторы могут вызываться из PowerShell, Command Prompt или даже документов Office с помощью кода макросов VBA.

ДРУГИЕ LOLBINS

Утилиты, описанные в этом разделе, далеко не исчерпывают множество LOLBins. Существует целый проект, посвящённый их отслеживанию и классификации, LOLBAS (lolbas-project.github.io); на момент написания книги он учитывал почти 200 LOLBins.

В заключительном разделе главы мы рассмотрим категорию методов уклонения под названием anti-forensics, или противодействие компьютерной криминалистике, которые часто идут рука об руку с бесфайловыми атаками.

Противодействие компьютерной криминалистике

Представьте, что вы следователь, которому недавно поручили сложное дело о краже данных. Пострадавшая организация установила, что инцидент произошёл на сервере Windows, и сумела локализовать атаку, изолировав сервер от остальной сети, но лишь после того, как злоумышленник похитил неизвестный объём потенциально конфиденциальных данных. Самое странное, что на скомпрометированном сервере как будто не осталось никаких крошек. Нет следов, по которым можно идти. Нет отпечатков или пятен на месте происшествия. Все физические следы вредоносной программы удалены с жёсткого диска. Система перезагружена, и в памяти не осталось артефактов для исследования. Некоторые файлы на диске даже выглядят зашифрованными, но требования выкупа нет.

Возможно, перед вами результат противодействия компьютерной криминалистике. Рассмотрим несколько изобретательных методов, которыми пользуются авторы вредоносных программ.

Сокрытие артефактов и кода

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

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

Удаление и повреждение артефактов

Некоторые вредоносные программы не просто скрывают файлы, а пытаются полностью удалить или уничтожить доказательства. Они могут удалять собственные файлы множеством способов, например вызовом функции WinAPI DeleteFile, через PowerShell или командную строку Windows. Однако в зависимости от способа удаления опытный следователь всё ещё может восстановить удалённые артефакты. Чтобы устранить этот недостаток, некоторые вредоносные программы включают утилиты, специализирующиеся на безопасном и необратимом уничтожении данных. Исследователи Unit42 сообщали, что злоумышленники, стоящие за программой-вымогателем BlackCat, применяли fileshredder, инструмент для необратимого уничтожения файлов, чтобы безопасно удалить доказательства из системы жертвы. См. статью Аманды Таннер, Алекса Хинчлиффа и Доэла Сантоса "Threat Assessment: BlackCat Ransomware": unit42.paloaltonetworks.com.

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

Вместо полного стирания памяти злоумышленник может изменить её, удалив или подменив код либо данные, которые выдали бы присутствие вредоносной программы. Например, программа может просто удалить магические байты PE MZ из области памяти, из-за чего некоторые полагающиеся на эту сигнатуру инструменты исследования перестанут работать. Либо она может скрыть в памяти части своего кода или конфигурации, например кодировать или шифровать строки вроде адресов управления и контроля. Обфускация и шифрование кода и данных будут рассмотрены в главе 16, но многие описанные там методы могут также применяться для противодействия компьютерной криминалистике.

Злоупотребление альтернативными потоками данных

Ещё один способ сокрытия файлов основан на альтернативных потоках данных NTFS (Alternate Data Streams, ADS). Данные файлов в файловой системе Microsoft NTFS обычно размещаются в основном потоке данных. Например, если открыть текстовый файл в редакторе, отображаемые сведения будут частью основного потока. Но данные можно скрыть и внутри ADS, и тогда следователь не увидит их при обычном осмотре файла.

Лучше всего проиллюстрировать ADS NTFS на примере, который вы можете воспроизвести самостоятельно. Сначала создайте текстовый файл с произвольным текстом и сохраните его как file.txt. Чтобы скрыть данные в этом файле, выполните следующую команду:

Эта команда сохраняет текст hidden text в ADS NTFS с именем supersecret. Если после её выполнения открыть file.txt в текстовом редакторе, скрытого текста вы не увидите. Чтобы доказать, что он по-прежнему существует, следующей командой выведите основные данные текстового файла:

Затем выведите текст из ADS supersecret:

Второй вывод должен содержать данные из ADS. В более практическом сценарии вредоносная программа может сходным образом скрыть в ADS код или файл, например исполняемый. Следующая команда записывает вредоносный исполняемый файл evil.exe в поток данных evil файла invoice.doc:

С помощью этой команды автор записал исполняемый файл размером около 760 КБ в файл invoice.doc, как показано на рис. 15.6.

Рис. 15.6. Сокрытие исполняемого файла в ADS

Метаданные документа показывают размер файла 12 байт, то есть размер основного потока данных, а значение "размер на диске" составляет 776 КБ, полный размер файла после копирования исполняемого файла в его ADS.

При просмотре этого файла в шестнадцатеричном редакторе или средстве просмотра PE никаких аномалий не видно. Данные в потоке evil будут невидимы для большинства файловых редакторов и инструментов расследования, если только следователь не знает точно, что искать. Хорошим средством выявления аномалий ADS является Streams из набора Sysinternals.

Применение ADS NTFS представляет собой лишь один механизм сокрытия вредоносных файлов и кода от расследования. Другой метод заключается в сокрытии кода в подсистеме журналов CLFS, как показали исследователи Mandiant. См. статью Адриена Батая и Блейна Стэнсилла "Too Log; Didn't Read: Unknown Actor Using CLFS Log Files for Stealth": mandiant.com. Такие методы могут эффективно скрывать доказательства от внимательных пользователей и увеличивать время и трудозатраты на реагирование на инцидент и криминалистическое расследование, что выгодно авторам вредоносных программ.

Сокрытие данных с помощью стеганографии

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

Среди ранних примеров применения стеганографии вредоносными программами можно назвать семейство Duqu 2011 года, которое собирало сведения из систем жертв и сохраняло их в файле изображения JPEG, а также банковский троян Zeus 2014 года, скрывавший C2-команды в изображениях, отправляемых жертвам. Более свежий пример, обнаруженная исследователями ESET и получившая название Stegano атака, содержала код эксплойта, встроенный в изображения на различных сайтах. Возможно, вредоносный код остался незамеченным средствами сетевой защиты именно благодаря способу его сокрытия в данных изображения. См. статью Дэниела Гудина "Millions Exposed to Malvertising That Hid Attack Code in Banner Pixels": arstechnica.com.

Вредоносная программа может обращаться к стеганографии по множеству причин: скрывать данные и вредоносный код от следователей, обфусцировать передаваемые C2-команды или маскировать данные, которые предстоит эксфильтрировать из сети жертвы. Есть несколько способов добиться этого, в том числе дописывание файлов и манипуляции с битами. Дописывание файла, как следует из названия, заключается в простом добавлении одного файла в конец другого, словно он едет на нём пассажиром. Например, исследуя JPEG-файл, который кажется изменённым, автор мог бы проверить его заголовки в шестнадцатеричном редакторе, как на рис. 15.7.

Рис. 15.7. Заголовок файла JPEG

Этот заголовок является стандартным для файла JPEG, на рисунке указан JFIF. Дальнейший анализ данных файла выявляет аномалию, показанную на рис. 15.8.

Рис. 15.8. Заголовок файла, скрытый внутри файла JPEG

Обратите внимание на PK на рисунке. Это стандартный заголовок файла ZIP-архива, указывающий, что к JPEG-изображению мог быть дописан ZIP-файл. Извлечь его и исследовать содержимое можно несколькими способами. Во-первых, встроенный ZIP можно "вырезать" из изображения шестнадцатеричным редактором, просто скопировав подозрительные данные из файла и сохранив их в новый файл. Более простой вариант состоит в применении бесплатной утилиты Binwalk (github.com). Binwalk проходит по входному файлу, ищет признаки других встроенных файлов и может автоматически вырезать их. На рис. 15.9 показано, как Binwalk извлекает скрытый исполняемый файл surprise.exe из ZIP-контейнера, встроенного в JPEG-изображение.

Рис. 15.9. Вырезание встроенных файлов посредством Binwalk

ПРИМЕЧАНИЕ. Этот образец вредоносной программы можно найти в MalShare или VirusTotal по следующему хешу SHA256: 0cfcf571748f0d0c3bcedead2508f0bec329558c29017e7093a138853cc0e17e.

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

Рис. 15.10. Шестнадцатеричный дамп неизменённого изображения

Но злоумышленник коварно изменил это изображение, как видно на рис. 15.11.

Рис. 15.11. Шестнадцатеричный дамп изменённого изображения

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

После сохранения всех байтов в памяти они складываются в байтовую строку 89 E9 8D 55 05 FF D0. Её преобразование в код x86 даёт следующий ассемблерный код, вероятно являющийся разновидностью шелл-кода:

Наконец, метод наименее значащего бита (least significant bit, LSB) предполагает изменение определённых битов внутри файла. Чтобы проиллюстрировать этот метод стеганографии, предположим, что файл изображения содержит следующий набор из восьми байтов, каждый из которых представляет пиксель изображения:

В некоторых форматах кодирования изображений, например bitmap (BMP), LSB, то есть последний бит каждого байта, можно изменить без заметного влияния на изображение. Поэтому злоумышленник, желающий спрятать вредоносный код внутри изображения, мог бы изменить LSB и сформировать новую битовую строку. Представим, что злоумышленник изменил несколько выбранных LSB, выделенных полужирным:

11101100 11000110 10100110 10010111

10111001 10011000 10001100 11000111

Если объединить все LSB в новый байт, получится:

Сам по себе этот байт мало о чём говорит. Однако, изменив большое количество LSB в изображении, злоумышленник может эффективно скрыть внутри него вредоносный код или данные. Вредоносная программа способна хранить фрагменты своего кода или конфигурации в изображении, временно используя для этого LSB.

Наконец, существует множество общедоступных инструментов с открытым исходным кодом, например Steghide (steghide.sourceforge.net), упрощающих реализацию методов стеганографии. Такие средства полезно изучить, чтобы лучше понять, как работает стеганография и как авторы вредоносных программ могут злоупотреблять ею для сокрытия вредоносного кода и данных.

Вмешательство в журналы и доказательства

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

Вмешательство в журнал событий Windows

Вмешательство в журнал предполагает изменение или удаление с узла записей, которые могут выдать присутствие вредоносной программы. Один из источников, в который способен вмешаться злоумышленник, представляет собой журналы событий Windows. Они содержат сведения о различных событиях Windows и приложений и потому являются прекрасными источниками данных для следователей. На рис. 15.12 показано средство просмотра событий Windows Event Viewer, встроенная утилита Windows для изучения журналов событий.

Рис. 15.12. Просмотр системных журналов событий в Windows Event Viewer

Журналы событий Windows имеют общую структуру, включающую следующие сведения:

• идентификатор события, обозначающий тип произошедшего события;

• временную метку с датой и временем события;

• источник события, например конкретную программу или компонент, который его вызвал;

• описание события.

Кроме того, каждому событию назначается уровень:

• Информационный: общие сообщения, например сведения об установке или удалении программного пакета;

• Предупреждение: события, которые могут указывать на требующую устранения проблему;

• Ошибка: события вроде аварийного завершения приложения;

• Критический: события, наносящие ущерб работе системы.

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

Таблица 15.3. Типы событий, представляющие интерес для аналитиков безопасности и следователей

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

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

Либо вредоносная программа может воспользоваться командой PowerShell:

Эта команда стирает все записи журнала событий безопасности Windows.

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

Не забывайте, что удаление файлов журналов или остановка журналирования создаёт немало шума, особенно если пострадавшая организация целенаправленно отслеживает методы вмешательства в журналы. Другой подход состоит в ручной записи новых событий Windows, которые собьют следователей с толку. Например, создав событие о вымышленном входе либо об удалении или создании несуществующего файла, автор вредоносной программы может подбросить ложный след. Это можно сделать командлетом PowerShell Write-EventLog:

События Windows хранятся в виде файлов .evtx в каталоге C:\Windows\System32\winevt\Logs. Пример содержимого каталога показан в следующем выводе:

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

Этот вредоносный код ссылается на путь C:\Windows\System32\winevt\Logs 1, а затем вызывает функцию, шифрующую эти данные, которую автор назвал encrypt_data 2, фактически уничтожая файлы.

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

Этот метод выходит за рамки книги, но подробнее о нём можно прочитать в публикации Medium "Event Log Tampering Part 2: Manipulating Individual Event Logs": svch0st.medium.com.

ПРИМЕЧАНИЕ. Во время написания этой книги Kaspersky сообщил о варианте вредоносной программы, записывающем вредоносный код в журналы событий Windows и выполняющем его в памяти непосредственно из самих журналов. Этот метод сочетает вмешательство в журналы событий с резидентными в памяти методами. Подробнее см. публикацию Дениса Легезо "A New Secret Stash for 'Fileless' Malware" в блоге Kaspersky: securelist.com.

Подмена временных меток

Подмена временных меток, или timestomping, применяется для введения специалистов по компьютерной криминалистике в заблуждение посредством изменения временных меток файлов. В NTFS, стандартной файловой системе современных версий Windows, временная метка представлена 64-разрядным целым числом, более формально называемым структурой filetime, которое соответствует числу 100-наносекундных интервалов, или тиков, прошедших с 1 января 1601 года по UTC. Это звучит довольно сложно, но важно знать, что после преобразования в удобочитаемый формат данное целое число представляет конкретные дату и время. Например, целое значение временной метки 133346988430000000 можно преобразовать в строку Monday, July 24, 2023 7:00:43 PM. Внутри Windows для такого преобразования применяется функция FileTimeToSystemTime.

Формат NTFS отслеживает временные метки файлов и каталогов, отмечающие запись или иное изменение файла либо каталога, доступ к нему, то есть открытие и чтение, создание, включая копирование, перемещение и так далее, а также изменение метаданных файла или каталога. Метаданные могут включать имя, атрибуты, разрешения и прочие сведения. Подробнее о формате структуры filetime см. ntfs.com.

Чтобы изменить эти временные метки filetime и ввести следователей в заблуждение, вредоносная программа может воспользоваться специально предназначенной для этого функцией WinAPI SetFileTime. Она принимает три параметра: время создания файла (lpCreationTime), время последнего доступа (lpLastAccessTime) и время последнего изменения (lpLastWriteTime). Для вмешательства в собственные временные метки или метки других файлов и каталогов вредоносная программа может сходным образом применять функции SetFileInformationByHandle и NtSetInformationFile.

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

Уничтожение системы

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

Чтобы уничтожить доказательства атаки, вредоносная программа может зашифровать весь диск и главную загрузочную запись (Master Boot Record, MBR), сделав систему незагружаемой, как это делают некоторые программы-вымогатели. Главное различие состоит в том, что злоумышленник уничтожит ключи шифрования и расшифрования, поскольку они ему больше не нужны. Либо программа может перезаписать участки диска случайными данными и добиться сходного результата.

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

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

Полное уничтожение системы исключительно ради противодействия компьютерной криминалистике встречается редко. Гораздо чаще основной целью вредоносной программы является уничтожение систем и данных ради нарушения обслуживания, а противодействие криминалистике остаётся вторичной задачей. Например, семейство вредоносных программ Shamoon уничтожало данные в целевых системах, что в качестве побочного результата могло затруднить расследование. Другим примером служит HermeticWiper, кратко рассмотренный в главе 14.

Итоги

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

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

В частности, вредоносные программы применяют алгоритмы кодирования и шифрования по следующим причинам:

• для защиты кода и данных в своих файлах на диске, чтобы уклониться от средств защиты конечной точки, например anti-malware. Часто для этого применяется метод упаковки, подробно рассматриваемый в главе 17;

• для защиты кода и данных в памяти, например C2-адресов, ключей или конфиденциальных строк, от защитного программного обеспечения конечных точек и аналитиков;

• для защиты передаваемых данных на сетевом уровне, например посредством их шифрования перед отправкой в инфраструктуру C2;

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

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

Основы кодирования

Одной из самых распространённых форм кодирования является Base64, изначально разработанная для передачи данных и обеспечения совместимости различных протоколов. Когда строка проходит через алгоритм кодирования Base64, она подаётся в него как двоичные данные и разбивается на 6-битовые блоки. Затем каждый блок преобразуется, кодируется, в формат ASCII с применением всего 64 различных символов: 26 строчных букв, 26 прописных букв, 10 цифр, а также символов / и +. От этого 64-символьного набора, показанного в табл. 16.1, Base64 и получила своё название. В таблице приведены символ (Симв.), десятичное значение (Дес.) и двоичное значение (Двоич.) каждого символа Base64.

Таблица 16.1. Набор символов Base64

Обратите внимание на знак равенства (=), который применяется как заполнитель и потому не считается одним из 64 символов. Если при анализе кода вредоносной программы вы заметили строку символов, за которой следуют один или несколько знаков равенства, у вас должен сработать внутренний сигнал: возможно, перед вами разновидность данных, закодированных в Base64. Учтите, что символ заполнения присутствует не всегда.

Набор символов Base64 часто жёстко задан во вредоносной программе:

Если в коде встречается похожая индексная строка, можно предположить, что вредоносная программа применяет разновидность Base64. Скоро мы вернёмся к этому вопросу.

Чтобы лучше понять практический вид кодирования Base64, рассмотрим пример со входной строкой evil. После преобразования в двоичный вид ASCII-строка evil выглядит так:

При обработке ASCII-строки evil алгоритмом Base64 символы ASCII преобразуются в двоичный вид, двоичная строка разбивается на 6-битовые блоки, а каждый блок сопоставляется с одним из символов набора Base64. Для строки evil блоки и значения выглядят следующим образом:

Полученная здесь строка Base64 равна ZXZpbA. Однако большинство реализаций Base64 группируют вывод наборами по шесть символов и, если в конце закодированной строки остаётся нечётное число символов, добавляют необходимое заполнение. В данном случае блок 6 неполон, поэтому в качестве заполнения добавляется ==, а окончательный результат имеет вид ZXZpbA==.

Полное обсуждение Base64 выходит за рамки этой книги. Более подробное объяснение технических особенностей алгоритма см. по адресу en.wikipedia.org.

Base64 широко применяется в законных целях, но вредоносная программа может использовать её и как быстрый и грубый способ добиться более зловещей цели: обфускации данных. Base64 и подобные алгоритмы кодирования позволяют скрыть вредоносное поведение или строки в самом файле либо в памяти. Преимущество таких алгоритмов состоит в необычайной простоте реализации. Недостаток в том, что их столь же легко "взломать": достаточно декодировать целевые данные тем же способом, которым они были закодированы. Base64 можно декодировать множеством методов и инструментов, один из которых, CyberChef (github.com), вскоре будет рассмотрен.

Существует много отличных инструментов, помогающих выявлять применение Base64 во вредоносных программах. Например, base64dump.py (github.com) представляет собой сценарий Python Дидье Стивенса, который сканирует входной файл и пытается найти в нём закодированные данные. Он перечисляет обнаруженные закодированные строки и показывает их декодированные значения, позволяя аналитику быстро выявлять подозрительные данные. Вывод этого инструмента представлен на рис. 16.1.

Рис. 16.1. Просмотр закодированных в Base64 строк двоичного файла в base64dump.py

Обратите внимание на возможную декодированную строку в строке 4 (homesshealth.inf). Также видна часть закодированного значения. Чтобы полностью исследовать эту декодированную строку, её можно выгрузить, то есть извлечь и сохранить на диск, посредством ключей -d (dump) и -s (section) программы base64dump.py, указав номер интересующего раздела, в данном случае 4:

Учтите, что авторы вредоносных программ могут легко изменить стандартное кодирование Base64, чтобы затруднить обратное преобразование своих данных. Даже простое изменение набора символов Base64 радикально меняет результат. Рассмотрим, например, следующую модифицированную индексную строку:

Сравните её с упомянутым ранее исходным набором символов Base64:

Заметили различие? В первом наборе символы abcd перемещены в начало, перед ABCD. Одно лишь перемещение abcd в начало индекса радикально изменяет результат кодирования Base64, а выполнить такое изменение очень легко. Для выявления подобных модификаций можно искать индексную строку в коде, как уже упоминалось. Довольно часто индекс Base64 хорошо виден в коде исполняемого файла вредоносной программы.

Наконец, помните о других кодировках, которые могут встретиться при анализе вредоносных программ, например Base32, Base85, uuencode и yEnc, хотя они распространены меньше. Время, потраченное на изучение способов выявления и декодирования Base64, поможет в подавляющем большинстве случаев простого кодирования данных вредоносной программы. Авторы вредоносных программ довольно часто кодируют PE-файлы в Base64. Поскольку заголовок PE-файла содержит ASCII-символы MZ, обращайте внимание на закодированный вариант MZ, начинающийся с TV.

Хеширование данных

По сути, хеширование представляет собой одностороннее кодирование данных, то есть теоретически необратимое. При обработке данных алгоритмом хеширования полученный хеш всегда имеет одну и ту же длину. Например, алгоритм MD5 всегда создаёт хеш фиксированной длины 128 бит, или 32 символа. SHA-1 выдаёт хеш длиной 160 бит, или 40 символов. Наконец, SHA256 выдаёт значение длиной 256 бит, или 64 символа.

Посмотрим, как хеширование данных выглядит на практике, с помощью упомянутого выше CyberChef. На рис. 16.2 автор применил CyberChef и MD5 для хеширования простого URL, получив показанное в поле Output 32-символьное значение.

Рис. 16.2. Хеширование MD5 посредством CyberChef

На рис. 16.3 автор изменил в URL один символ.

Рис. 16.3. Изменение входного URL в CyberChef

Можно заметить, что автор просто добавил s к строке http. Обратите внимание, что результат хеширования полностью изменился. Этот эффект, при котором разные входные данные, даже совпадающие на 99 процентов, дают резко отличающиеся значения хеша, называется каскадированием. При каскадировании входные данные разделяются на группы символов, а затем эти группы делятся дальше.

ПРИМЕЧАНИЕ. В различных примерах на протяжении оставшейся части главы мы будем применять CyberChef. Это прекрасный универсальный инструмент для операций с данными, полезный далеко не только для хеширования. Рекомендуется познакомиться с его возможностями.

Вредоносные программы также могут использовать возможности хеширования для обфускации, причём реализовать алгоритмы хеширования в коде можно несколькими способами. Один из них основан на штатном Windows CryptoAPI. Эта служба предоставляет программам, в нашем случае вредоносным, простой в использовании API для кодирования, декодирования, шифрования и расшифрования данных. CryptoAPI и пример его применения во вредоносной программе будут рассмотрены далее в этой главе. Второй возможный способ заключается в создании авторами вредоносных программ собственных алгоритмов хеширования. В статье "Windows API Hashing in Malware" из блога Red Team Experiments (ired.team) описан небольшой фрагмент специального кода, которым можно хешировать импортируемые функции API, скрывая их имена от специалистов по обратной разработке и средств защиты узла.

В зависимости от применяемого алгоритма справиться с хешированием при обратной разработке вредоносной программы бывает трудно. Можно попытаться перебрать входные данные инструментом взлома хешей, сравнивая результат хеш-функции с заранее вычисленным словарём известных входных и соответствующих им выходных значений. Для известных алгоритмов существуют инструменты и ресурсы с предварительно вычисленными хешами распространённых строк из вредоносных программ. Например, OALabs создала инструмент hashdb (github.com) и сопутствующий плагин IDA Pro hashdb-ida (github.com), представляющий собой базу распространённых строк вредоносных программ. Это прекрасное средство для запроса неизвестного значения хеша, встреченного во вредоносной программе, и получения исходной, "нехешированной" строки. Инструмент поддерживает распространённые хеши, например CRC-32 и ROR-13, а также специальные реализации хеширования из конкретных семейств вредоносных программ, таких как GuLoader и Lockbit.

Если вредоносная программа применяет неизвестный специальный алгоритм хеширования, задача усложняется. Чтобы понять, какие данные она хешировала, сначала нужно разобраться в окружающем их контексте. Возможно, придётся сделать обоснованные предположения об исходных строках на основе соседних данных. Например, если видны открытые строки функций CreateProcess и VirtualAlloc, то окружающие их обфусцированные строки могут относиться к функциям внедрения в процессы вроде WriteProcessMemory или CreateRemoteThread. Другой подход состоит в обратной разработке самого алгоритма хеширования для получения исходных входных данных. Сначала понадобится найти алгоритм в коде, а затем проанализировать его статически в дизассемблере или динамически в отладчике. Далее мы кратко рассмотрим поиск такого кода применительно к шифрованию.

Шифрование и расшифрование

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

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

Симметричное и асимметричное шифрование

Существуют две основные формы шифрования: симметричная и асимметричная. Симметричное шифрование предполагает применение двумя клиентами общего, симметричного, ключа. Если клиент 1 хочет отправить данные клиенту 2, ключ шифрования должен быть у обоих клиентов, поскольку он применяется как для шифрования, так и для расшифрования данных. Когда вредоносная программа пользуется симметричным шифрованием, ключ либо встроен в её код, либо создаётся на лету, например посредством стандартных библиотек Windows. К распространённым видам симметричного шифрования относятся AES, DES, Blowfish и RC4. Общая схема симметричного шифрования и расшифрования показана на рис. 16.4.

Рис. 16.4. Работа криптографии с симметричным ключом

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

Существуют две основные формы алгоритмов симметричного шифрования. Поточные шифры шифруют данные по одному биту и зачастую работают очень быстро. Они применяются в таких протоколах, как SSL/TLS, для шифрования веб-трафика. Блочные шифры шифруют данные порциями, блоками, и обычно обеспечивают более стойкое шифрование, чем поточные. Из этих двух видов они также используются чаще, особенно в задачах, где скорость не является главным требованием.

В отличие от симметричного, асимметричное шифрование применяет два ключа вместо одного: открытый для шифрования и закрытый для расшифрования. Если клиент 1 хочет зашифровать и отправить данные клиенту 2, клиент 2 сначала должен передать клиенту 1 свой открытый ключ, которым тот зашифрует данные. Затем клиент 2 расшифрует их собственным закрытым ключом. И наоборот, когда клиент 2 хочет зашифровать данные для клиента 1, он шифрует их открытым ключом клиента 1, а клиент 1 расшифровывает собственным закрытым ключом. Благодаря этому отпадает необходимость в безопасном обмене ключами: открытые ключи предназначены для передачи и обмена, а закрытые остаются тайными. Асимметричное шифрование и расшифрование показано на рис. 16.5.

Рис. 16.5. Работа криптографии с асимметричным ключом

Как и на рис. 16.4, открытые данные обрабатываются алгоритмом шифрования, но на этот раз асимметричным. Открытый ключ шифрует данные, а закрытый отвечает за их расшифрование обратно в исходный открытый вид.

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

В табл. 16.2 перечислены некоторые распространённые алгоритмы шифрования, встречающиеся во вредоносных программах.

Таблица 16.2. Криптографические алгоритмы, встречающиеся во вредоносных программах

Прежде чем подробно рассматривать несколько наиболее распространённых способов применения алгоритмов шифрования во вредоносных программах, необходимо познакомиться с важным компонентом шифрования: XOR.

Исключающее ИЛИ

Многие алгоритмы шифрования строятся вокруг операции "исключающее ИЛИ" (exclusive or, XOR), поэтому важно понимать принцип её работы. При XOR входные данные побитово сравниваются с заданным ключом. В табл. 16.3 показан пример сравнения битов входов A и B, дающего выходное значение.

Таблица 16.3. Двоичный результат XOR

Как видите, если биты входов A и B равны, результат равен 0. Если они различаются, результат равен 1.

Данные обрабатываются XOR на основе ключа, который иногда имеет длину 1 байт, хотя её можно менять, как вы скоро увидите. Рассмотрим операцию XOR в табл. 16.4, где применяется однобайтовый ключ 0x35.

Таблица 16.4. Результат XOR с ключом 0x35

В строке "Входной текст" ASCII-строка https обрабатывается XOR с ключом 0x35. В строке двоичного входа показан двоичный эквивалент строки https. В строке ключа XOR (35) приведён ключ 0x35 в двоичном виде (00110101). Строка двоичного результата содержит данные после завершения операции XOR. Наконец, в строке выходного текста показано ASCII-представление результата. Учтите, что XOR обратима: чтобы расшифровать выходной текст, достаточно снова обработать его XOR с тем же ключом 0x35, и получится https.

Это лишь простой пример с однобайтовым ключом XOR, но на практике вредоносные программы часто усложняют шифрование более длинным ключом. Например, если программа применяет пятибайтовый ключ 0x356C2DA155, показанный в табл. 16.5, каждый байт ключа последовательно, начиная с первого, обрабатывается XOR с каждым байтом входных данных.

Таблица 16.5. Результат XOR с ключом 0x356C2DA155

Теперь ASCII-строка https обрабатывается XOR с ключом 0x356C2DA155, который для простоты разбит на несколько столбцов. Каждый байт ключа обрабатывается XOR с одним из байтов текста. Двоичный результат показан в четвёртой строке, а за ним следует текстовое представление результата XOR. Более полное объяснение технических тонкостей операций XOR см. по адресу en.wikipedia.org.

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

Существует несколько инструментов для такого перебора. Например, XORSearch Дидье Стивенса (blog.didierstevens.com) ищет строки во входном файле, пробует различные ключи XOR и другие кодировки, а затем выводит результаты. Автор пропустил исполняемый файл через XORSearch и получил результат, показанный на рис. 16.6.

Рис. 16.6. Вывод инструмента XORSearch

Команда в первой строке содержит два параметра: -p указывает XORSearch искать именно закодированные PE-файлы, а ключ -s предписывает выгрузить найденный исполняемый файл. В этом файле встроено ещё пять исполняемых файлов, четыре из которых закодированы XOR; первый результат можно игнорировать, поскольку он содержит лишь PE-заголовок входного файла. XORSearch показывает ключ XOR, выделенный в столбце 1, и адрес смещения встроенного файла, выделенный в столбце 2.

XOR легко заметить во вредоносной программе с помощью дизассемблера или отладчика: соответствующая инструкция называется просто xor. Загрузив образец в IDA Pro, перейдите в меню Search > Text, введите xor как строку поиска и нажмите Find All Occurrences. Пример вывода представлен на рис. 16.7.

Рис. 16.7. Просмотр инструкций xor в IDA Pro

Первая операция XOR на рисунке нас не интересует. Обработка регистра XOR с самим собой просто очищает регистр, устанавливая его в 0. Это самое распространённое применение XOR в исполняемых файлах, и оно не связано непосредственно с шифрованием.

Нас интересуют три нижние операции xor. В этих примерах регистр процессора обрабатывается XOR с адресом памяти. В инструкции xor al, [edx] al является регистром, а [edx] адресом памяти. В таком случае регистр часто содержит ключ XOR, применяемый к данным в памяти. Но возможна и обратная ситуация.

Обнаружив XOR в коде, данные можно расшифровать, найдя целевые зашифрованные данные и ключ XOR. В случае xor al, [edx] можно исследовать регистр al в поисках ключа XOR. Кроме того, исследование указателя памяти в EDX, скорее всего, приведёт к данным, обрабатываемым XOR. В этом помогает динамический анализ вредоносной программы в отладчике.

Найдя данные и ключ XOR, можно скопировать данные из файла и обработать их XOR с этим ключом. Для этого подходит множество инструментов, но мы снова воспользуемся CyberChef. На рис. 16.8 показано его применение с ключом XOR 1A2D3F.

Рис. 16.8. Декодирование XOR в CyberChef

Вредоносная программа часто расшифровывает обработанные XOR данные и код в памяти непосредственно перед выполнением. Один из приёмов обратной разработки заключается в том, чтобы позволить программе самой расшифровать эти данные, а затем получить их. Это можно сделать отладчиком, как будет рассмотрено в разделе "Расшифрование зашифрованных данных вредоносной программы" на странице 339 оригинала.

Кроме инструкции xor, некоторые вредоносные программы применяют для обфускации кода и данных несколько других базовых методов, например ror (циклический сдвиг вправо) и rol (циклический сдвиг влево), просто перемещающие байты на заданное число позиций в соответствующем направлении. Рассмотрим инструкцию ror eax, 5. Если EAX содержит значение 12345678, после циклического сдвига всех цифр на пять позиций вправо новым значением станет 45678123. Все цифры сдвинулись на пять позиций вправо, а "вытолкнутые" с конца цифры 4, 5, 6, 7 и 8 оказались в начале строки. Инструкция rol обращает эту операцию.

Rivest Cipher 4

Rivest Cipher 4, или RC4, является одним из наиболее распространённых поточных алгоритмов шифрования во вредоносных программах, поскольку прост в реализации и сравнительно стоек, если сравнивать с базовым кодированием вроде Base64 или даже XOR. Основные этапы его работы показаны на рис. 16.9.

Рис. 16.9. Общая схема работы RC4

Сначала алгоритм создаёт массив значений длиной 256 байт, или 0x100 в шестнадцатеричном виде, называемый Sbox. Это Sbox 1. Затем инициализируется другой Sbox, Sbox 2, содержащий ключ шифрования. Длина ключа RC4 может составлять от 1 до 256 байт. Ключ может быть жёстко задан в исполняемом файле вредоносной программы или создаваться динамически.

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

При работе с процедурами шифрования и расшифрования в коде некоторые алгоритмы удаётся легко распознать. 256-байтовый массив является характерным признаком RC4. Скорее всего, в коде неоднократно встретится значение 0x100, за которым следуют циклы, как в следующем фрагменте:

Этот пример показывает, как RC4 может выглядеть в образце вредоносной программы. Первый блок кода инициализирует массив Sbox 1 и выполняет сравнение с 0x100 1. Обратите внимание на переход обратно к началу функции 2, указывающий на цикл. Во втором блоке снова встречается 0x100, относящееся к Sbox 2, последующая операция сравнения 3 и цикл 4. Два таких цикла в коде часто выдают применение RC4.

Windows CryptoAPI

Windows предоставляет собственную реализацию множества распространённых алгоритмов шифрования, Microsoft Cryptography API (CryptoAPI). Этот API поддерживает многие распространённые симметричные и асимметричные алгоритмы шифрования, а также другие службы, например цифровые сертификаты и хеширование. CryptoAPI также включает появившееся в Windows Vista обновление Cryptography API: Next Generation (CNG). CNG содержит новейшие криптографические библиотеки Windows, добавляя поддержку современных алгоритмов и специальных криптографических API. В новых версиях Windows CNG в значительной степени заменяет CryptoAPI. Хотя CryptoAPI объявлен устаревшим, его важно рассмотреть: вредоносные программы по-прежнему активно используют его благодаря долгой истории и хорошей изученности.

Функции CryptoAPI

При инициализации CryptoAPI одной из ключевых функций, которую обязаны вызвать приложения, является CryptAcquireContext. Она возвращает дескриптор поставщика криптографических служб (cryptographic service provider, CSP), модуля, выполняющего функции шифрования и расшифрования и хранящего связанные ключи. Поскольку CSP являются неотъемлемой частью некоторых программ Windows, они строго контролируются. Приложения не получают прямого доступа к внутреннему устройству CSP; всё выполняется косвенно посредством вызовов функций API.

В табл. 16.6 описаны CryptAcquireContext и некоторые другие важные функции CryptoAPI.

Таблица 16.6. Важные функции CryptoAPI

Наиболее интересные функции в этой таблице, CryptEncrypt и CryptDecrypt. CryptEncrypt принимает множество параметров, в том числе дескриптор ключа шифрования, созданного посредством CryptGenKey или CryptImportKey, и указатель на буфер открытых данных, которые предстоит зашифровать. Если анализируемый образец вредоносной программы выполняет криптографические операции и вызывает CryptEncrypt для шифрования данных, можно установить в отладчике точку останова на этой функции и исследовать буфер открытого текста, что раскроет шифруемые данные. Пример будет приведён далее в этой главе.

Разработчики часто создают обёртки вокруг криптографических функций, чтобы упростить реализацию: тогда им не приходится вызывать каждую функцию напрямую, а число программных ошибок уменьшается. Это заслуживает внимания, поскольку некоторые авторы вредоносных программ вызывают криптографические библиотеки непосредственно из своего кода вместо множества доступных обёрток. Разработчики вредоносных программ тоже люди и склонны ошибаться, поэтому прямой вызов криптографических функций Windows может создать проблемы для неопытного автора. В одном семействе программ-вымогателей, CryptoLocker, была ошибка реализации алгоритма RSA, позволявшая легко расшифровывать захваченные файлы. Исследователи Emsisoft обнаружили, что CryptoLocker неправильно применяла CryptAcquireContext. Один из параметров этой функции принимает значения флагов, включающие дополнительные возможности. Необходимо установить флаг CRYPT_VERIFYCONTEXT, иначе созданный закрытый ключ шифрования сохраняется на локальном узле. Для CryptoLocker это оказалось серьёзной проблемой. Если ключ расшифрования хранится локально, знающая, где искать, жертва легко восстановит свои файлы. Именно это сделала Emsisoft, восстановив файлы множества жертв. Подробнее см. публикацию "CryptoDefense: The Story of Insecure Ransomware Keys and Self-Serving Bloggers" в блоге Emsisoft: emsisoft.com.

Windows CryptoAPI довольно сложен и включает множество различных функций. Гораздо более подробные сведения о его возможностях приведены в прекрасной статье Microsoft "CryptoAPI System Architecture" на MSDN: learn.microsoft.com.

Практический анализ CryptoAPI

Теперь посмотрим, как Windows CryptoAPI выглядит на практике, а именно исследуем реализацию алгоритма хеширования. Этот образец вредоносной программы получает имя DNS-домена, в который входит система жертвы, хеширует его и сравнивает результат с жёстко заданным хешем имени целевого домена. Если хеши не совпадают, то есть домен жертвы не соответствует целевому, вредоносная программа не заражает систему. Кроме того, хранение жёстко заданного имени домена в хешированном виде значительно затрудняет, если не делает невозможным, обнаружение искомого домена специалистом по обратной разработке. Рассмотрим следующий псевдокод:

Сначала вредоносная программа определяет имя целевого домена victimcompany.com. SHA256-хеш этой строки равен 4b557a3281181193f1b1fae7228314e77d174fa13b59f606c5400409f13875a2 и сохраняется в переменной hashedTargetDomain 1. Затем программа вызывает GetComputerNameExA с параметром ComputerNameDnsDomain, чтобы получить домен заражённой жертвы, который будет сохранён в буфере памяти domainName 2. После этого вызывается CryptAcquireContextA 3 со следующими параметрами: указателем на область памяти для дескриптора CSP, именем контейнера ключей, здесь NULL, используемым CSP, где NULL означает стандартного поставщика Windows, типом поставщика 0x18, или Microsoft Enhanced RSA and AES Cryptographic Provider, и параметром флагов. Большинство этих параметров здесь несущественны. Наиболее важен тип криптографического поставщика: Microsoft Enhanced RSA and AES Cryptographic Provider поддерживает множество форматов хеширования и шифрования.

ПРИМЕЧАНИЕ. Полный список поддерживаемых Microsoft типов см. на странице "Cryptographic Provider Types": learn.microsoft.com.

Получив дескриптор контейнера ключей, вредоносная программа вызывает CryptCreateHash, чтобы создать дескриптор объекта хеша 4. Этот объект необходимо создать до вычисления хеша. Функция принимает дескриптор только что созданного поставщика криптографических служб (hCSP), идентификатор алгоритма (0x800C, или CALG_SHA_256), ключ хеша, необязательное значение флагов и указатель на дескриптор нового объекта хеша (hHash). Поскольку в параметре идентификатора алгоритма передаётся CALG_SHA_256, можно заключить, что программа применяет алгоритм SHA256.

Чтобы наконец получить хеш домена жертвы, вредоносная программа вызывает CryptHashData, создавая хеш строки домена 5. Ей передаются дескриптор ранее созданного объекта хеша (hHash), указатель на буфер хешируемых данных (domainName), длина хешируемых данных и необязательное значение флагов. После вызова функции хешированное значение имени домена сохраняется в объекте хеша.

Для извлечения хешированных данных вредоносная программа должна вызвать CryptGetHashParam 6. Эта функция принимает дескриптор объекта хеша (hHash), тип запроса, то есть вид запрашиваемых данных, например размер или значение хеша, указатель на буфер для результата, размер возвращаемых данных и необязательное значение флагов. Программа вызывает CryptGetHashParam дважды: первый раз получает размер хешированных данных, второй раз сами данные, то есть хеш имени домена жертвы. Ближе к концу функции она вызывает CryptDestroyHash, уничтожая объект хеша 7, и CryptReleaseContext, освобождая дескриптор контейнера ключей и CSP 8. Это стандартные функции очистки.

Наконец, вредоносная программа должна сравнить жёстко заданный хеш с хешем имени домена жертвы, чтобы определить, является ли жертва нужной целью. Для этого она вызывает memcmp, или сравнение памяти, функцию сравнения двух значений в памяти 9. Сравниваются hashedDomainName и hashedTargetDomain. Если значения совпадают, то есть узел входит в целевой домен вредоносной программы, она продолжает заражение. Если нет, программа завершает себя.

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

Windows Cryptographic API: Next Generation

Поскольку CNG является всего лишь обновлением CryptoAPI, функционально они очень похожи. Однако почти все функции CNG имеют префикс B, что помогает различать два API. Например, CryptEncrypt относится к CryptoAPI, а BCryptEncrypt к CNG. В табл. 16.7 перечислены некоторые распространённые функции CNG, которые могут встретиться во вредоносной программе.

Таблица 16.7. Важные функции CNG

Из-за сходства с CryptoAPI далее CNG подробно не рассматривается. Дополнительные сведения см. на странице "Cryptography API: Next Generation" в базе знаний Microsoft: learn.microsoft.com.

Теперь перейдём к практическим рекомендациям по преодолению шифрования во вредоносных программах.

Практические рекомендации по преодолению шифрования во вредоносных программах

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

Поиск и выявление криптографических процедур

В целом существует несколько способов найти и распознать алгоритмы шифрования во вредоносной программе. Во-первых, можно искать в коде поведение, соответствующее определённому алгоритму. Например, в RC4 два 256-байтовых массива (0x100) и связанные с ними циклы, как отмечалось ранее, часто являются безошибочным признаком. Можно также проверить код на распространённые инструкции криптографических алгоритмов, например xor и rol. Это более общий подход, но он полезен для поиска многих видов алгоритмов и даже специальных реализаций. Наконец, показательными могут быть вызовы функций CryptoAPI или CNG, например CryptEncrypt.

Существует несколько инструментов, способных значительно помочь в поиске и распознавании криптографических процедур. CAPA, представленная в главе 3, выполняет базовый анализ кода двоичного файла и выдаёт много полезных сведений, направляющих ручной анализ кода образца. CAPA также умеет находить применяемые во вредоносной программе криптографические алгоритмы, как показано на рис. 16.10.

Рис. 16.10. Просмотр применения RSA в CAPA

Здесь видно, что образец, являющийся вариантом семейства программ-вымогателей Ryuk, применяет асимметричное шифрование RSA. CAPA даже показывает расположение этих данных в коде, функцию 0x13F4E6018. Аналогичным образом на рис. 16.11 CAPA обнаружила шифрование RC4 в другом образце.

Рис. 16.11. Просмотр применения RC4 в CAPA

В этом фрагменте CAPA выявила код шифрования в образце вредоносной программы. В частности, обнаружен код, возможно относящийся к RC4, а также несколько связанных вызовов CryptoAPI: CryptDeriveKey, CryptAcquireContext и CryptDecrypt.

Для дизассемблеров IDA Pro и Ghidra доступны плагины поиска и распознавания криптографических процедур. CAPA является более независимым инструментом, которому не нужен дизассемблер, однако преимущество плагинов дизассемблеров в возможности быстро исследовать код с интересующими криптографическими функциями.

Два плагина для IDA Pro:

• FindCrypt2 (hex-rays.com);

• IDA Signsrch (github.com).

И два плагина для Ghidra:

• FindCrypt (github.com);

• FindCrypt, более свежая обновлённая версия (github.com).

Первый плагин FindCrypt для Ghidra в действии показан на рис. 16.12.

Рис. 16.12. Поиск кода шифрования плагином FindCrypt для Ghidra

FindCrypt обнаружил два возможных алгоритма хеширования, SHA-1 и MD4, и вывел смещение кода, где могут находиться данные. Помните, что подобные инструменты с открытым исходным кодом постоянно меняются: разработчики могут в любой момент прекратить их поддержку. Лучше постоянно искать новые инструменты и плагины для анализа вредоносных программ.

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

Сначала загружаются данные для шифрования или расшифрования, как правило посредством операции mov. Следующий код вредоносной программы перемещает данные (ebp+encrypted_data) в регистр (ebx):

Затем над данными выполняются вычисления. Они почти всегда включают циклы в коде, возможно математические инструкции, например add, sub, mul, imul и div, а также инструкции xor или сдвига, такие как shl, shr и другие:

Наконец, изменённые данные сохраняются для последующего применения:

В данном случае вредоносная программа помещает только что расшифрованные данные в стек 1. Скорее всего, здесь также будет один или несколько циклов и счётчик цикла 2, который вернётся к инструкции чтения данных и загрузит следующую порцию для расшифрования 3.

Что же делать после обнаружения зашифрованных данных?

Расшифрование зашифрованных данных вредоносной программы

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

Статическое расшифрование

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

Для статического расшифрования сначала необходимо определить применяемый алгоритм и требуемые ключи, которые часто жёстко заданы во вредоносной программе или находятся в памяти. Автоматизировать такие задачи можно посредством Python API PyCrypto (pypi.org). Кроме того, CyberChef является отличным инструментом декодирования множества типов данных и помогает быстро расшифровать найденные во вредоносной программе данные.

Динамическое расшифрование

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

Рассмотрим два сценария анализа, которые познакомят вас с некоторыми приёмами быстрого динамического расшифрования секретов вредоносной программы. Это общие методы, работающие независимо от применяемого алгоритма шифрования.

Перехват расшифрованного кода и данных

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

ПРИМЕЧАНИЕ. В примере используется исполняемый файл вредоносной программы, который можно загрузить из VirusTotal или MalShare по хешу SHA256: db136799d9e0854fdb99b453a0ebc4c2a83f3fc823c3095574832b6ee5f96708.

Сначала загрузите образец в выбранный дизассемблер. Автор использовал IDA Pro. Чтобы определить применяемый алгоритм шифрования и найти код расшифрования, можно воспользоваться CAPA или просто выполнить поиск операций xor средствами дизассемблера. Часть результатов поиска XOR в IDA Pro показана на рис. 16.13.

Рис. 16.13. Просмотр инструкций xor в IDA Pro

В этом исполняемом файле много инструкций xor, большинство из которых безобидны. Помните, что обработка регистра XOR с тем же регистром просто очищает его. Поэтому xor eax, eax, xor ecx, ecx и xor edx, edx нас не интересуют. Дважды щёлкнем запись xor [esi], al и исследуем её. Результат показан на рис. 16.14.

Рис. 16.14. Просмотр процедуры шифрования в IDA Pro

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

Если исследовать блоки кода выше текущей функции, можно заметить дополнительные признаки применения криптографии. Здесь есть инструкция cmp ebx, 100h и, судя по всему, ещё один цикл, как показано на рис. 16.15.

Рис. 16.15. Просмотр цикла RC4 в IDA Pro

Кроме того, по смещению 0x0045B684 находится ещё один цикл и инструкция cmp ebx, 100h, показанные на рис. 16.16.

Рис. 16.16. Ещё один цикл RC4 в IDA Pro

Всё указывает на RC4. Теперь, когда мы, по всей вероятности, нашли применяемую процедуру шифрования, можно определить место кода, где данные окажутся полностью расшифрованы, установить в отладчике точку останова на этом адресе и дождаться, пока программа расшифрует данные за нас. Сначала нужно определить место точки останова. Текущая функция называется sub_45B794. Если выбрать её в дизассемблере или графическом представлении IDA Pro и нажать X, появится список перекрёстных ссылок, то есть других функций, вызывающих sub_45B794. Дважды щёлкните функцию из списка.

Вы должны увидеть инструкцию lea ebx, [ebp+var_BEEP], как показано здесь:

Эта инструкция lea загружает адрес в регистр EDX. Она интересна тем, что идёт непосредственно после только что исследованной функции расшифрования RC4 (sub_45B5AC). Адрес инструкции lea равен 0045B850, поэтому это подходящая цель для точки останова в отладчике.

Для отладки автор использовал x64dbg. Также можно воспользоваться встроенным отладчиком IDA Pro или любым другим. Загрузите образец в отладчик, выберите Run to User Code, чтобы перейти к началу кода вредоносной программы, установите точку останова на интересующем коде (bp 0045B850) и запустите выполнение клавишей F9. Конкретно этот образец перед выполнением интересующего кода спит около 10 секунд, как показано на рис. 16.17.

Рис. 16.17. Установка точки останова на расшифрованном коде в x64dbg

После срабатывания точки останова щёлкните правой кнопкой [ebp-BEEP] и выберите Follow in Dump > Address: EBP-BEEP. Теперь в окне Dump должны появиться расшифрованные данные, как на рис. 16.18.

Рис. 16.18. Просмотр выгруженного расшифрованного кода в x64dbg

К сожалению, эти данные нелегко прочитать человеку. Исследуем их подробнее. Чтобы извлечь данные, щёлкните правой кнопкой окно Dump и выберите Follow in Memory Map. Затем щёлкните правой кнопкой выделенную область памяти, которая будет подсвечена серым в окне Memory Map, и выберите Dump Memory to File.

Если выполнить для файла команду strings или воспользоваться утилитой просмотра PE-строк вроде PEStudio, найдётся несколько строк, но ничего особенно интересного. Однако инструмент деобфускации строк FLOSS, который вы можете помнить по главе 2, позволяет деобфусцировать часть данных. Запустить FLOSS можно так:

Здесь FLOSS предписывается считать файл 32-разрядным шелл-кодом. В следующем выводе инструмент восстановил 52 строки стека:

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

Перехват кода и данных до шифрования

Вредоносные программы часто применяют шифрование для обфускации сетевого трафика, например коммуникаций с C2-сервером. Образец на рис. 16.19 вызывает BCryptEncrypt, чтобы зашифровать свои сведения C2 перед отправкой управляющей инфраструктуре. Для перехвата открытых данных автор просто установил точку останова на BCryptEncrypt.

Рис. 16.19. Установка точки останова на BCryptEncrypt в x64dbg

ПРИМЕЧАНИЕ. Этот образец можно найти в MalShare или VirusTotal по хешу SHA256: b2562b0805dd701621f661a43986f9ab207503d4788b655a659b61b2aa095fce.

В случае BCryptEncrypt второе значение в стеке является указателем на буфер с открытыми данными, которые предстоит зашифровать. По-видимому, эти данные представляют имя узла виртуальной машины автора, как показано на рис. 16.20.

Рис. 16.20. Просмотр данных для шифрования в x64dbg

Помните, что функции CryptEncrypt и BCryptEncrypt шифруют данные, а CryptDecrypt и BCryptDecrypt расшифровывают. Аналитику вредоносных программ очень полезно знать эти функции. Просто установите на них точку останова в отладчике, позвольте функции выполниться и исследуйте буфер с данными: этим вы сэкономите себе массу усилий по анализу.

Итоги

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