История развития Dridex

Банковский троянец Dridex, ставший одной из главных финансовых киберугроз последних лет (в 2015 году ущерб, нанесенный им, оценивался в более чем $40 млн), отличается от других вредоносных программ тем, что, существуя с 2011 года, постоянно развивается и усложняется. Так долго избегать правосудия Dridex смог благодаря сокрытию основных командных центров за проксирующими слоями. Основываясь на том, что с появлением новых версий старые перестают работать, а каждое новое улучшение является очередным шагом в планомерном развитии зловреда, можно сделать вывод, что на протяжении всего этого времени его разработкой занимаются одни и те же люди. Ниже мы кратко расскажем о том, как на протяжении шести лет развивалось это вредоносное ПО и раскроем технические особенности его последних версий.

С чего все начиналось

Первое появление Dridex (тогда - Cridex) как самостоятельной вредоносной программы датируется примерно сентябрем 2011 года. Анализ образца Cridex (MD5: 78cc821b5acfc017c855bc7060479f84) показал, что вредоносная программа уже тогда умела получать динамический конфигурационный файл, использовать веб-инжекты для кражи денег, а также могла заражать USB-накопители. Эта особенность повлияла на имя детекта "нулевой" версии Cridex - Worm.Win32.Cridex.

Данная версия имела бинарный конфигурационный файл:

Сами веб-инжекты, благодаря секциям databefore, datainject и dataafter, были похожи на распространенную вредоносную программу Zeus (этому могла поспособствовать утечка исходных кодов Zeus в 2011 году).

Cridex 0.77-0.80

В 2012 году модификация Cridex (MD5: 45ceacdc333a6a49ef23ad87196f375f) претерпела значительные изменения: злоумышленники отказались от функции заражения USB и заменили бинарный формат конфигурационного файла и пакетов на XML. Запрос зловреда к командному серверу выглядел следующим образом:

Корневым элементом XML был тег <message>. В теге <header> содержалась информация о системе, идентификаторе бота, а также версии.

А вот пример конфигурационного файла:

За исключением корневого элемента <packet>, конфигурационный файл Dridex 0.8 практически не менялся до версии 3.0.

Dridex 1.10

Существование "нулевой" версии продолжалось вплоть до июня 2014. В том же месяце произошла крупная операция (Operation Tovar) по закрытию другой распространенной вредоносной программы - Gameover Zeus. Практически одновременно с закрытием Zeus "нулевая" версия Cridex прекратила работу и буквально через месяц (22 июня) появился Dridex версии 1.100.

Пример конфигурационного файла:

В нем уже появились характерные для Dridex редиректы для инжектируемых .js-скриптов.

А вот сравнение инжектов Dridex и Gameover Zeus:

Таким образом закрытие одной популярной бот-сети (Gameover Zeus) привело к резкому скачку в развитии другой, включающей в себя множество совпадений со своим предшественником.

Выше мы отметили, что Dridex начал использовать PCRE, а в предыдущих версиях зловреда использовался SLRE. Примечательно, что единственной банковской вредоносной программой, которая также использовала SLRE, был Trojan-Banker.Win32.Shifu. Этот троянец был обнаружен в августе 2015 года и распространялся посредством спама с тех же ботнетов, что и Dridex. Кроме того, и в том, и в другом банкерах использовался формат XML для конфигурационных файлов.

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

Dridex: от версии 2 к версии 3

К началу 2015 года в Dridex появляется подобие пиринговой сети, что опять же напоминает нам о троянце Gameover Zeus. В данной сети некоторые пиры (суперноды) имели доступ к командному центру и перенаправляли запросы других членов сети к нему. Конфигурационный файл по-прежнему хранился в формате XML, но в него была добавлена секция <nodes>, которая сдержала список актуальных пиров. Также появилось шифрование протокола общения с командным центром.

Dridex: от версии 3 к версии 4

28 августа 2015 был арестован один из администраторов сети Dridex. В первых числах сентября перестают работать сети с идентификаторами: 120, 200, 220. Но уже в октябре они возвращаются в строй и появляются новые: 121, 122, 123, 301, 302, 303.

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

В 2016 году усложнился загрузчик и поменялись методы шифрования. Протокол загрузчика изменился на бинарный, а также появилась секция <settings>, содержащая конфигурационный файл в бинарном формате.

Dridex 4.x. Back to future

Четвертая версия Dridex была обнаружена в начале 2017 года. По своим возможностям она похожа на третью, за исключением того, что злоумышленники отказались от использования XML в конфигурационном файле и пакетах и вернулись к бинарному формату. Анализ новых образцов сильно осложняется тем, что загрузчик теперь работает максимум пару дней, примерно так же было с Lurk, только там загрузчик работал пару часов.

Анализ пакетов загрузчика

Структура пакетов четвертой версии схожа с пакетами поздних модификаций версии 3.х загрузчика. Однако имена запрашиваемых модулей были заменены хэшами:

А вот функция общения с командным центром, в которой используются данные хэши:

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

В четвертой версии Dridex достаточно много мест, где используется алгоритм хэширования CRC32: это и хэши для поиска API функций, и проверка целостности пакетов. Логично было бы предположить, что хэши в пакетах - это ни что иное как CRC32 от имен запрашиваемых модулей. Несложно проверить это предположение, выполнив следующий код Python:

Все верно, полученные хэши CRC32 соответствуют таковым в коде программы.

Если же говорить о шифровании пакетов загрузчика, то здесь ничего не изменилось. Как и в Dridex версии 3 используется алгоритм RC4 с ключом, хранящимся в зашифрованном виде в теле вредоносной программы.

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

Анализ протокола и шифрования бота

В Dridex версии 4 были сохранены основные черты взаимодействия c командным сервером, пиры по-прежнему играют роль прокси и могут обмениваться модулями. Но шифрование и сама структура пакетов сильно изменились: теперь они напоминают секцию <settings> из прошлой версии Dridex. Больше никаких XML.

Функция Basic Packet Generation используется для создания пакетов для общения как с командным сервером, так и с пирами. Пакеты для командного сервера делятся на два типа:

1. Регистрация, передается сгенерированный публичный ключ;
2. Запрос конфигурационного файла.

На выходе данной функции получается следующий пакет:

 

В начале пакета идет длина RC4 ключа (74h), который будет использоваться для шифрования строк в этом пакете. Далее две части этого ключа одного размера. Настоящий ключ получается путем XOR этих блоков. Далее тип пакета (00h) и зашифрованный идентификатор бота.

Peer-to-Peer encryption

Пример зашифрованного P2P-пакета:

Заголовок в P2P-пакете - это массив DWORD, общая сумма которых равна нулю. Обфусцированный размер данных такой же, как и в предыдущее версии. А вот сами данные зашифрованы по-новому:

Сначала идет ключ 16 байт, затем 4 байта сведений о размере данных, зашифрованных предыдущим ключом с помощью RC4. Далее идет ключ 16 байт и данные, зашифрованные этим ключом с помощью RC4. После расшифровки получим пакет, сжатый gzip.

Peer to C&C encryption

При общении с командным центром используется, как и раньше, связка RSA + RC4 шифрование + HTTPS. Пиры в этом случаи работают как прокси. Структура зашифрованного пакета - 4 байта CRC далее RSA_BLOB. После расшифровки RSA (пакеты запросов расшифровать невозможно без наличия закрытого ключа командного сервера) получаем GZIP-пакет.

Конфигурационный файл

Нам удалось получить и расшифровать конфигурационный файл бот-сети 222:

По своей структуре он сильно напоминает секцию <settings> из предыдущей версии Dridex. Сначала идет 4-байтный хэш, а затем секции конфигурационного файла.

Типы секций те же, что и в <settings>:

• 01h - HttpShots
• 02h - Formgrabber
• 08h - Redirects
• etc.

Изменилось лишь шифрование строк конфигурационного файла, теперь используется RC4.

RC4 также использовалось для шифрования данных p2p-пакетов.

География распространения

Потенциальных жертв создатели Dridex ищут в Европе. В период с первого января по начало апреля 2017 года мы обнаружили активность Dridex в нескольких европейских странах. Большая часть срабатываний - почти 60% - была зафиксирована в Великобритании, следом идут Германия и Франция. В то же время зловред принципиально не работает в России - командные сервера определяют страну по IP и не отвечают, если это Россия.

Заключение

За несколько лет существования семейства Dridex не раз предпринимались безуспешные попытки прекратить активность бот-сети. Непрерывное развитие зловреда показывает, что преступники не собираются расставаться со своим детищем, которое приносит стабильный доход. Так, например, в Dridex постоянно появляются новые техники обхода системы контроля учетных записей (User Account Control, UAC), позволяющие осуществлять запуск вредоносных компонентов в Windows-системах.

Можно предположить, что за троянцами Dridex и Zeus Gameover стоят одни и те же люди, возможно, русскоговорящие. Однако утверждать это наверняка мы не можем. Невозможно точно оценить и ущерб, нанесенный киберпреступниками. По крайне приблизительной оценке, на данный момент речь может идти о сотнях миллионах долларов. А учитывая то, как развивается зловред, можно предположить, что в разработку этого банковского троянца инвестируется значительная часть "заработанных" средств.

Анализ сделан на основе следующих семплов:

Dridex4 loader: d0aa5b4dd8163eccf7c1cd84f5723d48
Dridex4 bot: ed8cdd9c6dd5a221f473ecf3a8f39933