][-детектив: целевая атака на Сбербанк. Раскрываем подробности АРТ «Зловредный Санта-Клаус»

Содержание статьи

• Хронология
• Природа атак. Разбор писем
• Природа атаки. Первый этап атаки — вредоносный URL
• Динамическая библиотека main.dll/main64.dll
• Природа атаки. Первый этап атаки — вредоносное почтовое вложение
• Общая схема атаки
• Изменения по ходу повторного проведения атак
• Заключение

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

Хронология

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

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

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

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

Материалы из последних выпусков можно покупать отдельно только через два месяца после публикации. Чтобы продолжить чтение, необходимо купить подписку.

Подпишись на «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Уже подписан?

Источник