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

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

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

8.7.6. Восстановление потока выполнения

После создания потока выполнения программного трояна необходимо возобновить выполнение основной программы. То есть регистр 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 стандартных типов секций. Во все продукты, связанные с безопасностью, должен быть внедрен механизм обнаружения нестандартных и подозрительных секций. Данный механизм должен следить за энтропией и выравниваем данных внутри секции. Если секция содержит высокую энтропию и нестандартно упорядоченную информацию, это еще один подозрительный признак.

Проверка сигнатур

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

Проверка контрольной суммы файла

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

Puc. 8.40. Результаты проверки файла с внедренным бэкдорам