Denis и его команда

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

В данной статье мы рассмотрим наиболее примечательных «пользователей» DNS-туннеля. Продукты «Лаборатории Касперского» детектируют их как общими (Trojan.Denes.UDP.C&C и Backdoor.Win32.Denis.*), так и «индивидуальными» вердиктами.

Trojan.Win32.Ismdoor.gen

Первый рассматриваемый зловред имеет многоуровневую структуру протокола взаимодействия с C&C, сходную с моделью OSI, что выгодно отличает его от прочих описанных троянцев — авторы Trojan.Win32.Ismdoor.gen действительно постарались при его проектировании и разработке.

В качестве транспортного уровня используется, само собой, DNS-туннель. Длина исходящих «датаграмм» ограничена 60 символами – конфигурация DNS-серверов и сам протокол подразумевает возможность увеличения данного значения. Команды сервера разрешаются в виде адреса в формате IPv6.

В общем виде запрос к C&C выглядит следующим образом:

n.n.c.<ID сессии>.<Домен сервера>.com

Структура запроса/ответа «транспортного уровня»

Над транспортным протоколом DNS-туннеля выстроен сеансовый, подразумевающий возможность обмена «короткими» и «длинными» пакетами и отличающийся от транспортного протокола механизмом проверки утерянных сообщений. Тогда как сессия транспортного протокола завершается обменом данными о количестве отправленных и полученных пакетов, в сеансовом протоколе производится проверка корректного получения каждого отправленного пакета. Выбор, какой способ использовать, остается за сервером, — к примеру, для получения файла с зараженного компьютера используется протокол с «длинными» пакетами.

Пример протокола для обмена короткими сообщениями

Короткие сообщения

На этом уровне работу бота можно условно разделить на пять шагов:

• Объявление серверу IDсессии;
• Отправка сообщения пакетами;
• Отправка количества переданных пакетов;
• Получение количества входящих пакетов;
• Прием входящих пакетов.

Пример сессии:

1. Объявление серверу ID сессии

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

n.n.c.<ID сессии>.<Домен сервера>.com

Положительным ответом является сообщение A67DDB8A2A17334765443253702AA3. В противном случае отправка повторяется.

2. Отправка сообщения

Как уже говорилось ранее, выбранный механизм коммуникации накладывает некоторые ограничения на размер пакетов. Исходящее сообщение разбивается на пакеты длиной 60 байт и передается в виде URL:

<Исходящий пакет>.<Номер пакета>.dr.<ID сессии>. <Домен сервера>.com

В качестве ответа должно быть получено A67DDB885A3432576548A2A3707334.

3. Отправка количества переданных пакетов

После успешной отправки всех пакетов передается их количество в виде запроса следующего вида:

n.<Количество пакетов>.f.<ID сессии>.<Домен сервера>.com

Стоит отметить, что нумерация пакетов начинается с 0. Ответом служит 20202020202020202020202020202020.

4. Получение количества входящих пакетов

Данный шаг реализуется с помощью URL вида:

n.n.fc.<ID сессии>.<Домен сервера>.com

Ответ должен быть вида

A67D: DB8: 85A3: 4325: 7654: 8A2A :: <Количество входящих пакетов>

5. Прием входящих пакетов

Запрос на получение очередного пакета выглядит так:

www. <Номер пакета>.s. <ID сессии> .<Домен сервера>.com

Входящие сообщения приходят в виде 16-байтных пакетов IPv6 .

Длинные сообщения

В данном случае взаимодействие с сервером можно разбить на следующие шаги:

• Передача количества пакетов, на которые был разбит файл;
• Отправка файла;
• Периодический опрос сервера на предмет утерянных пакетов;
• Повторная отправка утерянных пакетов.

ID сессии берется из запроса, в котором этот файл был затребован.

1. Передача количества пакетов

Запрос: n.<Количество пакетов>.<ID сессии>.<Домен сервера>.com

Ответ: A67DDB8A2A17334765443253702AA3.

2. Отправка файла пакетами

Запрос: <Исходящий пакет>.<Номер пакета>.d.<ID сессии>.<Домен сервера>.com

Ответ: на данное сообщение сервер отвечать не будет или ответит ошибкой Server failure.

3. Периодический опрос сервера на предмет утерянных пакетов

Периодически бот опрашивает сервер:

uff<Количество пакетов>.<Количество пакетов>.<Домен сервера>.com

Ответ: 20202020202020202020202020202020

Далее реализуются пункты «Получение количества входящих пакетов» и «Прием входящих пакетов» из предыдущего раздела.

В ответе указываются через запятую номера пакетов, которые сервер не получил.

4. Повторная отправка утерянных пакетов

Запрос: <Исходящий пакет>.<Номер пакета>.dl.<ID сессии>.<Домен сервера>.com

Представительский уровень OSI отвечает за кодирование и декодирование сообщений. Ответ сервера, содержащийся в поле IPv4, представлен в виде обычной ASCII-строки, кратной шестнадцати. Обращение к серверу в DNS-запросе кодируются в base64 c переопределенной индексной таблицей.

Пример первого сообщения и его же в теле «датаграммы»

Прикладной уровень — это просто набор «GET-подобных» обращений к C&C:

• Проверка соединения. Cам запрос выглядит как строка «M:CC?»;
• Регистрация подключения — определяет доступные команды и идентификаторы зараженной машины и бота (M:AV?appId=<…>&uniqueId=<…>);
• Команда подтверждения регистрации;
• «Обобщенный» ответ (M:ME?appId=<…>&message=<…>);
• Получение команды (M:GAC?appId=8);
• Подтверждение команды (M:CR?cd=<GUID команды>);
• Отправить файл (M:SF?commandId=CmdResult=<GUID команды>|||<Результат выполнения команды>);
• Получить файл (M:GF?).

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

• SI — передача информации о зараженной системе;
• RunNewVersion — обновление;
• Restart — перезапуск;
• remove — «самоудаление»;
• CreateMimi1Bat — выполнение Mimikatz;
• ExecuteKL — активация кейлоггера ;
• RemoveKL — удаление файлов, созданных ExecuteKL;
• GetVersion — отправка версии зловреда;
• PauseUpload — приостанавливает загрузку файла на сервер;
• ResumeUpload — возобновляет загрузку файла на сервер;
• PauseDownload — приостанавливает скачивание файла с сервера;
• ResumeDownload — возобновляет скачивание файла с сервера;
• PWS — создание скриншота;
• DownloadFile — скачать файл с сервера;
• UploadFile — загрузить файл на сервер.

Прочие команды, которыми располагает троянец, отвечают за логику его работы (изменение адреса командного сервера и т.п.).

Backdoor.Win32.ClIEcker

Следующий из рассматриваемых семплов использует другую схему работы, основанную на пакетах ANY DNS. Такой механизм позволяет принимать от сервера DNS-пакеты произвольной структуры. В троянце отсутствует логическое разбиение на подпротоколы — есть просто исходящие и входящие запросы. Нам удалось обнаружить несколько модификаций данного зловреда, ниже будут описаны функции и особенности, присутствующие во всех.

Одной из интересных особенностей Backdoor.Win32.ClIEcker является способ получения IP-адреса — для этого он использует COM-интерфейс Internet Explorer. Троянец содержит список адресов сайтов, на которых посетитель может увидеть свой IP-адрес (например: http://www.ip-adress.com). Зловред выбирает случайным образом один, переходит по нему, находит в теле страницы строку, после которой начинается IP-адрес и извлекает его. Для того чтобы максимально правдоподобно «замаскировать» обращение, троянец также подбирает случайный адрес реферала и заполняет его в соответствующем запросе к Internet Explorer.

Неясно только, почему был выбран такой сложный способ: как правило, троянцы узнают IP-адрес жертвы, запрашивая данные с сайтов, возвращающих в качестве HTML-страницы строку с IP-адресом. Можно предположить, что это было сделано в попытке исключить резолв IP из списка IoC данного вредоноса, либо же это просто бездумный «копипаст» с репозитория или форума.

Ситуация усугубляется еще и тем, что в зловреде есть команда для открытия страницы в IE по запросу от сервера и для этого используется тривиальный вызов формата «IEXPLORE.EXE ya.ru», а не сложное взаимодействие через COM. Из-за этого зловред может детектироваться как Trojan-Clicker, однако, как было рассказано в одной из предыдущих статей, троянцы данной группы обычно используют для этих целей виртуальный рабочий стол.

Примеры адресов для резолва IP/Адреса рефералов/Получения содержимого страницы через COM

В качестве инициирующего запроса передается ряд параметров с информацией о системе, а также уникальный ключ RC4, созданный на основании данных о зараженном компьютере:

• Старшая версия операционной системы;
• Логический флаг – используется ли подключение по модему или нет;
• Идентификатор троянца;
• Зашифрованный IP-адрес пользователя;
• Код антивирусной службы.

По последнему пункту следует дать некоторое пояснение – троянец содержит список процессов защитного ПО, где каждый продукт имеет свой бит в коде, передаваемом на сервер. То есть, например, все процессы, относящиеся к продуктам McAfee, будут обозначатся флагом 0x400 в коде антивирусной службы.

Далее приведем описание некоторых команд:

Отдельного внимания заслуживает команда с кодом 8, так как в ней сосредоточен основные возможности программы. Ее задача — скачать и запустить полезную нагрузку. Аргументы у данной команды следующие:

Для передачи файла используются пакеты формата TXT DNS.

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

После завершения дешифровки целостность полученного файла проверяется с помощью CRC32.

Backdoor.Win32.Denis

Backdoor.Win32.Denis имеет наиболее простую структуру и наиболее простую функциональность для взаимодействия с DNS-сервером. Имя данной малвары совпадает с именем троянца, описанного в этой статье, но на этом сходство заканчивается.

Для взаимодействия с DNS-сервером используются пакеты формата A DNS, ограничивающего размер ответа четырьмя байтами. По всем признакам, данный зловред – обычный Trojan-Downloader с крайне низкой скоростью загрузки. В общем виде сообщение серверу выглядит следующим образом:

IC<Тип контейнера>.<UID>.<Контейнер>.<Адрес сервера>

Как «контейнер» мы обозначили упакованные результаты работы троянца — в зависимости от команды и ответа, структура контейнера может сильно разнится. UID это идентификатор пользователя с длинной 0x20. Представляет собой строку Base32, которая после декодирования имеет следующую структуру:

Контейнер так же является Base32-строкой:

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

Команды

Как видно из описания команд, целевое назначение троянца – выгрузка и запуск файлов.

MD5

15b36b1e3a41ad80bbd363aea8f2d704 — Trojan.Win32.Ismdoor.gen
1FD599FB9FA62EB91511002771D78104 — Backdoor.Win32.ClIEcker
1f3a2c48a7f5c2c31e71f552d74c3543 — Backdoor.Win32.Denis