WWW.LIB.KNIGI-X.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Электронные матриалы
 

«БАНКОВСКИЙ ТРОЯНЕЦ LURK: СПЕЦИАЛЬНО ДЛЯ РОССИИ Алексей Шульмин, Михаил Прохоренко Оглавление Введение Заражение Заражение через эксплоит-пак Заражение через взломанные сайты ...»

БАНКОВСКИЙ ТРОЯНЕЦ LURK:

СПЕЦИАЛЬНО ДЛЯ РОССИИ

Алексей Шульмин, Михаил Прохоренко

Оглавление

Введение

Заражение

Заражение через эксплоит-пак

Заражение через взломанные сайты

Заражение машин внутри сети организации

Шаг атаки №1: mini

Первый запуск mini

Регистрация mini

Запуск дополнительных модулей и инсталляция в системе

Поведение mini в других процессах

Загрузка исполняемых модулей Lurk

Хранилище модулей Lurk

Обобщенная схема работы mini

Шаг атаки №2: prescanner

Правила prescanner

Секция {CA72A280-ED0A-44ee-A975-1816A976E20B}(ip_data)

Секция {784B64AF-D4B5-4eed-B283-022244D3BCF1} (ftp_urls)

Секция {62438634-69F3-4843-A693-3D3B6A4E20CE} (browser_history_urls)

Секция {F681DE05-1EA5-4e9a-A69D-6BB2F14873B3} (whois_records)

Секция {FB96E508-DED3-4d32-AF5E-D555CC6D184D} (file_data)

Секция {E6206B0C-6838-409b-A8B6-BA13C841A75F} (software_data)

Секция {4920FEA9-46D6-4d28-9E9B-6B54D5D2BA94} (processes_data)

Коммуникация prescanner с командным центром

Коммуникация prescanner с mini

Шаг атаки №3: core

Сетевое взаимодействие core с C&C

Алгоритм генерации доменов

Шифрование трафика

Управляющие команды Lurk

Перехват клавиатурного ввода

Хранилище Lurk

Основные настройки

Настройки веб-инжектов

Настройки перехвата сетевых ресурсов

Настройки перехвата клавиатурного ввода

Настройки захвата видео

Модуль module_vnc {52F1F7D8-4BCC-4498-AC86-3562F81990F6}

Модуль w3bank {AABA3126-14E2-443b-A11B-FB6C1F793103}

Атака на банк X

Атака на банк Y

Модуль ibank {04DB063E-1454-4a73-B2CC-4DB6D4BB6AA1}

Модуль rdp-plugin-x86 {A06B5020-0DF3-11E5-BE38-AE5E4B860EDE}

Модуль highLauncher {9F786E98-3D4C-4020-8819-B97D9D4DBCC0}

Модуль launcher {968A2A9A-7DF4-4E69-BF81-563AF8FFB7DC}

Модуль lsa-plugin-x86 {5B3957F2-AAAF-4FF8-94B8-83C52AFCD2A9}

Заключение

IOCS:

Ключи реестра:

Файлы:

Возможные названия модуля mini:

Возможные названия хранилища модулей:

Сетевые индикаторы:

Сервера управления:

Правила IDS:

MD5:

mini:

prescanner:

core:

ibank.dll:

module_vnc:

w3bank.dll:

В статье приводится детальный анализ банковского троянца Lurk, описываются приемы распространения, особенности работы, механизмы, используемые для воровства денег, и способы снижения заметности.

Введение На закрытых форумах киберпреступников можно часто услышать фразу-совет: «не работай по RU» это своего рода напутствие опытных негодяев молодой смене. В переводе на русский язык фраза означает следующее: «не воруй деньги у граждан РФ и бывшего СНГ, не заражай их машины, не используй соотечественников для отмывания денег». Начинающие киберпреступники зачастую считают это чем-то вроде позиции Робина Гуда: воровать деньги у граждан развитых западных стран морально допустимо, а у соотечественников – нет, т.к. последние и без этого находятся в удручающем экономическом положении. Некоторые даже считают, что, руководствуясь этим принципом, совершают благое дело: выводят деньги из западных экономик и оставляют их в экономике РФ.

Ничего общего с правдой это, разумеется, не имеет.

Правда в том, что «работать по RU» не выгодно с точки зрения безопасности киберпреступников:

жители других стран вряд ли обратятся в полицию РФ. Кроме того, в зоне RU не слишком распространен интернет-банкинг, во всяком случае – распространен гораздо меньше, чем в западных странах. Следовательно, потенциальный доход от деятельности в RU-зоне ниже, чем в других зонах, а риск – выше. Именно поэтому появилось правило «не работай по RU».

Однако, как и всегда, из этого правила есть исключения. Например, весьма заметный банковский троянец, о котором мы расскажем, - Lurk - уже несколько лет активно используется для воровства денег у резидентов РФ и бывшего СНГ, и его создатели все еще на свободе. Пока.

Мы уже писали об этом банковском троянце раньше, практически сразу после появления он привлек наше внимание тем, что использовал механизм бестелесного распространения – вредоносный код не сохранялся на диске и запускался непосредственно из памяти. Однако детальное описание этого троянца до сих пор не было опубликовано.

Между тем, Lurk заслуживает подробного рассмотрения из-за нестандартных, порой – неочевидных решений, примененных его авторами. Мы не утверждаем, что этот троянец хорошо написан – мы видели и анализировали банковские троянцы, которых отличало гораздо более высокое качество кода. Более того, анализ Lurk показал, что над кодом работало несколько программистов и их квалификация была различной. Местами в коде встречаются откровенно неудачные решения, которые авторы не исправляют годами. Мы, разумеется, не будем указывать авторам на их ошибки.

Однако с уверенностью можно утверждать, что Lurk один из наиболее сложных банковских троянов с точки зрения анализа его кода.

Lurk – это универсальный банковский троянец. В том смысле, что способен похищать деньги не только из системы «iBank 2» (система ДБО «iBank» используется многими банками), но и из интернет-систем ДБО некоторых крупных российских банков, которые являются уникальными для каждого банка.

Троянец состоит из нескольких модулей, обладающих довольно богатыми возможностями. Причем на зараженную пользовательскую машину с C&C загружаются только те модули, которые на ней нужны для хищения денежных средств (или для кражи ценных данных и дальнейшего распространения по сети).

В качестве жертв злоумышленников интересуют:

IT-организации в сфере телеком (возможность создания перевалочных серверов, через которые пойдет трафик к серверам злоумышленников);

СМИ и новостные агрегаторы (возможность заражения большого числа компьютеров через популярные сайты);

банки и финансовые организации (кража денег);

клиенты крупнейших российских банков — пользователи систем ДБО этих банков (кража денег).

Желание авторов зловреда закрепиться на машинах силовых структур (эти организации также есть в списке атакованных) оставим без комментариев.

Вирусописатели развивают свой продукт – мы отмечаем повышение качества кода с течением времени и улучшение используемых авторами решений. Lurk отличает высокая таргетированность – авторы делают все, чтобы заразить максимальное количество интересных им жертв, не привлекая при этом внимания аналитиков и исследователей. Несмотря на то, что векторы распространения Lurk охватывают широкую аудиторию (например, заражения через эксплойты на популярных форумах) закрепление на системе жертвы происходит только в случае, если система представляет интерес для злоумышленников (подробнее об этом в разделе, посвящённом модулю prescanner).

Инциденты, о которых известно нам, убеждают в том, что Lurk со своей задачей справляется – периодически приходят сообщения о хищениях в системе ДБО, а криминалистические исследования после инцидентов показывают следы Lurk на машине.

Заражение Для распространения банковского троянца Lurk применяется широко известная техника drive-by.

Кроме нее, авторы также распространяют троянца через взломанные сайты легитимного ПО и внутри сетей организации – при помощи утилиты psexec.

Заражение через эксплоит-пак Lurk распространяется главным образом при помощи знаменитого эксплойт-пака Angler (авторское название – XXX). Такой способ распространения особенно опасен, т.к. для заражения не требует никаких специальных действий от пользователя.

Angler по праву считается флагманом: эксплойты для новых уязвимостей почти всегда реализуются сначала в этом эксплойт-паке, а уже потом расползаются по остальным (не исключено, что просто заимствуются). Нередки случаи реализации в Angler эксплойтов к уязвимостям «нулевого дня», что делает его особенно опасным. Основным показателем эффективности любого эксплойт-пака является так называемый «процент пробива» – количество жертв, на компьютерах которых успешно запустилась полезная нагрузка (payload). У эксплоит-пака Angler этот процент особенно высок (высоким обычно считается процент пробива = 10%). Отдельные исследователи допускают, что в некоторых ситуациях пробив Angler EK мог составлять порядка 40%.

Вот как обычно происходит подготовка к заражению 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-зоны, остальные посетители ресурса получают чистые файлы.

Стоит принять во внимание тот факт, что программы для удаленного администрирования, включая Ammyy Admin, детектируются большинством антивирусов как потенциально опасные и некоторые системные администраторы либо отключают антивирус на время работы с такими программами, либо добавляют исключение для Ammyy Admin, либо запрещают удаление/лечение даже если видят детект. Таким образом, злоумышленники, во-первых, заражают компьютеры своей целевой аудитории — администраторов средних и крупных корпоративных сетей, во-вторых, обходят проблему с детектированием своего трояна.

Заражение машин внутри сети организации Для злоумышленников очень интересна схема, при которой в ходе первоначальной атаки заражается один из компьютеров организации. Даже если на зараженной машине нет ничего, что представляет интерес для злоумышленников, такой компьютер находится в одной сети, в одном домене с другими компьютерами, которые обладают интересующей хозяев троянца информацией. В таких случаях злоумышленники сначала выявляют круг интересующих их компьютеров (контроллеры домена, бухгалтерские системы) в этой подсети с помощью сетевого сканера «SoftPerfect Network Scanner», а затем заражают эти компьютеры используя утилиту Марка Руссиновича PsExec, а для запуска основных модулей троянца на других компьютерах в сети – специальный дроппер mini. Такой способ распространения может привести к крайне печальным последствиям, так как безопасность компьютера с интересующими данными по сути определяется безопасностью самого слабозащищенного компьютера в атакованной сети.

Шаг атаки №1: mini На первом этапе атаки при помощи эксплойт-пака Angler происходит эксплуатация найденной уязвимости в ПО пользователя, а затем загрузка и запуск модуля mini. В случае, если пользователь скачал вредоносный файл со взломанного сайта или вредоносный код запущен при помощи утилиты psexec, сразу происходит запуск модуля mini.

–  –  –

Mini – это небольшая по меркам Lurk программа (100 Кб).

Ее основная задача – скачать и запустить на исполнение основные модули вредоносной программы Lurk:

prescanner (пресканер), core (ядро бота), core_x64 (64-битная версия ядра), mini_x64 (64-битная версия модуля mini).

После первого запуска задача mini сводится к запуску соответствующей версии core из хранилища модулей вредоносной программы.

Отметим, что 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 и может принимать одно из следующих значений:

–  –  –

Видимо, писатели Lurk пытались рандомизировать имя, с которым троянец будет установлен в системе, но при этом хотели, чтобы полученное имя выглядело похоже на имена системных библиотек. Для этого злоумышленники составили список имен, которые выглядят схоже с именами известных компонентов Window (представлен в таблице выше). Затем вирусописателям было необходимо обеспечить механизм, случайно выбирающий имя из этого списка, для закрепления на системе. Однако злоумышленники также хотели, чтобы можно было легко узнать с каким именем установился троянец на компьютере, чтобы можно было удалить его или обновить из другого модуля. Для одновременного выполнения этих двух задач они написали генератор имен, который выбирает имя из списка выше на основе времени создания каталога Windows, что на первый взгляд выглядит неплохим решением. Но, как оказалось, это время зависит только от версии ОС, и на большинстве систем под управлением Windows 7 одинаково. Поэтому в подавляющем большинстве случаев Lurk закрепляется на системах с именем sta.dll.

В дальнейшем для простоты изложения мы будем пользоваться обозначением LurkDll для указания полного имени файла mini.

Последовательность действий mini на машине жертвы после заражения следующая:

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 уже не мог функционировать.

–  –  –

Запуск дополнительных модулей и инсталляция в системе В контексте процесса 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 в параметр по умолчанию ключа реестра [HKCU\Software\Classes\CLSID\{118BEDCC-A901-4203-B4F2-ADCB957D1887}\InProcServer32], а также создании ключа реестра [HKCU\Software\Classes\Drive\ShellEx\FolderExtensions\{118BEDCC-A901-4203-B4F2ADCB957D1887}]. Таким образом достигается автоматический запуск 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= Обратите внимание на структуру этих 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 В представленном примере 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”, этот алгоритм можно представить следующим образом:

–  –  –

Другие модули зашифрованы при помощи криптоалгоритма BlowFish (ECB Mode), ключ для которого вшит непосредственно в mini.

Обычно он выглядит примерно так:

AXQIMNQAGXNVDLOKDGUKJHMXABUWLKVO. Однако, не все так просто. Попытка расшифровать скачанные данные при помощи этого ключа закончится неудачей, т.к. на самом деле данные зашифрованы при помощи другого ключа. Настоящий ключ получается из вшитого псевдо-ключа при помощи последовательного перебора одного символа (brute-force атака). В исследованных нами образцах mini перебором подбирался символ на позиции 16.

Кратко алгоритм подбора ключа можно представить следующим образом:

1. Генерируется очередной ключ на основе вшитого псевдоключа.

2. С его помощью расшифровываются первые 4096 байт данных.

3. Второе двойное слово расшифрованных данных сравнивается с жестко зашитым значением 0x0000C0DE. Если совпало – верный ключ найден, если нет – возвращаемся к пункту 1, продолжаем поиск.

Мы не знаем, почему авторы решили расшифровывать первые 4096 байт зашифрованных данных каждый раз, хотя проверка осуществляется только по второму двойному слову. Для поиска нужного ключа можно было бы расшифровывать только первые 8 байт, это значительно удешевило бы процедуру поиска (на нее будет затрачено меньше ресурсов ПК). Мы предполагаем, что авторы сознательно усложнили процедуру подбора верного ключа, чтобы «вымотать» эмуляторы АВпродуктов.

Хранилище модулей Lurk Для того, чтобы не приходилось загружать дополнительные модули при каждом запуске mini, троянец сохраняет эти модули в отдельный зашифрованный файл.

Этот файл расположен в каталоге %APPDATA% и имеет в зависимости от времени создания каталога Windows одно из следующих имен:

–  –  –

Содержимое хранилища зашифровано при помощи криптоалгоритма Blowfish с использованием ключа, зависящего от времени создания каталога Windows. Помимо названия плагина и его тела, в хранилище также содержится список контрольных сумм имен процессов, в контексте которых плагин должен выполняться. С помощью этой информации mini определяет, в какой процесс внедрять плагин: для модуля веб-инжектов это процесс браузера, для модуля ibank это Java.exe, в контексте которого функционирует система ДБО.

Расшифрованное хранилище имеет следующую структуру:

–  –  –

prescanner – это специальный модуль банковского троянца, который выполняет две основные задачи:

сбор информации о зараженной системе;

граббинг паролей из FTP-клиентов, обнаруженных на машине пользователя.

Модуль 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 тщательно избегают понятных человеку строк в своих модулях, т.к. полагают, что это может привести к быстрому опознанию вредоносности модулей и облегчить задачу аналитиков.

Поэтому чтобы описывать различные сущности, разработчики используют в троянце специальные идентификаторы, внешне похожие на 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-адресов информационных ресурсов, телекоммуникационных компаний, платежных систем, торговых площадок, банков и даже силовых структур.

Мы условно разделили цели на три группы:

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.

Элемент этой секции имеет типичную структуру:

Здесь “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} содержит в себе хэши от имени файлов и путей к ним, которые ищутся на компьютере жертвы и которые указывают на то, что эта система злоумышленникам интересна.

Каждая запись имеет следующую структуру:

Здесь:

“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 пробует обнаружить на компьютере пользователя. Каждый ее элемент имеет ту же структуру, что и элемент предыдущей секции.

По результатам анализа секции, можем сделать вывод, создатели троянца ищут в списке процессов зараженной машины названия программного обеспечения денежных переводов, ПО для POSтерминалов, ПО для почтовых служб, систем силовых ведомств и т.п.

Коммуникация prescanner с командным центром Собрав информацию о машине и проверив выполнение имеющихся правил, prescanner отправляет отчет на свой управляющий сервер. В рассмотренных нами случаях C&C perscanner’а совпадал с C&C загрузчика mini. Отчет, сформированный prescanner’ом, представлен на следующем рисунке.

–  –  –

Отчет зашифрован при помощи обычного xor-алгоритма, но с использованием длинного ключа.

В нашем случае ключ был следующим:

IHHJ2R8T2NKRR2OA1FU3IB764VRJ6402I6RNQHWLN5DV1LV0QKIZF3Y4AYL3D26KGGVWX06GQIV4O3W6BEV XQEMPBAFVFMGZ7I2TIYQQJ6X5PBAP87SGFR5N5CAGF63FMTTVVIHWGV4YU5AK5MZ2293MSVQ2DU4JC2O MUV4X0AUGSK1BZJQWMJTR0H3I6GXIDXDV421C2GCNB880CPU4HSPGDKO186U311ETP4D8ZAO2T0SEOT75I PH75J6BRYE35CD9JU3SIGZJUIDECH9GCL83L29OD06ZYHXCLPWFL0A9AL96PBCDB3RYGXK7UCLAAFMKLVIDD WL08EYHL72ZKNMGPUMO56G63EDDUH7ZWWUXKESI9T7AC8IYQY8SGBTJEJ99JQXZ5I6M43MPRQ6D0NWU G9XWEE6I9GKJVDIO492M909TCKKZ8MEB6IELX9Z45Z6RV28TXWUNAXH6OIOFH0YGJWG2

Ключ жестко зашит в тело prescanner.

В расшифрованном виде отчет prescanner’a выглядит следующим образом:

Из отчета видно (секция “dump”), что произошло три ошибки в процессе работы prescanner, точнее, в момент обработки секции “whois_records”. Комментарии представлены в виде жестко зашитой константы, по которой затруднительно определить причину неудачи, очевидно, prescanner не смог получить whois-информацию для исследуемой машины.

Этот отчет был отправлен prescanner, который не нашел, за что зацепиться на анализируемом компьютере.

Если бы зацепки были найдены, в отчет была бы добавлена соответствующая секция, например:

Каждая пара включает в себя элемент “item”, содержащий номер процесса в списке секции {9B05E4F6-E1D5-43ed-B1F6-6CF2F8F30C7D}, и элемент “rule”, содержащий номер правила, которому соответствует этот процесс.

Если бы prescanner нашел данные для авторизации на FTP-серверах, в отчет была бы добавлена примерно такая секция:

Коммуникация 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 (соответственно).

–  –  –

На рисунке ниже представлен процесс коммуникации 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 имеют один существенный недостаток: они предсказуемы. В качестве входных данных генераторы обычно используют текущую дату/время, идентификатор ботнет-сети и т.п. Основная проблема всех этих исходных данных в том, что они известны (или могут стать известными) исследователям заблаговременно. Т.е. аналитики могут составить список возможных имен управляющих серверов заранее, еще до того, как они будут сгенерированы собственно вредоносной программой, и заблокировать их (с помощью своего антивирусного продукта или «засинкхолив» их).

Пользы злоумышленникам от таких 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

Здесь:

–  –  –

Кроме этого, в качестве входных параметров DGA также используются длина сгенерированного имени домена, количество сгенерированных доменов и случайное значение – «посев», будем обозначать их соответственно “C&C_name_length”, “num_of_domains” и “seed”.

Итак, сначала core запрашивает данные с биржи для DGA с помощью описанного выше GET-запроса.

В результате сервер возвращает примерно следующее:

Возвращенные сервером котировки на запрос http://ichart.finance.yahoo.com/table.csv?a=11&c=2010&b=1&g=w&ignore=.csv&s=ZMH

Далее от полученных данных отрезается заголовок и две последние колонки. Получаем следующее:

Далее, если значение параметра seed установлено, полученные данные последовательно кодируются методом xor с параметром seed (в исследуемом случае он был равен ‘AAA’).

–  –  –

В результате работы DGA получим следующие значения имен C&C:

Генерация нового домена происходит каждые 5 секунд до успешного установления соединения.

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

Раз в день данный модуль отправляет статистику браузеров Internet Explorer и Mozilla Firefox по посещенным за день сайтам.

Шифрование трафика Вся коммуникация между модулем core и C&C шифруется. В качестве криптоалгоритма применяется AES в режиме CBC с длиной ключа 128 бит. При начале коммуникации бота с командным центром согласуется сессионный ключ, которым и шифруется трафик.

Сессионный ключ согласуется по протоколу Диффи-Хеллмана. В качестве параметров g и p протокола

Диффи-Хеллмана Lurk использует следующие значения:

g = 0x9EB9BE4D22A22E0EB1DCC1DB7F3EEDBB p = 0x03.

Для нас остается загадкой, почему авторы выбрали именно такую криптографическую схему – чем их не устроил обычный HTTPS?

Как бы там ни было, выбранная схема подвержена атаке типа MITM, поэтому авторы в процедуре согласования ключей дополнительно применяют алгоритмы DSA и HMAC.

–  –  –

Такого рода схема выглядит громоздкой и сложной, однако вирусописатели остаются верны ей уже много лет.

В другом вредоносном ПО в большинстве случаев в качестве сессионного криптоалгоритма используется упрощенная схема с AES (редко – RC4), симметричный ключ генерируется на стороне клиента и передается на сервер в зашифрованном при помощи RSA виде. Публичный ключ RSA обычно вшивается в бот, закрытый ключ RSA хранится на сервере. Но авторы Lurk, видимо, стараются быть уникальными во всем.

Итак, процедура согласования ключей выглядит следующим образом:

–  –  –

В ответ C&C присылает ответ, содержащий в себе следующие данные:

идентификатор соединения;

тип запроса (ответа);

длину данных в основном теле;

два пустых двойных слова;

случайные данные;

подпись DSA (два числа, по 160 бит каждое);

CRC32 от пустых двойных слов, случайных данных и DSA-подписи.

Детально структура ответа сервера представлена на рисунке.

–  –  –

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 – второй тип пакета, обмен ключами.

Остальные поля были описаны ранее.

Сервер отвечает пакетом:

–  –  –

Здесь:

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-ключ. Таким образом, процедуру согласования ключей можно считать законченной, бот получил сессионный ключ, которым далее будет шифроваться весь трафик.

Все пакеты, следующие после этого, имеют стандартную структуру:

Загрузка, установка и запуск дополнительных модулей троянца Обмен данными между 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).

–  –  –

В атрибуте “name” указано имя плагина в иерархии плагинов Lurk – “ibank.dll”, в поле “core” – данные, зашифрованные при помощи base91. В поле “targets” указано множество, состоящее из CRC32 от названий процессов, в которые этот модуль должен быть внедрен.

Отметим также, что для модулей module_Bifit и module_az при запросе файлов у командного центра бот сообщает C&C о том, с какими ДБО работает пользователь.

К примеру, бот направляет C&C следующий запрос:

Разберем его подробно:

1. запрос module_Bifit с указанием аплета системы «iBank2», с которым работает оператор зараженного компьютера и его версии (поскольку файлы для подмены для различных версий аплета также отличаются);

2. запрос на получение файлов автозаливов (module_az) для интернет-системы ДБО одного из крупнейших российских банков (банк x);

3. запрос на получение файлов автозаливов (module_az) для интернет-системы ДБО другого крупнейшего российского банка (банк y);

4. запрос на получение обновления mini;

5. запрос на получение обновления core;

6. запрос на получение обновления ibank.dll;

7. запрос на выкачку w3bank.dll.

Командный сервер возвращает ответ в следующем формате:

Здесь в тэгах “core” находятся закодированные в base91 данные, в тэге “rules” – правила для применения скриптов автозаливов, в теге “intf” - передаются названия обфусцированных классов module_Bifit. Важны не названия, а их последовательность – именно на ее основании производятся правильные вызовы методов из модуля module_Bifit.

В самом простом случае ответ C&C боту выглядит следующим образом:

В таком ответе всего одна секция – “info”. В первом содержательном ответе в подсекции “uid” находится уникальный идентификатор бота, который боту и назначается, в остальных запросах это поле просто отзеркаливает соответствующее поле из запроса бота.

Подсекция “dnsinfo” также всегда передается от C&C боту и содержит настройки DGA для core. Таким образом, с помощью этой секции можно легко перевести core с одного множества сгенерированных C&C на другое. Полученные настройки “dnsinfo” сохраняются в локальном хранилище бота.

Кроме групп FILES и INFO в запросе также могут быть следующие группы:

IBANK_INFO – бот передает идентификатор «iBank2»-аплета, найденного на компьютере, C&C в ответ сообщает уникальный идентификатор для ibank-модуля, который будет использоваться ботом далее.

IBANK – основной блок, используемый при воровстве денег. Именно в этом тэге бот передает C&C всю интересующую злоумышленников информацию, которую удалось получить из системы «iBank2» (счета, балансы, платежные поручения, их статус и т.п.). В ответ боту от C&C приходят команды на мошеннические платежи и указания на необходимость их сокрытия.

Забегая вперед, отметим, что Lurk уже после того, как украл деньги у клиента, осуществляет подмену баланса – скрывает мошеннический платеж. Это нужно для того, чтобы клиент не позвонил в банк и не отменил операцию.

W3BANK_INFO – это редко используемая служебная секция, она предназначена для координации с core и w3bank-аплета в том случае, если последних в системе запущено одновременно несколько (что бывает крайне редко – нечасто клиент одновременно может зайти в несколько интернет-систем ДБО).

W3BANK – вторая секция, активно используемая в процессе хищения денег. Если секция IBANK использовалась для работы с системами «iBank2», то эта секция используется для коммуникации с плагином w3bank, предназначенным для хищения денег из систем интернетбанкинга.

DUMP – секция, предназначенная для передачи на C&C диагностической информации о проблемах или о прогрессе работы бота.

IBANK_DUMP – секция, подобная предыдущей, но в ней передается информация о проблемах, возникших в плагине IBANK Lurk.

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

o module – название модуля, в котором произошла ошибка;

o stage – этап работы модуля;

o status – что случилось: ошибка, предупреждение или все хорошо;

o comment – комментарий (часто – текст ошибки).

SERVICE_COMMANDS – это очень важная секция. В направлении от C&C к боту она содержит команды, предназначенные для выполнения ботом; если же передача идет в другом направлении – результаты выполнения этих команд.

Управляющие команды Lurk Модуль core поддерживает команды, которые может выполнять по запросу с C&C. Команды приходят в разделе “service_commands” JSON-ответа C&C.

Вот список команд, поддерживаемых ботом.

–  –  –

Перехват клавиатурного ввода В новых версиях Lurk (как минимум, начиная с 8.9773) авторы реализовали в модуле core функцию перехвата данных, вводимых пользователем с клавиатуры. Перехват клавиатурного ввода организуется путем вызова функции «SetWindowsHookEx». Кроме клавиатурного ввода перехватываются также операции с буфером обмена. Перехват осуществляется только в контексте окон, удовлетворяющих хотя бы одному из условий, описанных в хранилище настроек вредоносной программы (эти условия запрашиваются с управляющего сервера вредоносной программы).

Перехваченная информация отправляется на управляющий сервер в ходе очередного сеанса связи (раз в 5 минут).

C&C присылает боту настройки для перехвата клавиатурного ввода, вот один из вариантов:

Русские символы, закодированные в тексте, представим далее в виде простого списка.

Итак, Lurk интересуется окнами со следующими словами/фразами в названии (мы сохранили орфографию создателей правил перехвата клавиатурного ввода):

–  –  –

Также Lurk интересуется окнами, содержащими названия крупных российских банков и других финансовых учреждений, популярных программ-клиентов для работы с банковским счетом и осуществления денежных переводов, бухгалтерских программ и т.д.

Нас особенно позабавила «безопастная авторизация», все-таки безграмотность порой может сыграть с создателями вредоносного ПО злую шутку: кейлоггер из такого окна ничего не запишет, поскольку просто его не найдет. Впрочем, мы не знаем точно, ошибка ли это авторов вредоносного ПО или разработчиков системы ДБО.

В правилах кейлоггера используются следующие обозначения:

process – имя процесса для кейлоггинга;

caption – подстрока заголовка окна, в котором будет осуществляться кейлоггинг;

window – класс окна, который будет искать кейлоггер;

control – класс дочернего управляющего элемента;

id – уникальный идентификатор правила.

Хранилище Lurk Основная часть хранилища этого троянца расположена в реестре, но часть дополнительных данных, относящихся к хранилищу, может быть представлена в виде файла на жестком диске. Как правило в виде файлов хранится большой, но логически единый, объем данных, например, видео захваченное с экрана или код веб-инжектов. Но в любом случае ссылки на эти дополнительные файлы обязательно присутствуют в основной части хранилища в реестре.

Lurk использует для хранения своих настроек подключ ключа реестра HKCU\SOFTWARE\MICROSOFT.

Название подключа имеет вид XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, где X – шестнадцатеричная цифра. Название подключа генерируется при помощи API-функции CreateGUID().

В этом подключе создаются параметры, имеющие такой же вид (тоже GUID), значением которых являются зашифрованные настройки вредоносной программы.

Настройки Lurk зашифрованы при помощи алгоритма AES с длиной ключа 128 бит в режиме CBC и с нулевым инициализационным вектором.

В качестве ключа выступает значение хэша Cubehash от конкатенации двух двойных слов – даты создания %SYSTEMROOT% и DWORD seed, который меняется от версии к версии бота. Очевидно, авторы бота полагают, что такой подход даст им множество различных вариантов имени ключа.

В исследованной нами версии бота seed = {0x09, 0x0A, 0x0B, 0xC, 0xD, 0xE, 0xF, 0x0}.

Троянец не хранит сгенерированный GUID своего хранилища где-либо, а просто анализирует подключи HKCU\SOFTWARE\MICROSOFT на предмет совпадения с форматом XXXXXXXX-XXXX-XXXXXXXX-XXXXXXXXXXXX, после чего последовательно расшифровывает записи (в том случае, если их имя соответствует длине GUID и тип соответствует REG_BINARY), после чего сравнивает начало с заранее определенной сигнатурой. Если совпало – бот считает, что нашел свое хранилище.

В исследованном нами образце бота сигнатура была следующей: Signature = {0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8}.

Дополнительные файлы хранилища расположены на диске по адресу «%LocalAppData%\Microsoft», причем файлы расположены не непосредственно в папке Microsoft, а в одной из ее подпапок, которая для каждого сохраняемого файла выбирается из существующих случайным образом. Имя сохраняемого файла также имеет формат стандартного GUID.

Так как файл со случайным GUID также укладывается в случайное место, ссылка на его имя сохраняется в хранилище настроек, иначе бот потом не сможет его найти.

Мы разделили настройки в хранилище на несколько категорий в соответствии с их назначением.

Основные настройки

В этом блоке настроек в хранилище Lurk хранится основная информация о боте:

StorageVersion – версия хранилища настроек (совпадает с версией бота);

PL | {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} – время последней модификации модуля с соответствующим идентификатором;

InstallTime – время первого запуска вредоносной программы (после отправки значения на управляющий сервер устанавливается в ноль и больше не изменяется);

InstallId – идентификатор экземпляра вредоносной программы, предположительно получаемый из отчета модуля prescanner;

DnsLastName – последний адрес управляющего сервера (C&C), с которым удалось удачно установить соединение;

uid – уникальный идентификатор зараженной системы, присвоенный системе управляющим сервером (CnC);

DnsInfo – параметры генерации новых доменных имен;

KLTimestampKLRules – время последнего изменения правил ведения журнала клавиатурного ввода.

Настройки веб-инжектов Этот тип настроек описывает вспомогательные файлы, хранящиеся вредоносной программой. Такими файлами могут быть, например, скрипты, внедряемые модулем w3bank.

В этом случае структура файловых настроек имеет следующий вид:

–  –  –

Настройки перехвата сетевых ресурсов Данный раздел настроек определяет сетевые ресурсы, за которыми осуществляется наблюдение (отправка на C&C всех POST запросов к сетевому ресурсу) модулем w3bank и в контекст которых может происходить внедрение вредоносных объектов типа Javascript.

Структура этих настроек имеет следующий вид:

–  –  –

Настройки перехвата клавиатурного ввода Данный раздел хранилища имеет два подраздела: KLRules и KLResults. В KLRules хранятся условия, при которых активируется перехват клавиатурного ввода, а KLResults описывает перехваченные данные клавиатурного ввода.

У каждой записи в этих разделах есть пять параметров:

id – идентификатор правила;

process – название процесса;

window – класс родительского окна;

caption – заголовок родительского окна;

control – класс окна элемента ввода.

Записи в разделе KLResults в дополнение к пяти описанным параметрам имеют еще и три других параметра, относящихся к перехваченным данным:

text – перехваченные данные;

timestamp – время перехвата данных;

rule_timestamp – время последнего изменения правила, срабатывание которого вызвало перехват.

Настройки захвата видео Данный раздел настроек описывает состояние захвата видеопотока. Захват видеопотока с экрана осуществляется модулем core в зависимости от настроек данного раздела.

Описание параметров:

VideoCaptureOn – определяет, должна ли быть включена запись видеопотока с экрана;

VideoCaptureTrigger – определяет условие, при котором производится запись (если установлено в always, запись осуществляется безусловно).

Модуль module_vnc {52F1F7D8-4BCCAC86-3562F81990F6} Данный модуль предоставляет возможность удаленного управления зараженной системой с использованием протокола VNC. При этом удаленный узел получает полный доступ к системе: видит изображение, выводимое на экран, может передавать и получать любые файлы и данные, включая данные с устройств записи видео и звука, использовать имеющееся на машине ПО и устанавливать новое.

Также данный модуль предоставляет возможность запускать процессы браузеров со следующими параметрами:

Mozilla Firefox:

-profile Google Chrome:

--user-data-dir= Internet Explorer:

-nomerge В случае с браузерами Mozilla Firefox и Google Chrome при каждом запуске создается новый профиль пользователя браузера. Это позволяет скрывать активность зловреда от легитимного пользователя, который не сможет видеть ее в истории посещенных сайтов. Кроме того, это позволяет создать на каком-либо сайте отдельную сессию параллельно с уже открытой (в частности это дает возможность второй раз пройти аутентификацию на сайте, с которым работает легитимный пользователь, и производить в параллельной сессии действия, которые не будут влиять на сессию пользователя).

Аналогичный эффект имеет указанный выше параметр запуска браузера Internet Explorer (за исключением сокрытия истории посещений).

Модуль w3bank {AABA3126-14E2-443bA11B-FB6C1F793103} Модуль w3bank (наряду с модулем ibank.dll) – одна из двух «рабочих лошадок» троянца Lurk, он непосредственно участвует в хищении денег. Рассматриваемый модуль предназначен для атак на онлайн-системы ДБО.

Основная задача модуля w3bank – внедрение «инжектов» («автозаливов») в браузер пользователя.

C&C, отдавая этот модуль core, указывает (c помощью рассмотренного выше поля “targets”) на необходимость его внедрения в следующие процессы:

–  –  –

Первые два процесса читателю, скорей всего, известны, а iscc.exe – это процесс криптопровайдера, который использовался одним из российских банков для подписи платежных поручений (до тех пор, пока у банка не была отозвана лицензия).

При внедрении нового кода в загруженную веб-страницу нужно каким-то образом получать управление и модифицировать код веб-страницы до ее отображения пользователю. В разных браузерах w3bank.dll решает эту задачу различными способами.

В контексте процесса iexplore.exe происходит перехват и модификация HTTP/HTTPS трафика «на лету»

методом регистрации Pluggable Namespace Handler.

В контексте процесса firefox.exe те же действия выполняются методом установки перехватов функций «AsyncOpen» и «GetResponseStatus» в таблице виртуальных функций объектов типа «Channel».

Перехват представляет собой отправку на управляющий сервер всех POST запросов к сетевым ресурсам, адреса которых получены от C&C и указаны в хранилище настроек вредоносной программы.

Модификация представляет собой внедрение объекта «javascript» между тегами «HEAD» вебстраницы. Адреса страниц и содержимое объекта «javascript» троянец получает от C&C и хранит в своем хранилище настроек.

В контексте процесса iscc.exe происходит перехват функций «Base64Utf8Decode» и «EncodeRelease»

динамически подгружаемой библиотеки encode.dll с целью подмены декодированного функцией «Base64Utf8Decode» текста в соответствии с таблицей замен из хранилища настроек вредоносной программы.

В процессе исследования троянца мы видели различные цели для перехвата и модификации трафика.

Их анализ показал очевидный интерес авторов зловреда к четырем крупнейшим российским банкам.

Атаки Lurk на пользователей двух из этих банков сводятся к хищению их учетных данных. А вот еще для двух крупных российских банков в рамках исследования мы получили скрипты инжектов – далее будем обозначать эти банки как «банк X» и «банк Y».

Атака на банк X Файлы скрипта инжектов имеют одинаковые имена для разных онлайн-ДБО (content.min.js), но различный GUID, т.к. последний генерируется случайным образом.

Данный скрипт осуществляет перехват аутентификационной информации, вводимой в систему ДБО банка X. Чтобы не давать подсказок начинающим вирусописателям, текст скрипта мы здесь не приводим.

При аутентификации пользователя в системе ДБО происходит перехват его логина и пароля. После успешной аутентификации создается скрытая от пользователя параллельная сессия, в ходе которой Lurk переходит по банковским страницам и ищет имя держателя карты и номер телефона, связанный с картой. В дальнейшем эта информация отправляется на управляющий сервер, адрес которого совпадает с сетевым адресом сервера, взаимодействующего с модулем core.

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

Также управляющий сервер может зарегистрировать автоматический платеж, который будет выполнен после следующей аутентификации пользователя в системе ДБО.

Атака на банк Y Скрипт, использовавшийся для атаки на банк Y, осуществляет перехват аутентификационной информации, вводимой в систему ДБО этого банка. Как и в предыдущем случае, текст вредоносного скрипта мы здесь не приводим.

В автоматическом режиме модифицируются следующие веб-страницы системы ДБО:

–  –  –

Таким образом вредоносный скрипт собирает всю информацию, необходимую для совершения платежа в данной системе ДБО. В дальнейшем эта информация отправляется на управляющий сервер, адрес которого совпадает с сетевым адресом сервера, взаимодействующего с модулем core.

Управляющий сервер в ответ может прислать скрипт, который будет исполнен в контексте браузера. В рамках исследования получить такой скрипт не удалось.

Также управляющий сервер может зарегистрировать автоматический платеж, который будет выполнен после следующей аутентификации пользователя в системе ДБО.

Модуль ibank {04DB063E-1454-4a73B2CC-4DB6D4BB6AA1} Данный модуль предназначен для совершения хищений в системах ДБО «iBank», разработанных компанией БИФИТ.

Модуль функционирует в контексте процесса виртуальной машины Java и устанавливает перехваты функций «LoadLibraryA», «LoadLibraryW», «GetProcAddress», «CreateFileW», а также функции «JNI_CreateJavaVM» библиотеки jvm.dll.

Ниже представлен функционал перехватчиков этих функций:

–  –  –

LoadLibraryA При попытке загрузки библиотеки профилировщика не производится никаких действий, но функция сообщает об успехе. Данный перехват LoadLibraryW реализует имитацию успешной загрузки библиотеки профилировщика.

GetProcAddress Подмена функций «Agent_OnLoad» и «Agent_OnUnload» на функции из вредоносного модуля.

–  –  –

В дальнейшем, при запуске Java-апплета, происходит проверка этого апплета на принадлежность системе «iBank 2». В случае запуска этой системы ДБО на управляющий сервер вредоносной программы отправляется запрос с сетевым адресом, откуда был загружен апплет, и контрольной суммой апплета. В ответ на данный запрос управляющий сервер отправляет команду «block» или «continue», означающие блокировку запуска или продолжение запуска апплета соответственно. При этом вместе с командой «continue» приходит набор файлов Java-классов, подменяющих оригинальные классы апплета «iBank».

iBank applet Infected iBank applet

–  –  –

Подмена скрывается от апплета путем перехвата следующих функций Java:

sun/management/VMManagementImpl.getVmArguments0 sun/misc/VMSupport.initAgentProperties java/lang/Throwable.getStackTraceDepth java/lang/Throwable.getStackTraceElement java/lang/Thread.dumpThreads java/lang/Thread.currentThread java/lang/ClassLoader.findLoadedClass0 sun/reflect/ConstantPool.getSize0 java/lang/Thread.getThreads java/security/AccessController.getStackAccessControlContext java/security/AccessController.getInheritedAccessControlContext Также вредоносный модуль ibank регистрирует некоторые свои функции в качестве нативных функций подмененных Java-классов. Среди них регистрируются функции работы с хранилищем настроек (для получения дополнительных настроек, необходимых для работы вредоносного кода в зараженном апплете), функции взаимодействия с управляющим сервером (отправка данных на управляющий сервер и получение команд для зараженного апплета).

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

В качестве примера работы зараженного апплета приведем скриншот, снятый на одной из зараженных Lurk машин. На скриншоте видно, что зараженный апплет запрашивает «подтверждение номера» телефона, используемого для двухфакторной авторизации в процессе подтверждения платежного поручения.

Отметим, что такого рода запрос Lurk показывает только если на счету зараженного пользователя больше 900 000 RUR.

Зараженный апплет пытается с помощью методов социальной инженерии узнать у пользователя номер телефона, используемого для подтверждения платежей Мы не знаем точно, зачем этот номер создателям троянца. Возможно – для клонирования SIM-карты.

Возможно - для блокировки, имеющейся и выпуска новой. В любом случае, им необходимо как-то заполучить mTAN – и номер телефона им нужен именно для достижения этой цели.

Модуль rdp-plugin-x86 {A06B5020-0DF3E5-BE38-AE5E4B860EDE} Этот модуль выполняет достаточно тривиальную задачу – включает поддержку RDP на зараженной машине. Это обеспечивается при помощи нескольких последовательных шагов.

1. Тип запуска службы “TermService” устанавливается в “Auto”.

2. Устанавливаются нужные значения ключей реестра:

a. HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server, fDenyTSConnections = 0 b. HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server, fSingleSessionPerUser = 0 c. HKLM\SYSTEM\CurrentControlSet\Control\Lsa, LimitBlankPasswordUse = 0 d. HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Licensing Core, EnableConcurrentSessions = 1 e. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, EnableConcurrentSessions = 1 f. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, AllowMultipleTSSessions= 1 g. HKLM\SOFTWARE\Policies\Microsoft\WindowsNT\Terminal Services, MaxInstanceCount = 5 h. HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\Standa rdProfile\GloballyOpenPorts\List, "3389:TCP" = "3389:TCP:*:Enabled:Remote Desktop" i. HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\Domai nProfile\GloballyOpenPorts\List, "3389:TCP" = "3389:TCP:*:Enabled:Remote Desktop"

3. Выполняется команда «netsh.exe firewall set service remotedesktop enable», добавляющая новое правило для firewall.

4. Создается новый пользователь в системе с правами администратора с заранее заданными именем пользователя и паролем.

В проанализированном нами экземпляре вредоносного ПО имя пользователя и пароль были соответственно равны «Support159024071» и «Zero0Night».

5. Библиотека RDP службы termsrv.dll изменяется «на лету» в оперативной памяти ОС, чтобы обеспечить несколько параллельных сессий на не серверных ОС.

Модуль highLauncher {9F786E98-3D4CB97D9D4DBCC0} Этот модуль предназначен для решения одной задачи – запуска плагинов, которые требуют элевации, т.е. повышения привилегий. Модули rdp-plugin-x86 и lsa-plugin-x86 работают с использованием mimikatz, поэтому вызывающему необходима привилегия SE_DEBUG. Сам по себе этот модуль не выполняет элевацию привилегий, только загрузку нужного плагина. Модуль highLauncher инжектится в svchost.exe и выполняет бесконечный цикл, периодически (1 раз в 10 секунд) запрашивая у core идентификатор плагина для запуска. После того, как нужный идентификатор получен, highLoader загружает нужный плагин путем вызова LdrLoadModule и ручной передачи управления в DllMain.

Модуль launcher {968A2A9A-7DF4-4E69BF81-563AF8FFB7DC} Это просто загрузчик mini, который используется в процессе запуска mini с повышением привилегий.

Элевация выполнена на основе UACME с использованием метода WinNT/Sirefef, позаимствованного в троянце Trojan-Downloader.Win32.ZAccess. Этот метод предполагает использование т.н. ProxyDll, в качестве которой и выступает модуль launcher. Будучи загруженным, launcher через IPC получает имя библиотеки троянца (LurkDll), которую и запускает уже при помощи LoadLibrary, но уже с большими правами.

Модуль lsa-plugin-x86 {5B3957F2-AAAFFF8-94B8-83C52AFCD2A9} Этот модуль предназначен для получения учетных данных администраторских и/или доменных аккаунтов на зараженном компьютере. По сути модуль представляет собой только обертку над mimikatz (над кодом, получающим привилегию SE_DEBUG и выполняющим команду sekurlsa::logonpasswords), весь вывод mimikatz передается на C&C через тег dump. Более ничего интересного в этом модуле нет.

Заключение Банковский троянец Lurk стоит особняком среди вредоносного ПО, предназначенного для хищения денежных средств у клиентов банков. Он интересен продолжительностью работы (существует и активно развивается более 5 лет), таргетированностью атак, методами внутренней организации зловреда. Троянец написан профессионально, по объему функционала и частоте вносимых изменений можно сделать вывод, что над проектом работает команда профессиональных разработчиков и тестировщиков. Lurk активно противодействует обнаружению – разработчики прикладывают много усилий, чтобы минимизировать детектирование своего троянца, а таргетированные атаки делают затруднительным оперативное получение новых самплов.

Авторы троянца прикладывали усилия, чтобы максимально защитить свое детище от аналитиков, особенно – защитить от глубокого анализа. Или, как минимум, сильно усложнить такой анализ.

Частично они пытались этого добиться активным использованием классов, библиотек Boost! и CryptoPP. CryptoPP очень неудобно анализировать, даже имея на руках исходный код приложения, не говоря уже об анализе бинарного файла, активно использующего эту библиотеку. Boost! и активное использование классов C++ также добавляют эксперту работы, но хорошего вирусного аналитика это не остановит.

Противодействуют Lurk не только антивирусные компании. Разработчик систем «iBank» – компания «БИФИТ» – также прикладывает усилия для борьбы с атаками на их продукт. Ведущий эксперт по безопасности компании «БИФИТ» Алексей Левин на конференции Zeronights 2015 выступал с докладом, в котором приводил обзор банковских троянцев, атакующих системы «iBank 2», и методы противодействия им, доступные для реализации в ПО «iBank 2». Также была показана эффективность этих мер противодействия. Из результатов проведенного «БИФИТ» исследования следует, что из всех реализованных в системе «iBank 2» средств защиты, против Lurk эффективен только контроль на стороне сервера банка, остальные меры противодействия, реализованные в системе «iBank 2», были успешно преодолены авторами Lurk, что говорит об их профессионализме.

В целом, Lurk оставляет впечатление сложной и мощной системы, предназначенной для достижения преступной цели создателей продукта – хищения информации и денежных средств у пользователей.

Упорство и сосредоточенность, с которыми авторы работают над своим троянцем, говорит о высокой степени их мотивации.

Однако вирусописатели не используют уязвимости нулевого дня для локального повышения привилегий, не проводят свои исследования безопасности ОС для внедрения и закрепления на машине, а также используют уже известные технологии для обхода UAC. В общем, создатели троянца решают не исследовательскую, а инженерную задачу, их цель – создание эффективного преступного инструмента для хищения денежных средств, а не поиск новых уязвимостей. Но в этом и главная слабость Lurk как проекта – его успех зависит от находок сторонних исследователей, так как имеющиеся техники, используемые Lurk, оперативно детектируются современными антивирусными решениями.

«Лаборатория Касперского» для противодействия этому троянцу применяет методики сигнатурного, эвристического и проактивного детектирования. Такой подход позволяет детектировать даже новые экземпляры Lurk еще до того, как они появляются у нас в коллекции. Детектирования этого троянца происходит со следующими вердиктами: Trojan.Win32.Lurk, Trojan-Banker.Win32.Lurk, TrojanSpy.Win32.Lurk.

В заключение дадим банальный, но от этого не потерявший актуальности совет. Безопасность системы

ДБО обеспечивается:

грамотным проектированием и администрированием локальных сетей организаций;

регулярным обучением сотрудников правилам и нормам информационной безопасности;

использованием современного и регулярно обновляемого антивирусного ПО.

Уверены, что соблюдение этих простых правил позволит обеспечить высокий уровень защиты от Lurk и подобных ему угроз.

IOCS:

Ключи реестра:

HKCU\Software\Classes\CLSID\{118BEDCC-A901-4203-B4F2-ADCB957D1887} HKLM\Software\Classes\CLSID\{118BEDCC-A901-4203-B4F2-ADCB957D1887} HKCU\Software\Classes\Drive\ShellEx\FolderExtensions\{118BEDCC-A901-4203-B4F2-ADCB957D1887} HKLM\Software\Classes\Drive\ShellEx\FolderExtensions\{118BEDCC-A901-4203-B4F2-ADCB957D1887}

Файлы:

Возможные названия модуля mini:

%APPDATA%\API32.DLL %APPDATA%\dlg.dll %APPDATA%\mm.dll %APPDATA%\setup.dll %APPDATA%\help.dll %APPDATA%\mi.dll %APPDATA%\http.dll %APPDATA%\wapi.dll %APPDATA%\ER32.DLL %APPDATA%\core.dll %APPDATA%\theme.dll %APPDATA%\vw.dll %APPDATA%\el32.dll %APPDATA%\sta.dll %APPDATA%\p10.dll %APPDATA%\fc.dll %APPDATA%\in_32.dll %APPDATA%\pool.drv %APPDATA%\env.dll %APPDATA%\man.dll

Возможные названия хранилища модулей:

%APPDATA%\ddd2.dat %APPDATA%\pdk2.dat %APPDATA%\km48.dat %APPDATA%\9llq.dat %APPDATA%\ddqq.dat %APPDATA%\834r.dat %APPDATA%\gi4q.dat %APPDATA%\wu3w.dat %APPDATA%\qq34.dat %APPDATA%\dqd6.dat %APPDATA%\w4ff.dat %APPDATA%\ok4l.dat %APPDATA%\kfii.dat %APPDATA%\ie31.dat %APPDATA%\4433.dat

Сетевые индикаторы:

Сервера управления:

3d4vzfh68[.]com 43xkchcoljx[.]com carlton69f[.]com diameter40i[.]com elijah69valery[.]com embassy96k[.]com evince76lambert[.]com globe79stanhope[.]com groom58queasy[.]com hackle14strand[.]com hotbed89internal[.]com mechanic17a[.]com paper17cried[.]com plaguey42u[.]com possum89hilarity[.]com rhythmic81o[.]com ri493hfkzrb[.]com roomful44e[.]com s8f40ocjv[.]com scale57banana[.]com wing97pyroxene[.]com yf3zf90kz[.]com

Правила IDS:

alert tcp $HOME_NET any - $EXTERNAL_NET $HTTP_PORTS (msg:"Bot.Lurk.HTTP.C&C";

flow:established,to_server; content:"POST"; pcre:"/\?hl=[a-z]+&source=[^\r\n&]+&q=[^\r\n&]+/msi";)

MD5:

mini:

185C8FFA99BA1E9B06D1A5EFFAE7B842 2F3259F58A33176D938CBD9BC342FDDD 217DAB08B62B6F892A7D33E05E7F788C 3387E820F0F67FF00CF0C6D0F5EA2B75 36DB67CCADC59D27CD4ADF5F0944330D 6548D3304E5DA11ED2BED0551C3D6922 72D272A8198F1E5849207BC03024922D 85B66824A7F2787E87079903F0ADEBDF B4FFAD760A52760FBD4CE25D7422A07B C461706E084880A9F0409E3A6B1F1ECD D0B4C0B43F539384BBDC103182E7FF42 E006469EA4B34C757FD1AA38E6BDAA72 E305B5D37B04A2D5D9AA8499BBF88940 E9CAB9097E7F847B388B1C27425D6E9A E9DA19440FCA6F0747BDEE8C7985917F F5022EAE8004458174C10CB80CCE5317

prescanner:

A802968403162F6979D72E04597B6D1F

core:

C15E18AFF4CDC76E99C7CB34D4782DDA 8643E70F8C639C6A9DB527285AA3BDF7

ibank.dll:

A6C032B192A8EDEF236B30F13BBFF204 4CB6CA447C130554FF16787A56A1E278 BFE73DE645C4D65D15228BD9A3EBA1B6 CC891B715C4D81143491164BFF23BF27

module_vnc:

601F0691D03CD81D94AD7BE13A10A4DB 6E5ADF6246C5F8A4D5F4F6BBFC5033B9 78EDD93CEA9BEDB90E55DE6D71CEA9C4

w3bank.dll:

1B84E30D4DF8675DC971CCB9BEE7FDF5

Похожие работы:

«СОДЕРЖАНИЕ Лист регистрации изменений.............. 3 Общие указания.................. 5 Меры предосторожности................ 6 Технологическая карта № 1. Осмотр спасательного каната....... 8 Технологическая карта.К" 2. Осмотр аварийных топоров....... 9 Технологиче...»

«СПЕЦВЫПУСК "ДОСЬЕ 02" – ВЫБОРЫ-2011 5 11.11.11 №43 ВЫБОРЫ2011 СВЕДЕНИЯ О ПОСТУПЛЕНИИ СРЕДСТВ В ИЗБИРАТЕЛЬНЫЕ ФОНДЫ РЕГИОНАЛЬНЫХ ОТДЕЛЕНИЙ ПОЛИТИЧЕСКИХ ПАРТИЙ И РАСХОДОВАНИИ ЭТИХ СРЕДСТВ (выборы депутатов Государственной Думы Федерального Собрания Российской Федерации шестого созыва) По состоянию на 9 ноября 2011 года на специальные избирательные счета...»

«Филиал "Ивановский" тел. +7 (4932) 304 533, 300 941 ПАО "Т Плюс" факс +7 (4932) 303 920 ул. Суворова, д. 76, ivn.secretary@ies-holding.com г. Иваново, 153012 www.tplusgroup.ru 19.11.2015 № 50200-06-30/183 на № от Извещение о проведении открытого запроса цен Уважаемые господа!1. Предмет ОЗЦ: В цел...»

«экспозиции ВЫСТАВКИ "Янтарная каюта. Путешествие натуралиста продолжается." Из фондов Музея Мирового океана. Видеосалон НИС "Витязь" Лучшие фотографии Арктики НИС "Витязь". "Сердце корабля" про...»

«1 Приложение 1 к Порядку заключения договоров на комплексное обслуживание на рынке ценных бумаг путем присоединения к Типовым условиям предоставления ОАО "БПС-Сбербанк" комплексных услуг по брокерскому обслуживанию на рынке ценных бумаг № 01-07/12 от 25.0...»

«Пермское отделение Межрегиональной общественной организации Евро-Азиатское геофизическое общество Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования "Пермский...»

«СОДЕРЖАНИЕ: ВВЕДЕНИЕ ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ НАЛОГА НА ДОБАВЛЕННУЮ СТОИМОСТЬ НДС по российскому законодательству 1.1.1.2. Налоговая нагрузка и необходимость налоговой оптимизации ГЛАВА 2. АНАЛИЗ ПЛАТЕЖЕЙ ПО НДС В ООО "ЮНИКОН" 2.1. Динамика изменения выручки и НДС 2.2. Анализ налоговой нагрузки ГЛАВА 3. ПУТИ СНИЖЕНИЯ ПЛАТЕЖЕЙ ПО НДС В ООО "ЮНИКОН"...»

«Содержание Введение Схема сети Оптимальный путь Типы версий таблицы Начальный номер версии таблицы Условия для разнообразия в версии таблицы BGP Использование версии таблицы Использование для устранения проблем Введение Этот документ описывает Версию таблицы, которая является номером...»

«Технологическая карта HEMPADUR 45141/ HEMPADUR 45143 45141: ОСНОВА 45148 с ОТВЕРДИТЕЛЕМ 97820 45143: ОСНОВА 45148 с ОТВЕРДИТЕЛЕМ 97430 Описание: HEMPADUR 45141/45143 – двухкомпонентная, отверждаемая полиамидным аддуктом,...»

«УТВЕРЖДЕНО приказом Председателя Правления НКО ЗАО НРД от 21 декабря 2015 г. № 312 Изменения и дополнения в Перечень документов, которые предоставляют и получают Участники клиринга в соответствии с Правилами клиринга Небанковской кред...»

«ОТЧЕТ по результатам проверки использования средств бюджета Республики Татарстан, выделенных на обеспечение функционирования и выполнение государственного задания специальными (коррекционными) школамиинтернатами Министерства образования и науки РТ за 2011-2012 годы Основание для проведения проверки: план работы Счетно...»

«Арбитражная практика: ТАК КАКИМ ЖЕ ПЕРЕЧНЕМ ПОЛЬЗОВАТЬСЯ АКЦИОНЕРНЫМ ОБЩЕСТВАМ? Наталья Храмцовская к.и.н., ведущий эксперт по управлению документацией компании "ЭОС", член Гильдии Управляющих Документацией и ARMA International Вопрос о том, каким "Перечнем типовых управленческих документов с указанием сроков хранения" ну...»

«Броски Пятая неделя ЭТОТ БЛОК УРОКОВ ВКЛЮЧАЕТ В СЕБЯ игры и упражнения, способствующие развитию у детей способности бросать, выносливости, силы, контроля над телом, а также ориентации в пространстве. www.specialolympics.org/youngathletes Краткий обзор В плане зан...»

«Борис Рогинский ПЕРЕГОВОРЩИК "Выходи по одному и бросай оружие на снег!. А теперь Горбатый! Я сказал: Горбатый!", — иного разговора с бандитами быть не может. Так это представлялось по советским фильмам. Профессия переговорщика сделалась известной по западным детективам. Если хочешь сохранить жизнь заложникам, с преступника...»

«Религия и наука в XIX — начале XX века: конфликты и компромиссы Бернард  Лайтман "Тезис о конфликте" и научный натурализм Bernard Lightman The “Conflict Thesis” and Scientific Naturalism Bernard Lightman — York University (Toronto, Ca...»

«ПЛЕНУМ ВЕРХОВНОГО СУДА РОССИЙСКОЙ ФЕДЕРАЦИИ ПОСТАНОВЛЕНИЕ от 16 октября 2009 г. N 19 О СУДЕБНОЙ ПРАКТИКЕ ПО ДЕЛАМ О ЗЛОУПОТРЕБЛЕНИИ ДОЛЖНОСТНЫМИ ПОЛНОМОЧИЯМИ И О ПРЕВЫШЕНИИ ДОЛЖНОСТНЫХ ПОЛНОМОЧИЙ В связи с вопросами, возникающими у судов по делам о злоупотребле...»

«Курс ACI 3: медитация в соответствии с тибетской традицией Второй этап в изучении Лам Рим Но основе уроков Геше Майкла Роуча Перевод, редакция, и подача Ламы Дворы-ла Рамат-Ган, март 2007 Урок 6 Проблемы медитации, и их исправление – часть 2 (Мандала) (Прибежище) Мы продолжаем с проб...»

«из архивных фондов Дагестана, дан обзор собственного сочинения М.-З. Камалова "Табсират ал-муршидин.",...»

«WWW.ENU.KZ Э.Р. Тагиров г. Казань, Татарстан ОБРАЗ "ЕВРАЗИЙСКОГО ПРОМЕТЕЯ" – Л.Н.ГУМИЛЕВА В ПРЕДСТАВЛЕНИИ НАРОДОВ МИРА Гении никогда не рождаются случайно. Их характер, ум, талант и мировоззренческая система оттачиваются на стыке яростно отбивающегося, но приговоренного к н...»

«Мониторинг регуляторной среды — 20–27 февраля 2017 года Подготовлен Институтом проблем естественных монополий (ИПЕМ) Исследования в областях железнодорожного транспорта, ТЭК и промышленности Тел.: +7 (495) 690-14-26, www.ipem.ru Президент и Правительство 20.02.2017. В. Путин встретился с ректором Академии народного хозяйства и го...»









 
2017 www.lib.knigi-x.ru - «Бесплатная электронная библиотека - электронные матриалы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.