Я есть HDRoot! Часть 1

Некоторое время назад в рамках слежения за активностью группы Winnti мы обнаружили подозрительный образец 64-битной программы.

Код был защищен от анализа коммерческой программой для защиты исполняемых файлов VMProtect. Сама программа была подписана сертификатом некой китайской компании Guangzhou YuanLuo Technology. Ранее мы уже обнаруживали вредоносные программы от группы Winnti, которые были подписаны этим же сертификатом. Более того, в свойствах этой программы было указано, что это якобы сетевая утилита компании Microsoft net.exe, и при запуске она даже выводила на экран обычный текст настоящей программы net.exe:

Маскировка под net.exe

Все это, конечно, выглядело очень подозрительно.

Буткит

Анализировать защищенный код программы – занятие не из приятных. Тем не менее, из дампа памяти работающей программы удалось извлечь уникальные текстовые строчки и еще четыре программы, которые хранились в изначальном образце: 32-битные и 64-битные версии библиотеки и драйвера:

Строчки в дампе вредоносной программы

Исходя из полученных данных, мы предположили, что эта программа, скорее всего, – некий инсталлятор буткита. По строчкам мы нашли аналогичные вредоносные программы, но уже без защиты от анализа, которые подтвердили наше предположение.

Вот что выводилось на экран при запуске одной из таких программ:

Выводимый на экран текст оригинального HDD Rootkit

Параметры к программе свидетельствуют о том, что это инструмент установки на компьютере буткита. После установки на этапе начальной загрузки компьютера операционная система заражается бэкдором, который определяется соответствующим параметром. При этом ожидается, что бэкдор будет исполняемым файлом или библиотекой Win32. Как видно на рисунке выше, эта утилита называется «HDD Rootkit» (отсюда и основа названий наших вердиктов — HDRoot). На 22-е августа 2006-го года это была уже версия 1.2.

Таким образом, защищенная программа была тем же инструментом, измененным так, чтобы, например, при обнаружении программы сторонним человеком во время ее использования на стороне жертвы, снизить риск разоблачения ее настоящего предназначения.

В теле HDD Rootkit присутствуют ресурсы, содержащие загрузочный код, который внедряется установщиком в разные части жесткого диска.

Ресурсы HDD Rootkit

Перечислим эти ресурсы:

• «MBR» – первая часть вредоносного кода, которая внедряется в MBR заражаемого компьютера;
• «BOOT» – вторая часть вредоносного кода, исполняемого на этапе начальной загрузки;
• «RKIMAGE» – третья часть вредоносного кода, исполняемого на этапе начальной загрузки;
• «DLLLOAD» – библиотека, которая на этапе начальной загрузки внедряется в файловую систему вредоносным кодом, путь к ней прописывается в реестре для автозапуска в операционной системе.

Давайте попробуем запустить некую программу в системе с помощью буткита. Для примера возьмем установщик буткита HDD Rootkit под именем «hdroot.exe» и «чистую» программу с единственным функционалом – созданием файла в корне диска C:. Установку буткита производим такой командой:

hdroot.exe inst write_to_c.exe c:

то есть, мы говорим: установить на диске C: буткит, который позволит запуститься программе write_to_c.exe при старте операционной системы.

Сообщение об установке буткита HDRoot в ходе эксперимента

Установщик буткита проверяет размер свободного места, доступного на указанном диске, и отказывает в установке буткита, если это значение меньше 30 процентов от всего объема диска.

Проверка свободного места на диске

В нашем примере проверка прошла успешно, и буткит был установлен. Давайте посмотрим, что при этом произошло.

В главной загрузочной записи утилита заменила часть кода на свой из ресурса «MBR»:

Ресурс «MBR»

Первые два байта EB 70 означают команду «jmp short 0x72» — переход исполнения первой части загрузочного вредоносного кода по смещению 0x72, где расположена оставшаяся часть вредоносного кода в MBR. Нули перед смещением 0x70 и после 0xB0 означают, что код в главной загрузочной записи в этих местах остается нетронутым. На следующем изображении показан измененный после установки буткита код в MBR:

Внедренный вредоносный код в MBR

Вредоносный код из MBR помещает в память следующий блок загрузочного кода, который был записан установщиком буткита в 11-й сектор (смещение 0x1400 от начала диска), и передает на него управление. Этот второй блок берется из ресурса «BOOT».

Второй блок загрузочного кода

По смещению 8 второго блока загрузочного кода хранится номер диска, а следующий DWORD – смещение в секторах на этом диске, где расположен следующий, третий блок загрузочного кода. В этом примере значение номера диска 0x80 означает диск 0, что соответствует диску C:, а значение 0x5FD9A0, если умножить его на 0x200 (размер сектора) – смещение 0xBFB34000 в байтах от начала диска. Это смещение, по которому установщик расположил третий блок загрузочного кода из ресурса «RKIMAGE».

Ресурс «RKIMAGE» – это довольно большой кусок кода, в котором реализовано внедрение библиотеки (ресурс «DLLLOAD») в файловую систему и внесение изменения в реестр операционной системы, чтобы внедренная библиотека запустилась при старте системы. Библиотека из ресурса «DLLLOAD» размещается установщиком в неразмеченной области диска за третьим блоком загрузочного кода. Так как код выполняется на раннем этапе загрузки, на котором еще нет никаких функций для работы с файловой системой (API), программе приходится самой реализовывать работу с файловой системой (FAT32 и NTFS).

Поддерживаемые файловые системы

Согласно таблице размещения файлов, программа ищет, где на диске расположен определенный файл, содержимое которого заменяется внедряемой библиотекой. Большинство версий HDRoot, которые мы обнаружили, заменяли файл %windir%\WMSysPr9.prx. Иногда вредоносной библиотекой может быть перезаписана системная библиотека – не самый разумный способ для вредоносной программы, так как в некоторых случаях это может привести к неправильной работе ОС и привлечь внимание к заражению. Вот список файлов, о которых нам известно, что они могут быть перезаписаны:

%windir%\twain.dll
%windir%\msvidc32.dll
%windir%\help\access.hlp
%windir%\help\winssnap.hlp
%windir%\system\olesvr.dll
%windir%\syswow64\C_932.NLS
%windir%\syswow64\C_20949.NLS
%windir%\syswow64\dssec.dat
%windir%\syswow64\irclass.dll
%windir%\syswow64\msvidc32.dll
%windir%\syswow64\kmddsp.tsp

Затем загрузочный код читает содержимое файла %windir%\system32\config\system, в котором хранятся данные ветки реестра HKEY_LOCAL_MACHINE\SYSTEM. Среди прочего, в этой ветке содержится информация об установленных службах. В операционной системе существует множество системных служб, которые автоматически запускаются при загрузке системы как сервисные библиотеки (ServiceDll) через программу svchost.exe. В реестре определяется путь к библиотеке, которая ассоциируется с той или иной службой. Вредоносный загрузочный код ищет в файле «system» заранее известный путь к библиотеке некой системной службы и заменяет его на путь к файлу, в который была внедрена вредоносная библиотека, например %windir%\WMSysPr9.prx. Согласно найденным версиям, HDRoot может использовать следующие службы для запуска своей библиотеки:

Таким образом, когда операционная система запускает службы, вместо загрузки настоящей сервисной библиотеки svchost.exe загрузит вредоносную. Цель этой вредоносной библиотеки – запуск бэкдора, спрятанного установщиком HDD Rootkit по определенному смещению на жестком диске.

Мы нашли две версии HDRoot с разными способами запуска бэкдора.

Способ, который используют бэкдоры первой версии – это чтение бэкдора с жесткого диска, сохранение его файлом %windir%\temp\svchost.exe и запуск с помощью API-функции WinExec. Судя по всему, создатель вредоносной программы HDD Rootkit посчитал, что это не самый лучший метод запускать бэкдоры: событие запуска программы отмечается в журналах ОС, и антивирусные программы реагируют на это соответственно, проверяя, что там запускается.

В другой версии библиотека уже ничего на диск файлом не сохраняет, а размещает прочтенный из неразмеченной области жесткого диска бэкдор в памяти, сама подготавливает его к корректной работе (подгружает необходимые бэкдору библиотеки согласно таблице импорта и настраивает адреса согласно таблице перемещений) и запускает код с точки входа бэкдора. Такой подход гораздо более выгодный в плане сокрытия вредоносных компонентов – это уменьшает шансы обнаружения бэкдора, даже если будет замечено заражение MBR и/или будет обнаружена вредоносная библиотека.

Возвращаемся к нашему эксперименту. Выполнив команду:

hdroot.exe inst write_to_c.exe c:

мы перегружаем компьютер. После того, как операционная система загрузилась, мы видим результат работы программы write_to_c.exe, которая выступает у нас в роли бэкдора: сразу после загрузки системы создался файл C:\zzz.bin, подтверждая, что программа write_to_c.exe успешно отработала.

Созданный проверочный файл zzz.bin

Схематично процесс заражения системы с помощью буткита HDRoot выглядит так:

Схема заражения HDRoot

Интересно, что вредоносная библиотека не восстанавливает работу той оригинальной службы, вместо которой она запустилась. Эти службы – часть операционной системы, и если какая-то из них не работает, это может привести к неправильной работе Windows, что повышает риск обнаружения заражения. Отсутствие такого функционала еще более странно, так как во вредоносной программе все-таки реализованы попытки скрыть следы заражения. Именно «попытки», потому что скрыть следы не удается. Во внедренной в файловую систему вредоносной библиотеке есть функция возврата оригинального значения параметра ServiceDll в реестре, хранящего путь к библиотеке, связанной со службой. Но создатель программы ошибся в расчетах смещений во время исполнения 3-го блока загрузочного кода (из «RKIMAGE»), который перед внедрением библиотеки в файловую систему вносит в ее тело некоторые изменения. В результате в библиотеку значения записываются не в те места, из которых библиотека будет брать пути реестра, чтобы восстановить оригинальное значение параметра ServiceDll. Поэтому, если в нашем эксперименте посмотреть в реестре раздел, соответствующий службе обновлений Windows, то в параметре ServiceDll вместо пути к системной библиотеке «C:\WINDOWS\system32\wuauserv.dll» (что должно быть в чистой операционной системе) мы все еще видим путь к вредоносной dll «C:\WINDOWS\WMSysPr9.prx»:

В реестре остается путь к внедренной вредоносной библиотеке

Неверные путь к разделу и название параметра реестра

Путь к разделу реестра переписан оригинальным значением ServiceDll

Из этих ошибок мы можем заключить, что вредоносная программа была создана не очень аккуратно, что совсем не похоже на такую серьезную и опасную APT-группировку, как Winnti. Однако создатель HDRoot приложил немало усилий, чтобы буткит работал правильно на этапе начальной загрузки, чтобы избежать ошибок, в результате которых могла бы быть вообще прервана загрузка операционной системы. Но из-за недоработок в системе остаются довольно заметные следы заражения (например, службы обновления Windows или планировщик задач фактически не работали). Судя по всему, никто на стороне жертв не обращал на это внимания – что печально.

Нам также удалось обнаружить несколько вредоносных программ, которыми буткит заражал операционные системы. О них мы расскажем во второй части статьи.