Как взламывали Сбербанк

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

Еще по теме: Взлом банка через мобильное приложение

Хронология атак

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

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

Вредоносное почтовое вложение

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

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

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

После исполнения 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.

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

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

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

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

Серверы 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 и ГосСОПКА. И эта система уже не раз доказала свою эффективность.

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

ПОЛЕЗНЫЕ ССЫЛКИ:

• Способы взлома банковских карт
• Банковские трояны и защита от них
• Как хакеры крадут деньги с банковских карт