Cobalt: обновление тактик и инструментов

Специалисты PT Expert Security Center отслеживают активность группы Cobalt с 2016 года. На сегодняшний день группа атакует финансовые организации по всему миру. Ущерб от этих атак уже год назад превышал 1 млрд рублей. За последние четыре года мы опубликовали несколько отчетов об атаках, связанных с данной группой.

В течение прошлого года группа Cobalt не только модифицировала свои основные инструменты CobInt и COM-DLL-дроппер в связке с JavaScript-бэкдором more_eggs, но и применяла новые способы доставки и новые техники для обхода средств защиты на начальном этапе атаки. Обновление тактик и инструментов может быть обусловлено тем, что группа уже долгое время находится под прицелом у исследователей со всего мира, и ей необходимо быть на шаг впереди, чтобы обходить средства защиты.

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

Если взглянуть на следующую гистограмму, то можно заметить, что к концу прошлого года группа начала отдавать предпочтение использованию CobInt.

Это может быть связано c детектированием трафика JavaScript-бэкдора more_eggs сетевыми сигнатурами ETPRO, в том числе и в публичных песочницах, в то время как срабатывания на трафик CobInt отсутствуют. К тому же CobInt загружает основную библиотеку с контрольного сервера сразу в память, а COM-DLL-дроппер сохраняет на диск обфусцированный more_eggs, который затем исполняется в памяти. Следовательно, COM-DLL-дроппер оставляет больше следов на зараженной машине.

1. Фишинговый сайт European Central Bank

В конце августа 2019 года, исследуя угрозы информационной безопасности, мы зафиксировали атаку с использованием CobInt. Атака, предположительно, была нацелена на европейские финансовые организации. У нас нет данных о том, насколько она была успешна. Дроппером для CobInt служил кастомный NSIS-installer. Мы обнаружили три версии такого дроппера: для Chrome, Firefox и Opera. Внутри каждого была одна и та же версия CobInt и соответствующий установщик для браузера. После запуска дроппер сохранял CobInt в папку %TEMP%, запускал его и установщик. Проанализировав ВПО мы выяснили, что распространение дропперов происходило с фишингового сайта ecb-european[.]eu.

Сайт являлся копией сайта Европейского центрального банка — за исключением того, что при его посещении пользователю показывалось всплывающее окно с просьбой обновить браузер.

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

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

Ниже представлены альтернативные окна, которые присутствуют в скрипте.

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

Данный фреймворк не является уникальным. Скорее всего, он был приобретен группой на одном из теневых форумов. Так, специалисты из Zscaler в ноябре 2019 года опубликовали статью о том, что похожим образом распространялся NetSupport RAT. Фреймфорк размещался на взломанных сайтах и при их посещении пользователям показывалось одно из всплывающих окон.

С сайта ecb-european[.]eu также распространялся вредоносный файл Login_Details.img, детальный разбор которого сделали коллеги из Group-IB.

2. Вредоносный VHD

В конце декабря 2019 года мы обнаружили очередной загрузчик CobInt группы Cobalt. Необычным был контейнер, в котором содержался данный загрузчик. Это был virtual hard disk (VHD), который, предположительно, рассылался по почте.

VHD-формат был создан компанией Connectix для их продукта Virtual PC, в 2003 году продукт был приобретен компанией Microsoft и стал называться Microsoft Virtual PC. В 2005 году формат стал общедоступным. VHD-формат используется с момента создания технологии виртуализации Hyper-V. VHD-файл может содержать все, что можно найти на обычном HDD: дисковые разделы, файловую систему с папками и файлами.

Начиная с Windows 7 пользователь может вручную подключить VHD, например через MMC-консоль. Начиная с Windows 8 пользователь может подключить VHD просто два раза кликнув на него мышкой, и он отобразится в системе как обычный диск.

В сентябре 2019 года в блоге CERT/CC вышла статья об опасности VHD-файлов и об использовании их как потенциального вектора в атаках . Will Dorman показал, что ни антивирусы, ни mark on the web не будут сигнализировать пользователю о том, что содержимое скачанного из интернета VHD-файла может нанести вред компьютеру. Исследователь создал вредоносный VHD-контейнер с EICAR внутри и загрузил его на VirusTotal, однако ни один антивирус не сработал. Низкое количество вердиктов или их отсутствие может быть связано с тем, что VHD является ключевым файлом при работе виртуальной машины в Hyper-V, и если он будет поврежден или заблокирован, виртуальная машина не запустится.

В документации, Microsoft рекомендует добавлять файлы формата VHD в исключения антивирусов, как это уже автоматически сделано в Windows Defender. Это нужно именно для того, чтобы не возникало ошибок в работе Hyper-V.

Не исключено, что результатами этого исследования воспользовалась группа Cobalt. Их VHD-файл также не детектировался антивирусами в момент его появления на VirusTotal. Спустя полгода этот файл детектируется всего одним антивирусом: это очень низкий показатель.

Внутри VHD находятся два файла CobInt. К концу одного из файлов прикреплены два невалидных сертификата Google для снижения вероятности обнаружения средствами защиты.

Поскольку VHD, по сути, представляет собой контейнер с файловой системой, в нем также можно искать различные артефакты. Например, в неразмеченном пространстве VHD-файла мы обнаружили изображение с текстом якобы от антифрод-системы банка HSBC.

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

2.1. Анализ CobInt

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

Основная библиотека загружается CobInt с контрольного сервера в виде HTML-файла. В сравнении с алгоритмом, описанным компанией ProofPoint в 2018 году , есть некоторые изменения.

В начале удаляются все теги, их содержимое игнорируется.

На втором этапе обрабатываются символы точки, запятой и пробела. Все символы, стоящие после указанных, переводятся в верхний регистр (вычитается значение 0x20).

Затем данные декодируются из Base64, после чего производится дешифрование XOR с 4-байтным ключом, который на каждой итерации инициализируется предыдущим значением дешифрованных данных. Кроме того, на каждой итерации происходит вычитание текущих для раунда дешифрования четырех байтов данных из данных предыдущего раунда, после чего ключом будет 4-байтное значение входного буфера предыдущего раунда.

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

Данные после декодирования из Base64 показаны на рис. 16. Красным отмечена 4-байтная предустановка для первого дешифровщика, которая в неизменном виде будет и на втором этапе, а желтым остальные данные.

После дешифрования получим другую картину (рис. 17). Наглядно виден ключ шифрования из-за наличия больших нулевых серий в исполняемом файле, после шифрования содержащие гамму в чистом виде.

После второго дешифрования получаем валидный PE-файл (рис. 18). Назначение первых восьми байтов выяснить не удалось, в загрузчике они никак не используются.

2.2. Анализ основной библиотеки

После создания события и инициализации необходимых параметров происходит дешифрование домена. Затем вызывается функция генерации остальной части адреса.

После создания полного адреса контрольного сервера библиотека дешифрует необходимые параметры для создания HTTP-полей и добавляет их в формируемый запрос, после чего отправляет его на сервер. В ответ с сервера приходят плагины, которые библиотека подгружает в свое адресное пространство методом reflectiveloader.

2.3. Дешифрование плагинов

Как и основная библиотека, плагины присылаются сервером в виде HTML-страниц. Первый этап преобразования входных данных достаточно похож на те, что были при передаче библиотеки. Отличием является то, что точки, запятые и пробелы игнорируются, а все символы переводятся в нижний регистр.

После первичного преобразования происходит декодирование полученных данных из алфавита a—z в символы 0x00—0xff. Для этого применяется ранее не встречавшаяся процедура декодирования, основанная на преобразовании входных значений в зависимости от текущего значения, предыдущего (в некоторых случаях) и значений глобального счетчика.

После декодирования происходят два цикла дешифрования.

Ключ для первого дешифрования находится в коде приложения, при этом он жестко зашит по смещению, которое принимает только два значения.

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

На последнем этапе происходит дешифрование с 4-байтным ключом, который также несложно получить путем анализа нулевых последовательностей PE-заголовка.

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

2.4. Дешифрование трафика

Собранные плагинами данные библиотека отправляет на сервер.

Пример трафика:

Преобразование трафика начинается с его шифрования случайно сгенерированным ключом произвольной длины. Данный ключ вставляется в пакет с указанием его длины.

Далее полученные данные шифруются вшитым 64-байтным ключом, тем же, которым дешифровывалась библиотека. После этого на данные накладывается рассмотренная ранее кодировка, в начало добавляется знак = и сгенерированная последовательность из символов a—z длины от 8 до 16.

Пример декодированного и дешифрованного трафика, полученного из предыдущего пакета:

Функция создания и преобразования пакета:

3. BIFF-макрос

В марте 2020 года мы зафиксировали документ группы Cobalt в формате XLS, который скачивал и запускал COM-DLL-дроппер. Документ содержал в себе достаточно старый формат макроса Excel 4.0 и практически не определялся антивирусами (1 вердикт из 60 по данным сервиса VirusTotal).

Этому стандарту макросов уже 20 лет. Его особенность в том, что макрос не хранится в VBA-проекте, он расположен в ячейках страницы, при этом страница может быть скрыта в самом Excel. Это значит, что макрос будет не в VBA-стриме, а в BIFF-записи (Binary Interchange File Format).

Если открыть документ в Excel, то мы увидим лишь одну страницу и отсутствие макросов в VBA-проекте. Однако Excel все равно обнаружит наличие макроса и заблокирует его исполнение. Для того чтобы обнаружить макрос, можно использовать утилиту olevba3.py из набора oletools.

В результате выполнения мы видим, что одна из страниц документа имеет состояние very hidden и имеет тип Excel 4.0 macro. При таком состоянии страницы вы не только не увидите ее в интерфейсе Excel, но и никак не сможете ее сделать видимой через интерфейс. Сделать видимой ее поможет либо Visual Basic, либо ручное модифицирование байтов документа.

Чтобы распознать структуру BIFF в удобном представлении, можно использовать утилиту BiffView . Распарсив исходный документ, увидим, что одна из страниц с названием sygfdfdfdesie имеет аттрибут very hidden. В Hex-редакторе изменяем этот параметр либо на 1, либо на 0.

Открыв исходный документ в менеджере формул, мы увидим, что одна из формул запускается автоматически при открытии документа.

Начальная формула запускает большую цепочку команд СЦЕПИТЬ, ВЫПОЛНИТЬ, СИМВОЛ, ВЫЗВАТЬ, что в конечном итоге приведет к загрузке и запуску COM-DLL-дроппер. Вся цепочка команд разбросана по огромному полю ячеек страницы Excel, что затрудняет анализ.

4. Анализ COM-DLL-дроппера

В начале апреля 2020 года мы обнаружили новую версию COM-DLL-дроппера. По функциям он отличался от всех, что мы видели ранее. Однако полезная нагрузка в виде JavaScript-бэкдора more_eggs осталась такой же.

COM-DLL-дроппер появился в арсенале Cobalt летом 2017 года и до сих пор используется группой для доставки JavaScript-бэкдора more_eggs, который содержится в нем в зашифрованном и заархивированном виде.

Особенности дроппера:

• Полностью написан на PureBasic.
• Использует большое число различных техник антианализа.
• Содержит в себе зашифрованные и заархивированные JavaScript-загрузчик, JavaScript-бэкдор, легитимную утилиту преобразования командной строки для запуска JavaScript-бэкдора more_eggs.
• Имеет встроенный обфускатор для зашитого внутрь JavaScript-бэкдора и JavaScript-загрузчика.

4.1. Внешнее устройство PE-файла

Все исследуемые экземпляры представляют собой PE-DLL-файлы, предназначенные для регистрации средствами regsvr32. Помимо экспортов, вызываемых regsvr32, каждый из образцов снабжен различными наборами экспортов, свойственных легитимным DLL-файлам. С помощью использования сторонних экспортов группа Cobalt пыталась замаскировать COM-DLL-дроппер. На рис. 32 можно увидеть статистику по самым популярным экспортам использовавшихся в файлах ВПО (всего 249 уникальных экспортов).

Данные экспорты содержат в себе, как правило, ничего не делающие заглушки. По названиям экпортов можно предположить, что злоумышленники пытались замаскировать дропперы под библиотеки медиаприложений. C 2019 года в ВПО появился экспорт DllInstall, который также вызывается с помощью regsvr32, и основной код дроппера был перемещен туда.

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

Для анализа необходимы две сущности — строки и массивы объектов. Строки в PureBasic хранятся в специальном буфере, выделяются и освобождаются практически без задействования системного API. На рис. 33 показан процесс выделения строки. При инициализации программы для строк создается отдельная куча через вызов HeapCreate().

Типичный шаблон для работы с этой сущностью такой:

1. Выделить строку в хранилище из константы.
2. Выполнить операции со строкой.
3. Обновить глобальную строку, обычно выделенную на куче. После завершения операции обновления индекс вершины сдвигается обратно. Таким образом, данная операция чем-то напоминает операцию pop().

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

Массивы объектов так подробно рассматривать не будем, достаточно сказать, что каждый массив хранит перед собой специальный заголовок, который содержит информацию о размере элемента, количестве элементов, а также о типе элементов. Заголовок занимает 18h байт, таким образом размер выделяемого пространства под массив объектов может быть рассчитан как размер элемента × количество элементов + 18h.

Завершая необходимые пояснения, дадим описания функций, которые встречаются на скриншотах далее.

Таблица 1

4.2. Антианализ

Для нахождения нужных API-функций используются нестандартные хеш-суммы от имен этих функций. Хеш-сумма реализуется как CRC32 от данных и последующий XOR с константой. Константы в семплах разные, поэтому в табл. 3 включены также CRC32-значения без XOR с константой.

В новой версии COM-DLL-дроппера cтроки зашифрованы алгоритмом RC4 (ранее использовался XOR).

Таблица 2. Техники, используемые в ВПО для затруднения анализа

Таблица 3. Различные строки и соответствующие им хеш-суммы, используемые в техниках

Брутфорс ключа для расшифровки строк не происходит полностью. В коде жестко прописан префикс, который занимает большую часть ключа. Окончание ключа — это число в десятичной форме записи. Таким образом, ключ = префикс + число.

4.3. JavaScript-генераторы

Дроппер в процессе работы создает два файла. Первый — это JavaScript-загрузчик, а второй — скриптлет, содержащий зашифрованный бэкдор more_eggs. Оба скрипта генерируются.

Общий шаблон генерации сохраняется среди образцов ВПО, изменяются данные, которые вставляются в него. Шаблон состоит из токенов и частей JavaScript, которые последовательно склеиваются. На рис. 35 можно видеть часть генерации JavaScript-загрузчика, а также примеры используемых частей JavaScript.

В генератор встроены несколько шаблонов обфускации:

• раздутие констант,
• генерация случайных имен для переменных,
• вставка шифрованных строк

Каждый генератор содержит в себе пул имен, которые генерируются перед началом создания скрипта, эти имена в дальнейшем используются в JavaScript. На рис. 35 можно видеть локальную переменную, которая называется lpbobj_arraywcs__JSObjectPool, а на рис. 36 — цикл инициализации этого пула.

Каждой доступное для использования в скрипте имя состоит из двух частей — случайный префикс, создаваемый один раз на весь скрипт, и случайное число в десятичной форме записи, ограниченное заданным количеством знаков. На рис. 37 можно видеть схему генерации имени и результат, получаемый в скрипте.

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

Полезная нагрузка вставляется в скрипт в закодированном с помощью RC4 и Base91 виде. Реализации RC4 и декодера Base91 также вставляются в скрипт.

4.4. Закрепление в системе

Дроппер в зависимости от имеющихся у него прав в системе закрепляется на зараженной машине несколькими разными способами:

• через Task Scheduler,
• через ключ реестра Environment\UserInitMprLogonScript,
• через ключ реестра Software\Microsoft\Windows\CurrentVersion\Run.

Для всех трех способов записываемое значение идентично и содержит в себе команду для запуска JavaScript-скрипта — загрузчика.

Для настройки таска, создаваемого дроппером, генерируется специальный XML-файл. Часть его хранится зашифрованной в дроппере, а часть генерируется в процессе работы.

Полученный XML-файл сохраняется со случайным именем, состоящим из шестнадцатеричных символов. Затем этот XML-файл передается в schtasks.exe как значение параметра «/XML».

4.5. Запуск полезной нагрузки

COM-DLL-дроппер сохраняет на диск три файла:

• обфусцированный JavaScript-загрузчик,
• обфусцированный JavaScript-бэкдор,
• легитимную утилиту преобразования командной строки для запуска JavaScript-бэкдора more_eggs.

Запуск основного бэкдора производится с помощью известной техники обхода AppLocker, использующей утилиту msxsl. Команды выглядит следующим образом:

• “C:\Users\\AppData\Roaming\Microsoft\msxsl.exe”
• “C:\Users\\AppData\Roaming\Microsoft\<имя_javascript_загрузчика>.txt”
• “C:\Users\\AppData\Roaming\Microsoft\<имя_javascript_бэкдора>.txt”

4.6. Функциональность JavaScript-бэкдора

Сохраненный на диск JavaScript-бэкдор, который нес в себе новый COM-DLL-дроппер, имеет версию 6.6.

Данный бэкдор используется группой с 2017 года, исполняется в памяти и всегда имеет низкое количество вердиктов антивируса.

Основные возможности бэкдора:

1. Шифрование трафика RC4 и Base91.
2. Выполнение команд от оператора (в этой версии команда more_eggs, по которой бэкдор получил свое название, отсутствовала):
• exec — загрузка и выполнение файла (.exe или .dll)
• gtfo — деинсталляция;
• more_onion — выполнить скрипт
• via_c — исполнить команду с помощью «cmd.exe /C»
• more_time — исполнить команду с помощью «cmd.exe / C», с сохранением результата во временный файл. После этого файл вычитывается, удаляется, а содержимое кодируется в Base64 и отправляется на сервер.
3. Проверка наличия в списке процессов системы антивирусов и исследовательского ПО путем сравнения CRC32 от имени процесса в нижнем регистре без расширения с заданными значениями внутри кода.
4. Сбор информации о системе:
• дата установки системы,
• IP-адрес зараженной машины,
• тип системы (серверная или стационарная),
• версия Windows (от XP до 10).

Заключение

Группа Cobalt продолжает атаковать финансовые организации по всему миру, берет на вооружение новые тактики, обновляет инструментарий и старается все более эффективно обходить средства защиты. Из-за карантина сейчас многие работники кредитно-финансовой сферы работают «на удаленке», вне досягаемости корпоративных средств защиты . К тому же многие злоумышленники используют тему коронавируса в своих атаках, как, например, группа Higaisa . Не исключено, что группа Cobalt попытается использовать эту тему в своих будущих атаках.

Индикаторы компрометации

Фишинг ECB

Контрольные серверы

ecb-european[.]eu

timeswindows[.]com

VHD

Контрольные серверы

telekom-support[.]info

45.80.69[.]34

BIFF

Контрольные серверы

download.sabaloo[.]com

origin.cdn77[.]kz

Новый COM-DLL-дроппер

Контрольный сервер

maps.doaglas[.]com

MITRE TTPs