Социальная инженерия. Атака на Сбербанк

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

Хронология.

Как все было организовано? Общая хронология зафиксированных атак:

все рассылки производились в разгар рабочего дня (часовой пояс UTC+3);
первая атака — последняя неделя декабря 2017 года;
вторая атака — вторая рабочая неделя 2018 года;
третья атака — третья рабочая неделя 2018 года.

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

Почему мы объединили все события:

списки рассылок совпадали с точностью 85%;
все письма были грамотно написаны на русском языке;
механизмы и инструменты, использовавшиеся в атаках, имели незначительные различия;
все письма имели идентичную структуру и были отправлены с помощью почтового сервера Exim 4.80;
использовались сертификаты, выписанные удостоверяющими центрами Comodo CA Ltd., Digicert, Inc. Указанные в сертификатах компании, которым они были выданы: Dazzle Solutions Ltd., Bright Idea Enterprise Ltd.;
использовалось два способа распространения вредоносного ПО: ссылка в письме, ведущая на исполняемый jar-файл; вложенный файл, эксплуатирующий опубликованную уязвимость CVE-2017-11882.

Природа атак. Разбор писем.

Рассылка писем производилась с доменов:

billing-cbr[.]ru
bankosantantder[.]com
oracle-russia[.]info
cards-nspk[.]ru
regdommain[.]com

Доменные имена регистрировались незадолго до проведения атак. Были установлены несколько успешных попыток подделки адреса отправителя письма. Анализ структуры писем показал, что все письма были отправлены с помощью почтового сервера Exim 4.80.

Структура фишинговых писем — text/html, кодировка — quoted-printable UTF-8.

Заголовки, описывающие структуру фишингового письма

Природа атаки. Первый этап атаки — вредоносный URL.

Все адреса, указанные в письмах, вели на страницы, в HTML-коде которых инициализировалась загрузка вредоносного Java-апплета signed.jar. Помимо этого, страницы содержали закодированные в Base64 фрагменты исполняемого кода, предназначенного для скачивания вредоносного ПО. Данная функциональность также дублировалась в Java-апплете.

Base64 encoded фрагмент, предназначенный для скачивания вредоносного Java-апплета

Фактически, когда жертва переходила по ссылке, запускался signed.jar. Поскольку jar-файл подписан действительным сертификатом, выданным Comodo CA Ltd. / Digicert, Inc., он проходил проверку настроек безопасности Java-машины. Стоит отметить, что при использовании параметров Java по умолчанию для запуска апплета требуется подтверждение пользователя. Наиболее простой способ запретить запуск апплетов в привилегированном режиме — отключить опцию Allow user to grant permissions to signed content в настройках Java.

Динамическая библиотека main.dll/main64.dll

Вредоносное ПО было разработано с применением механизмов Java Native Interface (JNI), позволяющих осуществлять вызов нативного кода из Java-машины и наоборот. Во время исполнения jar-апплета определялась разрядность ОС с последующим извлечением необходимой динамической DLL-библиотеки:

main.dll для ОС семейства Windows разрядности х86;
main64.dll для ОС семейства Windows разрядности x64.

После извлечения main.dll/main64.dll сохраняется на диск и запускается на исполнение с помощью функции System.load() в контексте виртуальной машины Java. Код из main.dll/main64.dll динамически получает адреса функций Windows API для работы с HTTP-протоколом из библиотеки wininet.dll, обращается к URL hxxps://servicenetupdate[.]com/yroyiuymsa, загружает и расшифровывает расположенный по этому адресу файл int.dll (для расшифровки использовался алгоритм XOR с обратной связью), после чего управление передается расшифрованному коду.

main.dll — формирование HTTP-запроса для получения загрузчика модулей

Природа атаки. Первый этап атаки — вредоносное почтовое вложение.

Вредоносное ПО распространялось через почтовое вложение, в некоторых случаях прямой URL на RTF-файл hxxp://oracle-russia.info/Oracle_RDBMS.rtf (3-я атака).

Если файл открывали, а необходимых обновлений не было, это вело к эксплуатации известной с ноября 2017 года уязвимости в модуле редактора формул (CVE-2017-11882). Исполнялся компонент вредоносного ПО в виде scr-файла, содержавшего .NET-скрипт, который загружал PowerShell-сценарий.

В ходе детального анализа scr-файла было установлено, что его содержимое зашифровано с помощью побитового алгоритма XOR с байтовым ключом 0xА5.

Вредоносный PowerShell-сценарий после снятия побитового XOR с ключом 0xA5

Фрагмент в формате Base64, модифицированном, чтобы усложнить разбор

Бинарный код, извлеченный из Base64-фрагмента, отвечавший за получение загрузчика модулей

После исполнения PowerShell-сценария создавалось SSL-соединение с узлом hxxps://teredo-update.com (3-я атака) и затем скачивался загрузчик модулей int.dll.

Природа атаки. Второй этап атаки — загрузчик модулей

Файл int.dll, получаемый в результате как первого, так и второго способов атаки, — это исполняемый файл Windows PE32 (DLL), предназначенный для загрузки других модулей вредоносного ПО с сервера управления. В качестве адреса сервера управления во время первой атаки использовался URL hxxps://help-desc-me[.]com/<псевдослучайная строка из ASCII-символов в нижнем регистре>/.

С периодичностью в одну секунду загрузчик модулей обращался к серверу управления по протоколу HTTP посредством GET-запросов. В случае получения HTTP-ответа с кодом 200 загружались зашифрованные модули и дешифровывались. После этого загрузчик запускал их в контексте своего процесса — это весьма распространенный метод затруднить детектирование вредоносного ПО. Результаты работы модулей отправлялись на сервер управления с помощью метода HTTP POST.

Загрузчик использовал достаточно оригинальный способ шифрования — бинарные данные, содержавшие загружаемые модули, были представлены в формате human readable content.

Human readable фрагменты, содержавшие дополнительный модуль вредоносного ПО

Часть кода загрузчика, отвечающая за декодирование получаемой нагрузки

В ходе динамического анализа на протяжении проводимых атак удалось получить три загружаемых модуля:

исполняемый файл формата Windows PE (DLL) — модуль для создания скриншотов, загружается каждый раз, когда с управляющего сервера поступает задача сделать скриншот;
исполняемый файл формата Windows PE (DLL) — модуль для получения списка запущенных процессов (имена исполняемых файлов и пути к ним). После выполнения отправляет данные обратно на управляющий сервер;
полезная нагрузка Cobalt Strike Beacon версии 3.8, выдаваемая только в случае принятого хакерами положительного решения на основе полученной информации о зараженной системе.

Код получения списка запущенных процессов

Атака через вредоносный URL в письме, ведущий на исполняемый jar-файл

Общая схема атаки.

В результате анализа установлена общая схема атак.

Атака через вложенный файл, эксплуатирующий уязвимость CVE-2017-11882

Серверы C&C № 1 использовались хакерами для размещения загрузчика модулей, скачиваемого в момент второго этапа атаки. C&C № 2 — реальные управляющие серверы для удаленного взаимодействия. Также они использовались для передачи дополнительных модулей, предназначавшихся для дальнейшего потенциального распространения в сети жертвы.

Список C&C-серверов:

servicenetupdate[.]com
bankosantantder[.]com
oracle-russia[.]info
help-desc-me[.]com
billing-cbr[.]ru
teredo-update[.]com
techupdateslive[.]com
getfreshnews[.]com

Изменения по ходу повторного проведения атак.

Первая и вторая атаки:

Main.class — строковые константы обернуты в Base64;
main.dll — изменен ключ кодирования;
int.dll — заменена полезная нагрузка и ключ кодирования;
появился второй способ распространения через RTF-файл (CVE-2017-11882).

Вторая и третья атаки:

int.dll — заменена полезная нагрузка и ключ кодирования;
в тело фишингового письма добавлена прямая ссылка на scr-файл.

Заключение.

Без подобных исследований невозможно выстроить надежную систему защиты, так как современные средства не справляются с таргетированными атаками. Внутри Службы кибербезопасности нам удалось выстроить процессы, позволяющие проводить детальный анализ кибератак и вредоносов. В рамках Security Operation Center работают команды Threat Intelligence, Forensics и RedTeam. Внутри SOC аккумулируются индикаторы компрометации, полученные благодаря взаимодействию с организациями-партнерами, такими как Bizone и ГосСОПКА. И эта система уже не раз доказала свою эффективность.

В конце прошлого года мы стали свидетелями начала нового этапа атак на финансовые организации России. Нельзя сказать, что количество атак резко увеличилось, но можно однозначно отметить, что их технический уровень растет — публикуемые уязвимости в кратчайшее время принимаются на вооружение хакерами. Помимо этого, фишинговые рассылки все чаще имеют признаки целенаправленных и тщательно подготовленных действий, а на замену изученным и известным методам злоумышленников приходят обновленные инструменты и механики. Компетенции наших специалистов позволяют осуществлять детальный разбор вредоносного кода с применением средств статического и динамического анализа, а также своевременно изучать и осваивать новые подходы хакеров. Это противостояние никогда не прекратится, но к нему можно быть подготовленным — это то, к чему мы стремимся и ради чего делимся нашим опытом.

Источник