Итак, начнём-с, пожалуй.
Задача: выделить и классифицировать вредоносное ПО среди горы исполняемых файлов.
Решение: использовать динамический анализ неудобно, IDA долго (и дорого), вывод — используем HIEW.
Опишем примерный алгоритм экспресс анализа исполняемого файла на вредоносность. Первое, что необходимо сделать — выявить возможное заражение анализируемого объекта файловым вирусом.
Загрузим исполняемый файл в HIEW и посмотрим, в какую секцию указывает точка входа (Enter, F8, F6). Здесь возможно несколько случаев.
Вариант первый. Точка входа указывает куда-то в область заголовка PE-файла. Вариант тривиален и обнаруживается визуальным просмотром файла в текстовом режиме.
Вариант второй. Точка входа указывает на последнюю секцию исполняемого файла. Это тоже очень подозрительно и, скорее всего, свидетельствует о заражении файла. Рассмотрим несколько примеров.
Точка входа имеет следующий вид:
Натренированный глаз режет применение инструкции call +5, что очень не характерно для обычного компилятора. Так же интересна строка 0x0048с030, где, вероятно, происходит ручная работа с заголовком PE-файла. Посмотрим на атрибуты секции:
Напрашивается очевидный вывод: анализируемый объект заражён файловым вирусом. В данном случае это разновидность вируса Virut.
Вообще, заражение последней секции файла очень популярная техника, не требующая больших усилий. Заражение легко определить по наличию осмысленного либо зашифрованного кода в последней секции, совершенно для этого не предназначенной. Например, в секции ресурсов, данных, перемещаемых элементов и т.д.
Иногда можно встретить следующую картину:
Вердикт очевиден – файл заражён. После байт, оставленных в конце файла для выравнивания компилятором, следует не только осмысленный код, но и сама точка входа.
Сделаем небольшое лирическое отступление от экспресс-анализа. Напрашивается вопрос: можно ли с HIEW исследовать динамически-расшифровывающиеся объекты? На удивление, это часто удаётся сделать. Рассмотрим предыдущий пример с вирусом Virut. Код вируса невелик, местами зашифрован и расположен в конце файла. Немножко полистав дизассемблерный листинг, натыкаемся на это:
Здесь нетрудно увидеть простейший цикл расшифровки. Однако в случае статического анализа мы не можем определить, что и с каким ключём тут расшифровывается. Но! Вспомним, что HIEW поддерживает поиск перекрёстних ссылок, наведём курсор на начало цикла расшифровки, нажмём F6 и поищем вызовы интересующего нас участка кода:
Очень вероятно, что это и есть код, вызывающий процедуру расшифровки. В этом случае зашифрованный участок находиться по адресу 0x0048c155 ([EAX]), а одно-байтовый ключ находиться по адресу 0x0048c154 ([EAX-1]). Размер блока — 0x12b2 байт.
Чтобы произвести расшифровку, пользователи IDA побежали бы писать скрипт на idc или питоне. В отладчике, вообще, ничего делать не пришлось бы. Пользователи же HIEW используют встроенные средства обработки блоков данных. Опишем требуемый алгоритм шифрования, выделим границы блока в режиме 16-ричного редактора и запустим скрипт.
Встроенное средство обработки блоков имеет Intel-подобный синтаксис и позволяет производить несложные преобразования по 8, 16, 32 и 64 бита. В результате расшифровки получим вполне пригодные для анализа данные:
Вернёмся снова к экспресс-анализу. Вариант третий. Точка входа указывает туда, куда ей и положено — в секцию кода. Для обнаружения заражения требуется небольшой опыт. Рассмотрим несколько примеров.
В глаза бросаются инструкции call +5; pop reg. Данный приём очень характерен при написании базо-независимого кода. Следует отметить, что вместо прямого перехода на тело вируса часто используются инструкции типа push reg; retn либо mov reg, addr; call reg и другие вариации на эту тему. Нормальные же компиляторы обычно так не поступают, по крайней мере, уж не на точке входа, а в каком-нибудь виртуальном классе. Из всего этого можно сделать вывод, что данный экземпляр так же заражён файловым вирусом. В данном случае это — небезызвестный Sality.
Двигаемся дальше. Допустим мы встретили следующий код:
Несмотря на то, что точа входа сразу указывает на call и jmp, файл не заражён, и это стандартное начало программы С/C++, скомпилированной Microsoft Visual Studio 2010. Данный пример скорее исключение. Обычно при заражении кодовой секции вредоносный код дописывается либо в её конец (при наличии достаточного количества места), либо делается jmp на вредоносный код прямо с точки входа. Компиляторы же обычно начинают выполнение программы с вызова стандартной функции, имеющей стандартный пролог:
Здесь мы видим начало программы, скомпилированной с помощью компилятора Visual Studio C++ 6.0. Точка входа указывает на стандартный пролог, далее следует установка собственного обработчика исключений.
Рассмотрим следующий код:
Здесь точка входа указывает на уже известную нам последовательность push addr; retn. Перед нами — Rustock.
После анализа точки входа неплохо произвести просто просмотр секций и оверлеев файла. Иногда встречаются следующие экземпляры:
В данном примере, в оверелее, вероятно, записано зашифрованное тело оригинальной программы. Суть механизма «заражения» можно понять из следующего кода:
По сути, «вирус» заражает файлы следующим образом: полностью зашифровывает оригинальный исполняемый файл, перемещает данные себе в оверлей и перезаписывает получившимся файлом оригинальную программу. При запуске программа расшифровывает оригинальный файл, записывает его на диск во временную директорию и запускает с оригинальными параметрами командной строки.
На этом вирусный анализ как таковой заканчивается. Обнаружить более сложные заражения за короткое время в режиме промышленного аналитика затруднительно (личное мнение). Далее идёт работа по определению вредоносного функционала самого анализируемого файла.
Различные вымогатели, фейковые антивирусы и т.п. обнаруживаются просто при беглом просмотре файла в текстовом режиме:
Поскольку ни для кого не секрет, что в России производиться достаточное количество вредоносного ПО, то возможнось работы HIEW с русскими кодировками из коробки сильно облегчает жизнь вирусному аналитику.
Так же HIEW позволяет на глаз определить зашифрованные участки файла. Специфика кода и данных такова, что в них присутствует много избыточности, а особенно нулевых байтов. Поэтому при обнаружении, например, следующего блока данных…
… можно сделать вывод, что эти данные зашифрованы. Можно ли их статически расшифровать? В данном случае нам повезло, и мы снова ограничимся одним HIEW. Перейдём на начало зашифрованных данных и поищем перекрёстные ссылки:
Сразу же находим требуемый цикл расшифровки. Всё, дело почти сделано. Выделяем зашифрованный блок, пишем скрипт:
И расшифровываем вредоносниый код:
В случае невозможности быстрой расшифровки, файл направляется на более глубокий анализ, но это уже другая история.
Далее по плану идёт определение стандартных троянских программ типа Zeus, SpyEye, Carberp и других. По словам, опытный вирусный аналитик идентифицирует их с первого взгляда (автор же проверить данное заявление не имеет возможности).
В итоге мы можем анализировать и классифицировать экземпляры с практически нереальной скоростью: 1 объект менее чем за 10 минут. Видимо это и стало залогом успеха такой легендарной программы как HIEW.
P.S. Подробное описание HIEW unicornix.spb.ru/docs/prog/heap/hiew.htm
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers.
Комментариев нет:
Отправить комментарий