4. В статье приводится детальный анализ банковского троянца Lurk, описываются приемы
распространения, особенности работы, механизмы, используемые для воровства денег, и способы
снижения заметности.
Введение
На закрытых форумах киберпреступников можно часто услышать фразу-совет: «не работай по RU» -
это своего рода напутствие опытных негодяев молодой смене. В переводе на русский язык фраза
означает следующее: «не воруй деньги у граждан РФ и бывшего СНГ, не заражай их машины, не
используй соотечественников для отмывания денег». Начинающие киберпреступники зачастую
считают это чем-то вроде позиции Робина Гуда: воровать деньги у граждан развитых западных стран
морально допустимо, а у соотечественников – нет, т.к. последние и без этого находятся в удручающем
экономическом положении. Некоторые даже считают, что, руководствуясь этим принципом,
совершают благое дело: выводят деньги из западных экономик и оставляют их в экономике РФ.
Ничего общего с правдой это, разумеется, не имеет.
Правда в том, что «работать по RU» не выгодно с точки зрения безопасности киберпреступников:
жители других стран вряд ли обратятся в полицию РФ. Кроме того, в зоне RU не слишком
распространен интернет-банкинг, во всяком случае – распространен гораздо меньше, чем в западных
странах. Следовательно, потенциальный доход от деятельности в RU-зоне ниже, чем в других зонах, а
риск – выше. Именно поэтому появилось правило «не работай по RU».
Однако, как и всегда, из этого правила есть исключения. Например, весьма заметный банковский
троянец, о котором мы расскажем, - Lurk - уже несколько лет активно используется для воровства
денег у резидентов РФ и бывшего СНГ, и его создатели все еще на свободе. Пока.
Мы уже писали об этом банковском троянце раньше, практически сразу после появления он привлек
наше внимание тем, что использовал механизм бестелесного распространения – вредоносный код не
сохранялся на диске и запускался непосредственно из памяти. Однако детальное описание этого
троянца до сих пор не было опубликовано.
Между тем, Lurk заслуживает подробного рассмотрения из-за нестандартных, порой – неочевидных
решений, примененных его авторами. Мы не утверждаем, что этот троянец хорошо написан – мы
видели и анализировали банковские троянцы, которых отличало гораздо более высокое качество
кода. Более того, анализ Lurk показал, что над кодом работало несколько программистов и их
квалификация была различной. Местами в коде встречаются откровенно неудачные решения,
которые авторы не исправляют годами. Мы, разумеется, не будем указывать авторам на их ошибки.
Однако с уверенностью можно утверждать, что Lurk один из наиболее сложных банковских троянов с
точки зрения анализа его кода.
Lurk – это универсальный банковский троянец. В том смысле, что способен похищать деньги не только
из системы «iBank 2» (система ДБО «iBank» используется многими банками), но и из интернет-систем
ДБО некоторых крупных российских банков, которые являются уникальными для каждого банка.
Троянец состоит из нескольких модулей, обладающих довольно богатыми возможностями. Причем на
зараженную пользовательскую машину с C&C загружаются только те модули, которые на ней нужны
для хищения денежных средств (или для кражи ценных данных и дальнейшего распространения по
сети).
5. В качестве жертв злоумышленников интересуют:
IT-организации в сфере телеком (возможность создания перевалочных серверов, через
которые пойдет трафик к серверам злоумышленников);
СМИ и новостные агрегаторы (возможность заражения большого числа компьютеров через
популярные сайты);
банки и финансовые организации (кража денег);
клиенты крупнейших российских банков — пользователи систем ДБО этих банков (кража
денег).
Желание авторов зловреда закрепиться на машинах силовых структур (эти организации также есть в
списке атакованных) оставим без комментариев.
Вирусописатели развивают свой продукт – мы отмечаем повышение качества кода с течением
времени и улучшение используемых авторами решений. Lurk отличает высокая таргетированность –
авторы делают все, чтобы заразить максимальное количество интересных им жертв, не привлекая при
этом внимания аналитиков и исследователей. Несмотря на то, что векторы распространения Lurk
охватывают широкую аудиторию (например, заражения через эксплойты на популярных форумах)
закрепление на системе жертвы происходит только в случае, если система представляет интерес для
злоумышленников (подробнее об этом в разделе, посвящённом модулю prescanner).
Инциденты, о которых известно нам, убеждают в том, что Lurk со своей задачей справляется –
периодически приходят сообщения о хищениях в системе ДБО, а криминалистические исследования
после инцидентов показывают следы Lurk на машине.
Заражение
Для распространения банковского троянца Lurk применяется широко известная техника drive-by.
Кроме нее, авторы также распространяют троянца через взломанные сайты легитимного ПО и внутри
сетей организации – при помощи утилиты psexec.
Заражение через эксплоит-пак
Lurk распространяется главным образом при помощи знаменитого эксплойт-пака Angler (авторское
название – XXX). Такой способ распространения особенно опасен, т.к. для заражения не требует
никаких специальных действий от пользователя.
Angler по праву считается флагманом: эксплойты для новых уязвимостей почти всегда реализуются
сначала в этом эксплойт-паке, а уже потом расползаются по остальным (не исключено, что просто
заимствуются). Нередки случаи реализации в Angler эксплойтов к уязвимостям «нулевого дня», что
делает его особенно опасным. Основным показателем эффективности любого эксплойт-пака
является так называемый «процент пробива» – количество жертв, на компьютерах которых успешно
запустилась полезная нагрузка (payload). У эксплоит-пака Angler этот процент особенно высок
(высоким обычно считается процент пробива >= 10%). Отдельные исследователи допускают, что в
некоторых ситуациях пробив Angler EK мог составлять порядка 40%.
6. Вот как обычно происходит подготовка к заражению Lurk новых жертв:
1. Выбирается сайт, интересный ЦА: бухгалтерский форум, новостной портал и т.п.
Заражение сайта осуществляется при помощи скрытного размещения на нем ссылки на
лендинг-страницу эксплойт пака.
2. Зашедшие на сайт пользователи скрытно отправляются на лендинг эксплойт-пака. Angler
пытается произвести эксплуатацию какой-либо уязвимости в ПО пользователя, что должно
привести к запуску загрузчика Lurk – mini.
Отметим, что ссылка на лендинг эксплойт-пака либо ставится на короткое время, либо появляется и
исчезает периодически.
Например, мы наблюдали заражение форума одного известного журнала для бухгалтеров, на
котором ссылка на лендинг эксплойт-пака Angler появлялась в рабочие дни ровно на два часа в
обеденное время. Мы, разумеется, замечали аномальную активность и оповещали владельцев
ресурса, однако к моменту, когда они читали наше письмо, ресурс уже был чист, и они не видели
заражения. А владельцы Lurk за время наличия вредоносной ссылки на форуме получали несколько
новых живых ботов.
Для распространения Lurk используется т.н. «indexm.html-версия» Angler, которая была описана здесь.
Эта версия Angler используется в основном для атаки на пользователей в зонах RU/UA, и активна на
момент написания этой статьи.
Вот пример заражения через Angler, которое прошло успешно:
Забегая вперед, отметим, что в этом заражении не был скачан и запущен модуль prescanner.
Заражение через взломанные сайты
Второй вариант заражения, который злоумышленники активно использовали, – это раздача
вредоносного кода с легитимных сайтов.
Один из таких сайтов – ammyy.com. Этот ресурс распространяет удобную и довольно популярную
среди системных администраторов программу для удаленного управления компьютером — Ammyy
Admin. Но периодически вместе с Ammyy Admin ничего не подозревающие администраторы
загружали и Lurk. Эта история началась в октябре 2015 года и продолжалась до мая 2016 года, мои
коллеги уже писали об этом. Здесь отметим только, что, похоже, при таком способе распространения
зараженные файлы отдаются только пользователям из RU-зоны, остальные посетители ресурса
получают чистые файлы.
7. Стоит принять во внимание тот факт, что программы для удаленного администрирования, включая
Ammyy Admin, детектируются большинством антивирусов как потенциально опасные и некоторые
системные администраторы либо отключают антивирус на время работы с такими программами,
либо добавляют исключение для Ammyy Admin, либо запрещают удаление/лечение даже если
видят детект. Таким образом, злоумышленники, во-первых, заражают компьютеры своей целевой
аудитории — администраторов средних и крупных корпоративных сетей, во-вторых, обходят
проблему с детектированием своего трояна.
Заражение машин внутри сети организации
Для злоумышленников очень интересна схема, при которой в ходе первоначальной атаки заражается
один из компьютеров организации. Даже если на зараженной машине нет ничего, что представляет
интерес для злоумышленников, такой компьютер находится в одной сети, в одном домене с другими
компьютерами, которые обладают интересующей хозяев троянца информацией. В таких случаях
злоумышленники сначала выявляют круг интересующих их компьютеров (контроллеры домена,
бухгалтерские системы) в этой подсети с помощью сетевого сканера «SoftPerfect Network Scanner», а
затем заражают эти компьютеры используя утилиту Марка Руссиновича PsExec, а для запуска
основных модулей троянца на других компьютерах в сети – специальный дроппер mini. Такой способ
распространения может привести к крайне печальным последствиям, так как безопасность
компьютера с интересующими данными по сути определяется безопасностью самого
слабозащищенного компьютера в атакованной сети.
Шаг атаки №1: mini
На первом этапе атаки при помощи эксплойт-пака Angler происходит эксплуатация найденной
уязвимости в ПО пользователя, а затем загрузка и запуск модуля mini. В случае, если пользователь
скачал вредоносный файл со взломанного сайта или вредоносный код запущен при помощи утилиты
psexec, сразу происходит запуск модуля mini.
Шаг атаки №1
Mini – это небольшая по меркам Lurk программа (<100 Кб). Ее основная задача – скачать и запустить на
исполнение основные модули вредоносной программы Lurk:
prescanner (пресканер),
core (ядро бота),
core_x64 (64-битная версия ядра),
mini_x64 (64-битная версия модуля mini).
После первого запуска задача mini сводится к запуску соответствующей версии core из хранилища
модулей вредоносной программы.
Angler EK mini
8. Отметим, что C&C-сервера для mini и для core разные – адрес сервера mini жестко зашит в теле
программы («захардкожен»), а адрес сервера управления core определяется в результате работы
алгоритма генерации доменов (DGA – Domain Generation Algorithm).
Первый запуск mini
После запуска модуль mini сохраняет собственный файл с добавленным в заголовок флагом
динамической библиотеки во временный файл. Это действие в дальнейшем позволяет mini
функционировать как библиотеке (файлу с расширением .dll).
Затем для этого временного файла запускается процедура регистрации (описана далее) вредоносной
программы путем запуска программы regsvr32, а основной функционал выполняется в контексте
explorer.exe
Регистрация mini
В контексте процесса regsvr32.exe mini с помощью модуля prescanner определяет есть ли на
зараженной системе программы для ДБО или интересная злоумышленникам информация, и в случае
необходимости загружает основной модуль core. Mini также умеет повышать привилегии с которыми
он исполняется, используя уязвимость CVE-2015-2387 или социальную инженерию.
На зараженных троянцем Lurk компьютерах в виде исполняемого файла хранится лишь модуль mini.
Все остальные модули хранятся в специальном зашифрованном файле, называемом нами
«хранилище модулей». Путь к файлу mini состоит из двух частей: постоянной — каталог %APPDATA% —
и переменной — имя файла mini. Имя файла вычисляется на основе времени создания каталога
Windows и может принимать одно из следующих значений:
API32.DLL dlg.dll mm.dll setup.dll
help.dll mi.dll http.dll wapi.dll
ER32.DLL core.dll theme.dll vw.dll
el32.dll sta.dll p10.dll fc.dll
in_32.dll pool.drv env.dll man.dll
Видимо, писатели Lurk пытались рандомизировать имя, с которым троянец будет установлен в
системе, но при этом хотели, чтобы полученное имя выглядело похоже на имена системных
библиотек. Для этого злоумышленники составили список имен, которые выглядят схоже с именами
известных компонентов Window (представлен в таблице выше). Затем вирусописателям было
необходимо обеспечить механизм, случайно выбирающий имя из этого списка, для закрепления на
системе. Однако злоумышленники также хотели, чтобы можно было легко узнать с каким именем
установился троянец на компьютере, чтобы можно было удалить его или обновить из другого
модуля. Для одновременного выполнения этих двух задач они написали генератор имен, который
выбирает имя из списка выше на основе времени создания каталога Windows, что на первый взгляд
выглядит неплохим решением. Но, как оказалось, это время зависит только от версии ОС, и на
большинстве систем под управлением Windows 7 одинаково. Поэтому в подавляющем
большинстве случаев Lurk закрепляется на системах с именем sta.dll.
В дальнейшем для простоты изложения мы будем пользоваться обозначением <LurkDll> для указания
полного имени файла mini.
Последовательность действий mini на машине жертвы после заражения следующая:
9. 1. mini удаляет предыдущую зарегистрированную версию Lurk, если mini был ранее
зарегистрирован. Такая ситуация возможна, например, при обновлении mini на новую версию.
Для этого удаляется файл с именем <LurkDll>.
2. mini загружает с управляющего сервера и запускает модуль prescanner, составляющий отчет об
установленном ПО для онлайн-банкинга, истории браузеров, и т.п. Также prescanner похищает
учетные данные от FTP-аккаунтов на компьютере пользователя, путем извлечения их из
настроек FTP-клиентов. Подробнее об этом можно прочитать в соответствующем разделе.
3. Если модуль prescanner не обнаружил программы или информации, интересной
злоумышленникам, то mini затирает собственный файл (если он есть) и завершает работу.
Для затирания своего файла mini перезаписывает файл псевдослучайными данными и только
после этого удаляет его. Такой метод затирания очень усложняет криминалистические
исследования зараженных компьютеров, которые выполняются в случаях хищения денежных
средств из систем ДБО. Восстановить файл mini, чтобы понять, что происходило на
зараженном компьютере, достаточно сложно.
4. В случае если у текущего процесса недостаточно привилегий – исполнение происходит с
низким уровнем целостности (low integrity level) – mini пробует повысить привилегии с
использованием уязвимости CVE-2015-2387 или производит повторный запуск процедуры
регистрации с повышением привилегий, используя техники социальной инженерии.
При использовании методов социальной инженерии пользователю выводится сообщение с
просьбой подтвердить запуск. В случае отказа, через секунду производятся повторные
попытки запуска – до тех пор, пока не будет получено согласие пользователя. Следует
отметить, что процессом, затребовавшим повышение привилегий, является доверенный
процесс regsvr32.exe и именно он будет отображаться в сообщении пользователю. Рано или
поздно большинство жертв подтверждает повышение привилегий, и Lurk продолжает
функционировать.
Однако в нашей практике был случай, когда жертва несколько раз отказалась от
подтверждения, затем ушла на обед, и во время обеда, в результате непредвиденного
перебоя питания компьютер выключился, а после включения mini уже не мог
функционировать.
5. Если prescanner обнаружил интересующую злоумышленников информацию, то mini загружает
основной модуль core и сохраняет его в хранилище модулей Lurk.
6. mini сохраняет собственный файл с именем <LurkDll> и внедряет себя в адресное пространство
процесса explorer.exe с целью исполнения основного функционала по запуску всех остальных
модулей Lurk. Текущий процесс завершается.
10. 1. Удаление
<LurkDll>
2. Загрузка и
запуск
prescanner
prescanner
обнаружил ПО
для ДБО
нет
3. Затирание
текущего
файла
да
Найдены
ключи
автозапуска
Завершение
работы
Низкий
уровень
целостности
нет
да
4. Перезапуск с
повышением
привилегий
нет
5. Загрузка
модуля core
6. Сохранение
и запуск
<LurkDll>
Завершение
работы
да
Завершение
работы
Завершение
работы
Схема работы mini в контексте процесса regsvr32.exe
Запуск дополнительных модулей и инсталляция в системе
В контексте процесса explorer.exe происходит основная активность mini, которую можно разделить на
две функции:
1. Инсталляция mini в зараженной системе (запись в ключи реестра, отвечающие за
автоматический запуск исполняемых файлов).
2. Запуск исполняемых модулей Lurk.
В случае успешной инсталляции в дальнейшем mini будет запускаться при каждом входе зараженного
пользователя в систему в контексте процесса explorer.exe.
Последовательность действий mini в контексте explorer.exe следующая:
1. mini запускает модуль core (идентификатор {101}) из хранилища модулей вредоносной
программы.
2. mini запускает остальные модули, которые должны исполняться в процессе explorer.exe, из
хранилища модулей вредоносной программы.
3. Если ключей реестра, отвечающих за автоматический запуск mini, не существует (инсталляция
mini не запускалась), запускается инсталляции mini. Процедура инсталляции заключается в
записи пути <LurkDll> в параметр по умолчанию ключа реестра
[HKCUSoftwareClassesCLSID{118BEDCC-A901-4203-B4F2-ADCB957D1887}InProcServer32], а
11. также создании ключа реестра
[HKCUSoftwareClassesDriveShellExFolderExtensions{118BEDCC-A901-4203-B4F2-
ADCB957D1887}]. Таким образом достигается автоматический запуск mini при старте ОС в
контексте процесса explorer.exe.
Инсталляция
Запуск модулей
1.1. Запуск модуля
Core
1.2. Запуск всех
остальных
модулей
Найдены ключи
автозапуска
Завершение
работы
2. Инсталляция
<LurkDll>
нет да
Схема работы mini в контексте процесса explorer.exe
Поведение mini в других процессах
Модуль mini отказывается выполнять «полезные» действия в контексте любых процессов кроме
regsvr32.exe, explorer.exe, verclsid.exe и spinstall.exe. Такое поведение усложняет его динамический
анализ и детектирование с помощью песочниц и эмуляторов, т.к. в этих случаях анализируемая
библиотека, как правило, внедряется в контекст специально созданного для этого процесса-жертвы,
например, notepad.exe.
Поведение mini в контексте процессов spinstall.exe и verclsid.exe заключается в запуске процедуры
инсталляции в первом случае и внедрении mini в контекст explorer.exe во втором. Ситуацию, в которой
mini внедряется в процесс spinstall.exe, нам не удалось смоделировать, однако ключи реестра,
которые mini изменяет для инсталляции, на некоторых версиях ОС Windows приводят к исполнению в
контексте verclsid.exe, а не explorer.exe. Именно чтобы обойти эту особенность mini выполняет
переход в explorer.exe, если исполняется в контексте verclsid.exe.
Загрузка исполняемых модулей Lurk
Как мы уже говорили, mini выкачивает и запускает на исполнение модули вредоносной программы
Lurk – prescanner, core, core_x64, mini_x64.
Скачивание модулей происходит при помощи обычных GET-запросов, причем изначально (в первых
версиях mini, которые мы видели) эти GET-запросы имели следующий вид:
Описание запроса Его вид
get_core search?hl=us&source=hp&q=%u&aq=f&aqi=&aql=&oq=
get_core_x64 search?hl=us&source=hp&q=%u&aq=f&aqi=&oq=
get_mini_x64 search?hl=us&source=hp&aq=f&aqi=&aql=&oq=
12. Обратите внимание на структуру этих GET-запросов. Она выбрана сознательно: таким образом
создатели троянца хотели добиться максимальной схожести с легитимными запросами, чтобы их
вредоносное ПО нельзя было детектировать при помощи анализа трафика, и увеличить шансы обхода
IPS-систем, таких как Snort.
Вот запрос поисковой системы Google для поиска по ключевой фразе «test request»:
https://www.google.com/search?q=test+request&ie=utf-8&oe=utf-8
Примерно пять лет назад, когда разрабатывался mini, запрос Google, отправленный с ноутбука HP,
выглядел следующим образом:
http://www.google.com/search?hl=us&source=hp&q=searchtext&aq=f&aqi=&aql=&
oq=
Несложно заметить, что разработчики этого вредоносного ПО пытались максимально приблизить
запросы mini к запросам Google. Однако после того, как мы положили сигнатуры на такие особенные
запросы и стали выдавать детект по ним, разработчики Lurk поменяли в запросе search на index.php.
Вот как выглядят запросы сейчас:
Описание запроса Его вид
get_prescanner index.php?hl=us&source=hp&q=%u&aq=f&aqi=&aql=&oq=%u
get_core index.php?hl=us&source=hp&q=%u&aq=f&aqi=&aql=&oq=
get_core_x64 index.php?hl=us&source=hp&q=%u&aq=f&aqi=&oq=
get_mini_x64 index.php?hl=us&source=hp&aq=f&aqi=&aql=&oq=
get_other_exe index.php?hl=us&source=hp&q=%u&aq=f&aqi=1&aql=&oq=
get_uid index.php?hl=us&source=hp&q=%u&aq=f&aqi=&aql=&oq=
send_status index.php?hl=us&source=hp&q=%u&aq=f&aqi=&aql=&oq=
Такую замену довольно сложно объяснить с точки зрения логики, единственный вариант – авторы не
слишком долго думали. Да, замена search на index.php, возможно, помогла авторам сбить
существующие на то время детекты антивирусных продуктов, но в итоге запросы стали совсем
непохожи на запросы Google, что дало возможность еще проще сделать детектирующие сигнатуры на
них.
Запрос get_other_exe присутствует в теле mini, но вызов кода, ответственного за этот запрос, никогда
не происходит. Возможно, он использовался в процессе разработки, а затем эту ветку забыли убрать.
Отдельно рассмотрим два специальных запроса – get_uid и send_status. Эти запросы типа “POST”,
остальные – “GET”.
Параметр “q” в запросе get_uid лежит в диапазоне (0xFFFF; 0xFFFFFFFF), в ответ сервер сообщает
уникальный идентификатор mini-загрузчика, далее этот идентификатор используется как значение
параметра “q” в запросе send_status.
Запрос get_uid имеет пустое тело; тело запроса send_status содержит в себе отчет о работе mini,
зашифрованный при помощи “xor-next”. Первый dword – псевдослучайное письмо, второй dword –
длина полезных данных, далее – полезные данные в виде ASCII-строки.
Пример расшифрованного тела запроса send_status
13. В представленном примере mini сообщил на свой C&C-сервер следующую последовательность
статусов:
1->2->5->6, что означает:
1 – mini запустился (в контексте explorer.exe).
2 – mini уже установлен в систему.
5 – mini выкачал и запустил prescanner.
6 – prescanner закончил свою работу.
Всего существует более 70 различных статусных отстуков, которые mini передает на C&C в процессе
своей работы.
Скачиваемые mini модули зашифрованы, причем с применением различных криптоалгоритмов.
Модуль prescanner зашифрован при помощи простого “xor-next”, этот алгоритм можно представить
следующим образом:
Алгоритм расшифровки модуля prescanner
Другие модули зашифрованы при помощи криптоалгоритма BlowFish (ECB Mode), ключ для которого
вшит непосредственно в mini. Обычно он выглядит примерно так:
AXQIMNQAGXNVDLOKDGUKJHMXABUWLKVO. Однако, не все так просто. Попытка расшифровать
скачанные данные при помощи этого ключа закончится неудачей, т.к. на самом деле данные
зашифрованы при помощи другого ключа. Настоящий ключ получается из вшитого псевдо-ключа при
помощи последовательного перебора одного символа (brute-force атака). В исследованных нами
образцах mini перебором подбирался символ на позиции 16.
Кратко алгоритм подбора ключа можно представить следующим образом:
1. Генерируется очередной ключ на основе вшитого псевдоключа.
2. С его помощью расшифровываются первые 4096 байт данных.
3. Второе двойное слово расшифрованных данных сравнивается с жестко зашитым значением
0x0000C0DE. Если совпало – верный ключ найден, если нет – возвращаемся к пункту 1,
продолжаем поиск.
Мы не знаем, почему авторы решили расшифровывать первые 4096 байт зашифрованных данных
каждый раз, хотя проверка осуществляется только по второму двойному слову. Для поиска нужного
ключа можно было бы расшифровывать только первые 8 байт, это значительно удешевило бы
процедуру поиска (на нее будет затрачено меньше ресурсов ПК). Мы предполагаем, что авторы
14. сознательно усложнили процедуру подбора верного ключа, чтобы «вымотать» эмуляторы АВ-
продуктов.
Хранилище модулей Lurk
Для того, чтобы не приходилось загружать дополнительные модули при каждом запуске mini, троянец
сохраняет эти модули в отдельный зашифрованный файл. Этот файл расположен в каталоге
%APPDATA% и имеет в зависимости от времени создания каталога Windows одно из следующих имен:
ddd2.dat pdk2.dat km48.dat 9llq.dat
ddqq.dat 834r.dat gi4q.dat wu3w.dat
qq34.dat dqd6.dat w4ff.dat ok4l.dat
kfii.dat ie31.dat 4433.dat
Содержимое хранилища зашифровано при помощи криптоалгоритма Blowfish с использованием
ключа, зависящего от времени создания каталога Windows. Помимо названия плагина и его тела, в
хранилище также содержится список контрольных сумм имен процессов, в контексте которых плагин
должен выполняться. С помощью этой информации mini определяет, в какой процесс внедрять
плагин: для модуля веб-инжектов это процесс браузера, для модуля ibank это Java.exe, в контексте
которого функционирует система ДБО.
Расшифрованное хранилище имеет следующую структуру:
Смещение
относительно
начала
хранилища
Размер Поле
0 4 Сигнатура 0x99371331
4 4 Количество дополнительных модулей в хранилище
Модуль 1
Смещение
относительно
начала
модуля
Размер Поле
0 4 Размер исполняемого файла модуля
4 4 Опции выполнения модуля
8 4 Размер блока хешей процессов, в которые должен быть внедрен
модуль
12 39 Название модуля
51 hs Хеши названий процессов, в которые должен быть внедрен модуль
51+hs ms Исполняемый файл модуля
Модуль 2 …
15. Обобщенная схема работы mini
Обобщая алгоритмы работы загрузчика mini в разных контекстах, мы составили следующую схему:
explorer.exe
regsvr32.exe
Первоначальный
запуск
Регистрация своего
исполняемого
файла
Загрузка и запуск
prescanner
Загрузка Core
Сохранение себя в
<LurkDll>
Запуск <LurkDll> Запуск Core
Запуск остальных
модулей
Инсталляция
<LurkDll>
Последующие
запуск
Шаг атаки №2: prescanner
В соответствии со схемой работы mini вторым этапом атаки является загрузка модуля prescanner.
prescanner – это специальный модуль банковского троянца, который выполняет две основные задачи:
сбор информации о зараженной системе;
граббинг паролей из FTP-клиентов, обнаруженных на машине пользователя.
mini prescanner
16. Модуль perscanner нужен злоумышленникам для того, чтобы сделать свои атаки максимально
целевыми. Если машина не соответствует правилам prescanner’a и на ней не найдены системы ДБО,
prescanner сообщает об этом mini, а последний принимает решение не закрепляться на этой машине.
Сам модуль prescanner никогда не сохраняется на файловую систему жертвы, но исполняется
исключительно в оперативной памяти зараженной системы. Таким образом создатели троянца
пытаются избежать лишнего внимания к себе со стороны правоохранительных органов и
разработчиков антивирусных продуктов. В подтверждение приведем следующий факт: каждый раз
при регистрации нового бота в C&C боту назначается его уникальный идентификатор – целое число,
проще говоря – номер бота. За более чем пятилетнюю историю этого банковского троянца в C&C было
зарегистрировано около 60 000 ботов, что не слишком много.
Модуль prescanner представляет собой динамически загружаемую библиотеку с единственной
экспортируемой функцией Prescan.
Таким образом, последовательность внедрения троянца на машину следующая:
1. машина пользователя заражается при помощи эксплуатации уязвимости
2. на зараженной машине запускается mini;
3. mini выкачивает prescanner и запускает его;
4. prescanner похищает у пользователя учетные данные FTPи, если машина по результатам
анализа признана непригодной, mini и prescanner тихо «умирают» (если используется
бестелесное распространение, которое поддерживается в Angler, от троянца не остается почти
никаких следов на диске). Если же машина интересует злоумышленников, атака
продолжается.
Как злоумышленники определяют подходит им система или нет? При помощи специальных правил,
которыми комплектуется prescanner. Правила просто записываются в конец модуля prescanner, их
начало и конец обозначаются при помощи маркеров “pres0000”. Сами правила выполнены в формате
JSON.
Отметим, что, кроме целей, определяемых правилами, prescanner исследует систему на наличие
системы «iBank2» и систем интернет-банкинга.
Фрагмент правил prescanner троянца Lurk
Прежде чем начать анализ правил prescanner, отметим одну особенность авторов троянца.
Разработчики Lurk тщательно избегают понятных человеку строк в своих модулях, т.к. полагают, что
это может привести к быстрому опознанию вредоносности модулей и облегчить задачу аналитиков.
17. Поэтому чтобы описывать различные сущности, разработчики используют в троянце специальные
идентификаторы, внешне похожие на GUID’ы.
Той же концепции они придерживаются и в правилах prescanner. В исследованном нами образце
были выявлены следующие GUID’ы, соответствующие логическим секциям правил:
{CA72A280-ED0A-44ee-A975-1816A976E20B}
{784B64AF-D4B5-4eed-B283-022244D3BCF1}
{62438634-69F3-4843-A693-3D3B6A4E20CE}
{F681DE05-1EA5-4e9a-A69D-6BB2F14873B3}
{FB96E508-DED3-4d32-AF5E-D555CC6D184D}
{E6206B0C-6838-409b-A8B6-BA13C841A75F}
{4920FEA9-46D6-4d28-9E9B-6B54D5D2BA94}
Рассмотрим каждую из этих секций правил отдельно.
Правила prescanner
Секция {CA72A280-ED0A-44ee-A975-1816A976E20B}(ip_data)
Секция {CA72A280-ED0A-44ee-A975-1816A976E20B} содержит правила, с которыми сравнивается IP-
адрес зараженной системы и определяется ее принадлежность к одной из интересующих подсетей.
Будем условно называть ее ip_data.
Внешний IP-адрес зараженной системы получается путем отправки на www.yandex.ru GET-запроса “ip
address” и анализа ответа.
Эта секция содержит множество элементов (исследованный нами образец содержал 55 правил в этой
области), каждый из которых выглядит следующим образом:
Здесь: o1, o2, o3 и o4 (в рассмотренном правиле отсутствует) – это правила для 1, 2, 3 и 4 октета IP-
адреса, ‘id’ – уникальный идентификатор правила, ‘h’ – хэш искомого значения, ‘l’ – длина значения,
для которого приведен хэш. Если какой-то октет отсутствует (в нашем примере это o4), то это означает,
что любое его значение будет соответствовать требованию этого правила.
В качестве хэш-функции создатели троянца используют Cubehash, что нетипично. Видимо, такой
выбор продиктован желанием усложнить работу аналитика, т.к. эта хэш-функция используется редко,
и создатели троянца, очевидно, надеялись, что аналитики ее не узнают.
Запись значения при помощи его хэша, опять же, нужна для того, чтоб усложнить исследование
правил: хэш-функция работает только в одну сторону, т.е. по данным получить хэш можно, а вот по
хэшу восстановить исходные данные нельзя. Это в теории. На практике мы в «Лаборатории
Касперского» восстановили все данные для правил этой секции и вот что получили: большая часть из
55 записей относилась к диапазонам внешних IP-адресов информационных ресурсов,
телекоммуникационных компаний, платежных систем, торговых площадок, банков и даже силовых
структур.
18. Мы условно разделили цели на три группы:
IT-организации в сфере телеком;
СМИ и новостные агрегаторы;
Банки и финансовые организации.
Мы предполагаем, что каждая из этих групп нужна злоумышленникам для конкретных целей. Банки и
финансовые организации располагают деньгами, которые можно украсть. СМИ и новостные
агрегаторы работают с большой аудиторией посетителей, и, заразив один из таких сайтов ссылкой на
лендинг эксплойт-пака, можно получить много новых ботов и новых жертв. IT-организации в сфере
телеком – это потенциальный «новый дом» для «прокладок», т.е. для перевалочных серверов, через
которые пойдет трафик к реальным серверам злоумышленников.
Ну а желание авторов зловреда закрепиться на машинах силовых структур оставим без комментариев.
Секция {784B64AF-D4B5-4eed-B283-022244D3BCF1} (ftp_urls)
Секция {784B64AF-D4B5-4eed-B283-022244D3BCF1} содержит правила, которые описывают FTP-
ресурсы, посещенные пользователем. Будем условно называть ее ftp_urls.
В исследованном нами конфигурационном файле prescaner в этой секции содержалось 270 записей,
каждая из которых имела следующую структуру:
Сущность “patternh” содержит информацию о хэше от некого паттерна, остальные поля аналогичны
полям предыдущей секции.
Мы восстановили паттерны этой секции - среди них были обнаружены значения, соответствующие
адресам административных панелей управления крупных телекоммуникационных ресурсов,
интернет-СМИ, рекламных партнерских агентств, внутренних адресов ресурсов, используемых в
государственных финансовых учреждениях и т.п.
Интересы злоумышленников не изменились: авторов троянца интересуют крупные корпорации, банки
и разработчики банковских решений, а также телекоммуникационные компании.
Секция {62438634-69F3-4843-A693-3D3B6A4E20CE}
(browser_history_urls)
Секция {62438634-69F3-4843-A693-3D3B6A4E20CE} также содержит в себе хэши от HTTP-адресов или их
частей, но на этот раз с этими хэшами сравниваются HTTP-адреса, найденные в истории браузера
пользователя. Будем называть ее условно browser_history_urls.
Элемент этой секции имеет типичную структуру:
19. Здесь “domainh”, “pageh” и “porth” – cubehash-хэши от имени домена, страницы и порта, с которыми
будет производиться сравнение записей из истории браузера. Отметим, что не обязательно все три
поля должны присутствовать в каждом правиле.
В исследованном нами конфигурационном файле содержалось 359 записей в этой секции. Мы
восстановили оригинальные значения и получили результаты, схожие с теми, что рассматривались в
предыдущем разделе: злоумышленников интересуют доступ на уровне администратора в крупные
интернет-СМИ, информационные и коммерческие площадки, рекламные партнерские агентства,
внутренние ресурсы государственных компаний, разработчики систем ДБО и т.п.
Мы видим, что основные группы паттернов те же, добавились большие корпорации и внутренние
государственные ресурсы. Среди целей был обнаружен ресурс darkmoney.cc, который представляет
особый интерес – это форум киберпреступников, предназначенный для обналичивания денег и всего,
что с этим связано. Видимо, логика злоумышленников следующая: если человек читает darkmoney.cc,
значит, у него есть, что обналичивать, и мы остаемся тут жить.
Секция {F681DE05-1EA5-4e9a-A69D-6BB2F14873B3} (whois_records)
Секция {F681DE05-1EA5-4e9a-A69D-6BB2F14873B3} содержит в себе хэши от ключевых слов, которые
будут искаться в выдаче whois-сервиса (who.is) по внешнему IP зараженной машины. Если что-то
нашлось, то машина представляет интерес. Будем условно называть эту секцию whois_records.
Типичное правило из этой секции выглядит следующим образом:
Здесь “patternh” – хэш от ключевого слова, которое prescanner будет искать в выдаче whois.
Среди искомых паттернов были обнаружены названия, банков, платежных систем и сервисов,
ключевые слова вроде «investment», «credit», «bank», «investbank» и другие.
Секция {FB96E508-DED3-4d32-AF5E-D555CC6D184D} (file_data)
Секция {FB96E508-DED3-4d32-AF5E-D555CC6D184D} содержит в себе хэши от имени файлов и путей к
ним, которые ищутся на компьютере жертвы и которые указывают на то, что эта система
злоумышленникам интересна. Каждая запись имеет следующую структуру:
20. Здесь:
“has_drive” – может быть установлено в «1» или в «0», в зависимости от того, есть ли далее в
составе множества “pathh” хэш от имени логического диска, на котором установлено
определяемое ПО.
“pathh” – хэши от частей пути (путь к описываемому файлу разбивается на составные части,
используя «» в качестве разделителя).
По результатам анализа была выявлена заинтересованность создателей троянца в наличии у
пользователя установленных клиентов платежных систем, систем ДБО, программного обеспечения
новостных ресурсов и т.п.
Из действительно интересного – заинтересованность авторов троянца государственными
финансовыми учреждениями и крупнейшими банками РФ.
Секция {E6206B0C-6838-409b-A8B6-BA13C841A75F} (software_data)
Следующая секция – {E6206B0C-6838-409b-A8B6-BA13C841A75F}, назовем ее software_data, - содержит
в себе хэши от названий ПО, установленного на компьютере пользователя. Каждая запись имеет
следующую структуру:
Здесь “nameh” – словарь, содержащий хэш от названия и его длину, а “pathh” – множество хэшей от
названий каталогов.
В числе прочего, создатели Lurk интересуются наличием у пользователя, следующего ПО (частей
названия, паттернов): сontacting, rclient, bss, bank и прочих.
Секция {4920FEA9-46D6-4d28-9E9B-6B54D5D2BA94} (processes_data)
Наконец, секция {4920FEA9-46D6-4d28-9E9B-6B54D5D2BA94}, назовем ее processes_data. Она содержит
хэши имен процессов, которые prescanner пробует обнаружить на компьютере пользователя. Каждый
ее элемент имеет ту же структуру, что и элемент предыдущей секции.
21. По результатам анализа секции, можем сделать вывод, создатели троянца ищут в списке процессов
зараженной машины названия программного обеспечения денежных переводов, ПО для POS-
терминалов, ПО для почтовых служб, систем силовых ведомств и т.п.
Коммуникация prescanner с командным центром
Собрав информацию о машине и проверив выполнение имеющихся правил, prescanner отправляет
отчет на свой управляющий сервер. В рассмотренных нами случаях C&C perscanner’а совпадал с C&C
загрузчика mini. Отчет, сформированный prescanner’ом, представлен на следующем рисунке.
Отчет prescanner, отправленный на управляющий сервер
Отчет зашифрован при помощи обычного xor-алгоритма, но с использованием длинного ключа. В
нашем случае ключ был следующим:
IHHJ2R8T2NKRR2OA1FU3IB764VRJ6402I6RNQHWLN5DV1LV0QKIZF3Y4AYL3D26KGGVWX06GQIV4O3W6BEV
XQEMPBAFVFMGZ7I2TIYQQJ6X5PBAP87SGFR5N5CAGF63FMTTVVIHWGV4YU5AK5MZ2293MSVQ2DU4JC2O
MUV4X0AUGSK1BZJQWMJTR0H3I6GXIDXDV421C2GCNB880CPU4HSPGDKO186U311ETP4D8ZAO2T0SEOT75I
PH75J6BRYE35CD9JU3SIGZJUIDECH9GCL83L29OD06ZYHXCLPWFL0A9AL96PBCDB3RYGXK7UCLAAFMKLVIDD
23. Из отчета видно (секция “dump”), что произошло три ошибки в процессе работы prescanner, точнее, в
момент обработки секции “whois_records”. Комментарии представлены в виде жестко зашитой
константы, по которой затруднительно определить причину неудачи, очевидно, prescanner не смог
получить whois-информацию для исследуемой машины.
Этот отчет был отправлен prescanner, который не нашел, за что зацепиться на анализируемом
компьютере. Если бы зацепки были найдены, в отчет была бы добавлена соответствующая секция,
например:
Каждая пара включает в себя элемент “item”, содержащий номер процесса в списке секции
{9B05E4F6-E1D5-43ed-B1F6-6CF2F8F30C7D}, и элемент “rule”, содержащий номер правила, которому
соответствует этот процесс.
Если бы prescanner нашел данные для авторизации на FTP-серверах, в отчет была бы добавлена
примерно такая секция:
24. Коммуникация prescanner с mini
Если prescanner принял решение закрепиться на машине, он сообщает об этом загрузчику mini,
который, в свою очередь, скачивает и запускает компонент core – основное тело бота. Напомним, что
запуск prescanner осуществляется загрузчиком mini при помощи передачи управления в функцию
Prescan. Если после своего выполнения эта функция возвращает в mini значение 0x00, значит
prescanner не нашел ничего интересного на исследуемом компьютере, и mini тихо «умирает».
Другие возвращаемые значения могут являться комбинацией флагов 0x01, 0x02 и 0x04. Значения у
этих флагов следующие:
0x01 – на исследуемой машине в истории браузера были обнаружены адреса систем интернет-
банкинга;
0x02 – на исследуемой машине найдены следы системы «iBank2» (prescanner пытается
обнаружить апплет «iBank2» в кэше Java-машины и проверяет наличие драйвера ключей
«iBank2» по хэшу от строки “iBank 2 Key” в списке установленного ПО);
0x04 – на исследуемой машине найдено что-то, что описано правилами prescanner.
В случае наличия одного из этих флагов в возвращенном значении функции Prescan, mini сообщает на
свой командный центр один из статусов 51, 50, 52 (соответственно).
Шаг атаки №3: core
Следующим шагом в соответствии с описанием mini будет загрузка основного модуля – core. Модуль
mini загружает его и сохраняет на диске. Происходит это только в том случае, если машина признана
пригодной для установки бота.
25. На рисунке ниже представлен процесс коммуникации mini с командным центром. Остановимся на
нем чуть подробней.
Запрос №1 – это запрос типа get_uid для получения уникального идентификатора бота.
Запрос №2 – mini выкачал prescanner и запустил его.
Запрос №7 – это запрос prescanner’a для получения внешнего IP зараженной системы.
Запрос №11 – mini успешно загрузил основное тело бота – core.
Запросы №№3, 4, 5, 6, 8, 10, 12 – это запросы типа send_status, mini рассказывает C&C о выполненных
на зараженной системе действиях.
Модуль core – это главный модуль рассматриваемой вредоносной программы. Его основные
функции:
сетевое взаимодействие с C&C;
загрузка, установка и запуск дополнительных модулей троянца;
выполнение команд, полученных от злоумышленников;
ведение журнала клавиатурного ввода (функция кейлоггера) и запись видеопотока с экрана
зараженной системы, а также отправка статистики браузеров Internet Explorer и Mozilla Firefox
по посещенным за день сайтам;
обеспечение работы шифрованного хранилища данных и настроек Lurk.
Рассмотрим каждую из этих функций подробнее.
Сетевое взаимодействие core с C&C
Алгоритм генерации доменов
Модуль core является своего рода «каналом связи» между другими модулями вредоносной
программы и командным центром, вся сетевая коммуникация реализована именно в этом модуле.
Сам по себе core не содержит жестко зашитого адреса центра управления вредоносной программой,
он вычисляется при помощи алгоритма генерации доменных имен (DGA – Domain Generation
Algorithm).
Большинство реализованных в других вредоносных программах DGA имеют один существенный
недостаток: они предсказуемы. В качестве входных данных генераторы обычно используют текущую
mini core
26. дату/время, идентификатор ботнет-сети и т.п. Основная проблема всех этих исходных данных в том,
что они известны (или могут стать известными) исследователям заблаговременно. Т.е. аналитики
могут составить список возможных имен управляющих серверов заранее, еще до того, как они будут
сгенерированы собственно вредоносной программой, и заблокировать их (с помощью своего
антивирусного продукта или «засинкхолив» их).
Пользы злоумышленникам от таких DGA не много: какая, по большому счету, разница – большой
список жестко зашитых в коде бота адресов C&C или алгоритм их генерации, который все равно
приводит к конечному и предсказуемому множеству? Особенно никакой, разве только аналитики
потратят время на анализ DGA и его имплементацию отдельным скриптом. Еще существует
потенциальная возможность для авторов зловреда поменять настройки DGA при помощи
специальной команды с C&C (впрочем, можно просто отдать новое тело зловреда с новым жестко
зашитым новым списком командных серверов).
Разработчики Lurk эту ошибку создателей другого вредоносного ПО учли. Очевидно, они задались
вопросом: какие входные данные для DGA использовать, чтобы они соответствовали следующим
характеристикам:
регулярно обновлялись;
были непредсказуемыми;
были доступными (их источник должен надежно работать);
были параметризируемыми (должна существовать возможность менять некоторые
параметры этих данных для различных результатов генерации).
Авторы троянца выбрали решение – они стали использовать данные биржевых котировок,
полученных с Yahoo Finance, которые не могут быть предсказаны аналитиками.
Строго говоря, авторы зловреда для получения входных данных DGA используют запрос вида:
ichart.finance.yahoo.com/table.csv?s={1}&a={2}&b={3}&c={4}&g=w&ignore=.csv
Здесь:
{1} – название (код) компании, котировки которой будут использоваться при генерации списка
доменов;
{2} – месяц,
{3} – день,
{4} – год, за которые запрашиваются котировки.
Кроме этого, в качестве входных параметров DGA также используются длина сгенерированного имени
домена, количество сгенерированных доменов и случайное значение – «посев», будем обозначать их
соответственно “C&C_name_length”, “num_of_domains” и “seed”.
Итак, сначала core запрашивает данные с биржи для DGA с помощью описанного выше GET-запроса. В
результате сервер возвращает примерно следующее:
27. Возвращенные сервером котировки на запрос
http://ichart.finance.yahoo.com/table.csv?a=11&c=2010&b=1&g=w&ignore=.csv&s=ZMH
Далее от полученных данных отрезается заголовок и две последние колонки. Получаем следующее:
Далее, если значение параметра seed установлено, полученные данные последовательно кодируются
методом xor с параметром seed (в исследуемом случае он был равен ‘AAA’).
Данные о котировках, закодированные методом xor (фрагмент)
Затем от полученных данных рассчитывается хэш Cubehash размером 0x200 – он и будет входным
параметром DGA.
На рисунке ниже представлен восстановленный DGA модуля core, значение data_to_hash при первой
итерации вычислено на предыдущем шаге.
28. DGA модуля core
В результате работы DGA получим следующие значения имен C&C:
Генерация нового домена происходит каждые 5 секунд до успешного установления соединения.
После успешного соединения каждые 5 минут на управляющий сервер отправляются собранные
данные, результаты выполнения команд и запрашиваются обновления и команды, а адрес сервера
записывается в хранилище, чтобы при следующем запуске не пришлось генерировать доменные
имена заново.
29. Раз в день данный модуль отправляет статистику браузеров Internet Explorer и Mozilla Firefox по
посещенным за день сайтам.
Шифрование трафика
Вся коммуникация между модулем core и C&C шифруется. В качестве криптоалгоритма применяется
AES в режиме CBC с длиной ключа 128 бит. При начале коммуникации бота с командным центром
согласуется сессионный ключ, которым и шифруется трафик.
Сессионный ключ согласуется по протоколу Диффи-Хеллмана. В качестве параметров g и p протокола
Диффи-Хеллмана Lurk использует следующие значения:
g = 0x9EB9BE4D22A22E0EB1DCC1DB7F3EEDBB
p = 0x03.
Для нас остается загадкой, почему авторы выбрали именно такую криптографическую схему – чем их
не устроил обычный HTTPS?
Как бы там ни было, выбранная схема подвержена атаке типа MITM, поэтому авторы в процедуре
согласования ключей дополнительно применяют алгоритмы DSA и HMAC.
Публичный ключ DSA, используемый ботом
Такого рода схема выглядит громоздкой и сложной, однако вирусописатели остаются верны ей уже
много лет.
В другом вредоносном ПО в большинстве случаев в качестве сессионного криптоалгоритма
используется упрощенная схема с AES (редко – RC4), симметричный ключ генерируется на стороне
клиента и передается на сервер в зашифрованном при помощи RSA виде. Публичный ключ RSA
обычно вшивается в бот, закрытый ключ RSA хранится на сервере. Но авторы Lurk, видимо, стараются
быть уникальными во всем.
Итак, процедура согласования ключей выглядит следующим образом:
Шаг 1. клиент хочет начать коммуникацию с сервером, для чего посылает на C&C пустой POST-запрос.
30. Отправка пустого POST-запроса C&C
В ответ C&C присылает ответ, содержащий в себе следующие данные:
идентификатор соединения;
тип запроса (ответа);
длину данных в основном теле;
два пустых двойных слова;
случайные данные;
подпись DSA (два числа, по 160 бит каждое);
CRC32 от пустых двойных слов, случайных данных и DSA-подписи.
Детально структура ответа сервера представлена на рисунке.
Структура первого ответа C&C боту
crc connection_id type
data_length
DSA
empty_dword
random bytes
31. Здесь:
connection_id – уникальный идентификатор соединения, он будет использоваться в других
пакетах в процессе согласования ключей;
type == 0x01 – тип ответа (пакет-приветствие, 0x01);
data_length – длина данных, начиная с этого поля и до конца пакетов;
crc – crc32 от поля empty_dwords до конца пакета.
Бот проверяет CRC, затем DSA-подпись, после чего извлекает и запоминает connection_id.
Шаг 2. Бот вычисляет DH public-key-A, формирует второй пакет и отправляет серверу.
Процедура согласования ключей, шаг №2: отправка второго пакета C&C
Формат запроса следующий:
Здесь:
public_Key_A – публичный ключ, сгенерированный на стороне клиента на основании констант g
и p;
type = 0x02 – второй тип пакета, обмен ключами.
Остальные поля были описаны ранее.
crc connection_id type
data_length
public_Key_A
32. Сервер отвечает пакетом:
Структура второго ответа C&C боту
Здесь:
public_Key_B – публичный ключ, сгенерированный на стороне сервера на основании констант g
и p;
HMAC – HMAC-хэш, ключ – session_Key (уже рассчитанный на стороне сервера, но не
включенный в этот пакет), данные – public_Key_B и последовательность случайных байт. В
качестве хэш-функции в HMAC используется Cubehash, таким образом авторы зловреда
кастомизировали HMAC;
DSA-signature – DSA-подпись от HMAC, public_Key_B и случайных байт.
Остальные поля были описаны ранее.
Имея public_key_A, public_key_B, p и g, бот вычисляет K – сессионный AES-ключ. Таким образом,
процедуру согласования ключей можно считать законченной, бот получил сессионный ключ, которым
далее будет шифроваться весь трафик.
Все пакеты, следующие после этого, имеют стандартную структуру:
crc connection_id type
data_length
public_Key_B DSA signature random_bytes
HMAC
33. Загрузка, установка и запуск дополнительных модулей троянца
Обмен данными между CORE и C&C происходит в JSON-формате, расшифрованный запрос от бота к
серверу имеет следующий вид.
Это типичный запрос от бота к C&C. Очевидно, что структурно он состоит из двух блоков – INFO и FILES.
Опишем сначала блок INFO, т.к. он передается от бота к серверу в каждом запросе.
Блок INFO состоит из следующих полей:
“uid” – идентификатор бота, целое число, преобразованное в строку, назначается сервером
при первом обращении бота к C&C;
“install_time” – целое число, timestamp момента установки бота, передается от бота к C&C
только один раз – в момент первого обращения бота;
“version” – версия бота, строковый параметр;
“timestamp” – timestamp, текущие дата/время;
“osversion” – версия ОС, строковый параметр;
“platform” – разрядность бота (32 или 64);
“silent” – 0 или 1 – в зависимости от того, находится ли бот в сайлент-режиме, или нет.
Блок FILES предназначен для запроса у сервера модулей (плагинов) бота. В запросе передается GUID
требуемого модуля и его битность (в случае бинарного плагина), в ответ приходят данные. Если
соответствующий плагин уже установлен в хранилище Lurk на зараженной машине, в запросе также
указывается CRC32 имеющегося модуля.
На сегодняшний день известные нам виды плагинов и модулей Lurk приведены в таблице ниже.
Каждому модулю авторы Lurk присвоили уникальный идентификатор (GIUD).
GUID плагина Название Назначение плагина
34. {5FBA6505-4075-485b-AEC4-
75767D9054C9}
module_Bifit Набор .class-файлов для внесения
изменения в нормальную
функциональность систем «IBank 2»
с целью хищения денег.
{0F3E7AFA-1F2B-4b0e-99D6-
3716A4C3D6DE}
module_Bifit_admin Модифицированный
злоумышленниками
административный апплет для
систем «iBank 2» (предназначен для
хищения учетных данных «iBank 2»-
систем, в том числе – ключевых
файлов).
{04DB063E-1454-4a73-B2CC-
4DB6D4BB6AA1}
module_ibank Плагин для обеспечения инжектов
собственных апплетов в систему
«IBank 2». Именно с помощью этих
апплетов (но не только их) деньги
воруются у пользователя.
{AABA3126-14E2-443b-A11B-
FB6C1F793103}
module_w3bank Плагин, предназначенный для
организации веб-инжектов в
страницы систем ДБО.
{5C345F77-B111-4a85-B6D6-
EC8F27F993C4}
module_w3bank_scripts Набор скриптов на JavaScript, для
инжектированя модулем w3bank.
Предназначен для кражи денег и
данных из систем ДБО.
{50D13F6C-FC46-4fdf-A294-
E149D36E54D4}
module_spider Вспомогательный модуль, основная
задача которого – обеспечить
загрузку других модулей Lurk в
контекст процессов «iexplore.exe»,
«firefox.exe», «chrome.exe»,
«opera.exe», «jp2launcher.exe»,
«java.exe» до реального запуска этих
процессов.
{52F1F7D8-4BCC-4498-AC86-
3562F81990F6}
module_vnc Плагин для доступа по VNC на
зараженную машину (в целях
удаленного управления
скомпрометированным
компьютером).
{A06B5020-0DF3-11E5-BE38-
AE5E4B860EDE}
rdp-plugin-x86 Плагин, обеспечивающий
включение RDP на зараженной
машине.
{9F786E98-3D4C-4020-8819-
B97D9D4DBCC0}
highLauncher Загрузчик плагинов бота в high
Integrity level (нужен для rdp-plugin-
x86 и lsa-plugin-x86).
{968A2A9A-7DF4-4E69-BF81-
563AF8FFB7DC}
launcher Загрузчик mini. Ожидает IPC-
сообщения с именем <LurkDll>,
после чего загружает mini при
помощи LoadLibrary(). Используется
в процессе запуска mini с
повышением привилегий.
{5B3957F2-AAAF-4FF8-94B8-
83C52AFCD2A9}
lsa-plugin-x86 Плагин для граббинга
администраторских и/или доменных
аккаунтов (используется известная
программа mimikatz).
35. В ответ на соответствующий запрос C&C возвращает модуль в следующем формате.
В атрибуте “name” указано имя плагина в иерархии плагинов Lurk – “ibank.dll”, в поле “core” – данные,
зашифрованные при помощи base91. В поле “targets” указано множество, состоящее из CRC32 от
названий процессов, в которые этот модуль должен быть внедрен.
Отметим также, что для модулей module_Bifit и module_az при запросе файлов у командного центра
бот сообщает C&C о том, с какими ДБО работает пользователь.
К примеру, бот направляет C&C следующий запрос:
