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

Рис. 8.33. Участок шелл-кода, отвечающий за соединение с обработчиком

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

Рис. 8.34. Модифицированная версия участка кода, отвечающего за соединение с обработчиком

После внесения изменений внутри ассемблерного кода выполняем компиляцию при помощи команды nasm — f bin stager_reverse_tcpnx.asm. Теперь обратный tcp-шелл-код готов к употреблению, но пока еще не помещен в правильное место. Наша цель — осуществить выполнение в отдельном потоке, для создания которого потребуется отдельный шелл-код, выполняющий вызов API-функции CreateThread. Функция будет указывать на первоначальный обратный tcp-шелл-код. Код для создания потоков из проекта metasploit также написан Стивеном Фивером.

Рис. 8.35. Шелл-код для создания отдельного потока

После помещения байтов шелл-кода внутрь файла createthread. asm в шестнадцатеричном формате, как показано на рисунке выше, выполняем компиляцию при помощи команды nasm — fbin createthread. asm. Теперь шелл-код готов для внедрения в code cave, но перед вставкой следует выполнить кодирования для того, чтобы обойти статиче-ский/сигнатурный анализ антивируса. Поскольку все кодировщики из проекта metasploit известны большинству антивирусов, в работе рекомендуется использовать нестандартное кодирование. Здесь можно обойтись сочетанием нескольких стандартных кодировщиков, но можно обойтись сочетанием нескольких кодировщиков из проекта metasploit. После каждого акта кодирования загружаем шелл-код в проект Virus Total в «сыром» формате и проверяем результаты проверки. Комбинируем кодировщики до тех пор, пока шелл-код станет полностью незаметным (или можно подождать следующей статьи). После правильного кодирования шелл-код готов к внедрению внутрь code cave. Выбираем инструкцию, которая следует за инструкцией PUSHFD, и нажимаем Ctrl+E в отладчике Immunity Debugger. Шелл-код будет вставлен в шестнадцатеричном формате.

Рис. 8.36. Вставка шелл-кода

Получить закодированный шелл-код в шестнадцатеричном формате можно двумя способами: вывести на печать при помощи команды xxd-ps createthread или открыть и скопировать в шестнадцатеричном редакторе. При копировании шестнадцатеричных значений в отладчик Immunity Debugger не забывайте об ограничениях на копируемые байты, которые присутствуют при вставке кода. Необходимо запомнить последние два вставленных байта, и после нажатия на кнопку ОК нужно сделать повторное копирование последующих участков. Когда шелл-код полностью вставлен в code cave, операцию по внедрению можно считать завершенной.

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

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

Рис. 8.37. Инструкции для восстановления первоначального состояния регистров

для того, чтобы перенаправить выполнение на code cave. При помещении инструкции PUSH 467С7С в конец кода, перехваченная инструкция также восстановится. Теперь настало время вернуться к функции, которая перенаправляла выполнение к code cave при помощи вставки инструкции JMP 0х41СВ77. Конец результирующего кода должен выглядеть, как показано на рисунке ниже.

Рис. 8.38. Завершающие изменения в конце кода

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

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

Рис. 8.39. Изменение контрольной суммы в редакторе РЕ-файлов

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

Контроль над привилегиями секций

Когда речь заходит о зараженных файлах, в первую очередь следует думать о детектировании аномалий, связанных с привилегиями секций. По умолчанию компиляторы никогда не устанавливают полные права на секции, если только программист не выставил специальные настройки. Особенно не должны иметь привилегий на выполнение секции данных:.data и. rdata. Кроме того, секции кода (например, text) не должны иметь прав на запись. Подобные аномалии, связанные с изменением привилегий, следует рассматривать как подозрительное поведение.

Присутствие нестандартных секций

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