Анализ Winnti 1.0

Начальная DLL

Все начинается с библиотеки DLL. Библиотека выдает себя за стандартные библиотеки ОС Windows winmm.dll или apphelp.dll. В подавляющем большинстве случаев нами были обнаружены самплы, маскирующиеся под winmm.dll, поэтому далее мы будем писать, что вредоносная библиотека скрывается именно под этим именем.

Winmm.dll — это библиотека ОС Windows, предоставляющая функции для работы с мультимедиа. Размещается она в каталоге %WINDIR%System32. Злоумышленники рассчитывали на то, что это базовая библиотека, и вероятность, что какая-то программа подгрузит ее, довольно высока (с apphelp.dll дела обстоят так же). Например, winmm.dll загружается программой explorer.exe, которая запускается во время загрузки операционной системы.

Если вредоносная библиотека с названием winmm.dll размещается в том же каталоге, что и программа, которая зависит от этой библиотеки, то вместо оригинальной библиотеки %WINDIR%System32winmm.dll загрузится вредоносная.

Управляя зараженным компьютером, злоумышленники размещают вредоносную библиотеку в каталоге %WINDIR%. В этом же каталоге расположена и программа explorer.exe. Таким образом, злоумышленники обеспечивают запуск вредоносной DLL при загрузке операционной системы: explorer.exe загружает вредоносную winmm.dll из каталога %WINDIR% как только сам запускается в процессе загрузки операционной системы.

Но как будет корректно работать программа, которая зависит от оригинальной библиотеки, если вместо настоящей winmm.dll загрузилась вредоносная? На этот счет вирусописатели подстраховались: во вредоносной библиотеке добавлена принудительная загрузка библиотеки winmm.dll из каталога %WINDIR%System32. Добавлен также перехватчик загрузки модулей: если какой-то дополнительный загружаемый модуль (другая библиотека DLL, например) зависит от winmm.dll, то вредоносная программа подстроит все так, чтобы загрузилась оригинальная библиотека.

Чтобы добиться принудительной загрузки оригинальной библиотеки winmm.dll , злоумышленники не стали утруждать себя собственной разработкой, а использовали известную программу AheadLib.

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

Функции-перехватчики (код, генерируемый легальной программой)

Гибкость этого инструмента позволяет подстраивать логику вредоносного приложения в ходе анализа и исполнять вспомогательный код для показа каких-либо отладочных данных. Например, можно добавить дополнительный код для отображения параметров функций, чтобы выяснить, какие значения передаются оригинальным функциям при их вызове. Данный метод используется при так называемом динамическом анализе вредоносных приложений.

Определение адресов настоящих функций

(в рамке — сообщение об ошибке: «Невозможно найти функцию %hs, программа не сможет работать правильно»)

Загрузка оригинальной библиотеки модифицированным модулем

(в рамке — сообщение об ошибке: «Невозможно загрузить %s, программа не сможет работать правильно»)

По иронии судьбы это приложение подошло вирусописателям для создания вредоносных библиотек. На вход этой программе они давали настоящую библиотеку (например, winmm.dll), а на выходе получали заготовку для модифицированной библиотеки — в виде Си-файла. Добавив основой вредоносный код, злоумышленники получали готовую вредоносную программу, которая, помимо своих вредоносных функций, обеспечивала работу настоящей библиотеки.

Довольно странно было видеть, что злоумышленники в ранних версиях оставили код отладочных сообщений самой программы AheadLib (отмеченные красной рамкой на скриншотах выше). Эти строчки встречаются и в скомпилированных бинарных файлах вредоносных библиотек:

Невозможно найти функцию %hs, программа не сможет работать правильно

Невозможно загрузить %s, программа не сможет работать правильно

Впоследствии эти фрагменты кода все-таки были удалены из сгенерированного AheadLib Си-файла.

Управляющая DLL

Вредоносная библиотека winmm.dll скрывает в своем теле другую библиотеку, которая расшифровывается на лету и размещается в памяти процесса. Эта библиотека называется PlusDLL и является основным управляющим компонентом платформы. Разместив дополнительную DLL в памяти, winmm.dll передает на нее управление вместе с параметром, который представляет собой строку с настройками бота. Строка с настройками в зашифрованном виде также находится в теле библиотеки winmm.dll — после слова PLUSUNIT.

Зашифрованные настройки бота

После дешифровки строка имеет такой вид:

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

Зашифрованные настройки в начале вредоносной программы

В других вариантах была немного изменена строка «PLUSUNIT»:

UUUSUN»» вместо PLUSUNIT

Библиотека PlusDLL.dll содержит в себе драйвер. Драйвер сохраняется в каталог %WINDIR%System32, регистрируется как служба и запускается функцией NtLoadDriver. Сразу после этого файл драйвера удаляется, равно как и все записи в реестре, появившиеся в связи с регистрацией службы. Оригинальные названия драйверов (названия проектов, которые дал вирусописатель): PortLess и PointFilter, однако в процессе заражения используются файлы драйверов с именами sp1itter.sys и acplec.sys.

Назначение драйвера — сокрытие установленных сетевых соединений, связанных с работой вредоносной программы. Если, например, во время активного «общения» бота с центром управления пользователь посмотрит, с какими адресами в интернете с его компьютера установлены соединения (например, командой «netstat —a» или программой tcpview), то драйвер предотвратит обнаружение вредоносных соединений.

Интересным оказался метод, с помощью которого драйвер узнаёт, какие адреса скрывать, а какие нет. Эту информацию знает управляющая библиотека PlusDLL, которая в штатном режиме активного заражения работает в контексте процесса explorer.exe. Передается эта информация из пользовательского режима, где работает PlusDLL, на уровень ядра, где работает драйвер, через функцию NtSetQuotaInformationFile, которая доступна в обоих режимах.

Драйвер при запуске ставит хук на функцию NtSetQuotaInformationFile:

Перехват вызова NtSetQuotaInformationFile

Каждый раз, когда вызывается эта функция, драйвер проверяет ее параметры, в частности HANDLE FileHandle и PVOID Buffer.

Параметр FileHandle — это дескриптор, связанный с разделом жесткого диска, для которого собственно и устанавливаются дисковые квоты с помощью этой функции.

Параметр Buffer — буфер, в котором содержится информация о новых квотах, которые надо установить. Драйвер проверяет, не равняется ли значение параметра FileHandle минус двум. Очевидно, что когда система вызывает NtSetQuotaInformationFile для того, чтобы действительно изменить квоты, дескриптор должен быть связан с каким-либо диском, а значит, не может равняться минус двум. Такое отрицательное значение этот параметр получит принудительно в библиотеке PlusDLL, чтобы драйвер распознал, что вызов функции NtSetQuotaInformationFile сделан именно из этой библиотеки. При вызове NtSetQuotaInformationFile библиотека PlusDLL передает драйверу в параметре Buffer информацию о том, соединения с какими сетевыми адресами скрывать. Если же FileHandle не равен минус двум, то функция-перехватчик в драйвере отдает управление системе так, как должно быть в незараженной системе.

Передача данных из библиотеки PlusDLL.dll драйверу sp1itter.sys

Как известно, 64-битные ОС Windows не позволяют запускать неподписанные драйверы. 64-битные версии вредоносного драйвера были подписаны с помощью похищенных сертификатов.

За все время слежения за группой Winnti мы обнаружили 11 сертификатов, которыми подписывались вредоносные программы, используемые группой. 10 из них принадлежали десяти различным компаниям игровой индустрии.

Запуск основной функции

Как уже было замечено, библиотека PlusDLL — это управляющий модуль. Посмотрим, каким образом вирусописатели реализовывали переход к выполнению основных задач. Они могли бы просто вызвать функцию, могли бы создать отдельный поток, выполняющий эту функцию, но почему-то злоумышленники использовали некий трюк: был изменен код функции SetWindowStationUser библиотеки user32.dll. Первой командой функции стала jmp , где — адрес функции библиотеки PlusDLL, в которой реализовано выполнение основных функций вредоносной библиотеки.

Хук на SetWindowStationUser

Сразу после такого изменения прямо в памяти кода функции SetWindowStationUser создается поток (CreateThread) с адреса этой функции. И когда в итоге управление передается на эту функцию, по команде jmp addr управление возвращается обратно на код PlusDLL.

Запуск собственного кода через создание потока с вызовом якобы SetWindowStationUser

Такой же метод используется для запуска еще двух функций библиотеки PlusDLL: одна используется для инициализации работы с сетью, вторая — в самом конце выполняет процедуры по завершению работы вредоносной программы. Только для их запуска вместо кода функции SetWindowStationUser изменяются коды двух других функций из user32.dll: в первом случае — EndTask, во втором — WinHelpW.

Вероятно, это сделано для того, чтобы скрыть настоящие адреса функций PlusDLL при анализе кода по журналам исполнения программы с помощью какой-либо автоматической системы («песочницы»), где отмечаются все вызовы функций. Если используется такой трюк, то в журнале исполнения может проявиться только запуск потоков с адресов функций SetWindowStationUser, EndTask и WinHelpW, что может запутать исследователей.

Еще одно предположение: это антиэмуляция. Возможно, эмуляторы каких-то антивирусных продуктов не могут справиться с такими «прыжками» и, соответственно, не получится проэмулировать управление до вредоносного функционала, что также на руку злоумышленникам.

Вредоносный функционал

Чем же управляет PlusDLL? Как оказалось, файлы с целевым функционалом, предоставляющие конкретно те или иные возможности удаленного управления, загружаются с сервера злоумышленников каждый раз при запуске системы. Эти файлы не сохраняются на диск или в реестр, а сразу помещаются в память.

В самом начале работы, после запуска драйвера, PlusDLL собирает информацию о зараженной системе. На основе данных о жестком диске и MAC-адреса сетевой карты генерируется уникальный идентификатор зараженного ботом компьютера, например TKVFP-XZTTL-KXFWH-RBJLF-FXWJR. Интересуют злоумышленников в первую очередь имя компьютера, программа, которая подгрузила вредоносную библиотеку, и информация о сессиях службы удаленного стола (имя сессии, имя клиента, имя пользователя и время сессии). Все эти данные собираются в буфер, который сжимается и отправляется на контрольный центр атакующих. Вот как может выглядеть такой буфер:

Бот передает центру управления информацию о зараженной системе

В ответ на это первое сообщение от бота центр управления посылает боту список доступных плагинов. Плагины — это библиотеки DLL, предоставляющие определенные функции удаленного управления. Получив список плагинов, бот поочередно их скачивает, размещает в памяти и передает управление этим библиотекам.

Разные серверы управления могли отдавать разные плагины. Всего нами было обнаружено 8 функциональных библиотек:

В этих плагинах и заключен основной функционал всей вредоносной платформы.

Схема работы вредоносной платформы

Схема работы платформы на начальном этапе

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

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

Продукты «Лаборатории Касперского» детектируют описанные выше программы со следующими вердиктами:

— начальные библиотеки winmm.dll и apphelp.dll, управляющие библиотеки PlusDll.dll и функциональные подгружаемые модули (CmdPlus.dll и т.д.): Backdoor.Win32.Winnti или Backdoor.Win64.Winnti;

— драйверы sp1itter.sys и acplec.sys: Rootkit.Win32.Winnti или Rootkit.Win64.Winnti.

Общение с центром управления

Данные, передаваемые в ходе общения бота и командного центра, разумеется, в трафике в явном виде не проявляются. Так как объем данных при активном удаленном управлении может быть существенным, злоумышленники передаваемую информацию сжимают алгоритмом LZMA, но не включают заголовок, свойственный этому алгоритму.

Общение происходит по протоколу TCP. В обнаруженных нами самплах соединение с серверами устанавливалось на порты 53, 80 и 443. Эти порты выбраны не случайно: они ассоциируются с протоколами DNS, HTTP и HTTPS соответственно. Все три протокола постоянно используются в обычной работе, поэтому в большинстве случаев в правилах межсетевых экранов они разрешены. Да и затеряться передаваемым данным среди всего потока трафика, который проходит по этим портам (кроме, может быть, 53-го), нетрудно.

Несмотря на то что сами порты ассоциируются с вышеназванными протоколами, структура трафика вредоносной программы им не соответствует. Первые версии платформы Winnti использовали следующую структуру данных при общении с командным центром: каждый блок передаваемых данных начинался с магического числа 0xdeadface, далее DWORD — количество блоков, 8 байт — хеш передаваемого блока, размер сжатых данных (DWORD), размер исходных данных (DWORD) и, наконец, сами сжатые данные.

Структура единичного блока данных в ранних версиях Winnti для передачи по cети

Здесь проявляется еще одно слабое место бэкдоров семейства Winnti. При такой структуре данных вредоносный сетевой трафик легко угадывался по тому же магическому числу 0xdeadface. Судя по всему, злоумышленники частенько теряли контроль над захваченными рабочими станциями из-за того, что сетевые администраторы зараженных компаний обнаруживали проникновение с помощью IDS/IPS-систем по такому уникальному заголовку сетевых пакетов и избавлялись от вредоносных программ. И в 2011 году появились бэкдоры группы Winnti, которые при сохранении той же платформы использовали для общения с центром управления уже модернизированный протокол — добавилось дополнительное шифрование, из-за которого передаваемые данные не имели статичных меток. Перед шифрованием передаваемые данные имеют следующую структуру (очень похожую на первый вариант): начальные 4 байта — магическое число 0xaced1984, далее DWORD — описание пакета данных, следующий DWORD = 0,8 байт хеша передаваемого блока, DWORD — размер сжатых данных, DWORD — размер исходных данных и далее сами сжатые данные:

Структура единичного блока данных в новых версиях Winnti для передачи по cети

Далее эти данные шифруются обычным XOR-ом со случайным значением размера DWORD и в таком виде передаются на центр управления. Так как известно, что первые четыре байта в исходных данных должны представлять значение 0xaced1984, можно легко восстановить значение, с которым операцией XOR были зашифрованы все передаваемые данные. Вот что представлял из себя перехваченный сетевой трафик, хранящий показанные выше данные (XOR-значение = 0x002a7b2e):

Зашифрованный блок данных в новых версиях Winnti, передаваемый по cети

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

Какой бы протокол ни использовался (с дополнительным шифрованием или без него), применяется одинаковая концепция общения бота с центром управления на начальном этапе работы:

1. бот отсылает первый блок данных, сообщая о себе
2. центр управления отвечает ему списком плагинов, которые у него имеются
3. бот начинает скачивать плагины, поочередно посылая центру управления запрос на загрузку каждого плагина
4. центр отдает запрошенный плагин
5. бот информирует о том, что плагин получен

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

После скачивания вредоносного функционала бот размещает плагины в памяти и передает им управление. Теперь все готово для полноценного удаленного управления зараженным компьютером, и бот переходит в режим ожидания подключения оператора, поддерживая связь с центром, примерно раз в 15 секунд посылая «пустые» блоки данных.

Кроме отдачи плагинов со стороны центра управления больше никаких автоматических действий не происходит — вся работа по исследованию зараженного компьютера проводится атакующими вручную.