Зловредная аналитика. Ботсеть на базе Black Energy 2

В последнее время DDoS-атаки приобрели второе дыхание и стали довольно популярны среди злоумышленников, да и вредоносное программное обеспечение сделало существенный шаг вперед, как я писал в одной из своих аналитический статей, и уже давно не является узкопрофильным. А посему в каждом зловреде можно найти что-нибудь из класса, к которому он не относится. Ботов, которые занимаются зомбированием пользовательских машин и созданием ботнетов, довольно много, но одним из самых популярных является Black Energy, которого модифицировали в 2008 году, новая версия носила название Black Energy 2 (Backdoor.Win32.Blakken по классификации Лаборатории Касперского). Именно об этом боте я и хотел бы сегодня поговорить.

При создании зловреда автор хорошо все продумал и напичкал его как следует. В боте можно найти и механизмы сокрытия кода от антивирусных программ, и модуль заражения системных процессов, и различные вредоносные функции, которыми можно управлять из ЦУ ботнета – как видите, полный набор необходимых функций .

Система защиты от обнаружения сделана неплохо: шифрование кода, архивирование + еще и антиэмуляционные методы встречаются. При заражении компьютера-жертвы exe-шник выделяет место в памяти и копирует туда код дешифровщика, передавая ему управление. Результатом работы дешифровщика является код в памяти, имеющий функции дропера. Последний создает в системном каталоге \system32\drivers драйвер-дешифровщик со случайным именем. После этого создается служба, связанная с этим драйвером, и запускается (рис. 2)

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

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

Расшифрованные данные представляют собой драйвер-инфектор, в функционал которого заложено внедрение библиотеки dll в процесс пользовательского режима svchost.exe. Чтобы запустить драйвер-инфектор, драйвер-дешифровщик выделяет под него память, копирует туда расшифрованный код, настраивает под текущее адресное пространство и передает управление. Вредоносная библиотека dll хранится в секции «.bdata» драйвера-инфектора. Этот блок данных также имеет вышеупомянутую структуру. Драйвером-инфектором находится процесс svchost.exe, в его адресном пространстве выделяется память, в нее копируется вредоносная dll, которая настраивается под адреса выделенной памяти. Код внедренной библиотеки из режима ядра запускается так, как показано на рисунке 5.

Здесь используется обработка очереди APC. Сначала инициализируется APC с адресом функции DllEntry внедренной библиотеки, затем с помощью KeInsertQueueApc APC ставится в очередь. Когда svchost.exe будет готов к обработке APC-очереди (что происходит практически сразу же), в его контексте запустится поток с адреса DllEntry.

Внедренная в svhost.exe библиотека и есть основное связующее звено в организации ДОСа. Так же, как и драйвер-инфектор, в библиотеке имеется секция .bdata, в которой хранится блок зашифрованных данных. Данные представляют собой xml-код, который несет в себе дефолтные настройки бота.

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

На адрес центра управления бот посылает заранее подготовленный http-запрос, который представляет собой строку, содержащую идентификационные данные зараженной машины. Вот как может выглядеть такая строка:

id=xCOMPUTERNAME_62CF4DEF&ln=ru&cn=RU&nt=2600&bid=3

Параметр id, идентификатор зараженной машины, включает в себя имя компьютера и серийный номер жесткого диска, на котором размещен диск C:. Далее указываются данные об операционной системе: язык системы, страна, в которой установлена система, и номер сборки системы. В конце добавляется идентификатор сборки бота (последнее поле «build_id» в xml-документе начальных настроек).

Определенный вид строки запроса служит подтверждением тому, что запрос делает именно бот. Кроме того, для центра управления своего рода паролем может служить также user-agent http-запроса.

Если центр управления принимает запрос, то в ответ он посылает файл конфигурации бота также в виде зашифрованного xml-документа. Шифрование используется то же самое, что и в случае шифрования данных в драйвере и dll — RC4. Ключом служит идентификатор зараженной машины (параметр id строки запроса, в приведенном выше примере — «xCOMPUTERNAME_62CF4DEF»).

Давайте посмотрим на пример таких инструкций на рисунке 6.

Раздел сообщает боту, какие модули есть на сервере хозяина для организации DDoS-атаки. Если у бота еще нет такого модуля, или на сервере более новая версия, то бот посылает запрос серверу на скачивание плагина, например:

getp=http&id=xCOMPUTERNAME_62CF4DEF &ln=ru&cn=RU&nt=2600&bid=3

Плагин представляет собой библиотеку dll. Передается она боту в зашифрованном виде. Если для шифрования используется ключ, отличный от значения параметра id, то он указывается в файле конфигурации в поле . После получения и расшифровки библиотеки-плагина, она размещается в выделенную под нее память, после чего готова приступить к DDoS-атаке, как только придет соответствующая команда.

Плагины загружаются на зараженный компьютер регулярно: как только вирусописатель улучшит метод атаки, бот Black Energy 2 подгрузит более новую версию плагина.

Скачанные таким образом плагины сохраняются на жестком диске зараженного компьютера в системном каталоге «\system32\drivers» под именем «str.sys». Содержимое файла str.sys шифруется, ключом является значение параметра id. До шифрования данные, сохраняющиеся в str.sys (рис. 7).
В каждом плагине имеется экспортируемая функция DispatchCommand, которую вызывает основной управляющий модуль — внедренная в процесс svchost.exe библиотека dll. Функции DispatchCommand передается параметр — одна из команд раздела в файле конфигурации бота. После чего плагин выполняет данную команду.

Основными плагинами для этого бота можно считать ddos, syn и http, предлагаю рассмотреть их подробнее.

Что касается плагина ddos, то тут ничего нового вы для себя не откроете. Плагину из ЦУ отправляется ip-адрес атакуемого сервера, протокол и порт. Далее следуют многочисленные соединения, после установления каждого из них компьютер-зомби отправляет свободный пакет данных. Поддерживаются протоколы tcp, udp, icmp и http, собственно, все, что необходимо.

Ниже вы можете посмотреть на выполнение команды ddos_start udp <интернет-адрес> 80: рис.8 - создание сокета, протокол UDP; рис.9 - отправка данных: sendto и стек; рис.10 - отправка данных — куда. pTo: ip-адрес и порт; рис.11 - отправка данных — что. Data: случайный набор байт.

В отличие от других плагинов, упомянутых в этой статье, в плагине syn присутствует сетевой драйвер. При вызове функции DllEntry плагина этот драйвер устанавливается в системный каталог «\system32\drivers» под именем «synsenddrv.sys». Отправку сетевых пакетов он берет на себя. Функция DispatchCommand, как уже можно догадаться, ждет от управляющей библиотеки параметр такого вида: «syn_start » или «syn_stop ». В случае получения первого параметра плагин начинает атаку, если получен второй — прекращает. Атака в данном случае представляет собой множественные запросы серверу на установку соединения, открытие сетевой сессии, так называемый «обмен рукопожатиями» (рис.12).

Против описанных выше методов DDoS-атак часто применяется редирект: сервер с интернет-ресурсами прячется за шлюз, который видно извне, а шлюз перенаправляет запросы на сервер с ресурсами. От DDoS-атак шлюз защищается всевозможными способами, и «свалить» его не так-то просто. Соответственно, плагинами ddos и syn по IP-адресу может быть атакован только шлюз, так как никакого функционала распознавания перенаправления трафика у них нет, и сетевой «флуд», который они генерируют, до сервера с интернет-ресурсами просто не доходит. На этот случай вирусописателями и был разработан плагин http.

Получив команду «http_start », плагин http создает COM-объект «Internet Explorer(Ver 1.0)» с интерфейсом «IWebBrowser2». Вызывается метод Navigate с параметром из команды «http_start». В результате COM-объект «Internet Explorer(Ver 1.0)» реализует переход на указанную страничку. Далее с помощью метода Busy вредоносная программа ожидает, когда запрос полностью отработает (рис.13 - создание COM-объекта; рис.14 - указатель на CLSID; рис.15 - указатель на ID интерфейса; рис.16 - вызов метода Navigate; рис.17 - вызов метода Busy).

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

Заключение

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

P.S.: Я выражаю благодарность Дмитрию Тараканову, эксперту Лаборатории Касперского, за отличные материалы, которые были использованы при написании данной статьи.

Евгений Кучук, q@sa-sec.org