Одним из наиболее ярких зловредов последнего времени является TDSS. Правда, в этой статье под TDSS’ом будет подразумеваться не широко известный руткит, а полиморфный упаковщик, который обладает антиэмуляцией и использует обфускацию для усложнения детектирования.
РУТКИТ TDSS обычно защищен именно этим пакером. Его-то мы сегодня и разберем. А точнее, разберем не только его, но и весь довольно примечательный путь, который проходит руткит – от зараженного сайта до отработки на компьютере пользователя.
Вся настоящая история началась с зараженного сайта east.*****. pu.ru. Его главная страница содержала сразу семь разных вредоносных скриптов.
На нем приведена схема, которая поясняет расположение инородных элементов в HTML-коде. Все исследование сайта производилось на специальном компьютере, который подключен к интернету через рабочую машину. На рабочей системе установлен прокси-сервер на основе Small Http Server, сохраняющий на лету все файлы, которые через него проходят, и сниффер WireShark для подробного изучения интересующих пакетов. Скрипты разбирались отдельно с помощью программы MalZilla.
Кратко пробежимся по каждому из них и остановим внимание на самых интересных экземплярах. Самый первый скрипт с конца – Trojan-Downloader.JS.Pegel.g, знаменитый троян-загрузчик, написанный на JavaScript. Результатом его работы является код вида «<iframe src = …», который перенаправляет на страницу, содержащую эксплойт-пак. Однако в нашем случае с вредоносной страницы пришло лишь два байта, что было подтверждено в WireShark – поле Content-Length ответа сервера – 2.
Далее по списку и по расположению в файле (идем снизу вверх) находится Exploit.Script.Generic. Этот скрипт также написан на JavaScript, но защищен довольно просто. А именно – одна переменная является строкой, содержащей символы, образующие шестнадцатиричное число, из которой в цикле выделяется по два байта, затем они конкатенируются с «%», преобразуются функцией unescape и выводятся с помощью document.write. Преобразованный код пытается скачать и запустить очень опасный и популярный вирус Virus.Win32.Sality.ag. Реализуется это двумя способами – прямая загрузка с помощью уязвимости MS06-014 и выполнение шеллкода в результате переполнения буфера во время исполнения кода.
Судя по коду, следующий скрипт предназначался для заражения PHP-страницы, но проявиться в должной степени ему была не судьба – похоже, что PHP-движок на сервере просто отсутствовал. Расшифровав криптованные строки с помощью алгоритма base64, я обнаружил функ ционал – отсылка определенной информации на сервер с помощью запроса POST, получение ответа, расшифровка и использование.
Следующий экземпляр довольно интересен из–за его обращения к сети Twitter. В результате его дешифровки происходит загрузка JSON-файла из социальной сети с помощью следующего кода:
<script src='http://search.twitter.com/trends/daily.json?callback=callback'>
Полученный файл содержит наиболее обсуждаемые темы за последний день и код, вызывающий функцию, стоящую в запросе после «callback=». К сожалению, в рассматриваемом скрипте отсутствует функция callback, поэтому дальнейшее поведение проследить не получилось.
Последние три зловреда объединены конечным функционалом – все они переходят по разным ссылкам, но в ответ приходит пакет «302 Moved Temporarily», содержащий в поле location ссылку на другую страницу с вредоносным скриптом – 121.101.***.203. Отлично, скачаем и проанализируем этот файлик. Оказывается, его код производит попытку скачать вредоносный PE-файл, детектируемый как Packed.Win32.Krap.x. Делается это многими способами, которые слегка модифицируются для каждой версии Windows, но ожидаемый результат всегда одинаковый. Среди этих способов присутствует запуск PDF-файла, эксплуатирующего уязвимость в Adobe Reader, использование зловредного Java-апплета, загрузка с использованием MS06-014.
Остановимся поподробнее на PDF’ке, а затем перейдем к рассмотрению Krap.x. Если открыть файл с помощью какого-либо просмотрщика, например, Hiew, то вложенный вредоносный JavaScriptкомпонент будет отлично виден. Когда пользователь открывает уязвимый Adobe Reader, происходит эксплуатация уязвимости и вызывается вышеупомянутый скрипт. Результатом его деятельности является исполнение машинного кода, который скачивает и запускает Krap.x. Сам шеллкод зашифрован довольно просто – с помощью инструкции XOR с ключом 0x99.
На этом рассмотрение всех скриптов можно закончить. Действие каждого из них ты можешь увидеть на соответствующей схеме. Фактически, только четыре из них оказались полностью рабочими, при этом три скрипта выполняли загрузку одного и того же файла. Красной рамкой отмечены вредоносные объекты, полученные в результате исполнения главной странички сайта.
Пришло время проанализировать зловред Packed.Win32.Krap.x, который, в конечном итоге, скачивает и запускает TDSS. Файл подробно исследовался с помощью дизассемблера и отладчика IDA. После первичного осмотра при помощи Hiew были обнаружены большие зашифрованные области и небольшой участок кода. Однако этот участок не такой простой – в нем используется антиэмуляция на основе FakeApi и работы с исключениями, что также усложняет отладку. Обфускация в файле не применялась. Зашифрованные участки расшифровываются с помощью инструкций ROL и SHR.
На этом первую часть, посвященную появлению Trojan.Win32.TDSS на компьютере, можно считать завершенной. Мы рассмотрели все скрипты, расположенные на зараженной странице, их поведение. Также был затронут анализ типичного даунлодера Packed.Win32. Krap.x, защищенного зловредным упаковщиком. Оказалось, что путь от посещения «плохого» сайта до появления TDSS на компьютере очень длинный.
Ковыряем образец
Первым делом исследуемый образец был подвергнут визуальному осмотру в Hiew. В файле была обнаружена одна секция с исполняемым кодом размером ~0x1000, а большую его часть (~0x60000 байт) составляли зашифрованные данные. Насторожила таблица импортов, в которой, помимо довольно обычных функций для расшифровщика (VirtualProtect, GetTempPathA, GetModuleHandle из библиотеки Kernel32.dll), содержались записи, предназначенные для работы с диалоговыми окнами – GetDlgCtrlId, GetParent из user32.dll. Наличие только двух таких функций вызывает недоумение и указывает на возможность их использования для реализации антиэмуляции.
Исполняемая часть выглядит весьма своеобразно – присутствует большое количество повторяющихся символов: «H», «.», «f». Они соответствуют инструкциям LEA, префиксу семгента CS, префиксу размера операнда. В режиме дизассемблера в глаза бросилась явная обфускация – множество инструкций, которые не несут полезной нагрузки, например, LEA AX, CS:[EAX + 0]; LEA AX, [EAX + 0]; LEA AX, [EAX] и др.
Для того, чтобы упростить анализ, коды вышеупомянутых инструкций были заменены на последовательности из NOP’ов. После выполнения этого действия оказалось, что только ~25% кода что–то реально выполняют. Кстати, полностью обфускацию мы не убрали – осталась та, которую исключить уже сложнее, например, четыре вызова inc reg подряд вместо add reg, 4. Однако даже преобразованный фрагмент анализировать под отладчиком получается очень непросто ввиду того, что выполнение происходит нелинейно – управление непрерывно передается с помощью JMP’ов в разные участки исполняемой области.
В процессе отладки обнаружилась антиэмуляция. Она заключается в последовательном вызове функций GetDlgCtrlID и GetParent и косвенному обращению к FS: с использованием кодов возврата. Это смещение соответствует полю LastErrorValue недокументированной структуры Windows – TEB. Затем значение поля сравнивается с эталонным. Далее происходит обращение к полю SpareBool структуры PEB. Его значение впоследствии используется для корректной работы зловреда.
После отработки разнообразных защитных механизмов приходит время исполнения полезной составляющей. В данном случае это расшифровка основного тела вредоносного файла с помощью алгоритма RC4.
Причем вначале подготавливается алфавит от 0x0 до 0x100 с полученным значением SpareBool, а затем и основной ключ. С помощью программы PETools был получен дамп, содержащий расшифрованное тело. Оказалось, что оно было скомпилировано с помощью MSVC и содержит еще один файл, который был незамедлительно извлечен. Он оказался динамической библиотекой, которая работает в связке с исходным вредоносом, также упакована TDSS и содержит в себе еще файл. Такое повторялось несколько раз, и в результате, помимо исходного экземпляра, появилось еще три файла. С каждого был снят дамп памяти процесса.
По приведенному выше скриншоту можно однозначно идентифицировать класс вредоносного файла – фальшивый антивирус. Его основное назначение – напугать пользователя так, чтобы он согласился заплатить деньги за «излечение» системы от вирусов. Этот экземпляр также прописывается в автозагрузке, выполняет множество других деструктивных действий и пытается отключить целый ряд легальных антивирусов (строки взяты в дампе одного из компонентов): Malwarebytes' Anti-Malware_is1; NOD32; Agnitum Outpost Security Suite Pro_is1; Avira AntiVir Desktop; avast!; AntiVir PersonalEdition Classic; Sophos; Sophos Client Firewall; Sophos Antivirus; Kaspersky 2010; Kaspersky 2008; F-Secure Web Filter.
Заключение
Результат банален: все свелось к получению прибыли путем обмана пользователя. Фальшивый антивирус оказался очень хорошо защищен как от антивирусов (путем использования полиморфизма, обфускации и антиэмуляции), так и от людей, пытающихся его разобрать. Очень интересна цепочка, по которой происходит распространение TDSS – в ней принимает участие несколько скриптов, а также защищенный даунлоадер. Вполне возможно, что вирусописатели разработали фальшивый антивирус, затем купили упаковщик TDSS, а потом стали распространять свое детище через партнерку.
