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

Хронология

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

  • все рассылки производились в разгар рабочего дня (часовой пояс 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.

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

Тебе приходилось сталкиваться с APT?

Загрузка ... Загрузка ...
 

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

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

  • 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-апплета
Base64 encoded фрагмент, предназначенный для скачивания вредоносного Java-апплета

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

Содержимое вредоносного jar-файла
Содержимое вредоносного jar-файла


Выданный хакерам сертификат
Выданный хакерам сертификат
 

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

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

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

После извлечения 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-запроса для получения загрузчика модулей
main.dll — формирование HTTP-запроса для получения загрузчика модулей

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Подписаться
Уведомить о
6 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии