Содержание
1 Хронология атак
2 Разбор писем
3 Вредоносный URL
4 Динамическая библиотека main.dll/main64.dll
5 Вредоносное почтовое вложение
6 Загрузчик модулей
7 Общая схема атаки
8 Изменения по ходу повторного проведения атак
9 Итого
Накануне праздников мы все с головой погружаемся в задачи, которые нужно успеть завершить, бдительность офисных работников притупляется, и это на руку хакерам. Недавно мы столкнулись с серией кибератак на компании финансового сектора России, в том числе и Сбербанк. На первый взгляд, это были привычные фишинговые рассылки на адреса банковских сотрудников. Но детальный разбор и анализ выявили постоянно эволюционирующую целенаправленную атаку.
Хронология атак
Как была организована атака? Общая хронология зафиксированных атак:
Почему мы объединили все события:
Разбор писем
Рассылка писем производилась с доменов:
Заголовок агента фишингового письма
Структура фишинговых писем — 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.
Содержимое вредоносного jar-файла
Выданный хакерам сертификат
Динамическая библиотека main.dll/main64.dll
Вредоносное ПО было разработано с применением механизмов Java Native Interface (JNI), позволяющих осуществлять вызов нативного кода из Java-машины и наоборот. Во время исполнения jar-апплета определялась разрядность ОС с последующим извлечением необходимой динамической DLL-библиотеки:
Метод 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-запроса для получения загрузчика модулей
Вредоносное почтовое вложение
Вредоносное ПО распространялось через почтовое вложение, в некоторых случаях прямой 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 фрагменты, содержавшие дополнительный модуль вредоносного ПО
Часть кода загрузчика, отвечающая за декодирование получаемой нагрузки
В ходе динамического анализа на протяжении проводимых атак удалось получить три загружаемых модуля:
Код получения скриншота экрана
Код получения списка запущенных процессов
Атака через вредоносный URL в письме, ведущий на исполняемый jar-файл
Общая схема атаки
В результате анализа установлена общая схема атак.
Атака через вложенный файл, эксплуатирующий уязвимость CVE-2017-11882
Серверы C&C № 1 использовались хакерами для размещения загрузчика модулей, скачиваемого в момент второго этапа атаки. C&C № 2 — реальные управляющие серверы для удаленного взаимодействия. Также они использовались для передачи дополнительных модулей, предназначавшихся для дальнейшего потенциального распространения в сети жертвы.
Список C&C-серверов:
Первая и вторая атаки:
Без подобных исследований невозможно выстроить надежную систему защиты, так как современные средства не справляются с таргетированными атаками. Внутри Службы кибербезопасности нам удалось выстроить процессы, позволяющие проводить детальный анализ кибератак и вредоносов. В рамках Security Operation Center работают команды Threat Intelligence, Forensics и RedTeam. Внутри SOC аккумулируются индикаторы компрометации, полученные благодаря взаимодействию с организациями-партнерами, такими как Bizone и ГосСОПКА. И эта система уже не раз доказала свою эффективность.
В конце прошлого года мы стали свидетелями начала нового этапа атак на финансовые организации России. Нельзя сказать, что количество атак резко увеличилось, но можно однозначно отметить, что их технический уровень растет — публикуемые уязвимости в кратчайшее время принимаются на вооружение хакерами. Помимо этого, фишинговые рассылки все чаще имеют признаки целенаправленных и тщательно подготовленных действий, а на замену изученным и известным методам злоумышленников приходят обновленные инструменты и механики.
1 Хронология атак
2 Разбор писем
3 Вредоносный URL
4 Динамическая библиотека main.dll/main64.dll
5 Вредоносное почтовое вложение
6 Загрузчик модулей
7 Общая схема атаки
8 Изменения по ходу повторного проведения атак
9 Итого
Накануне праздников мы все с головой погружаемся в задачи, которые нужно успеть завершить, бдительность офисных работников притупляется, и это на руку хакерам. Недавно мы столкнулись с серией кибератак на компании финансового сектора России, в том числе и Сбербанк. На первый взгляд, это были привычные фишинговые рассылки на адреса банковских сотрудников. Но детальный разбор и анализ выявили постоянно эволюционирующую целенаправленную атаку.
Хронология атак
Как была организована атака? Общая хронология зафиксированных атак:
- все рассылки производились в разгар рабочего дня (часовой пояс 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
Заголовок агента фишингового письма
Структура фишинговых писем — 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.
Содержимое вредоносного 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
После извлечения 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 и ГосСОПКА. И эта система уже не раз доказала свою эффективность.
В конце прошлого года мы стали свидетелями начала нового этапа атак на финансовые организации России. Нельзя сказать, что количество атак резко увеличилось, но можно однозначно отметить, что их технический уровень растет — публикуемые уязвимости в кратчайшее время принимаются на вооружение хакерами. Помимо этого, фишинговые рассылки все чаще имеют признаки целенаправленных и тщательно подготовленных действий, а на замену изученным и известным методам злоумышленников приходят обновленные инструменты и механики.
