А. Белоус - Кибероружие и кибербезопасность. О сложных вещах простыми словами

Использование нескольких code cave’oe позволяет преодолеть ограничения с пространством. Здесь же дополнительный плюс в том, что обычно программный троян собирается из отдельных кусков. Однако изменение привилегий секции будет выглядеть подозрительным. Существуют продвинутые методы для модификации привилегий у областей памяти во время выполнения приложения с целью избежания прямого изменения флагов секции, но поскольку эти техники требуют специализированного шелл-кода, кодирования и парсинга таблицы IAT, эта тема будет затронута в следующих статьях.

При помощи утилиты Cminer очень легко подсчитать все code cave’bi бинарного файла. Используем команду./Cminerputty.exe 300 для поиска code cave’oe более 300 байт.

В нашем случае найдено 5 хороших экземпляров для последующего использования. Стартовый адрес задает адрес виртуальный памяти (virtual memory address, УМА) у code cave при загрузке

Puc. 8.26. Параметры найденных Code cave’oe

РЕ-файла в память. Смещение файла, измеряемого в байтах, — адрес местонахождения нужной области внутри РЕ-файла.

По результатам поиска выяснилось, что большинство областей находятся внутри секции данных. Поскольку в этих секциях не установлен флаг на выполнения, потребуются изменения. Размер бэкдо-ра около 400–500 байт, и области Cave 5 хватит за глаза. Стартовый адрес этой области нужно сохранить, а после изменения привилегий секции первый этап внедрения вредоноса можно считать завершенным. Теперь нужно перенаправить выполнение на нашу область.

На этом этапе нужно перенаправить поток выполнения на код бэкдора при помощи модификации нужной инструкции в исполняемом файле. Здесь следует упомянуть важную деталь относительно выбора инструкции для изменения. Все бинарные инструкции имеют размер в байтах. Чтобы перейти к адресу расположения бэкдора потребуется длинный переход (long jump) размером, который использует 5 или 6 байт. При изменении бинарного файла инструкция, которая будет патчиться, должна быть того же размера, что и длинный переход, иначе предыдущая и последующая инструкция будут испорчены.

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

Сокрытие внутри пользовательских функций

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

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

По нажатию кнопки «Open» из графической оболочки запускается функция проверки установленного IP-адреса.

Рис. 8.27. Графическая оболочка для настройки putty

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

Если клиент успешно создал ssh-сессию, появится новое окно для ввода имени пользователя и пароля.

Рис. 8.28. Окно для ввода учетных сведений

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

При помощи несложных методов реверс-инжиниринга, предназначенных для работы со строками и ссылками на строки, будет не сложно найти адрес функции соединения после того, как клиент установил соединение с назначенным IP-адресом. Строка «login as:», появляющаяся во всплывающем окне, поможет нам найти адрес функции соединения. В поисках ссылок на строки нам поможет IDA Pro.

Для нахождения строки «login as:» в IDA Pro открываем Views->Open Subviews->Strings on IDA.

Puc. 8.29. Ссылка на строку «login as:»

После нахождения нужной строки дважды кликаем и переходим местонахождению. Внутри секций данных IDA находит все перекрестные ссылки на строки. Для вывода всех перекрестных ссылок нажимаем комбинацию клавиш «Ctrl+Х».

На рисунке ниже показана ссылка внутри функции, которая выводит строку «login as:».

Puc. 8.30. Ссылки внутри функции, которая выводит строку «login as:»

На рисунке ниже показана инструкция, которую мы будем изменять. После выполнения кода бэкдора, эта инструкция будет использоваться вновь.

Puc. 8.31. Инструкция, которую мы будем менять

После изменения инструкции PUSH 467С7С на JMP 0x47А478 процесс перенаправления потока выполнения можно считать завершенным. Важно не забывать, что адрес следующей инструкции будет использоваться как адрес возврата после выполнения кода вредоноса. Следующий шаг — инжектирование кода бэкдора.

Первая мысль, которая приходит в голову при внедрении (ин-жинировании) бэкдора, — сохранение регистров перед выполнением вредоносного кода. Каждое значение внутри регистров — чрезвычайно важно для выполнения программы. Поместив инструкции PUSHAD и PUSHPD в начале code cave, мы сможем сохранить все регистры и флаги регистров внутри стека. Эти значения будут возвращены после выполнения кода вредоноса, и программа продолжит выполнение без каких-либо проблем.

Как было упомянуто ранее, наш бэкдор представляет собой обратный tcp-шелл-код под meteipreter, взятый из проекта metasploit.

Puc. 8.32. Помещение инструкций PUSHAD и PUSHFD перед code cave

Однако потребуется некоторые изменения внутри шелл-кода. Обычно обратный tcp-шелл-код пытается подсоединиться к обработчику некоторое количество раз, и если соединиться не удалось, процесс закрывается посредством вызова API-функции ExitProcess.