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

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

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

Теоретически вредоносную программу можно написать на любом языке программирования, включая C, C++, C#, Python, Go, PowerShell и Rust. Однако существует несколько причин, по которым одни языки программирования популярнее других при разработке вредоносного ПО.

Например, простейшая вредоносная программа на C выглядит так, как показано в файле GitHub.

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

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

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

Она создаёт новый поток выполнения и запускает в нём полезную нагрузку:

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

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

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

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

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

Таким образом, владение C/C++ становится мощным преимуществом на непрерывно меняющемся поле кибервойны, где понимание и имитация возможностей противника служат ключом к созданию надёжной и устойчивой защиты.

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

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

Ниже приведены краткие описания некоторых распространённых вариантов поведения вредоносного ПО:

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

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

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

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

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

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

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

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

Обратная оболочка может использовать стандартные исходящие порты, например 80, 443, 8080 и другие.

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

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

Для создания обратной оболочки требуется три этапа:

1. Сначала противник эксплуатирует недостаток системы или сети, позволяющий выполнить код на целевой машине.

2. Затем противник запускает прослушивающую программу в собственной системе.

3. После этого противник эксплуатирует уязвимость, внедряя обратную оболочку в уязвимую систему.

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

Прежде всего напишем простейшую обратную оболочку для машин под управлением Linux: GitHub.

Подробно разберём, что делает этот код:

1. Сначала подключаются необходимые заголовочные файлы:

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

IP-адрес атакующего:

Это IP-адрес машины атакующего, с которой должна установить обратное соединение оболочка.

2. На следующем этапе подготавливается адрес целевой машины жертвы:

Здесь настраивается структура sockaddr_in с IP-адресом и портом цели. IP-адрес преобразуется из удобочитаемого представления в структуру in_addr с помощью функции inet_aton(). Указывается порт 4444, который посредством htons() преобразуется в сетевой порядок байтов.

3. Затем создаётся новый сокет:

Здесь вызывается функция socket(), создающая новый сокет TCP/IP.

4. Выполняется подключение к серверу атакующего:

Эта функция пытается подключить сокет к указанным IP-адресу и порту.

5. Затем выполняется самая важная операция - перенаправление стандартного ввода, вывода и потока ошибок в сокет:

Функция dup2() используется для дублирования файлового дескриптора сокета в файловые дескрипторы стандартного ввода, стандартного вывода и стандартного потока ошибок. Это означает, что весь ввод и вывод последующей оболочки будет передаваться через сетевое соединение.

6. Запускается оболочка:

Наконец, вызывается функция execve(), которая заменяет образ текущего процесса образом нового процесса. В данном случае она запускает новую оболочку "/bin/sh". Благодаря предшествующим вызовам dup2() эта оболочка будет взаимодействовать через сетевое соединение.

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

Теперь напишем простую обратную оболочку для Windows. Ниже приведён псевдокод оболочки Windows:

1. Инициализировать библиотеку сокетов вызовом WSAStartup.

2. Создать сокет.

3. Подключить сокет к удалённому узлу и порту, то есть к узлу атакующего.

4. Запустить cmd.exe.

Прежде всего настраиваются необходимые библиотеки, переменные и структуры:

5. Затем задаются IP-адрес и порт для обратного подключения, которым сейчас присвоены значения 10.10.1.5 и 4444:

6. Эта часть называется инициализацией сокета. Библиотека Windows Sockets инициализируется функцией WSAStartup, а функцией WSASocket создаётся сокет:

7. После этого структура адреса сокета заполняется сведениями об IP-адресе и порте, а затем с помощью WSAConnect выполняется попытка соединения:

8. Теперь настроим логику создания процесса. Структура STARTUPINFO настраивается так, чтобы сокет использовался в качестве дескрипторов стандартного ввода, вывода и потока ошибок. Затем вызывается CreateProcess, которая запускает командную строку с перенаправленными дескрипторами ввода-вывода:

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

Теперь продемонстрируем работу этой логики!

Сначала скомпилируем нашу вредоносную программу с обратной оболочкой:

Ниже кратко объясняется каждый флаг, использованный в команде:

• -o hack3.exe: задаёт имя выходного исполняемого файла.

• -lws2_32: подключает библиотеку Winsock (ws2_32.lib), необходимую для сетевых операций на платформах Windows.

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

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

• -fdata-sections: подобно -ffunction-sections, предписывает компилятору помещать каждую глобальную переменную в отдельную секцию.

• -Wno-write-strings: подавляет предупреждения, связанные с записью в строковые литералы. Он предписывает компилятору не выдавать предупреждение, когда код пытается изменить строковые литералы, что является неопределённым поведением.

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

• -fmerge-all-constants: включает объединение одинаковых констант. Компилятор пытается представить одинаковые константы одним экземпляром, уменьшая размер исполняемого файла.

• -static-libstdc++: статически компонует стандартную библиотеку C++, чтобы итоговый исполняемый файл во время выполнения не зависел от динамически подключаемой libstdc++.

• -static-libgcc: статически компонует библиотеку времени выполнения GCC, гарантируя, что итоговый исполняемый файл во время выполнения не будет зависеть от динамически подключаемой libgcc.

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

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

На машине с Kali Linux это выглядит следующим образом:

Рисунок 1.1. Компиляция hack3.c

Далее выполним следующие действия:

1. Подготовим прослушивающую программу с помощью Netcat:

На машине с Parrot Security OS это выглядит следующим образом:

Рисунок 1.2. Прослушивающая программа Netcat на машине атакующего

2. Затем запустим оболочку на машине жертвы, которой в моём случае служит Windows 10 x64:

На виртуальной машине с Windows 10 x64 это выглядит так:

Рисунок 1.3. Запуск обратной оболочки

Как видно, всё работает как ожидалось!

В сущности, именно так можно создать обратную оболочку для машин под управлением Windows.

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

Microsoft предоставляет обширную документацию по Windows API, с которой можно ознакомиться в MSDN.

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

В этом коде GetUserName - функция Windows API, которая получает имя пользователя, связанного с текущим потоком. UNLEN - определённая в lmcons.h константа (этот файл включается через windows.h), задающая максимальную длину имени пользователя.

Обратите внимание, что для компиляции этой программы требуется выполнить компоновку с библиотекой advapi32.lib.

Большинство функций Windows API существует в вариантах с суффиксами A и W. Примерами служат GetUserNameA и GetUserNameW. Функции, имена которых оканчиваются на A, предназначены для ANSI, а оканчивающиеся на W - для Unicode, или «широких символов».

Функции ANSI, где это применимо, принимают в качестве параметров типы данных ANSI, а функции Unicode - типы данных Unicode. Например, первый параметр GetUserNameA имеет тип LPSTR: это указатель на строку символов Windows ANSI, оканчивающуюся нулевым символом. В отличие от него, первый параметр GetUserNameW имеет тип LPWSTR: это указатель на постоянную 16-битную строку Unicode, оканчивающуюся нулевым символом.

Кроме того, требуемое количество байтов будет зависеть от используемого варианта:

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

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

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

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

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

Теперь мы рассмотрим одно из самых важных и фундаментальных понятий в мире разработки вредоносного ПО.

Что представляет собой формат PE-файла? Это собственный формат файлов Win32. Некоторые его спецификации происходят от Unix COFF (Common Object File Format, общий формат объектных файлов). Смысл понятия переносимый исполняемый файл состоит в том, что этот формат повсеместно используется на платформе Win32: загрузчик PE каждой платформы Win32 распознаёт и применяет его даже тогда, когда Windows работает на процессорных платформах, отличных от Intel. Это не означает, что исполняемые PE-файлы можно без изменений переносить на другие процессорные платформы. Поэтому анализ формата PE-файла даёт ценную информацию об архитектуре Windows.

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

• Заголовок DOS. Заголовок DOS содержит сведения, необходимые для запуска PE-файлов. Следовательно, для загрузки PE-файла требуется следующая преамбула:

Размер этой структуры составляет 64 байта. Самые важные её поля - e_magic и e_lfanew.

Первые два байта заголовка файла имеют значения 4D, 5A, или MZ: это инициалы Марка Збиковски, инженера Microsoft, работавшего над DOS. Эти магические символы определяют файл как файл формата PE:

Рисунок 1.4. Магические байты 4d 5a

e_lfanew: этот элемент находится в заголовке DOS со смещением 0x3c и хранит смещение, указывающее на заголовок PE:

Рисунок 1.5. Поле e_lfanew

• Заглушка DOS. За начальными 64 байтами файла следует заглушка DOS. Эта область памяти обычно заполнена нулями:

Рисунок 1.6. Заглушка DOS

• Заголовок PE. Это очень маленький компонент, содержащий только сигнатуру файла, которая состоит из магических байтов PE\0\0, или 50 45 00 00:

Рисунок 1.7. Заголовок PE

На языке C его конструкция выглядит следующим образом:

Рассмотрим эту структуру подробнее:

• Заголовок файла, или заголовок COFF. Это набор полей, описывающих основные характеристики файла:

В PE-bear, который доступен по адресу GitHub, если вы не пользуетесь другим инструментом, он выглядит так:

Рисунок 1.8. Заголовок файла

• Необязательный заголовок. В контексте объектных файлов COFF этот заголовок необязателен, но для PE-файлов он необходим. В данной структуре хранятся такие важные переменные, как AddressOfEntryPoint, ImageBase, Section Alignment, SizeOfImage, SizeOfHeaders и DataDirectory.

Существуют 32-битная и 64-битная версии этой структуры: документация Microsoft.

В PE-bear она выглядит следующим образом:

Рисунок 1.9. Необязательный заголовок

Здесь я хотел бы обратить ваше внимание на IMAGE_DATA_DIRECTORY:

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

В настоящее время PE-файлы могут содержать следующие каталоги данных:

• таблица экспорта;

• таблица импорта;

• таблица ресурсов;

• таблица исключений;

• таблица сертификатов;

• таблица базовых перемещений;

• отладочные данные;

• архитектура;

• глобальный указатель;

• таблица TLS;

• таблица конфигурации загрузки;

• связанный импорт;

• IAT (таблица адресов импорта);

• дескриптор отложенного импорта;

• заголовок среды выполнения CLR;

• зарезервированный элемент, который должен быть равен нулю.

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

• Таблица секций. Она содержит массив структур IMAGE_SECTION_HEADER, описывающих секции PE-файла, например .text и .data:

Размер этой структуры составляет 0x28 байта.

• Секции. После таблицы секций располагаются сами секции:

Рисунок 1.10. Секции

Приложения не обращаются непосредственно к физической памяти, а работают только с виртуальной. Секции - это фрагменты данных, которые помещаются в виртуальную память и напрямую используются при выполнении всех операций. Виртуальный адрес, или VA, представляет собой адрес в виртуальной памяти без каких-либо смещений. Иными словами, VA - это адреса памяти, используемые программой. В поле ImageBase можно задать адрес, по которому приложение чаще всего должно загружаться. Это своего рода точка в виртуальной памяти, с которой начинается область программы. Относительные виртуальные адреса (RVA) отсчитываются от этой точки. RVA можно вычислить по следующей формуле: RVA = VA - ImageBase. Значение ImageBase нам всегда известно, поэтому, имея VA или RVA, можно через одно получить другое.

Таблица секций задаёт размер каждой секции, поэтому все секции должны иметь определённый размер. Для этого в секции добавляются нулевые байты (00).

В Windows NT приложение обычно содержит разные заранее определённые секции, в том числе .text, .bss, .rdata, .data и .rsrc. В зависимости от назначения используются некоторые из них, но необязательно все:

• .text: весь код в Windows находится в секции с именем .text.

• .rdata: доступные только для чтения данные файла, например строки и константы, находятся в секции .rdata.

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

• .edata: данные экспорта исполняемого файла или DLL хранятся в секции .edata. Если эта секция присутствует, она содержит каталог экспорта, через который можно получить доступ к сведениям об экспорте. Структура IMAGE_EXPORT_DIRECTORY выглядит следующим образом:

Чаще всего экспортируемые символы находятся в DLL, однако DLL могут также импортировать символы. Основная задача таблицы экспорта - связать имена и/или номера экспортируемых функций с их RVA, то есть положением в памяти процесса.

• Таблица адресов импорта. Таблица адресов импорта состоит из указателей на функции и используется при загрузке DLL для поиска имён функций. Скомпилированное приложение устроено так, что вызовы API используют не непосредственно жёстко заданные адреса, а указатели на функции.

Написание кода на C для исполняемых файлов (exe) и библиотек динамической компоновки (DLL) имеет несколько небольших отличий. Главное из них состоит в способе вызова кода внутри модуля или программы. В случае exe должен существовать метод с именем main, который загрузчик операционной системы вызывает после подготовки нового процесса. Программа начинает выполняться сразу после того, как загрузчик операционной системы завершит свою работу.

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

Итак, файлу exe нужна функция с именем main, а DLL - функция DllMain. По существу, это единственное существенное различие.

Создадим простую DLL. Чтобы не усложнять пример, сделаем библиотеку, которая лишь выводит окно сообщения:

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

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

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

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

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

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

Теперь мы поговорим о внедрении полезной нагрузки с помощью отладочного API - хорошо известного классического метода.

Сначала подготовим полезную нагрузку. Для простоты воспользуемся полезной нагрузкой обратной оболочки msfvenom из Kali Linux:

Результат выполнения этой команды выглядит следующим образом:

Рисунок 2.1. Создание полезной нагрузки msfvenom

Здесь 10.10.1.5 - IP-адрес машины атакующего, а 4444 - порт, на котором позднее будет запущена прослушивающая программа.

Начнём с простого кода нашей вредоносной программы на C++. Мы использовали его в главе 1: GitHub.

Отличается только полезная нагрузка. Приступим.

Сначала скомпилируем код:

Результат выполнения этой команды, в нашем случае в Kali Linux, выглядит следующим образом:

Рисунок 2.2. Компиляция hack1.c

Теперь подготовим прослушивающую программу:

В Parrot Security OS вы увидите следующее:

Рисунок 2.3. Подготовка прослушивающей программы Netcat

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

На моей виртуальной машине с Windows 10 x64 это выглядит следующим образом:

Рисунок 2.4. Успешный запуск обратной оболочки

Как видите, всё в порядке: обратная оболочка запущена.

Для исследования hack1.exe мы воспользуемся Process Hacker (Process Hacker). Process Hacker - инструмент с открытым исходным кодом, который позволяет увидеть работающие на устройстве процессы, определить программы, потребляющие ресурсы процессора, и просмотреть связанные с процессом сетевые соединения.

На вкладке Network обратите внимание, что наш процесс установил соединение с 10.10.1.5:4444 - IP-адресом узла атакующего:

Рисунок 2.5. Установленное сетевое TCP-соединение

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

Следовательно, мы внедрим полезную нагрузку в другой процесс - в данном случае calc.exe:

Рисунок 2.6. Полезная нагрузка хранится во вредоносной программе

Здесь мы перенаправляем выполнение в целевой процесс, иными словами, выполняем полезную нагрузку в другом процессе на той же машине - например, в calc.exe или firefox.exe.

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

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

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

Затем нужно скопировать полезную нагрузку в предоставленную память целевого процесса, в нашем случае calc.exe:

Рисунок 2.8. Копирование полезной нагрузки в выделенную память

После этого необходимо попросить систему начать выполнение полезной нагрузки в целевом процессе, в нашем случае calc.exe:

Рисунок 2.9. Выполнение полезной нагрузки в целевом процессе

Итак, реализуем эту базовую логику в коде.

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

• VirtualAllocEx: документация Microsoft;

• WriteProcessMemory: документация Microsoft;

• CreateRemoteThread: документация Microsoft.

Простой пример такой реализации находится по адресу GitHub.

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

Затем посредством VirtualAllocEx выделяется буфер памяти для удалённого процесса:

Поскольку WriteProcessMemory позволяет копировать данные между процессами, скопируем полезную нагрузку в процесс calc.exe:

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

Теперь скомпилируем этот код:

Результат выполнения этой команды в Kali Linux выглядит следующим образом:

Рисунок 2.10. Компиляция hack2.c

Теперь подготовим прослушивающую программу Netcat:

На машине жертвы сначала запустим mspaint.exe:

Рисунок 2.11. Запуск mspaint.exe

Как видим, идентификатор процесса mspaint.exe равен 3388.

Затем запустим инжектор с машины жертвы:

Результат выполнения этой команды, например на виртуальной машине с Windows 10 x64, выглядит следующим образом:

Рисунок 2.12. Запуск инжектора

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

Рисунок 2.13. Сетевые соединения mspaint.exe

Следовательно, исследуем процесс mspaint.exe. Перейдя на вкладку Memory, мы можем найти выделенный нами буфер памяти:

Рисунок 2.14. Выделенная память в процессе mspaint.exe

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

После этого в Process Hacker можно выполнить поиск и сортировку по столбцу Protection, прокрутить список вниз и найти области, доступные одновременно для чтения и выполнения:

Рисунок 2.15. Области памяти, доступные для чтения и выполнения

Как видим, в памяти mspaint.exe находится множество таких областей.

Однако обратите внимание: в mspaint.exe загружен модуль ws2_32.dll. В обычных обстоятельствах этого никогда не должно происходить, поскольку данный модуль отвечает за работу с сокетами:

Рисунок 2.16. Модуль ws2_32.dll

Именно так код можно внедрить в другой процесс.

Однако есть один нюанс: открытие другого процесса с доступом для записи ограничивается. Примером такой защитной меры служит обязательный контроль целостности (Mandatory Integrity Control, MIC). Это метод управления доступом к объекту на основе уровня целостности этого объекта.

Существует четыре уровня целостности:

• Низкий уровень. Процессы с ограниченным доступом к системе, например Internet Explorer.

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

• Высокий уровень. Процессы, выполняемые с правами администратора.

• Системный уровень. Используется пользователями SYSTEM; к этому уровню относятся системные службы и процессы, которым требуется наивысший уровень безопасности.

Далее мы подробно рассмотрим внедрение DLL.

Теперь мы обсудим традиционный метод внедрения DLL, использующий отладочный API.

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

Для удобства создадим DLL, которая лишь отображает окно сообщения:

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

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

После выполнения во внедрённом процессе должно появиться наше сообщение Meow from evil.dll!, указывающее на успешное внедрение. Теперь можно скомпилировать библиотеку на компьютере атакующего:

Результат выполнения этой команды, например на виртуальной машине с Kali Linux, выглядит следующим образом:

Рисунок 2.17. Компиляция DLL evil из файла evil.c

Поместите её в выбранный вами каталог на компьютере жертвы.

Теперь нам нужен лишь фрагмент кода, который внедрит эту библиотеку в выбранный процесс.

В нашем случае мы рассматриваем традиционное внедрение DLL. Здесь выделяется буфер, вместимость которого не меньше длины пути к DLL на диске. Затем путь копируется в этот буфер: GitHub.

Как видите, всё довольно просто. Код идентичен примеру внедрения кода. Единственное отличие состоит в том, что мы добавляем путь к DLL на диске:

Перед внедрением и выполнением DLL нам требуется адрес в памяти функции LoadLibraryA - именно этот вызов API мы выполним в контексте процесса жертвы, чтобы загрузить DLL:

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

Результат выполнения этой команды на виртуальной машине с Kali Linux выглядит так:

Рисунок 2.18. Компиляция логики внедрения DLL из файла hack3.c

Сначала запустим экземпляр mspaint.exe:

Рисунок 2.19. Идентификатор процесса mspaint.exe равен 2592

Поместим файл DLL на машину жертвы:

Рисунок 2.20. Размещение файла evil.dll на машине жертвы

Затем запустим нашу программу:

Результат выполнения этой команды, например на виртуальной машине с Windows 7 x64, выглядит следующим образом:

Рисунок 2.21. Запуск сценария внедрения DLL hack3.exe

Чтобы подтвердить успешное внедрение DLL в процесс mspaint.exe, можно воспользоваться Process Hacker:

Рисунок 2.22. Область памяти RWX в процессе mspaint.exe

В другой области памяти можно увидеть наше сообщение Meow from evil.dll!:

Рисунок 2.23. Строка Meow from evil.dll! в памяти mspaint.exe

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

Теперь, научившись внедрять DLL, мы рассмотрим различные методы подмены.

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

Подмена DLL, также известная как атака с предварительной загрузкой DLL, предусматривает внедрение вредоносного кода в приложения Windows посредством эксплуатации порядка загрузки DLL.

Как это работает?

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

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

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

Первый вопрос, который может возникнуть на этом этапе: «Какой порядок поиска DLL использует Windows?»

На следующем рисунке показан стандартный порядок поиска DLL в Windows:

Рисунок 2.24. Порядок поиска DLL в Windows

Разберём его подробнее:

1. Сначала проверяется каталог, из которого было запущено приложение.

2. Затем проверяется системный каталог C:\Windows\System32.

3. После этого проверяется 16-битный системный каталог C:\Windows\System.

4. Далее проверяется каталог Windows C:\Windows\.

5. Затем оценивается текущий рабочий каталог.

6. Наконец, проверяются каталоги, определённые переменной среды PATH.

Посмотрим, как это работает на практике.

Самый распространённый способ поиска отсутствующих в системе DLL - использование Process Monitor (документация Microsoft) из комплекта Sysinternals со следующими фильтрами:

Рисунок 2.25. Фильтры Process Monitor для поиска отсутствующих DLL

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

Рисунок 2.26. Результат Process Monitor

В нашем примере процессу Bginfo.exe не хватает нескольких DLL. Эти библиотеки, например Riched32.dll, можно использовать для подмены DLL.

Теперь проверим разрешения каталога:

На машине с Windows 7 x64 вы должны увидеть следующий вывод:

Рисунок 2.27. Проверка разрешений каталога

Согласно документации, у нас есть доступ для записи в этот каталог.

Теперь выполним подмену DLL. Сначала запустим Bginfo.exe:

Рисунок 2.28. Запуск Bginfo.exe

Следовательно, если поместить DLL с именем Riched32.dll в тот же каталог, где находится Bginfo.exe, при запуске этой утилиты будет выполнен наш вредоносный код. Для удобства я создаю DLL, которая лишь отображает окно сообщения:

Теперь можно скомпилировать её на компьютере атакующего:

Затем переименуем вредоносную DLL в Riched32.dll и скопируем её в C:\Users\user\Desktop:

Рисунок 2.29. «Вредоносная» Riched32.dll

Теперь запустим Bginfo.exe:

Рисунок 2.30. Запуск bginfo.exe после замены легитимной DLL

В результате выполняется наша вредоносная логика.

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

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

В предыдущих разделах мы обсудили традиционное внедрение кода и DLL. В этом разделе я расскажу о методе раннего внедрения APC. Мы рассмотрим функцию QueueUserAPC (документация Microsoft), которая использует APC для постановки вызова в очередь определённого потока.

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

Сначала наша вредоносная программа создаёт новый легитимный процесс, например Notepad.exe:

Рисунок 2.31. Создание нового легитимного процесса notepad.exe

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

Затем в адресном пространстве процесса выделяется память для полезной нагрузки:

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

На языке C выделение памяти выглядит следующим образом:

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

На следующем этапе определяется процедура APC, указывающая на шелл-код. После этого полезная нагрузка записывается в выделенную память:

Рисунок 2.33. Запись полезной нагрузки в память удалённого процесса

Затем APC ставится в очередь основного потока, который в данный момент приостановлен:

Рисунок 2.34. Постановка пользовательского APC в очередь

Теперь мы можем выполнить внедрение в приостановленный поток:

Наконец, выполнение потока возобновляется и полезная нагрузка успешно запускается:

Рисунок 2.35. Возобновление потока

Для этого используется следующий код:

Полный исходный код этого примера находится по адресу GitHub.

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

Скомпилируем программу:

Результат выполнения этой команды на виртуальной машине с Kali Linux выглядит следующим образом:

Рисунок 2.36. Компиляция hack1.c

Теперь выполним файл hack1.exe в операционной системе Windows 10 x64:

Рисунок 2.37. Запуск hack1.exe

Исследовав недавно запущенный notepad.exe с помощью Process Hacker, мы увидим, что основной поток находится в приостановленном состоянии:

Рисунок 2.38. Поток notepad.exe приостановлен

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

В предыдущем примере мы обсудили метод раннего внедрения APC.

В этом примере будет рассмотрен и обсуждён дополнительный метод внедрения APC. Его особенность состоит в использовании недокументированной функции NtTestAlert. Цель обсуждения - продемонстрировать выполнение шелл-кода внутри локального процесса с помощью функции Win32 API QueueUserAPC и официально не документированного Native API NtTestAlert.

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

Полный исходный код находится в репозитории книги на GitHub: GitHub.

В этом разделе мы подробно рассмотрим методы перехвата API и приведём практические примеры.

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

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

В этом разделе приводится наглядный пример с DLL, содержащей логику по адресу GitHub.

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

Скомпилируем её:

Результат выполнения этой команды выглядит следующим образом:

Рисунок 2.39. Компиляция pet.cpp

Затем создадим простой фрагмент кода для проверки DLL:

Теперь скомпилируем программу:

Наконец, запустим программу в 64-битной операционной системе Windows 10:

Рисунок 2.40. Всплывающее сообщение meow-meow

Далее появляется следующее всплывающее сообщение:

Рисунок 2.41. Всплывающее сообщение mmmmeow

А вот и третье всплывающее сообщение:

Рисунок 2.42. Всплывающее сообщение tweet-tweet

Как видите, все компоненты работают как ожидалось.

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

Итак, какой метод здесь используется? Давайте разберёмся.

Сначала получим адрес функции Cat в памяти:

Затем необходимо сохранить первые 5 байт функции Cat. Они потребуются позднее:

Теперь создадим функцию myModifiedCatFunction, которая будет вызываться при обращении к исходной функции Cat:

Перезапишем 5 байт инструкцией перехода к myModifiedCatFunction:

Что это означает? Мы выполняем операцию записи, заменяя 5 байт данных инструкцией перехода, которая перенаправляет выполнение программы по адресу функции myModifiedCatFunction в памяти.

Теперь создадим исправление:

На этом этапе необходимо изменить функцию Cat, перенаправив её в myModifiedCatFunction, то есть применить исправление:

Какие действия были здесь выполнены? Этот подход широко известен как классический приём пятибайтового перехвата. Дизассемблируем функцию:

Рисунок 2.43. Дизассемблирование функции

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

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

Для этого необходимо выполнить исходную функцию Cat, установить перехват, а затем снова выполнить Cat:

Полный исходный код находится по адресу GitHub.

Теперь скомпилируем его:

На моей машине с Kali Linux это выглядит следующим образом:

Рисунок 2.44. Компиляция примера в Kali Linux

Наконец, посмотрим, как он выполняется в 64-битной операционной системе Windows 7:

Рисунок 2.45. Выполнение примера в Windows 7 x64

Как видите, перехват сработал безупречно! Теперь вместо meow-meow функция Cat выдаёт meow-squeak-tweet!!!.

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

По умолчанию системы Windows создают следующие разделы Run:

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

Рассмотрим практический пример. Предположим, мы столкнулись с кибератакой, в которой задействована вредоносная программа hack.c:

Скомпилируем её:

Например, на машине с Kali Linux компиляция выглядит следующим образом:

Рисунок 3.1. Компиляция нашей «вредоносной программы»

Наша вредоносная программа представляет собой всего лишь всплывающее окно сообщения.

Далее мы разработаем программу pers.c, которая будет создавать разделы реестра, запускающие нашу вредоносную программу hack.exe при входе в операционную систему Windows:

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

Скомпилируем программу закрепления:

Это выглядит следующим образом:

Рисунок 3.2. Компиляция программы закрепления

Теперь проверим всё в действии. Запустим программу закрепления:

Выйдем из системы и войдём снова:

Рисунок 3.3. Выход из системы жертвы и повторный вход

После завершения примера рекомендуется удалить созданные записи реестра:

Если на вашей машине установлена Windows 10, результат этой операции выглядит следующим образом:

Рисунок 3.4. Удаление записей реестра для корректного завершения эксперимента

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

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

Для применения этой стратегии закрепления необходимо изменить следующие записи реестра:

Тем не менее успешная реализация этой стратегии требует прав локального администратора.

Рассмотрим практическую реализацию и демонстрацию. Для начала создадим вредоносное приложение hack.c:

Скомпилируем его:

В Kali Linux или Parrot Security OS это выглядит следующим образом:

Рисунок 3.5. Компиляция hack.c

Файл hack.exe необходимо развернуть на целевой машине.

Изменения записи реестра Shell, в которую добавляется вредоносное приложение, приведут к запуску как explorer.exe, так и hack.exe при входе в Windows.

Задачу можно быстро выполнить с помощью следующей программы:

Теперь скомпилируйте программу, отвечающую за закрепление:

В Kali Linux или Parrot Security OS это выглядит следующим образом:

Рисунок 3.6. Компиляция pers.c

Для демонстрации этого метода прежде всего рекомендуется проверить записи реестра:

На нашей виртуальной машине Windows получаем следующий результат:

Рисунок 3.7. Записи реестра Winlogon

Поместите вредоносное приложение в указанный каталог C:\Windows\System32\. Теперь необходимо выполнить программу:

Затем выйдите из текущего сеанса и снова войдите в систему:

Рисунок 3.8. Выход из текущего сеанса и повторный вход

В соответствии с логикой нашего вредоносного ПО появляется окно с сообщением Hello, Packt!:

Рисунок 3.9. Появление окна сообщения и успешное изменение записи реестра

Чтобы изучить свойства процесса, можно воспользоваться программой Process Hacker 2:

Рисунок 3.10. Свойства процесса hack.exe

После этого выполним очистку:

На виртуальной машине Windows 10 x64 результат выглядит следующим образом:

Рисунок 3.11. Очистка после экспериментов

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

Успешное применение этого метода закрепления наблюдалось в операциях группировки Turla, а также при развёртывании в реальных условиях такого программного обеспечения, как Gazer и Bazaar.

Службы Windows играют важнейшую роль в проведении хакерских атак по следующим причинам:

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

• Процессы автоматически запускаются при инициализации системы.

• Они могут обладать чрезвычайно высокими привилегиями в операционной системе.

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

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

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

Создадим обратную оболочку meow.exe с помощью инструмента msfvenom из состава Metasploit:

На машине с Kali Linux (в вашем случае это может быть Parrot Security OS):

Рисунок 3.21. Исполняемый файл обратной оболочки для нашего примера

Далее мы разработаем службу, которая выполняет программу meow.exe в целевой системе. Минимальные требования к службе включают следующее:

• Основная точка входа, как и у любой программы.

• Точка входа службы.

• Обработчик управления службой.

В основной точке входа необходимо сразу вызвать StartServiceCtrlDispatcher, чтобы диспетчер управления службами (SCM) мог вызвать точку входа службы (ServiceMain):

Главная точка входа службы отвечает за выполнение следующих действий:

• Инициализация всех необходимых компонентов, отложенная в основной точке входа.

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

• Регистрация этих команд в виде битовой маски с помощью элемента dwControlsAccepted структуры SERVICE_STATUS.

• Установка состояния службы SERVICE_RUNNING.

• Выполнение процедур инициализации, таких как создание потоков, событий, мьютексов, механизмов IPC и так далее.

Главной функцией службы является ServiceMain:

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

Реализованы и поддерживаются только запросы SERVICE_CONTROL_STOP и SERVICE_CONTROL_SHUTDOWN. Помимо них могут обрабатываться SERVICE_CONTROL_CONTINUE, SERVICE_CONTROL_INTERROGATE, SERVICE_CONTROL_PAUSE, SERVICE_CONTROL_SHUTDOWN и различные другие запросы.

Создадим также функцию со вредоносной логикой:

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

Теперь скомпилируем нашу службу:

В Kali Linux это выглядит следующим образом:

Рисунок 3.22. Компиляция файла MeowService: meowsrv.c

Установку службы можно начать из командной строки на компьютере с Windows 10 x64, выполнив приведённую команду. Обратите внимание: все команды следует выполнять с правами администратора:

В нашем случае это выглядит так:

Рисунок 3.23. Создание MeowService

Проверим службу:

В результате получаем:

Рисунок 3.24. Проверка MeowService

Если открыть Process Hacker, служба будет видна на вкладке Services:

Рисунок 3.25. MeowService в Process Hacker

Если проверить её свойства, можно увидеть следующее:

Рисунок 3.26. MeowService в Process Hacker

Учётная запись LocalSystem - это предварительно настроенная локальная учётная запись, которую использует диспетчер управления службами. На локальном компьютере ей предоставлены широкие привилегии, позволяющие выступать от имени компьютера в сети. Токен системы содержит идентификаторы безопасности (SID) NT AUTHORITY\SYSTEM и BUILTIN\Administrators. Эти SID предоставляют привилегированный доступ к большинству системных объектов. Во всех локализациях используется имя учётной записи .\LocalSystem. Также можно применять обозначения LocalSystem или "Computer Name"\LocalSystem. У этой учётной записи нет пароля.

Согласно документации MSDN, если при вызове функции CreateService или ChangeServiceConfig указана учётная запись LocalSystem, все переданные сведения о пароле будут проигнорированы.

Теперь запустим службу следующей командой:

В результате получаем:

Рисунок 3.27. Запуск MeowService

Видно, что была получена обратная оболочка:

Рисунок 3.28. Получена обратная оболочка

А наша служба MeowService получила PID 3608:

Рисунок 3.29. Служба MeowService получила PID 3608

Теперь запустим Process Hacker от имени пользователя без административных прав:

Рисунок 3.30. Запуск Process Hacker от имени пользователя без административных прав

В представленных сведениях явно отсутствует имя пользователя. Однако при запуске Process Hacker с административными привилегиями картина меняется: становится видно, что наша оболочка работает от имени учётной записи NT AUTHORITY\SYSTEM:

Рисунок 3.31. Запуск Process Hacker от имени администратора

Она также будет видна на вкладке Network:

Рисунок 3.32. Сетевое соединение обратной оболочки

Итак, всё сработало превосходно. :)

После завершения тестов необходимо выполнить очистку:

На нашей виртуальной машине Windows 10 x64 это выглядит так:

Рисунок 3.33. Остановка MeowService

Служба MeowService была успешно остановлена. Удалим её:

В Process Hacker появится соответствующее уведомление:

Рисунок 3.34. Удаление MeowService

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

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

Полный исходный код MeowService можно найти на GitHub: GitHub.

Хотя эта стратегия не нова, ей необходимо уделить должное внимание, особенно начинающим специалистам синей команды. Субъекты угроз могут не создавать новые службы, а изменять уже существующие службы Windows. В реальных условиях описанный метод часто применяли такие хакерские группировки, как APT 38, APT 32 и APT 41. Более подробно группы APT и их действия будут рассмотрены в главе 14.

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

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

Существует и такая запись:

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

Рассмотрим конкретный пример. Прежде всего необходимо выбрать целевое приложение. В качестве цели я выбрал 64-разрядную версию 7-Zip:

Рисунок 3.35. 7-Zip в качестве приложения-жертвы

Перед началом экспериментов рекомендуется проверить правильность значений записей реестра:

На виртуальной машине Windows 10 x64 это выглядит следующим образом:

Рисунок 3.36. Предварительная проверка записей реестра

Я также подготовил вредоносное приложение. Это наше обычное вредоносное ПО с сообщением Hello, Packt!:

Рисунок 3.37. Пример вредоносной программы

Затем разрабатывается программа, реализующая логику закрепления (pers.c). Она доступна по адресу: GitHub.

Как видите, применяемая логика проста: изменяются лишь значения целевых записей реестра.

Посмотрим, как всё работает. Скомпилируем вредоносную программу:

В Kali Linux это выглядит следующим образом:

Рисунок 3.38. Компиляция нашего примера вредоносной программы

Скомпилируем сценарий закрепления:

На машине с Kali Linux это выглядит так:

Рисунок 3.39. Компиляция сценария закрепления

Затем программа была выполнена на целевой машине, работающей под управлением Windows 10 x64:

В Windows 10 x64 это выглядит следующим образом:

Рисунок 3.40. Запуск сценария закрепления

После перезагрузки машины я попытался удалить 7-Zip:

Рисунок 3.41. Попытка удалить приложение-жертву 7-Zip

В результате запустилась наша вредоносная программа:

Рисунок 3.42. Запуск вредоносной программы при попытке удалить приложение-жертву 7-Zip

Затем мы просмотрели свойства hack.exe в приложении Process Hacker 2:

Рисунок 3.43. Проверка свойств hack.exe с помощью Process Hacker 2

Родительским процессом, который наблюдается при открытии параметров Windows, является SystemSettings.exe. В данном случае выбранной функцией служит добавление или удаление приложений. Отлично!

Всё сработало именно так, как ожидалось!

После завершения экспериментов выполним очистку:

После выполнения этой команды на виртуальной машине Windows 10 x64 видим следующее:

Рисунок 3.44. Восстановление записей после завершения эксперимента

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

Полный исходный код всех рассмотренных в этой главе сценариев закрепления можно найти в репозитории GitHub: GitHub.

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

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

Ниже приведена упрощённая схема токенов в Windows:

Рисунок 4.1. Токены Windows

После успешной аутентификации пользователя локальный орган безопасности (LSA) создаёт новый сеанс входа и токен доступа.

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

Главная задача токена доступа - служить временным хранилищем параметров безопасности, связанных с сеансом входа и допускающих изменение в реальном времени. В описанном контексте разработчики Windows взаимодействуют с токеном доступа, который представляет сеанс входа и находится в процессе lsass.

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

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

Помимо прочих сведений, токен содержит идентификатор безопасности входа (SID), определяющий текущий сеанс входа.

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

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

Эти сведения также можно получить следующей командой:

На виртуальной машине Windows 10 это выглядит так:

Рисунок 4.2. Сведения о пользователе и группах

Эти сведения также можно получить с помощью инструмента Process Explorer:

Рисунок 4.3. Сведения о пользователе и группах в Process Explorer

Существует два типа токенов доступа:

• Первичные, которые иногда называют делегирующими.

• Токены олицетворения.

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

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

Теперь разберём понятие локального администратора.

Для продолжения откроем две командные строки, одну из которых запустим с правами администратора:

Рисунок 4.4. Командная строка с правами администратора

А вторую - без прав администратора:

Рисунок 4.5. Командная строка без прав администратора

Теперь сравним оба процесса с помощью Process Explorer:

Рисунок 4.6. Два процесса в Process Explorer

После запуска cmd.exe с повышенными правами администратора становится видно, что флаг BUILTIN\Administrators назначен владельцем. Это означает, что cmd.exe выполняется в контексте безопасности, связанном с правами администратора.

Какое значение это различие имеет для общей структуры метода кражи токена? Известно, что мы можем выполнять следующие действия:

• Олицетворять клиента после аутентификации с помощью SeImpersonatePrivilege.

• Отлаживать программы.

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

Если токен обладает разрешением SeDebugPrivilege, пользователь может обойти выполняемую ядром проверку доступа к определённому объекту. Включив разрешение SeDebugPrivilege в вызывающем процессе, можно получить дескриптор любого системного процесса. Затем вызывающий процесс может обратиться к Win32 API OpenProcess(), чтобы получить дескриптор с правами PROCESS_ALL_ACCESS, PROCESS_QUERY_INFORMATION или PROCESS_QUERY_LIMITED_INFORMATION.

Перейдём к практическим примерам.

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

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

Рисунок 4.7. Практическая реализация

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

Затем откройте процесс, токен доступа которого необходимо украсть, и получите дескриптор этого токена:

Создайте копию текущего токена доступа процесса:

Наконец, запустите новый процесс с только что полученным токеном доступа:

Полный исходный код этой логики доступен по адресу: GitHub.

Этот код представляет собой примитивное доказательство концепции (PoC); для простоты используется mspaint.exe.

Посмотрим на всё в действии. Скомпилируем исходный код нашего PoC:

На машине с Kali Linux результат выглядит следующим образом:

Рисунок 4.8. Компиляция нашей вредоносной программы

Затем выполните её на компьютере жертвы:

Например, на машине с Windows 10 это выглядит так:

Рисунок 4.9. Запуск нашей вредоносной программы

Работая в контексте локального администратора в среде с высоким уровнем целостности, можно получить токен доступа процесса winlogon.exe с PID 536 и создать новый процесс от имени учётной записи SYSTEM:

Рисунок 4.10. Процесс mspaint.exe создан от имени SYSTEM

Теперь проверим свойства нашего процесса:

Рисунок 4.11. Результат кражи токена

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

Как упоминалось ранее, функция ImpersonateLoggedOnUser позволяет текущему потоку принять личность другого пользователя, который в данный момент вошёл в систему. Поток продолжит олицетворять вошедшего пользователя до вызова функции RevertToSelf() или до завершения потока.

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

Этот метод используют программы-вымогатели Ryuk и BlackCat; он также входит в арсенал множества фреймворков с открытым исходным кодом для удалённого администрирования и действий после эксплуатации.

Рассмотрим следующий метод повышения привилегий - кражу паролей.

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

Mimikatz широко известен как знаменитый инструмент для действий после эксплуатации, позволяющий извлекать хеши диспетчера локальной сети новой технологии (NTLM) посредством дампа процесса lsass.

Мы продемонстрируем извлечение памяти lsass без использования Mimikatz, применив API MiniDumpWriteDump. Поскольку Mimikatz широко известен и легко обнаруживается, хакеры постоянно ищут новые способы повторно реализовать отдельные возможности, основанные на его внутренней логике.

Как разработать простую вредоносную программу, создающую дамп процесса lsass.exe? В данном случае используется функция MiniDumpWriteDump:

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

Сначала обнаружим процесс lsass.exe с помощью функции, доступной по адресу: GitHub.

Чтобы атакующий мог создать дамп LSASS, ему необходима привилегия SeDebugPrivilege:

После этого создадим логику формирования дампа:

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

Посмотрим на всё в действии. Скомпилируем программу создания дампа на машине атакующего с Kali Linux x64 или Parrot Security OS:

В Kali Linux это выглядит так:

Рисунок 4.12. Компиляция кода PoC

Затем выполним программу на машине жертвы, в моём случае - Windows 10 x64:

На виртуальной машине Windows 10 это выглядит следующим образом:

Рисунок 4.13. Запуск вредоносной программы

Как показано на рисунке, файл lsass.dmp записывается в рабочий каталог для временных файлов C:\temp.

Затем импортируем файл дампа в Mimikatz и извлечём пароли:

На виртуальной машине Windows 10 x64 результат выполнения этих команд выглядит так:

Рисунок 4.14. Запуск Mimikatz

В чём же смысл? Мы можем провести атаку следующим образом:

1. Выполнить hack.exe в целевой системе.

2. В результате файл lsass.dmp будет помещён в рабочий каталог.

3. Забрать файл lsass.dmp из системы Windows жертвы.

4. Открыть Mimikatz и загрузить файл дампа, чтобы получить учётные данные жертвы на машине атакующего!

В реальном мире эту тактику применяют многочисленные развитые устойчивые угрозы (APT) и хакерские инструменты. Например, Cobalt Strike может запустить задание, которое внедряет хеши паролей в память LSASS и создаёт её дамп. Fox Kitten и HAFNIUM используют procdump для создания дампа памяти процесса lsass. Более подробно группы APT и их действия будут рассмотрены в главе 14.

Существует множество способов создания дампа LSASS, и они реализуются не только на языке C: можно найти немало вариантов этого метода и его реализаций на C#, PowerShell, Rust и Go.

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

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

В Windows 10 это выглядит так:

Рисунок 4.15. Пользователь с низкими привилегиями

Для сравнения пользователь с высокими привилегиями выглядит следующим образом:

На машине Windows это выглядит так:

Рисунок 4.16. Привилегии администратора

Для выполнения операции нам понадобятся следующие сведения:

• Служба или приложение, в которых отсутствует необходимый файл DLL.

• Имя отсутствующего требуемого файла DLL.

• Расположение требуемой DLL.

• Разрешения, предоставленные для этого пути.

Откройте Process Monitor и добавьте следующие три фильтра:

Рисунок 4.17. Process Monitor с фильтрами

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

Рисунок 4.18. Результат Process Monitor после настройки фильтров

В нашем примере процесс Discord.exe уязвим в отношении нескольких DLL, которые потенциально можно использовать для подмены, например d3d11.dll.

Пользователи с действительными учётными данными смогут получить доступ к Discord.exe, если он расположен в C:\. Добавление средств сценариев в PATH позволяет злоумышленнику создавать вредоносные DLL в этом каталоге. При следующем перезапуске вредоносная DLL будет загружена с разрешениями процесса:

Результат этой команды на моей виртуальной машине Windows 10 выглядит следующим образом:

Рисунок 4.19. Проверка доступа на запись

Для эксплуатации создайте вредоносную программу со следующим кодом:

Либо создайте что-то наподобие обратной оболочки, доступной по адресу: GitHub.

Скомпилируем её:

На машине с Kali Linux это выглядит следующим образом:

Рисунок 4.20. Компиляция нашей вредоносной DLL

После размещения вредоносной DLL по правильному пути, если Discord.exe в данный момент выполняется от имени SYSTEM, при следующем запуске системы пользователь получит эти разрешения, поскольку процесс выполнит вредоносную DLL:

Рисунок 4.21. Разрешения процесса жертвы

Файл output.dll переименовывается в d3d11.dll и помещается в тот же каталог: C:\Users\user\AppData\Local\Discord\app-1.0.9004\.

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

Рисунок 4.22. Файл d3d11.dll в каталоге app-1.0.9004

Теперь запустим оболочку:

Рисунок 4.23. Оболочка запущена с привилегиями администратора (nt authority\system)

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

В этом разделе мы продемонстрируем один из наиболее любопытных методов обхода UAC - изменение реестра с помощью fodhelper.exe.

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

• HKCU\Software\Classes\<targeted_extension>\shell\open\command - значения Default или DelegateExecute в целевой системе.

• HKCU\Environment\windir.

• HKCU\Environment\systemroot.

Программа fodhelper.exe появилась в операционной системе Windows 10 для управления дополнительными компонентами, например региональными настройками клавиатуры. Она расположена по пути C:\Windows\System32\fodhelper.exe. Этот исполняемый файл, находящийся в каталоге System32 операционной системы Windows, имеет цифровую подпись Microsoft, подтверждающую его подлинность и целостность:

Рисунок 4.24. fodhelper.exe

После запуска fodhelper.exe Process Monitor начинает захватывать действия процесса и предоставляет подробные сведения, включая операции чтения и записи в реестре и файловой системе. Наблюдение за чтением реестра представляет особый интерес, хотя некоторые конкретные ключи или значения могут остаться незамеченными. Записи реестра HKEY_CURRENT_USER особенно удобны для оценки возможного влияния новой записи на поведение программы, поскольку для их изменения не требуются специальные разрешения.

Программа fodhelper.exe ищет запись реестра HKCU:\Software\Classes\ms-settings\shell\open\command. В конфигурации Windows 10 по умолчанию эта запись отсутствует:

Рисунок 4.25. Отсутствующая запись реестра для fodhelper.exe

Когда вредоносная программа запускает двоичный файл fodhelper, компонент Windows, допускающий повышение без запроса UAC, Windows немедленно повышает уровень целостности fodhelper со среднего до высокого. Затем fodhelper с высоким уровнем целостности пытается получить доступ к файлу ms-settings с помощью его обработчика по умолчанию. Поскольку обработчик был скомпрометирован вредоносной программой со средним уровнем целостности, привилегированный fodhelper выполнит команду атаки в виде процесса с высоким уровнем целостности.

Разработаем PoC этой логики. Прежде всего необходимо создать запись реестра и назначить значения, то есть изменить реестр:

Как видите, обход UAC достигается простым созданием новой структуры реестра в HKCU:\Software\Classes\ms-settings\.

Затем запустим приложение с повышенными привилегиями:

Полный исходный код выглядит следующим образом: GitHub.

Посмотрим на всё в действии. Сначала изучим реестр:

На виртуальной машине Windows 10 x64 это выглядит так:

Рисунок 4.26. Проверка реестра

Проверим также текущие привилегии:

На виртуальной машине Windows 10 x64 это выглядит так:

Рисунок 4.27. Текущие привилегии

Скомпилируем наш PoC hack.c на машине атакующего:

На моей машине с Kali Linux это выглядит следующим образом:

Рисунок 4.28. Компиляция PoC

Затем выполним описанную процедуру на целевом устройстве, в нашем сценарии - Windows 10 x64 версии 1903:

На машине с Windows 10 получаем следующее:

Рисунок 4.29. Запуск hack.exe

Очевидно, что приложение cmd.exe было запущено. Ещё раз проверим структуру реестра:

Результат выполнения этой команды выглядит так:

Рисунок 4.30. Повторная проверка записей реестра

Очевидно, что реестр был успешно изменён.

Теперь проверим права в текущем активном сеансе cmd.exe:

На машине с Windows 10 x64 это выглядит следующим образом:

Рисунок 4.31. Проверка привилегий

Запустим Process Hacker 2 с правами администратора и проверим наш сеанс cmd.exe:

Рисунок 4.32. Повышенные привилегии cmd.exe

А вот как он выглядит на вкладке General:

Рисунок 4.33. Свойства процесса cmd.exe

Как видите, всё сработало безупречно.

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

Все эти и многие другие методы применяются злоумышленниками в реальных атаках; такие приёмы используются в большинстве вредоносных программ.

Подробнее их можно изучить, например, на этой странице: MITRE ATT&CK.

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

Можно запросить у операционной системы, подключён ли отладчик. Функция IsDebuggerPresent проверяет, установлен ли флаг BeingDebugged в блоке окружения процесса (PEB):

Соответствующая документация доступна по адресу: документация Microsoft.

Полный исходный код доказательства концепции (PoC) выглядит следующим образом:

Посмотрим на всё в действии. Скомпилируем исходный код нашего PoC:

Результат выполнения этой команды в Kali Linux выглядит так:

Рисунок 5.1. Компиляция нашей вредоносной программы

Затем откроем её в x64dbg. В нашем случае на виртуальной машине Windows 10 x64 это выглядит следующим образом:

Рисунок 5.2. Запуск нашей вредоносной программы через x64dbg

Логика противодействия отладке сработала как ожидалось. Просто идеально!

Другой приём обнаружения отладчика использует ещё одну функцию. Функция CheckRemoteDebuggerPresent() проверяет, подключён ли к текущему процессу отладчик, работающий в другом процессе на той же машине.

Логика проверки выглядит следующим образом:

Посмотрим на всё в действии. Скомпилируем исходный код нашего PoC:

Результат выполнения этой команды в Kali Linux выглядит так:

Рисунок 5.3. Компиляция нашей вредоносной программы

Затем откроем её в отладчике x64dbg. В нашем случае на виртуальной машине Windows 10 x64 это выглядит следующим образом:

Рисунок 5.4. Запуск нашей вредоносной программы через x64dbg

Если запустить её без подключения отладчика:

Результат выполнения этой команды в Windows выглядит следующим образом:

Рисунок 5.5. Запуск вредоносной программы без подключения к отладчику

Как видите, логика противодействия отладке сработала как ожидалось. Просто идеально!

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

Ниже приведён простой код PoC на C, демонстрирующий логику проверки разрешений страниц памяти для обнаружения точек останова: GitHub.

Посмотрим на всё в действии. Скомпилируем наш PoC на машине атакующего с Kali Linux x64 или Parrot Security OS:

Результат выполнения этой команды в Kali Linux выглядит так:

Рисунок 5.6. Компиляция кода PoC

Затем на машине жертвы, в моём случае Windows 10 x64, запустим отладчик:

Рисунок 5.7. Запуск отладчика

Затем подключимся к нашему процессу hack.exe:

Рисунок 5.8. Подключение к hack.exe

Как видите, наша логика сработала: отладчик обнаружен:

Рисунок 5.9. Вывод сообщения «Debugger detected»

Запустим код PoC следующей командой:

Как обычно, на виртуальной машине Windows 10 x64 это выглядит так:

Рисунок 5.10. Запуск hack.exe

Отладчик не обнаружен, и логика работает именно так, как ожидалось.

Перейдём к исследованию других методов.

По умолчанию в поле NtGlobalFlag блока окружения процесса хранится значение 0. Это поле расположено по смещению 0x68 в 32-разрядной Windows и 0xBC в 64-разрядной Windows:

Рисунок 5.11. NtGlobalFlag

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

• FLG_HEAP_ENABLE_TAIL_CHECK (0x10).

• FLG_HEAP_ENABLE_FREE_CHECK (0x20).

• FLG_HEAP_VALIDATE_PARAMETERS (0x40).

Чтобы определить, был ли процесс запущен с отладчиком, проверьте значение поля NtGlobalFlag в структуре PEB.

Рассмотрим практическую реализацию и демонстрацию с помощью простого кода PoC для противодействия отладке:

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

Скомпилируем программу в Kali Linux или на любой машине Linux с MinGW:

Результат выполнения этой команды в Kali Linux выглядит так:

Рисунок 5.12. Компиляция нашего вредоносного кода PoC

Запустим программу и подключимся к ней в отладчике x64dbg:

Рисунок 5.13. Запуск hack.exe через x64dbg

Затем запустим hack.exe из командной строки:

Рисунок 5.14. Запуск hack.exe без отладчика

Как видите, всё работает безупречно.

Следующий интересный приём с флагами устроен так: структура ядра EPROCESS, описывающая объект процесса, содержит поле NoDebugInherit. Обратное значение этого поля можно получить из недокументированного класса ProcessDebugFlags (0x1f). Следовательно, если возвращаемое значение равно 0, отладчик активен.

Рассмотрим практическую реализацию и демонстрацию с помощью простого кода PoC для этого метода противодействия отладке.

Полный исходный код доступен на GitHub: GitHub.

Основная логика представлена следующей функцией:

Скомпилируем её следующим образом:

Результат выполнения этой команды в Kali Linux выглядит так:

Рисунок 5.15. Компиляция нашего вредоносного кода PoC

Запустим программу и подключимся к ней в отладчике x64dbg:

Рисунок 5.16. Запуск hack2.exe через x64dbg

Затем запустим hack2.exe из командной строки:

Рисунок 5.17. Запуск hack2.exe без отладчика

Как видите, всё работает безупречно.

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

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

Проверим наличие определённых файлов.

Если в целевой системе имеются следующие файлы, она, скорее всего, является виртуальной машиной VirtualBox:

• c:\windows\system32\drivers\VBoxMouse.sys.

• c:\windows\system32\drivers\VBoxGuest.sys.

• c:\windows\system32\drivers\VBoxSF.sys.

• c:\windows\system32\drivers\VBoxVideo.sys.

• c:\windows\system32\vboxdisp.dll.

• c:\windows\system32\vboxhook.dll.

• c:\windows\system32\vboxservice.exe.

• c:\windows\system32\vboxtray.exe.

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

Создадим код, который проверяет систему на наличие таких артефактов. Ниже приведён полный код на C с функцией checkVM, проверяющей существование указанных путей:

Полный исходный код этой логики доступен по адресу: GitHub.

Как видите, для простоты эта функция проверяет только два пути:

• c:\windows\system32\drivers\VBoxMouse.sys.

• c:\windows\system32\drivers\VBoxGuest.sys.

Однако эту логику можно дополнить проверкой других артефактов.

Как обычно, скомпилируем пример в виртуальной машине Kali:

В Kali Linux это выглядит следующим образом:

Рисунок 6.1. Компиляция примера hack.c

Затем запустим его на целевой машине Windows VirtualBox:

На виртуальной машине Windows 10 это выглядит так:

Рисунок 6.2. Запуск hack.exe в виртуальной машине

Как видно на предыдущем снимке экрана, указанные файлы действительно присутствуют на целевой машине Windows VirtualBox.

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

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

Один из методов состоит в проверке идентификатора производителя жёсткого диска на определённое значение. Для этой логики используется следующая функция:

Полный исходный код этой логики доступен по адресу: GitHub.

Скомпилируем наш пример:

В Kali Linux это выглядит следующим образом:

Рисунок 6.3. Компиляция примера hack.c

Затем запустим его на целевой машине Windows VirtualBox:

На машине с Windows 10 это выглядит так:

Рисунок 6.4. Запуск hack.exe в виртуальной машине

Как видите, всё сработало как ожидалось.

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

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

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

Задержка выполнения может позволить обойти анализ в песочнице за счёт превышения предельной продолжительности выполнения образца. Однако всё не так просто, как вызов Sleep(1000000).

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

Приведённый код представляет собой примитивное доказательство концепции (PoC); для простоты мы выводим сообщения в консоль и показываем окна сообщений.

Посмотрим на всё в действии. Скомпилируем исходный код нашего PoC:

В Kali Linux это выглядит следующим образом:

Рисунок 6.5. Компиляция нашей вредоносной программы

Затем выполним её на компьютере жертвы:

На виртуальной машине Windows 10 x64 это выглядит так:

Рисунок 6.6. Запуск нашей вредоносной программы

Просто идеально!

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

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

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

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

Как видите, я просто проверяю существование пути записи реестра. Если значение существует, возвращается TRUE, в противном случае - FALSE.

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

Логика этой функции столь же проста. Мы проверяем значение записи реестра посредством RegQueryValueExA, первым параметром которой служит результат функции RegOpenKeyExA.

Я буду проверять только Oracle VirtualBox. Для других виртуальных машин и песочниц применяются те же методы.

Рассмотрим практический пример. Изучим полный исходный код, доступный в нашем репозитории GitHub: GitHub.

Как видите, по сути это обычная атака с внедрением полезной нагрузки, дополненная приёмами обнаружения VirtualBox по реестру Windows.

Проверим путь HKLM\HARDWARE\ACPI\FADT\VBOX_:

Рисунок 6.7. Проверка HKLM\HARDWARE\ACPI\FADT\VBOX_

Получим значение реестра SystemProductName из HKLM\SYSTEM\CurrentControlSet\Control\SystemInformation и сравним его со строкой VirtualBox:

Рисунок 6.8. Проверка ...\Control\SystemInformation

Получим из того же расположения ключ версии BIOS BiosVersion:

Рисунок 6.9. Проверка BiosVersion

Посмотрим на всё в действии. Скомпилируем пример на машине атакующего с Kali Linux x64 или Parrot Security OS:

В Kali Linux это выглядит так:

Рисунок 6.10. Компиляция кода PoC

Затем выполним его на машине жертвы, в моём случае Windows 10 x64:

На виртуальной машине Windows 10 x64 это выглядит следующим образом:

Рисунок 6.11. Запуск вредоносной программы

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

Например, по пути реестра HKLM\SYSTEM\ControlSet001\Services\Disk\Enum значения DeviceDesc и FriendlyName равны VBOX, а по пути HKLM\SYSTEM\CurrentControlSet\Control\SystemInformation значение SystemProductName равно VIRTUAL или VIRTUALBOX.

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

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

Все эти и многие другие методы применяются злоумышленниками в реальных атаках. Подробнее их можно изучить на странице: MITRE ATT&CK.

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

Ниже перечислены некоторые распространённые методы, способные помешать дизассемблированию:

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

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

• Уплощение графа потока управления (CFG) предусматривает разбиение вложенных циклов и операторов if, которые затем скрываются внутри большого оператора switch, заключённого в цикл.

Следующий приём состоит в сочетании jz с jnz. Это позволяет создавать инструкции перехода с одной и той же целью. Дизассемблер не распознаёт такой переход, поскольку дизассемблирует инструкции по отдельности.

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

Начнём с кода из главы 1: GitHub.

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

Пример обфускации представленной программы на C с помощью методов обфускации опкодов и ассемблерного кода доступен по адресу: GitHub.

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

Функция dummyFunction() начинается с инициализации:

На этом этапе можно выполнить дополнительные математические операции:

Затем необходимо обновить результат. Например, можно добавить ещё один цикл for:

Наконец, конечный результат можно использовать для выполнения условных операций:

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

Как обычно, скомпилируем код PoC с помощью MinGW. Введите следующую команду:

В Kali Linux это выглядит так:

Рисунок 7.1. Компиляция нашей вредоносной программы

Для простоты при компиляции мы не использовали дополнительную оптимизацию.

Выполните следующую команду на машине жертвы. В моём случае это машина Windows 10 x64 версии 1903:

Результат выполнения команды показан на следующем снимке экрана:

Рисунок 7.2. Обратная оболочка, запущенная на машине Windows

Разумеется, в настоящем вредоносном ПО всё будет сложнее и запутаннее.

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

• Practical Malware Analysis: Amazon.

• Learning Malware Analysis: Amazon.

• Malware Analysis Techniques: Amazon.

В следующем примере мы применим последний приём - сочетание jz с jnz.

В качестве отправной точки ещё раз рассмотрим нашу обратную оболочку: GitHub.

После нескольких изменений мы можем объединить jz и jnz в программе на C. Пример доступен по адресу: GitHub.

Как видите, единственное отличие заключается в условном блоке.

Как обычно, скомпилируем код PoC с помощью MinGW. Введите следующую команду:

В Kali Linux это выглядит следующим образом:

Рисунок 7.3. Компиляция нашей вредоносной программы

Как обычно, запустим её на машине жертвы, чтобы проверить правильность работы:

Результат выполнения этой команды в Windows 10 выглядит следующим образом:

Рисунок 7.4. Обратная оболочка, запущенная на машине Windows

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

Современные дизассемблеры, такие как IDA Pro и Ghidra от NSA, чрезвычайно эффективно анализируют вызовы функций и выводят высокоуровневые сведения, понимая взаимосвязи между функциями. Такой анализ эффективен, когда применяется к коду, написанному в традиционном стиле программирования и скомпилированному стандартным компилятором. Однако создатель вредоносного ПО может легко его обойти.

Указатели на функции широко используются в языке программирования C и играют важную роль в C++. Тем не менее они по-прежнему создают трудности для дизассемблеров.

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

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

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

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

Рассмотрим пример. Мы применим обфускацию вызовов функций в нашей программе обратной оболочки Windows: GitHub.

Для косвенного вызова функций Winsock используем указатели на функции:

Перед использованием функций динамически разрешим их адреса:

Наконец, используем эти функции в логике создания обратной оболочки: GitHub.

Как обычно, скомпилируем код PoC с помощью MinGW. Введите следующую команду:

В Kali Linux это выглядит так:

Рисунок 7.5. Компиляция нашей вредоносной программы

Затем, как обычно, запустим её на машине жертвы:

Результат выполнения этой команды в Windows 10 выглядит следующим образом:

Рисунок 7.6. Обратная оболочка, запущенная на машине Windows

Этот метод также используется в настоящем вредоносном ПО.

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

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

Рассмотрим практический пример, чтобы понять этот метод.

Здесь мы не будем изучать алгоритм хеширования и его важность для разработки вредоносного ПО: эта тема будет подробно рассмотрена в главе 9. Сейчас мы лишь напишем исходный код.

Прежде всего создадим простой сценарий PowerShell для вычисления хеша заданного имени функции. В нашем случае это строка CreateProcess:

Для строки CreateProcess результатом сценария будет 0x005d47253.

Таким образом, в коде на C эта функция выглядит следующим образом:

Полный исходный код доступен на GitHub: GitHub.

Скомпилируем его в Kali Linux:

Вот полученный результат:

Рисунок 7.7. Компиляция нашей вредоносной программы

Затем, как обычно, запустим её на машине жертвы:

Результат выполнения команды в Windows 10 показан ниже:

Рисунок 7.8. Обратная оболочка, запущенная на машине Windows

Как видите, всё сработало безупречно. Этот приём относится к наиболее популярным методам в настоящем вредоносном ПО, включая Carbanak, Carberp, Loki, Conti и другие программы. Исходный код самых известных вредоносных программ будет рассмотрен в заключительной части книги.

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

Простой пример на C, демонстрирующий аварийное завершение инструментов анализа посредством чрезвычайно сложных рекурсивных функций, доступен по адресу: GitHub.

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

Скомпилируем программу:

В Kali Linux это выглядит следующим образом:

Рисунок 7.9. Компиляция нашей вредоносной программы

Затем, как обычно, запустим её на машине жертвы:

Результат выполнения команды в Windows 10 показан ниже:

Рисунок 7.10. Обратная оболочка, запущенная на машине Windows

Этот приём также популярен в настоящем вредоносном ПО и таких инструментах, как Cobalt Strike, известный его применением.

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

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

Эти правила необходимо заранее создать и передать защитному решению. Один из инструментов, с помощью которых поставщики средств защиты создают правила обнаружения, - YARA.

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

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

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

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

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

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

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

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

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

Для шифрования полезной нагрузки hello.bin и обфускации функций можно использовать следующий сценарий Python:

Что такое обфускация вызовов функций и зачем разработчикам вредоносного ПО и специалистам красных команд её изучать? Рассмотрим наш файл hack1.exe из главы 2 (GitHub) в VirusTotal (VirusTotal) и откроем вкладку Details:

Рисунок 8.1. Вредоносные строки в нашей программе

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

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

Что же мы, разработчики вредоносного ПО, можем с этим сделать? Здесь и вступает в дело обфускация вызовов функций - метод сокрытия DLL и внешних функций, которые будут вызываться во время выполнения. Для этого можно использовать стандартные функции Windows API GetModuleHandle и GetProcAddress. Первая возвращает дескриптор определённой DLL, а вторая позволяет получить адрес в памяти требуемой функции, экспортируемой этой DLL.

Рассмотрим пример. Допустим, программе нужно вызвать функцию Meow, экспортируемую DLL с именем cat.dll. Сначала следует вызвать GetModuleHandle, а затем GetProcAddress, передав ей имя функции Meow. В результате мы получим адрес этой функции:

Что здесь особенно важно? При компиляции кода компилятор не включит cat.dll в таблицу адресов импорта. Поэтому антивирусный движок не сможет обнаружить её при статическом анализе.

Посмотрим, как применить этот приём на практике. Исходный код примера вредоносной программы доступен по адресу: GitHub.

Скомпилируем исходный код PoC:

На машине атакующего с Kali Linux это выглядит так:

Рисунок 8.2. Компиляция нашей вредоносной программы

Рассмотрим таблицу адресов импорта. Выполним следующую команду:

На моей машине с Kali Linux результат выглядит так:

Рисунок 8.3. Таблица адресов импорта

Как видите, наша программа использует KERNEL32.dll и импортирует различные функции, включая CreateThread, VirtualAlloc, VirtualProtect и WaitForSingleObject. Все они используются в нашем коде.

Попробуем скрыть VirtualAlloc. Сначала нужно найти объявление VirtualAlloc. Оно доступно здесь: документация Microsoft.

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

Теперь с помощью GetProcAddress получим этот адрес и заменим вызов VirtualAlloc на pVirtualAlloc:

Попробуем скомпилировать программу. Снова посмотрим на таблицу адресов импорта:

На моей машине с Kali Linux результат выглядит так:

Рисунок 8.4. Новая таблица адресов импорта без VirtualAlloc

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

На моей машине с Kali Linux это выглядит так:

Рисунок 8.5. Поиск VirtualAlloc с помощью команды strings

Мы получили такой результат, потому что при вызове GetProcAddress использовали строку в открытом виде. Что с этим можно сделать?

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

Для этого понадобятся ключ шифрования и строка. Добавим зашифрованную строку cVirtualAlloc и изменим код:

Также добавим логику XOR-расшифровки полезной нагрузки и строки:

Полный исходный код PoC доступен по адресу: GitHub.

Посмотрим, как всё работает. Скомпилируем исходный код PoC:

На машине атакующего с Kali Linux это выглядит так:

Рисунок 8.6. Компиляция нашей вредоносной программы

Затем запустим её на компьютере жертвы:

На машине с Windows 10 x64 результат выглядит так:

Рисунок 8.7. Запуск нашей вредоносной программы на машине с Windows 10 и включённым Windows Defender

Этот пример демонстрирует, что происходит при выполнении исполняемого файла и как реагирует Microsoft Defender. Отлично!

Ещё раз проверим исполняемый файл с помощью следующей команды strings, а затем запустим его на компьютере жертвы:

На моей машине с Kali Linux это выглядит так:

Рисунок 8.8. VirtualAlloc отсутствует в выводе strings

Если загрузить наш образец в VirusTotal, обнаружится, что вредоносным его считают лишь 14 из 70 антивирусных движков:

Рисунок 8.9. Результат проверки нашего образца в VirusTotal

Этот файл доступен по адресу: VirusTotal.

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

Я оставляю это вам в качестве упражнения. Решения находятся в GitHub-репозитории книги: GitHub.

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

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

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

Рассмотрим простой PoC-код на C, демонстрирующий логику сна и задержек: GitHub.

Посмотрим, как всё работает. Скомпилируем PoC-код на машине атакующего с Kali Linux x64 или Parrot Security OS:

На машине атакующего с Kali Linux это выглядит так:

Рисунок 8.10. Компиляция нашего PoC-кода

Затем на машине жертвы - в моём случае с Windows 10 x64 - выполним команду:

Вот результат:

Рисунок 8.11. Запуск hack.exe

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

Набор API Windows под названием AMSI позволяет интегрировать любое приложение с антивирусным продуктом при условии, что этот продукт работает как поставщик AMSI. Разумеется, поставщиком AMSI является Windows Defender, как и многие сторонние антивирусные решения.

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

Чтобы предоставить экземпляр AMSI, приложение должно загрузить amsi.dll в своё адресное пространство и вызвать последовательность экспортируемых этой DLL API AMSI. Подключив PowerShell к такому инструменту, как APIMonitor, можно увидеть, какие API он вызывает.

Два основных метода обхода AMSI - обфускация и исправление модуля amsi.dll в памяти. В этой главе мы рассмотрим первый вариант.

Предположим, нам нужно выполнить следующую команду:

Вот что выведет машина жертвы:

Рисунок 8.12. Попытка загрузить и запустить вредоносный сценарий

Как видите, специалисты по тестированию на проникновение в сетях Active Directory (AD) часто сталкиваются с этой проблемой во множестве общеизвестных сценариев.

Как именно работает AMSI? Для обнаружения команд, признанных опасными, и потенциально вредоносных сценариев применяется обнаружение на основе строк.

Как же его обойти?

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

Рисунок 8.13. Метод разделения строки

Этот подход широко применяется для обфускации.

Рассмотрим более совершенный метод обхода - системные вызовы (syscalls).

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

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

Код ошибки содержится в значении NTSTATUS, возвращаемом всеми системными вызовами. При успешном выполнении системный вызов возвращает код состояния 0, означающий, что операция завершена успешно.

Корпорация Microsoft не документировала большинство системных вызовов, поэтому в модулях системных вызовов используется справочник NTDLL проекта ReactOS: ReactOS Doxygen.

Многие системные вызовы обрабатываются и отправляются из библиотеки ntdll.dll.

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

Кроме того, системные вызовы можно применять для обхода средств защиты на уровне узла.

У каждого системного вызова есть уникальный номер, называемый идентификатором системного вызова или номером системной службы. Рассмотрим пример. Если открыть notepad.exe в отладчике x64dbg, можно увидеть, что системный вызов NtAllocateMemory имеет идентификатор 18:

Рисунок 8.14. Идентификатор системного вызова NtAllocateMemory равен 18

Однако обратите внимание: идентификаторы системных вызовов различаются в зависимости от операционной системы, например Windows 10, Windows 7 или Windows 11, а также её версии, например Windows 10 v1903 или Windows 10 1809:

Рисунок 8.15. Windows 10 v1903

Рассмотрим пример.

Возьмём пример, похожий на рассмотренное в главе 2 внедрение DLL: GitHub.

Единственное отличие заключается в следующем коде:

Скомпилируем его:

На моей машине с Kali Linux это выглядит так:

Рисунок 8.16. Компиляция hack.c

Затем запустим программу на машине жертвы:

Рисунок 8.17. Запуск hack.exe на машине жертвы

Запустим её и подключим к отладчику x64dbg:

Рисунок 8.18. Запуск hack.exe через x64dbg

Как видите, hack.exe имеет тот же идентификатор системного вызова - 18.

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

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

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

Ниже приведён пример системного вызова, сформированного в ассемблерном файле syscall.asm:

Эту ассемблерную функцию можно использовать вместо NtAllocateVirtualMemory с GetProcAddress и GetModuleHandle, получив тот же результат. При этом отпадает необходимость вызывать NtAllocateVirtualMemory из адресного пространства ntdll, содержащего перехваты, а значит, эти перехваты обходятся.

В следующем коде показано, как определить и использовать функцию myNtAllocateVirtualMemory в программе на C: GitHub.

Чтобы включить ассемблерную функцию в программу на C и определить её параметры, имя и возвращаемый тип, необходимо применить директиву extern "C" (EXTERN_C). Эта директива препроцессора связывает и вызывает функцию в соответствии с соглашениями языка C, указывая, что функция определена в другом месте. Такой подход можно использовать и при включении в код функций системных вызовов, написанных на языке ассемблера. Чтобы добавить в проект написанные на ассемблере вызовы, следует преобразовать их в синтаксис шаблона ассемблера, определить функцию директивой EXTERN_C и добавить функцию в код либо сохранить её в заголовочном файле, который затем подключается к проекту.

Скомпилируем файл .asm:

На машине атакующего с Kali Linux это выглядит так:

Рисунок 8.19. Компиляция syscall.asm

Теперь скомпилируем код на C:

На моей машине атакующего с Kali Linux это выглядит так:

Рисунок 8.20. Компиляция кода на C для hack2.exe

Затем выполним вредоносную программу на устройстве жертвы:

Вот вывод на машине жертвы с Windows 10 x64:

Рисунок 8.21. Запуск hack.exe на машине с Windows x64 v1903

Как видите, всё выполнилось безупречно!

Кроме того, для удобства я добавил практический пример, в котором программа запускает mspaint.exe, а затем внедряется в него с помощью системных вызовов: GitHub.

А как насчёт обхода EDR?

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

В этом практическом примере мы исследуем McAfee EDR. Механизм перехвата в другом EDR может отличаться от механизма McAfee EDR.

Создадим простой PoC-пример. Он доступен в GitHub-репозитории книги: GitHub.

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

Скомпилируем программу следующей командой:

На моей машине атакующего с Kali Linux это выглядит так:

Рисунок 8.22. Компиляция кода на C для hack4.exe

Сначала запустим вредоносную программу на устройстве жертвы без повторного отображения:

На машине с Windows 10 x64 это выглядит так:

Рисунок 8.23. Логика перехвата McAfee EDR

Теперь обновим вредоносную программу, добавив логику повторного отображения ntdll.dll, и запустим её:

На машине с Windows 10 x64 результат выглядит так:

Рисунок 8.24. Запуск hack4.exe на виртуальной машине Windows 10 x64

Как видите, всё выполнилось безупречно!

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

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

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

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

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

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

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

В этой главе мы рассмотрим различные криптографические и некриптографические хеш-функции и покажем их применение на практике.

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

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

• сигнатурное обнаружение;

• аналитика угроз;

• устранение дубликатов образцов вредоносного ПО.

Перейдём к практическим реализациям методов хеширования и их применению при разработке вредоносного ПО.

В этом разделе мы подробнее рассмотрим распространённые алгоритмы хеширования, часто применяемые в сфере безопасности, для проверки целостности данных и хеширования паролей. Мы изучим характеристики и типичные сценарии использования MD5, SHA-1, SHA-256 и Bcrypt.

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

Хотя простые шифры часто критикуют за недостаточную сложность, они дают вредоносному ПО множество преимуществ:

• Они достаточно компактны и поэтому способны работать в условиях ограниченного пространства, например в эксплуатируемом шелл-коде.

• Они не столь явно заметны, как более сложные шифры.

• Благодаря минимальным накладным расходам они почти не влияют на производительность.

В этом разделе мы рассмотрим несколько простых шифров и покажем их применение при разработке вредоносного ПО.

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

Простой шифр подстановки букв ROT13, название которого означает поворот на 13 позиций и иногда записывается как ROT-13, заменяет заданную букву тринадцатой следующей за ней буквой латинского алфавита. ROT13 - особый случай шифра Цезаря, алгоритма, возникшего в Древнем Риме. Поскольку в базовом латинском алфавите 26 букв, то есть 2 x 13, ROT13 является обратным самому себе: для отмены ROT13 применяется тот же алгоритм, поэтому одно и то же действие подходит для кодирования и декодирования.

Другой, хотя и менее распространённый вариант - ROT47. Он преобразует 94 символа ASCII с кодами от 33, то есть символа !, непосредственно следующего за пробелом, до 126, <. Обфусцируя знаки препинания, буквы и цифры, он сохраняет результат в безопасном печатном 7-битном ASCII.

Рассмотрим практическую реализацию простых шифров применительно к разработке вредоносного ПО.

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

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

Процесс использует DLL Winsock посредством функции WSAStartup:

Затем создаётся сокет и устанавливается соединение с удалённым узлом:

После этого область памяти заполняется, а свойства Windows задаются с помощью структуры STARTUPINFO (sui):

Это необходимо потому, что функция CreateProcess принимает указатель на структуру STARTUPINFO в качестве одного из параметров:

Предыдущий код демонстрирует создание обратной оболочки для Windows без каких-либо методов кодирования и шифрования.

Кодирование Base64 служит для представления двоичных данных в виде строки ASCII. Оно широко применяется при разработке вредоносного ПО, а название Base64 происходит от стандарта Multipurpose Internet Mail Extensions (MIME). Изначально Base64 предназначался для кодирования вложений электронной почты, но получил широкое распространение в HTTP и XML. Кодирование Base64 преобразует двоичные данные в ограниченный набор из 64 символов. Для разных видов Base64 существуют различные схемы, или алфавиты; все они используют 64 основных символа и дополнительный символ заполнения, обычно =.

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

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

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

• Вредоносное ПО часто взаимодействует с сервером управления и контроля. Криптография позволяет защитить эту связь и затруднить её обнаружение.

• Авторы вредоносного ПО могут шифровать или обфусцировать код, чтобы обходить статический анализ и сигнатурное обнаружение.

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

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

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

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

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

Рассмотрим пример реализации защищённой связи в распространённом сценарии шифрования и расшифровки сообщений между двумя сторонами.

Создадим простой пример из двух программ: получателя - HTTPS-сервера Linux - и клиентских программ, то есть вредоносного ПО Windows, передающих ему информацию.

Для этого создадим HTTPS-сервер на Python: GitHub.

Логика очень проста: получить POST-запрос, расшифровать данные и вывести результат.

Разберём код по частям. Сначала импортируем необходимые модули:

Рассмотрим их подробнее:

• http.server: предоставляет базовые классы для реализации веб-серверов. Мы используем его для создания HTTP-сервера.

• socketserver: упрощает написание сетевых серверов. Мы используем его совместно с http.server.

• ssl: предоставляет доступ к криптографическим протоколам Secure Socket Layer (SSL). Мы используем его для включения HTTPS на сервере.

• urllib.parse: предоставляет функции анализа URL. Мы используем его для разбора входящих запросов.

Теперь зададим конфигурацию:

Затем создадим собственный класс обработчика запросов, производный от http.server.BaseHTTPRequestHandler. В нём определяется переменная класса XOR_KEY, представляющая ключ XOR для шифрования и расшифровки:

Метод xor выполняет операцию XOR между заданными данными и ключом:

Метод xor_decrypt расшифровывает полученные данные с помощью метода xor и заранее определённой переменной класса XOR_KEY:

Метод do_POST считывает зашифрованные данные из запроса, расшифровывает их с помощью XOR и выводит результат:

В конце сценария мы определили функцию run_https_server. Она создаёт экземпляр socketserver.TCPServer с заданным адресом сервера и классом MyHTTPRequestHandler в качестве обработчика запросов. Функция оборачивает сокет сервера средствами SSL/TLS посредством ssl.wrap_socket, используя указанные файлы сертификата и ключа. Наконец, сервер запускается и с помощью метода serve_forever неограниченно ожидает входящие соединения.

А что насчёт клиента Windows? Код доступен по адресу: GitHub.

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

Как видно из исходного кода, выполняется следующая последовательность действий:

1. Вредоносная программа собирает базовые сведения о системе.

2. Затем она устанавливает соединение с удалённым сервером посредством WinHTTP.

3. Далее программа отправляет POST-запрос, содержащий сведения о системе.

4. Наконец, она обрабатывает ответы сервера и закрывает все дескрипторы WinHTTP.

Полный исходный код находится в GitHub-репозитории книги.

Скомпилируем его следующей командой:

На моей машине с Kali Linux команда даёт следующий результат:

Рисунок 11.6. Компиляция клиентского кода hack.c

Подготовим Python-сервер server.py на машине атакующего:

Рисунок 11.7. Запуск HTTPS-сервера Python

Наконец, запустим hack.exe на машине жертвы с Windows:

Рисунок 11.8. Запуск hack.exe

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

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

Рассмотрим ещё один пример. В этом разделе мы создадим шаблон классического внедрения полезной нагрузки, показанный в GitHub-репозитории книги: GitHub.

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

Разберём его:

1. Определение полезной нагрузки:

• encryptedPayload: заполнитель для зашифрованной полезной нагрузки.

• decryptionKey: заполнитель для ключа шифрования и расшифровки.

2. Функция расшифровки:

• decryptPayload: функция XOR-расшифровки, принимающая буфер данных, его длину, ключ расшифровки и длину ключа. Она расшифровывает буфер данных операцией XOR с ключом.

3. Главная функция:

A. Сначала она получает идентификатор целевого процесса из аргументов командной строки.

B. Затем открывает указанный процесс посредством OpenProcess.

C. Далее расшифровывает полезную нагрузку с помощью decryptPayload.

D. Затем выделяет буфер памяти в целевом процессе посредством VirtualAllocEx.

E. После этого записывает расшифрованную полезную нагрузку в выделенный буфер с помощью WriteProcessMemory.

F. Затем создаёт в целевом процессе удалённый поток для выполнения внедрённого кода посредством CreateRemoteThread.

G. Наконец, закрывает дескриптор процесса.

Теперь создадим сценарий Python, который заполняет этот файл уже зашифрованной полезной нагрузкой. Он находится в GitHub-репозитории книги: GitHub.

Логика проста: этот сценарий Python генерирует полезную нагрузку обратной оболочки, шифрует её простым шифром XOR, а затем компилирует в исполняемый файл Windows.

Как видите, random_key() генерирует случайный ключ для XOR-шифрования, а xor(data, key) выполняет XOR-шифрование предоставленных данных заданным ключом.

Сценарий Python использует Metasploit (msfvenom) для создания полезной нагрузки обратной оболочки с указанными узлом и портом.

Теперь необходимо выполнить следующие действия:

1. Прочитать сформированную полезную нагрузку из файла.

2. Зашифровать полезную нагрузку с помощью XOR.

3. Изменить файл шаблона C temp.c, включив в него зашифрованную полезную нагрузку и ключ шифрования.

Наконец, скомпилируем изменённый шаблон в исполняемый файл Windows hack.exe посредством кросс-компилятора MinGW.

Запустим сценарий следующей командой:

На моей машине с Kali Linux получен следующий вывод:

Рисунок 11.9. Выполнение логики шифрования через Python

Запустим программу на виртуальной машине с Windows 10 x64:

В моём случае шелл-код внедряется в процесс mspaint.exe:

Рисунок 11.10. Запуск hack.exe на машине с Windows

Похоже, наша логика выполнилась - обратная оболочка создана. Отлично!

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

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

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

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

Подробнее программы-вымогатели будут рассмотрены в главе 16.

В предыдущих главах мы рассмотрели популярные и хорошо изученные алгоритмы кодирования и шифрования, такие как XOR, AES, RC4 и Base64. В последние годы я задавался вопросом: «Что, если использовать другие продвинутые алгоритмы шифрования, основанные на простых?» Я решил провести исследование, применить различные алгоритмы шифрования, представленные публике в 1980-х и 1990-х годах, и посмотреть, как их использование влияет на оценку VirusTotal. Можно ли применять их при разработке вредоносного ПО? Рассмотрим несколько алгоритмов и практических примеров шифрования полезной нагрузки.

Tiny Encryption Algorithm (TEA) - блочный шифр с симметричным ключом, который работает с 64-битными блоками и использует 128-битный ключ. Основная последовательность шифрования TEA выглядит так:

1. Расширение ключа: 128-битный ключ разделяется на два 64-битных подключа.

2. Инициализация: 64-битный блок открытого текста делится на два 32-битных блока.

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

• Сложение: два 32-битных блока объединяются посредством побитового сложения по модулю 2^32.

• XOR: один из подключей складывается по XOR с одним из 32-битных блоков.

4. Сдвиг: результат предыдущего этапа циклически сдвигается влево на определённое число бит.

5. XOR: результат сдвига складывается по XOR с другим 32-битным блоком.

6. Завершение: два 32-битных блока объединяются и образуют 64-битный блок шифротекста.

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

В 1984 году У. Э. Мадрыга представил алгоритм Madryga как блочный шифр. Он был создан для простой и эффективной программной реализации. Одной из его отличительных особенностей были зависящие от данных вращения: количество вращений при шифровании определялось шифруемыми данными. Такой подход впоследствии использовался в других шифрах, включая RC5 и RC6.

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

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

Я решил реализовать шифрование и расшифровку полезной нагрузки посредством TEA: GitHub.

Как видите, для простоты я использовал полезную нагрузку окна сообщения Meow-meow!:

В Kali Linux это выглядит так:

Рисунок 12.1. Создание полезной нагрузки посредством msfvenom

Теперь необходимо обновить логику, применив алгоритм TEA и классическое внедрение кода. Изменим классическое внедрение:

1. Заменим полезную нагрузку meow-meow на зашифрованную посредством TEA.

2. Добавим функцию decryptUsingTEA.

3. Расшифруем и внедрим полезную нагрузку.

Полный исходный код находится в GitHub-репозитории книги: GitHub.

Чтобы скомпилировать PoC-код на C, выполним следующую команду:

В Kali Linux это выглядит так:

Рисунок 12.2. Компиляция hack2.c

Затем выполним программу на любой машине с Windows:

Например, в Windows 10 получим следующий вывод:

Рисунок 12.3. Запуск hack2.exe на машине с Windows

Как видите, пример сработал ожидаемым образом: полезная нагрузка была расшифрована и внедрена в notepad.exe.

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

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

При создании ключа необходимо выбрать два простых числа, обозначаемых p и q, и вычислить их произведение n = p*q. Безопасность RSA основана на трудности определения p и q по n. Чем больше p и q, тем сложнее найти их, зная n.

Полный исходный код находится в GitHub-репозитории книги: GitHub.

Основная логика довольно проста:

1. Выбрать два больших простых числа.

2. Вычислить n - модуль - и phi, функцию Эйлера.

3. Выбрать открытый показатель e.

4. Вычислить закрытый показатель d.

5. Зашифровать сообщение открытым ключом.

6. Расшифровать сообщение закрытым ключом.

Большинство функций программы предназначены для математических вычислений.

Сначала идёт функция, проверяющая, является ли число простым:

Затем следует функция нахождения наибольшего общего делителя (GCD) двух чисел:

Далее функция находит число e, такое что 1 < e < phi и gcd(e, phi) = 1:

Следующая функция находит мультипликативное обратное числа по модулю:

Наконец, следующая функция выполняет модульное возведение в степень:

Скомпилируем программу:

В Kali Linux это выглядит так:

Рисунок 12.4. Компиляция кода hack.c

Затем запустим hack.exe на машине жертвы с Windows:

Рисунок 12.5. Запуск hack.exe

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

Теперь попробуем применить ту же логику для шифрования строк. Например, зашифруем и расшифруем строку cmd.exe: GitHub.

Всё здесь устроено так же; отличаются только функции шифрования и расшифровки:

Скомпилируем программу:

В Kali Linux это выглядит так:

Рисунок 12.6. Компиляция кода hack2.c

Затем запустим hack2.exe на машине жертвы с Windows:

Рисунок 12.7. Запуск hack2.exe

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

Возьмём зашифрованную строку 24,597,2872,1137,3071,55,3071,0, то есть cmd.exe, расшифруем её и запустим обратную оболочку, как в главе 10:

Скомпилируем программу:

На моей машине с Kali Linux получен следующий вывод:

Рисунок 12.8. Компиляция примера hack3.c

Теперь запустим программу на виртуальной машине с Windows 10 x64:

Вот результат выполнения hack3.exe на машине жертвы с Windows:

Рисунок 12.9. Запуск hack3.exe на машине с Windows

Всё работает безупречно: обратная оболочка создана, как и ожидалось!

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

Поскольку хеши и алгоритмы шифрования, такие как Caesar, Base64 и MurmurHash, хорошо известны исследователям безопасности, иногда они могут служить признаками вредоносной активности программы и привлекать лишнее внимание защитных решений. А как насчёт пользовательских методов шифрования или кодирования?

Рассмотрим ещё один пример. Здесь мы создадим обратную оболочку Windows, закодировав строку cmd.exe. Для кодирования я буду использовать алгоритм Base58: GitHub.

Логика проста: эта программа на C декодирует строку cmd.exe алгоритмом Base58 и создаёт обратную оболочку Windows.

Как видите, функция base58decode() содержит логику декодирования:

Функция base58encode() содержит логику кодирования:

Скомпилируем программу:

На моей машине с Kali Linux получен следующий вывод:

Рисунок 12.10. Компиляция нашего PoC-кода

Запустим программу на виртуальной машине с Windows 10 x64:

В моём случае получен следующий результат:

Рисунок 12.11. Запуск hack.exe на машине с Windows

Похоже, наша логика выполнилась: обратная оболочка создана! Отлично.

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

Что такое ECC и как она работает? Эта технология лежит в основе Bitcoin и Ethereum, шифрует ваши сообщения iMessage и является частью практически каждого значимого посещаемого вами веб-сайта.

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

В 1977 году были представлены алгоритм RSA и алгоритм обмена ключами Диффи-Хеллмана. Революционность этих новых алгоритмов заключалась в том, что они стали первыми практическими криптографическими схемами на основе теории чисел. Более того, они впервые позволили двум сторонам безопасно взаимодействовать без общего секрета.

Как вы могли заметить при рассмотрении простых чисел, система RSA использует класс задач односторонней факторизации. Каждое число имеет уникальное разложение на простые множители. Например, 8 можно представить как 2 в степени 3, а 30 - как 2*3*5. ECC не опирается на факторизацию, а вместо этого решает уравнения - эллиптические кривые - следующего вида:

Предыдущее уравнение называется формой Вейерштрасса для эллиптических кривых и выглядит так:

Рисунок 12.12. Пример эллиптической кривой

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

Рассмотрим ещё один пример. Как ECC применяется при разработке вредоносного ПО?

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

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

Я рассмотрю упрощённый пример использования ECC в Python 3 с библиотекой tinyec. Он включает функции создания пар ключей, шифрования и расшифровки файлов посредством протокола Диффи-Хеллмана на эллиптических кривых (ECDH). Обратите внимание, что этот пример не обрабатывает все аспекты проверки ошибок и управления ключами, необходимые в производственной среде.

Код Python доступен здесь: GitHub.

Ниже приведено пошаговое объяснение кода Python:

1. Прежде всего импортируем необходимые библиотеки:

2. Затем создадим пары ключей:

A. Используем кривую secp256r1 (P-256), широко применяемую эллиптическую кривую.

B. Алиса создаёт свою пару ключей - закрытый и соответствующий открытый ключ.

C. Боб создаёт свою пару ключей - закрытый и соответствующий открытый ключ:

3. Затем Алиса получает общий секрет с помощью своего закрытого ключа и открытого ключа Боба, а Боб - с помощью своего закрытого ключа и открытого ключа Алисы:

4. Основная логика предусматривает шифрование файла с помощью AES:

5. Теперь расшифруем файл с помощью AES:

Расшифрованный файл sample_decrypted.txt должен содержать исходные данные.

Как вы увидите в последующих главах, ECC применяется в настоящем вредоносном ПО такими программами-вымогателями, как Babuk, TeslaCrypt и CTB-Locker.

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

Концепция компьютерных вирусов возникла в 1980-х годах, когда начали распространяться персональные компьютеры. Одним из первых и самых известных примеров стал вирус Brain, обнаруженный в 1986 году. Этот вирус загрузочного сектора поражал IBM PC, распространялся через заражённые гибкие диски и вызывал сравнительно безобидные, но заметные последствия, например изменял метки томов.

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

Червь Morris (1988) стал знаковым событием: он заразил тысячи компьютеров на базе UNIX и продемонстрировал уязвимость взаимосвязанных сетей. В 1990-х произошла смена парадигмы: появились самораспространяющиеся черви, причинявшие обширный ущерб взаимосвязанным системам.

В начале 2000-х червь ILOVEYOU (2000) выделился как классический пример атаки социальной инженерии. Замаскированный под любовное письмо, он распространялся через вложения электронной почты, причинял значительный ущерб, перезаписывая файлы, и быстро заражал новые системы. Его глобальное воздействие подчеркнуло способность вредоносного ПО эксплуатировать человеческое поведение.

Stuxnet (2010) стал революционной вредоносной программой, созданной для конкретной цели - саботажа ядерной программы Ирана. Используя несколько уязвимостей нулевого дня, Stuxnet показал, что вредоносное ПО способно пересечь границу между киберпространством и физическим миром. Незаметно для широкой публики со Stuxnet начались повседневные кибервойны XXI века.

Вирус Stuxnet, который, как считается, был разработан Соединёнными Штатами и Израилем, являлся вредоносным ПО государственного уровня. Он был намеренно создан для саботажа иранской ядерной программы и фактически вывел из строя центрифуги для обогащения урана.

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

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

Вирус эффективно искал на заражённых рабочих станциях программное обеспечение Siemens: PCS 7, WinCC и STEP 7. Если Stuxnet находил объект, получал управление, проверял подключённое оборудование и подтверждал, что это действительно центрифуга, а не оборудование другого предприятия, он переписывал часть кода контроллера, чтобы изменить скорость вращения.

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

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

Банковские трояны Carberp (2010) и Carbanak (2014) были созданы для компрометации финансовых учреждений. Они сочетали сложные методы, чтобы незаконно получать конфиденциальные данные и координировать мошеннические транзакции. Их успехи подчеркнули динамичность вредоносного ПО, адаптирующегося к меняющейся среде интернет-банкинга.

В середине 2010-х получили распространение программы-вымогатели - вредоносное ПО, шифрующее пользовательские данные и требующее выкуп за их освобождение. Одним из первопроходцев был CryptoLocker (2013), применявший стойкое шифрование, чтобы удерживать файлы жертв в заложниках. Это ознаменовало переход к финансово мотивированной киберпреступности. Conti - программа-вымогатель, разработанная Conti Ransomware Gang, русскоязычной преступной группировкой с предполагаемыми связями с российскими спецслужбами. Conti также работает по бизнес-модели «программа-вымогатель как услуга» (RaaS).

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

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

Рассмотрим исходный код одной из функций из утечки Carberp: GitHub.

Посмотрим на функцию GetKernel32. По-видимому, это реализация функции, получающей базовый адрес модуля kernel32.dll. Для этого код сочетает язык ассемблера и обход структур данных внутри блока окружения процесса (PEB).

Разберём его пошагово:

Этот ассемблерный код получает указатель на PEB из блока окружения потока (TEB). FS:[0x30] - смещение PEB в TEB.

Получим список модулей:

Peb->Ldr получает указатель на структуру данных загрузчика внутри PEB, содержащую сведения о загруженных модулях. Head указывает на начало двусвязного списка загруженных модулей, а Entry инициализируется первой записью списка.

Затем выполним цикл по модулям:

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

Наконец, видна логика проверки хеша имени модуля:

Блок получает имя DLL BaseDllName и переводит его в нижний регистр. Затем имя передаётся функции CalcHashW, которая, вероятно, вычисляет хеш имени DLL. Если хеш совпадает с заданным значением 0x4B1FFE8E, возвращается базовый адрес модуля.

Как видите, здесь реализованы популярные приёмы:

• Для сравнения используется хеш имени DLL, а не прямое сравнение строк. Это распространённый способ обхода простого сопоставления строк в эвристиках защиты от вредоносного ПО.

• Код динамически обходит PEB и список модулей, что делает его устойчивым к простому анализу шаблонов кода.

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

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

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

Чтобы найти GetProcAddress и GetModuleHandle, я использовал функцию getApiAddr из главы 9: GitHub.

Для простоты, как обычно, я использовал полезную нагрузку окна сообщения Meow-meow:

В Kali Linux это выглядит так:

Рисунок 13.1. Создание полезной нагрузки посредством msfvenom

Полный исходный код доказательства концепции (PoC) можно загрузить из GitHub-репозитория: GitHub.

Чтобы скомпилировать PoC-код на C, введём:

В Kali Linux это выглядит так:

Рисунок 13.2. Компиляция hack.c

Затем выполним программу на любой машине с Windows:

Например, в Windows 10 это выглядит так:

Рисунок 13.3. Запуск hack.exe на машине с Windows

Как видите, пример сработал ожидаемым образом.

Исследуем исходный код UEFI-буткита BlackLotus, опубликованный на GitHub 12 июля 2023 года: GitHub.

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

Какой алгоритм хеширования использовали авторы этой программы-вымогателя? По-видимому, здесь применён алгоритм Cyclic Redundancy Check 32 (CRC32), как видно в файле GitHub:

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

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

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

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

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

Термин «APT» получил известность после раскрытия в 2010 году червя Stuxnet - революционного вредоносного ПО, созданного для атаки на ядерные объекты Ирана и подробно рассмотренного в главе 13. Однако корни атак в стиле APT прослеживаются и в более ранних инцидентах.

Одним из первых предшественников APT была операция Moonlight Maze, обнаруженная в конце 1990-х годов. Эта серия кибервторжений была направлена на военные и государственные системы США. Злоумышленники, предположительно поддерживаемые государством, в течение длительного периода выводили большие объёмы конфиденциальных данных, заложив основу устойчивого характера APT.

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

2009 год стал важным поворотным моментом благодаря атакам Operation Aurora. Google и несколько других крупных компаний стали жертвами скоординированной и чрезвычайно сложной кампании кибершпионажа. Злоумышленники, которых связывали с Китаем, нацелились на репозитории исходного кода и интеллектуальную собственность. Событие подчеркнуло уровень сложности и организованности APT.

Вредоносное ПО Hydraq, применённое в Operation Aurora, продемонстрировало передовые возможности, включая эксплуатацию уязвимостей нулевого дня. Злоумышленники использовали ранее неизвестные уязвимости популярного ПО для доступа к целевым сетям, создав прецедент применения APT самых современных методов.

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

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

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

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

Хотя NotPetya первоначально считался программой-вымогателем, позднее выяснилось, что это разрушительное вредоносное ПО-вайпер. Происхождение NotPetya связывали с российскими военными; программа показала способность атак в стиле APT вызывать широкомасштабные нарушения и финансовый ущерб.

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

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

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

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

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

APT28, которую связывают с российской разведкой, обвинялась в различных громких операциях кибершпионажа. Среди известных кампаний - атаки на политические организации, в том числе Национальный комитет Демократической партии (DNC) во время президентских выборов США 2016 года.

APT28 применяет целевой фишинг, уязвимости нулевого дня и такое вредоносное ПО, как Sofacy и X-Agent. Её TTP часто предусматривают применение документов-приманок и скомпрометированной инфраструктуры для управления и контроля.

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

Cozy Bear использует фишинговые письма и связывается с применением сложной вредоносной программы CozyDuke. Группа демонстрирует высокий уровень операционной безопасности, затрудняющий атрибуцию.

Lazarus Group, предположительно связанная с Северной Кореей, ассоциируется с кибершпионажем, финансово мотивированными атаками и разрушительными кампаниями. Среди известных примеров - взлом Sony Pictures и атака программы-вымогателя WannaCry.

Lazarus Group применяет разные тактики, включая целевой фишинг, такое печально известное вредоносное ПО, как Destover, и атаки watering hole. Способность группы переключаться между киберпреступностью и кибершпионажем демонстрирует её универсальность.

Equation Group, которую многие связывают с Агентством национальной безопасности США (NSA), обвинялась во множестве сложных операций кибершпионажа. Группа получила известность благодаря развёртыванию мощной вредоносной платформы EquationDrug.

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

Tailored Access Operations (TAO) - подразделение NSA, отвечающее за проведение продвинутых киберопераций. Оно известно арсеналом сложных инструментов и методов, часто применяемых для сбора разведывательной информации.

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

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

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

В центре этих усилий находится MITRE ATT&CK - всеобъемлющая база знаний о TTP противника, организованная в структурированную матрицу. ATT&CK разработана некоммерческой корпорацией MITRE, занимающейся развитием технологий на благо общества, и является основополагающим ресурсом для аналитики угроз, поиска угроз и операций кибербезопасности. Классифицируя тактики и методы APT по стадиям цепочки кибератаки, ATT&CK предоставляет стандартизированную основу для понимания, категоризации и нейтрализации киберугроз.

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

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

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

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

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

Утечка Zeus на хакерские форумы даркнета положила начало тенденции, при которой авторы вредоносного ПО и киберпреступные группы стали открыто обмениваться вредоносными программами и торговать ими. Это привело к появлению специализированных платформ «вредоносное ПО как услуга» (malware-as-a-service, MaaS), где пользователи могли арендовать или покупать доступ к сложным вредоносным инструментам и услугам.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Citadel: сложный банковский троян, появившийся в начале 2010-х годов как преемник Zeus и SpyEye. Подобно предшественникам, Citadel предназначался для кражи финансовой информации и проведения мошеннических транзакций. По сообщениям, в 2013 году его исходный код утек в интернет, предоставив исследователям кибербезопасности сведения о развитых возможностях программы, включая применение шифрования и методов уклонения. Утечка привела к усилению внимания правоохранительных органов и специалистов по кибербезопасности к Citadel и в конечном счете способствовала пресечению его деятельности.

• Mirai: печально известное вредоносное ПО для ботнетов, атакующее устройства интернета вещей (IoT), такие как маршрутизаторы, камеры и цифровые видеорегистраторы (DVR). Mirai, впервые обнаруженный в 2016 году, прославился способностью заражать большое количество IoT-устройств и управлять ими, используя их для распределенных атак типа «отказ в обслуживании» (DDoS). В 2016 году исходный код Mirai утек в интернет, что привело к распространению ботнетов на его основе и резкому росту DDoS-атак. Утечка подчеркнула уязвимость IoT-устройств к заражению вредоносным ПО и необходимость совершенствования мер защиты от подобных угроз.

Хотя программы-вымогатели не включены в этот список, стоит отметить, что исходный код нескольких их семейств, таких как Locky, Cerber и GandCrab, также в разное время утекал или становился общедоступным. Эти утечки способствовали распространению вариантов программ-вымогателей и развитию модели «программа-вымогатель как услуга» (ransomware-as-a-service, RaaS), позволяя запускать атаки с применением программ-вымогателей даже менее технически подготовленным киберпреступникам.

Итак, как утечки исходного кода влияют на популярное вредоносное ПО?

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

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

Одной из примечательных особенностей исходного кода Zeus было применение методов шифрования и обфускации для сокрытия вредоносных действий и уклонения от обнаружения средствами защиты. Это обозначило переход разработки вредоносного ПО к более сложным тактикам обеспечения скрытности и закрепления. Zeus стал одним из первопроходцев в применении алгоритмов шифрования RC4 и хеширования Cyclic Redundancy Check 32 (CRC32).

Пример реализации алгоритма RC4 показан на следующем снимке экрана:

Рисунок 15.1. Реализация RC4 в трояне Zeus

Как видно, Crypt::_rc4 реализует часть логики RC4, отвечающую за генерацию псевдослучайной последовательности.

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

Рисунок 15.2. Реализация CRC32 в трояне Zeus

Этот вариант CRC-32 использует полином x^8 + x^7 + x^6 + x^4 + x^2 + 1 (0xEDB88320), задает начальное значение CRC равным 0xFFFFFFFF и инвертирует итоговый CRC.

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

Например, ниже показаны некоторые функции, реализованные в библиотеке для работы с реестром Windows:

Рисунок 15.3. Работа с реестром Windows в Carberp

Как видно, в данном случае Registry::CreateKey реализует логику создания ключа в реестре Windows.

Здесь также реализована функция GetKernel32, логику которой мы рассматривали в главе 13 (см. GitHub).

Обратите внимание на функцию из главы 13 и логику функции на следующем снимке экрана:

Рисунок 15.4. Функция GetKernel32 в Carberp

Разберем, что она делает:

1. Инициализирует указатель Peb на структуру блока окружения процесса (PEB).

2. Затем получает из PEB указатель на таблицу данных загрузчика.

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

4. В цикле получает имя каждого загруженного модуля и вычисляет для него хеш.

5. Если вычисленный хеш совпадает с заданным значением (0x4B1FFE8E), возвращает базовый адрес модуля.

Как видим, обе функции предназначены для получения базового адреса модуля kernel32.dll из PEB процесса Windows.

Летом 2013 года исходный код Carberp утек в интернет; одна хакерская группа использовала его, чтобы с меньшими затратами создать Carbanak.

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

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

Далее рассмотрим работу ядра трояна, начав с его взаимодействия с WinAPI:

Рисунок 15.5. Взаимодействие Carbanak с WinAPI

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

Ниже приведен список обязательных DLL, содержащих WinAPI; это лишь часть библиотек, которые использует бот-троян Carbanak:

Рисунок 15.6. Список необходимых DLL для бота Carbanak

Кроме того, в блоке инициализации модуля, функции bool Init(), присутствует код, динамически получающий функции GetProcAddress и LoadLibraryA по их хешам:

Рисунок 15.7. Динамический вызов по хешу

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

Рисунок 15.8. Функция GetApiAddr в исходном коде Carbanak

Как видно, Carbanak применяет один из самых простых, но эффективных приемов обхода антивирусных движков: вызывает функции по хешам вместо использования имен.

Следовательно, если мыслить как разработчики трояна Carbanak, можно ли еще улучшить систему? Разумеется! Предположим, что для нашего вредоносного ПО мы используем технику внедрения в удаленный процесс. Анализ двоичного файла показывает, что применяемые функции, такие как CloseHandle, OpenProcess, VirtualAllocEx, WriteProcessMemory и CreateRemoteThread, перечислены в таблице адресов импорта двоичного файла. Антивирусы ищут сочетание этих Windows API, которые часто используются во вредоносных целях, поэтому оно вызывает подозрения. Таким образом, этот прием эффективен против большинства антивирусных движков.

Вернемся к нашему трояну: какой алгоритм хеширования использует Carbanak?

В файле core/source/misc.cpp можно увидеть следующее объявление хеш-функции:

Рисунок 15.9. Логика хеширования в исходном коде Carbanak

Кроме того, в файле bot/source/AV.cpp обнаружен метод определения конкретного используемого антивируса, что понятно уже из имени файла. Троян Carbanak выполняет стандартный поиск процессов следующим образом: GitHub

Затем хеши обнаруженных процессов сравниваются с хешами, содержащимися в этом конкретном образце, с помощью функции int AVDetect():

Рисунок 15.10. Логика обнаружения антивирусов в исходном коде Carbanak

Также здесь имеется функция IsPresentKAV(), которую тоже используют для обнаружения антивируса:

Рисунок 15.11. Логика обнаружения антивируса Kaspersky в исходном коде Carbanak

Полный исходный код из утечки Carbanak можно найти в следующем репозитории GitHub: GitHub.

Одна из важных особенностей Carbanak состоит в том, что на зараженных машинах он никак не проявляет себя во внешнем мире.

Создадим собственное вредоносное ПО, реализующее похожую логику: оно будет обнаруживать различные антивирусные движки и средства обнаружения и реагирования на конечных точках (EDR) на компьютерах с Windows.

Мы покажем лишь базовый код доказательства концепции (PoC), который обнаруживает движки антивирусов и EDR путем перечисления запущенных процессов Windows.

Прежде всего предположим, что у нас есть файл processes.txt следующего формата:

Затем определим следующую структуру:

Теперь прочитаем список процессов из файла:

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

Единственное отличие состоит в том, что, найдя процесс в списке, мы просто выводим его:

Полный исходный код нашей программы доступен на GitHub; его можно загрузить по следующей ссылке: GitHub.

Как обычно, скомпилируйте PoC-код с помощью mingw. Введите следующую команду:

В Kali Linux это выглядит так:

Рисунок 15.12. Компиляция PoC hack.c

На компьютере жертвы, в моем случае это Windows 10 x64 версии 1903, выполните следующее:

Результат выполнения этой команды показан на следующем снимке экрана:

Рисунок 15.13. Проверка на компьютере Windows с Windows Defender

Затем выполним проверку с антивирусом Bitdefender:

Рисунок 15.14. Проверка на компьютере Windows с антивирусом Bitdefender

Наконец, проверим компьютер Windows с антивирусом Kaspersky:

Рисунок 15.15. Проверка на компьютере Windows с антивирусом Kaspersky

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

Начнем с наиболее значимой и переломной утечки исходного кода Conti, а затем проанализируем исходный код программы-вымогателя HelloKitty.

Что представляет собой программа-вымогатель Conti? ContiLocker - программа-вымогатель, созданная группировкой Conti Ransomware Gang, преступной организацией, действующей в России и предположительно связанной с российскими службами безопасности. Кроме того, Conti использует бизнес-модель RaaS.

Утечку исходного кода программы-вымогателя Conti под названием ContiLeaks опубликовал украинский исследователь безопасности в ответ на поддержку киберпреступниками России во время вторжения в Украину в феврале 2022 года.

Структура исходного кода ContiLeaks выглядит следующим образом:

Рисунок 16.1. Структура исходного кода ContiLeaks conti_v3

Как видно, последняя дата обновления - 25 января 2021 года.

В утечке исходного кода присутствует решение Visual Studio, содержащее conti_v3.sln:

Рисунок 16.2. Решение Visual Studio

Оно предоставляет доступ к шифровальщику программы-вымогателя любому, кто сумеет его скомпилировать:

Рисунок 16.3. Шифровальщик программы-вымогателя

Кроме того, любой может использовать расшифровщик, показанный ниже:

Рисунок 16.4. Расшифровщик программы-вымогателя

Чтобы увидеть механизм взаимодействия с WinAPI, изучите папку api:

Рисунок 16.5. Папка api из ContiLeaks

Затем изучите файл getapi.cpp. Обратите внимание на следующий макрос:

Рисунок 16.6. Преобразование RVA в VA

Очевидно, этот макрос систематически применялся для преобразования относительного виртуального адреса (RVA) в виртуальный адрес (VA).

Найдите функцию GetApiAddr, которая сравнивает хеш заданной функции Windows API, чтобы определить ее адрес:

Рисунок 16.7. Динамический вызов по хешу

Иными словами, Conti применяет один из самых простых, но эффективных способов обхода антивирусных алгоритмов; мы уже писали об этом при анализе исходного кода Carbanak в главе 15.

А какой алгоритм хеширования использует Conti?

Рисунок 16.8. MurmurHash в исходном коде программы-вымогателя Conti

MurmurHash - некриптографическая хеш-функция, созданная Остином Эпплби. Мы писали и исследовали ее в главе 9.

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

Рисунок 16.9. Отключение перехвата в исходном коде программы-вымогателя Conti

Продолжим анализ. Как работает модуль threadpool? Помимо выделения собственного буфера для предстоящего шифрования, каждый поток инициализирует собственный криптографический контекст с помощью открытого ключа RSA и API CryptAcquireContextA следующим образом:

Рисунок 16.10. Модуль threadpool в исходном коде Conti

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

Рисунок 16.11. Очереди задач в исходном коде Conti

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

А что с шифрованием? В предыдущих главах мы столько о нем писали; как оно реализовано здесь?

Процесс шифрования начинается с генерации случайного ключа для заданного файла при помощи API CryptGenRandom:

Рисунок 16.12. Генерация случайного ключа для шифрования в исходном коде Conti

Что здесь интересно? Помимо 32-байтового ключа, эта логика случайным образом генерирует 8-байтовый IV. Очевидно, Conti использовал потоковый шифр ChaCha, разработанный Д. Дж. Бернштейном. Это видно по переменным ChaChaKey и ChaChaIV.

Вызов метода CheckForDataBases проверяет, возможно ли полное или частичное шифрование, как показано ниже:

Рисунок 16.13. Метод CheckForDataBases

Проверяется, входит ли расширение целевого файла в следующий список:

Вызов метода CheckForVirtualMachines проверяет возможность 20-процентного частичного шифрования:

Рисунок 16.14. Метод CheckForVirtualMachines

Такое частичное шифрование применяется для следующих расширений:

Что в данном контексте означает частичное шифрование? Conti применяет интересную логику шифрования файловой системы. Рассмотрим ее подробнее.

Полное шифрование применяется, если размер файла меньше 1048576 байт (1,04 ГБ); если размер больше 1048576 байт, но не превышает 5242880 байт (5,24 ГБ), шифруются только заголовки:

Рисунок 16.15. Полное шифрование и шифрование только заголовков

В остальных случаях применяется 50-процентное частичное шифрование:

Рисунок 16.16. Частичное шифрование

Режимы шифрования можно найти в другой части кода:

Рисунок 16.17. Режимы шифрования

Кроме того, в исходном коде был обнаружен интересный модуль под названием obfuscation:

Рисунок 16.18. Модуль obfuscation

Этот модуль использует ADVObfuscator (GitHub) для получения обфусцированного кода. Например, взгляните на следующие строки:

Рисунок 16.19. Применение ADVObfuscator для обфускации строк в Conti

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

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

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

Загружаемый архив hellokitty.zip содержит решение Microsoft Visual Studio, включающее шифровальщик и расшифровщик HelloKitty, а также библиотеку NTRUEncrypt, которую эта версия программы-вымогателя использует для шифрования файлов:

Рисунок 16.20. HelloKitty представляет собой решение Microsoft Visual Studio (.sln)

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

Например, взгляните на папку crc32:

Рисунок 16.21. Папка crc32

Код в этой папке представляет собой независимую реализацию алгоритма CRC-32.

Следующая папка называется decoder и содержит файлы с логикой расшифровки. Этот код предназначен для расшифровки файлов, зашифрованных программой-вымогателем HelloKitty. Важно отметить, что зашифрованные файлы имеют расширение .kitty:

Рисунок 16.22. Папка decoder с логикой расшифровки

Функция DWORD WINAPI decryptFile(file_to_decrypt *ftd) управляет процессом расшифровки файла с помощью алгоритмов NTRUEncrypt и AES.

Функция searchForFiles(PCWSTR widePath) выполняет поиск в заданном каталоге и добавляет файлы в очередь на расшифровку.

Функции bool CreateAndContinue(const wchar_t* _mutexName) и void CloseMutex() работают с мьютексом, предотвращая двойной запуск процесса.

Функция StopDoubleProcessRun проверяет наличие уже запущенных экземпляров процесса расшифровки.

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

Следующая папка - Innocent:

Рисунок 16.23. Папка Innocent

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

Рисунок 16.24. Реализация base64

Здесь также есть файл aesMbedTls.hpp:

Рисунок 16.25. Реализация AES-128 в программе-вымогателе HelloKitty

В этом коде представлен класс AES128MbedTls, содержащий необходимые возможности для шифрования и расшифровки AES-128 с использованием библиотеки Mbed TLS.

Класс изолирует функциональность AES, упрощая интеграцию шифрования и расшифровки AES-128 с Mbed TLS в программе на C++.

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

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

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

Дата: 12 мая 2017 года

Программа-вымогатель WannaCry быстро распространилась по миру, заразив более 200 000 компьютеров в 150 странах. Ее целью были системы под управлением устаревших версий Microsoft Windows. Атака затронула различные отрасли, включая здравоохранение, финансы и государственные учреждения.

WannaCry эксплуатировала уязвимость операционной системы Windows с помощью эксплойта EternalBlue, который был разработан Агентством национальной безопасности США (NSA), а позднее опубликован хакерской группой The Shadow Brokers. После заражения программа-вымогатель шифровала файлы на компьютере жертвы и требовала оплату в биткойнах за расшифровку.

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

Дата: 27 июня 2017 года

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

Подобно WannaCry, NotPetya использовала эксплойт EternalBlue для распространения по сетям. Однако, в отличие от традиционных программ-вымогателей, основной целью NotPetya, по всей видимости, было разрушение, а не финансовая выгода. Она шифровала главную загрузочную запись (MBR) зараженных компьютеров, делая их неработоспособными, и требовала оплату в биткойнах за расшифровку.

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

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

Дата: впервые обнаружена в январе 2018 года

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

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

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

Дата: впервые обнаружена в августе 2018 года

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

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

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

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

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

• Программа-вымогатель Conti: появившаяся в 2020 году разновидность Ryuk, известная высокими требованиями выкупа и агрессивной тактикой. Она часто атакует организации здравоохранения и связана с несколькими громкими атаками.

• Программа-вымогатель Sodinokibi (REvil): Sodinokibi, также известная как REvil, получила известность в 2019 году и с тех пор участвовала во множестве атак на компании по всему миру. Она работает по модели RaaS, а партнеры проводят атаки от имени операторов.

• Программа-вымогатель DarkSide: DarkSide попала в заголовки новостей в 2021 году после атаки на Colonial Pipeline, один из крупнейших топливопроводов США. Стоящая за DarkSide группа взяла на себя ответственность за атаку, которая привела к дефициту топлива и серьезным нарушениям.

• Программа-вымогатель Maze: Maze привлекла внимание тактикой кражи конфиденциальных данных перед шифрованием файлов и угрозой опубликовать сведения при неуплате выкупа. Хотя первоначальные операторы объявили об уходе в 2020 году, код Maze был перенят другими субъектами угроз.

• Программа-вымогатель CLOP: CLOP известна атаками на крупные предприятия и связана с несколькими громкими инцидентами. Она применяет такие методы, как двойное вымогательство, и активно атакует организации в производстве, технологиях и розничной торговле.

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

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

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

Для проникновения в системы и их шифрования LockBit применяет различные техники:

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

• Наборы эксплойтов: в некоторых случаях LockBit может эксплуатировать уязвимости ПО или операционных систем для получения несанкционированного доступа. Наборы эксплойтов с готовыми средствами эксплуатации известных уязвимостей часто применяются для доставки полезной нагрузки программы-вымогателя.

• RDP: операторы LockBit могут атаковать системы с открытыми портами RDP. Подбирая пароли или используя похищенные учетные данные для доступа к системам с RDP, злоумышленники могут развернуть программу-вымогатель непосредственно в скомпрометированных системах.

После запуска в системе жертвы LockBit шифрует файлы с помощью стойких алгоритмов, таких как Advanced Encryption Standard (AES), делая их недоступными пользователю. Затем программа показывает записку с требованием выкупа, обычно в виде текстового файла или всплывающего окна, содержащую инструкции по оплате и получению ключей расшифровки.

LockBit участвовала в нескольких громких атаках на организации разного масштаба и из разных отраслей. Среди заметных инцидентов:

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

• Финансовые организации: банки, инвестиционные компании и другие финансовые организации также становились целями LockBit. Такие атаки могут привести к финансовым потерям, репутационному ущербу и санкциям регулирующих органов.

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

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

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

Полный исходный код нашей программы доступен на GitHub; его можно загрузить по следующей ссылке: GitHub.

Как обычно, скомпилируйте PoC-код с помощью MinGW. Введите следующую команду:

В Kali Linux это выглядит так:

Рисунок 16.26. Компиляция нашего приложения «программы-вымогателя»

Для простоты наше приложение лишь шифрует и расшифровывает файл. Если расшифрованный файл совпадает с исходным, программа работает правильно.

Запустим ее на компьютере жертвы, в моем случае это Windows 10 x64 версии 1903:

Результат этой команды показан на следующем снимке экрана:

Рисунок 16.27. Новые зашифрованный и расшифрованный файлы

Как видно, создаются новый зашифрованный файл test.txt.AES и расшифрованный файл test.txt.decrypted.

Сравним исходный файл test.txt и файл test.txt.decrypted. Выполните следующую команду:

В Kali Linux это выглядит так:

Рисунок 16.28. Сравнение исходного и расшифрованного файлов

Можно также выполнить сравнение с помощью hexdump. Оно наглядно продемонстрирует идентичность файлов. Выполните следующее:

В Kali Linux это выглядит так:

Рисунок 16.29. Сравнение исходного и расшифрованного файлов с помощью hexdump

Как видим, эти файлы идентичны.

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