Обратный инжиниринг вредоносных программ (часть 5)

• Обратный инжиниринг вредоносных программ (часть 1)
• Обратный инжиниринг вредоносных программ (часть 2)

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

Реверс-инжиниринг и вы, часть V

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

Например, выполнение rev eng для разработки эксплойтов — это совсем другое дело. Во-первых, вы проводите анализ существующей программы, например, Windows XP или какой-либо другой программы FTP-сервера. То, что вы ищете, тоже совсем другое. Вы будете искать любые случаи возможных переполнений буфера, проблем со строками формата и других подобных связанных уязвимостей плохого кодирования. С этим типом усилий вы фактически выполняете подпрограммы, операнд за операндом. Такая работа тяжелая, утомительная и занимает много времени. Кроме того, это требует довольно хорошего понимания программирования. Как и при проверке вредоносного ПО, вы также применяете статический и динамический подходы к проверке версии для разработки эксплойтов.

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

Вперед и вверх

Возможно, вы помните, что ранее в этой серии я предлагал вам установить MAP (Malcode Analyst Pack) из IDefense. Что мы сейчас сделаем в качестве первого шага в нашем анализе вредоносного ПО, так это запустим команду strings из инструмента MAP для распакованного вредоносного ПО. Все, что вам нужно сделать, это щелкнуть правой кнопкой мыши вредоносное ПО, и вы увидите, что в диалоговом окне появится опция «Строки». Оттуда все, что вам нужно сделать, это щелкнуть по нему. После завершения программы появится другое окно с результатами. Пожалуйста, смотрите ниже вывод, который должен быть показан.

фигура 1

Что ж, на скриншоте выше мы видим, что первые несколько записей относятся к самому заголовку MZ и некоторым различным разделам внутри него, например:.text,.data и idata, и это лишь некоторые из них. Также указан другой хеш MD5 файла и его размер. Теперь я прокрутил свой строковый вывод вниз и начал видеть интересные текстовые строки, которые были извлечены из самого двоичного файла.

фигура 2

Одна из записей, которая привлекает мое внимание, — это «shlwapi.dll». Этот файл dll не вызывает у меня никаких сомнений, поэтому я отправляюсь в Microsoft Technet, чтобы выполнить поиск по нему. Судя по хитам, которые я вижу, я не переполнен уверенностью в том, что эта вредоносная программа исходит из наших лучших намерений. Существует длинный список уязвимостей, связанных с этой dll, и это усиливает аргументы в пользу того, что эта вредоносная программа является именно вредоносной программой.

Рисунок 3

Посмотрев на это, я продолжаю прокручивать список строк ascii, извлеченных из двоичного файла вредоносного ПО. Большинство из них заключаются в обычной записи, открытии и прочей возне с ключами реестра. Кроме того, есть длинный список других строк ascii, которые, кажется, намекают на тот факт, что эта вредоносная программа после запуска представит пользователю какое-то окно. Я пришел к этому предположению по строке «CreateWindowExA», как показано на скриншоте ниже.

Рисунок 4

Ну, написание этой строки ascii кажется довольно простым, но давайте посмотрим через Google, чтобы увидеть, сможем ли мы придумать лучшее объяснение того, что она делает. Именно это я и делаю, как показано на скриншоте ниже. Мои подозрения, по-видимому, подтверждаются тем, что окно, скорее всего, будет представлено пользователю после запуска вредоносной программы.

Рисунок 5

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

От статики к динамике

Во всяком случае, я не знаю о вас, но я хотел бы сделать вещи немного более захватывающими и добраться до сути вопроса. Итак, на этой ноте давайте перейдем к динамической части нашего анализа. Вам нужно будет установить и запустить как regmon, так и filemon. После установки и запуска убедитесь, что вы исключили все запущенные файлы, найденные в обоих приложениях. Таким образом, вы сможете зафиксировать все действия, происходящие после того, как мы запустим вредоносное ПО. На этой ноте давайте запустим наш маленький образец вредоносного ПО. Я делаю это, просто переименовывая вредоносное ПО с расширением.exe и вызывая его через приглашение DOS. Как только я это сделал, разве вы не знаете, мне открывается всплывающее окно. Вы действительно должны любить строки и то, что они могут извлечь из двоичного файла.

Рисунок 6

Так что, как мы думали, когда мы увидели строку CreateWindowExA ascii, а затем погуглили ее, мы поняли ее назначение. Это была часть кода, используемого для создания всплывающего окна, которое мы видим над собой. Теперь как насчет того, что произошло в regmon и filemon после того, как я запустил двоичный файл вредоносного ПО? Что ж, давайте посмотрим на два скриншота ниже.

Рисунок 7

Рисунок 8

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

Заворачивать

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

• Обратный инжиниринг вредоносных программ (часть 1)
• Обратный инжиниринг вредоносных программ (часть 2)