APT Cloud Atlas: Unbroken Threat

Введение

Специалисты Positive Technologies(PT Expert Security Center, PT ESC) отслеживают активность группы Cloud Atlas с мая 2019 года. По имеющимся у нас данным, ее атаки нацелены на правительственный сектор следующих стран:

• Россия;
• Беларусь;
• Азербайджан;
• Турция;
• Словения.

Цель группы — шпионаж и кража конфиденциальной информации.

В качестве исходного вектора в своих атаках группа традиционно использует фишинговые письма с вредоносным вложением.

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

О злоумышленниках стало известно еще в 2014 году, когда вышел отчет исследователей «Лаборатории Касперского», и с тех пор их инструмены практически не изменились (подробнее о них можно прочитать в пункте «Анализ ВПО»). Однако детального разбора и описания функционала данных инструментов до сих пор не было.

В отчете мы рассмотрим основные техники группировки Cloud Atlas, а также остановимся на инструментарии данной группы.

Анализ найденных документов

Как и в предыдущие годы, группа начинает свою атаку с рассылки фишинговых писем, используя в качестве текста-приманки актуальные геополитические проблемы, которые непосредственно связаны с атакуемой ими страной. Пример письма с вредоносным содержимым, которое рассылалось в рамках кампании в 2022 году, приведен на рисунке 1. Особое внимание стоит обратить на адрес отправителя: злоумышленники маскировались под известный в России и СНГ новостной портал Lenta.ru, однако почту с таким доменом позволяет создать Rambler (рисунок 2).

Чаще всего текст берется из СМИ или из общедоступных официальных документов. Также, к примеру, в 2019-м в атаке, нацеленной на Азербайджан, использовался текст, связанный с учениями «Нерушимое братство 2019» в Таджикистане, а в 2020-м при атаках на организации в Республике Беларусь — текст, связанный с выборами президента.

Пример документа, скачивающего вредоносный шаблон, представлен на рисунке 3 (ссылка на страницу с содержимым документа).

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

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

Шаблон уже может быть вредоносным — содержать макрос или эксплойт. Такой метод загрузки является легитимной функцией Microsoft Office, однако может использоваться и злоумышленниками. Эту же технику, к примеру, в своих атаках применяет группа Gamaredon.

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

Аналогичную цепочку доставки обнаружили исследователи из компании PaloAlto в 2018 году. При этих атаках в загружаемых RTF-шаблонах находился эксплойт для уязвимости CVE-2017-11882, а также простой powershell-бэкдор, который был назван PowerShower.

Особое внимание мы уделили документам формата .doc , использованным в рамках данной атаки: характерной особенностью всех документов с загрузкой вредоносного содержимого было наличие ссылки на вредоносное содержимое внутри потоков 1Table Stream или 0Table Stream (рисунок 9, выделено зеленым цветом).

После изучения DOC-формата и сравнения вредоносных документов с обычными мы нашли ряд закономерностей в зараженных файлах.

Во-первых, формат DOC предусматривает наличие в любом документе, наряду с потоком WordDocument Stream (который также обязательно должен присутствовать), потоков 1Table Stream или 0Table Stream (рисунок 6).

Во-вторых, каждый документ содержит специальную структуру FIB (File Information Block) — на рисунке 7 фрагмент выделен желтым цветом, — в которой есть параметр base.fWhichTblStm. По факту, установка данного бита в 0 или 1 определяет, какой из данных потоков в документе должен быть использован.

На рисунке 8 показана структура FIB, взятая из документации. Особое внимание стоит обратить на выделенную красным цветом структуру, в которой нас интересует бит G (выделен зеленым цветом) — это и есть base.fWhichTblStm.

Наконец, последнее, что мы выяснили: ссылки на вредоносные шаблоны располагаются всегда по примерно одним и тем же смещениям относительно hex-последовательностей внутри Table Stream (при этом сам формат потока нас интересовал куда меньше). На рисунке 9 желтым и красным цветом приведены последовательности байтов, на основании которых мы и высчитывали различные смещения до ссылки на вредоносный шаблон, что позволило нам достаточно эффективно детектировать применение данной техники в конкретной имплементации.

Анализ цепочек атак

В ходе нашего исследования мы выявили несколько цепочек атак (рисунок 10), которые отличались числом этапов загрузки основного функционала, а также используемыми инструментами на каждом из этапов. Тем не менее использование упомянутых цепочек для данной группы — не новинка.

Первое, что мы увидели: загрузка удаленным шаблоном rtf-документа с эксплойтом, который в свою очередь скачивает и запускает hta-файл, примерное содержимое которого приведено на рисунке 11.

Исследование документа, а также его содержимого показало, что для запуска полезной нагрузки эксплойта используется уязвимость в Equation Editor. Непосредственно шелл-код (выделен красным на рисунке 12) располагается внутри одного из объектов документа и исполняется в контексте процесса EQNEDT32.EXE.

Основная нагрузка шелл-кода хранится в зашифрованном виде и расшифровывается после передачи на него управления.

На рисунке 13 представлен расшифрованный вид шелл-кода: наглядно видны первые 13 байтов, которые отвечают за расшифрование основной части шелл-кода (оператор цикла расшифровывается на первой итерации). Для расшифрования применяется xor с двухбайтовым ключом, вшитым в код.

Непосредственно ссылка на hta-файл (по которой будет осуществляться загрузка) хранится в теле шелл-кода (рисунок 14) и дополнительно зашифрована однобайтовым xor со значением 0x12.

Как видно из рисунка 11, hta-файл предназначен для создания на диске vbs-скриптов с нагрузкой последующих этапов, а также lnk-файла с основной нагрузкой, содержащей код загрузки бинарных модулей. Соответственно, основной задачей vbs-макросов (в нашем случае оба макроса имели идентичные имена unbroken.vbs, а второй макрос имел дополнительное расширение *.vbs (unbroken.vbs.vbs)) является деобфускация и передача управления на содержимое lnk-файла (внешний вид приведен на рисунке 15), после чего происходит запуск загрузки, скачанной кодом lnk-файла (о которой речь пойдет в пункте «Анализ ВПО»).

Также стоит отметить, что вредоносные документы, эксплуатирующие те же уязвимости в Equation Editor и содержащие при этом идентичные имена объектов (к примеру, "weaseoijsd", на рисунке 16 выделено красным) в rtf-документах, были проанализированы специалистами из Cisco Talos Intelligence и отнесены к группировке Bitter APT.

Вторая цепочка, которую мы видели, — загрузка через удаленные шаблоны вредоносных powershell–скриптов (рисунок 17), которые в свою очередь загружают вредоносные компоненты (в большинстве своем закодированы base64).

Также нам встречались случаи промежуточного dotNet-загрузчика, который скачивал с удаленного сервера полезную нагрузку и передавал на нее управление.

Данный dotNet-загрузчик декодируется из кодировки Base64 и запускается powershell-скриптом (рисунок 18).

Экспорт (рисунок 19), вызываемый из загрузчика, принимает все необходимые параметры для сетевой коммуникации, в том числе и ключ шифрования соединения (выделен желтым на рисунке 18).

При этом коммуникация шифруется простым xor с переданным ключом (рисунок 20).

Анализ ВПО

Начальный модуль

Основная задача начального этапа — расшифрование и передача управления на загрузчик основного функционала. Стоит отметить, что все обнаруженные нами подобные образцы имеют достаточно большой размер и при этом обфусцированы. Загрузчик, в свою очередь, хранится исключительно в памяти процесса и на диске никаким образом не присутствует. Расшифрование загрузчика производится частями, однобайтовым xor с различными ключами (рисунок 21). Также бросается в глаза, что код расшифрования «разбавлен» различными операциями — очевидно, для усложнения поиска и идентификации процедур расшифрования данных.

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

Основной загрузчик

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

В самом начале загрузчик расшифровывает конфигурацию, которая находится в теле приложения. Алгоритм расшифрования (рисунок 23) — однобайтовый xor со вшитым ключом; также после расшифрования конфигурации происходит проверка ее валидности.

Отмечаем, что внешний вид конфигурации не изменился по сравнению с предыдущими исследованиями — содержит те же данные и параметры (рисунок 23).

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

И на данном этапе появляются первые отличия от более ранних образцов: для сокрытия нагрузки используется AES в режиме CBC, после чего данные разжимаются LZNT1 (раньше был LZMA).

Достаточно любопытен алгоритм, применяющийся для декомпрессии: данные разжимаются не единым байтовым массивом, а чанками различного размера. На рисунке 25 видно добавление смещения header_start_chunk к нулевому смещению каждого чанка (для первого из них — дополнительное смещение 4), после чего уже производится вызов функции декомпрессии.

Таким образом, структура, описывающая первый чанк в расшифрованной нагрузке, может быть представлена следующим образом:

    

	struct first_comprChunk
	{
		DWORD signature;
		WORD sizeOfCurrChunk; // in fact compressed buffer size
		BYTE data[sizeOfCurrChunk]; //compressed data
	} first_comprChunk, *pfirst_comprChunk;

	    
	

Соответственно, остальные чанки не имеют первого DWORD-поля и представляют собой следующую структуру:

    

	struct comprChunk
	{
		WORD compressedBuffSize;
		BYTE data[sizeOfCurrChunk];
	} comprChunk, *pcomprChunk;
	    
	

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

На заключительном этапе загрузчика происходит загрузка разжатых данных как валидного PE-образа, а также поиск нужного экспорта по имени ординала и передача на него управления (рисунок 26).

Полезная нагрузка

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

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

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

Структура, описывающая пакет и его внешний вид, приведена ниже (рисунок 27).

    

	struct Message
	{
		DWORD lenOfPacket;
		DWORD sizeOf_OSVERSIONINFO;
		BYTE data_OSVERSIONINFO[sizeOf_OSVERSIONINFO - 4];
		DWORD volumeInformation;
		BYTE timestamp[16]; // GetLocalTime
		WORD GetUserDefaultLCID;
		WORD GetSystemDefaultLCID;
		DWORD len_of_1_field;
		DWORD len_of_2_field;
		DWORD len_of_3_field;
		DWORD len_of_4_field;
		char username; //1_field
		char PcName; //2_field
		char executePath; //3_field
		char applicationName; //4_field
		char argvParam;
		DWORD lenOf_curr currFileSystem;
		char currFileSystem[lenOf_curr currFileSystem];
	} Message, *pMessage;
 
	

ВПО отправляет сформированный пакет на контрольный сервер, используя при этом для коммуникации COM-объект CLSID_IServerXMLHTTPRequest2 (рисунок 28).

Восстановленная таблица виртуальных методов данного объекта может быть описана следующей структурой:

    

	struct IServerXmlHttpRequest2Vtbl
	{
		int QueryInterface;
		int AddRef;
		int Release;
		int GetTypeInfoCount;
		int GetTypeInfo;
		int GetIDsOfNames;
		int Invoke;
		int open;
		int setRequestHeader;
		int getResponseHeader;
		int getAllResponseHeaders;
		int send;
		int abort;
		int get_status;
		int get_statusText;
		int get_responseXML;
		int get_responseText;
		int get_responseBody;
		int get_responseStream;
		int get_readyState;
		int put_onreadystatechange;
		int setTimeouts;
		int waitForResponse;
		int getOption;
		int setOption;
		int setProxy;
		int setProxyCredentials;
	} IServerXmlHttpRequest2Vtbl, *pIServerXmlHttpRequest2Vtbl;
	
	

Стоит отметить, что протокол коммуникации ВПО с сервером поддерживает пять типов запросов (рисунок 29), каждый из которых используется на определенном этапе коммуникации.

К примеру, после запроса PROPFIND, который установит содержимое директории на удаленном сервере, происходит GET-запрос с целью загрузки модуля, содержащегося на контрольном сервере. Что любопытно, в случае успешной загрузки данный модуль будет удален (рисунок 30).

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

Для обфускации данных используются те же процедуры, что и для извлечения полезной нагрузки загрузчиком: шифрование AES-CBC и сжатие LZNT1.

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

В ходе исследования нам удалось получить образец, который ВПО загружает с контрольного сервера (примеры содержимого сервера на рисунках 32, 33).

Загруженный модуль расшифровывается и разжимается (рисунок 34), а также размещается в памяти как PE-образ идентично тому, как это делает загрузчик. Стоит также отметить, что имя ординала, по которому ищется нужный для вызова экспорт, идентично тому, которое используется для передачи управления полезной нагрузке.

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

В частности, злоумышленников интересуют файлы с расширениями *.doc, *.docx, *.xls, *.xlsx, *.pdf, *.rtf, *.contact, *.odt, *.jpg, *.jpeg. Соответственно, пути, по которым необходимо искать файлы, также присутствуют в конфигурации. Это могут быть как имена дисков, так и сетевые пути до удаленных машин.

Функционал загруженного модуля

Первое, что нас заинтересовало — функция, передающая управление коду загруженного модуля первым аргументом (рисунок 35), передает указатель на функцию коммуникации с контрольным сервером.

Анализ данной функции позволил установить, что и в данном случае тип коммуникации идентичен уже рассмотренному; данные передаются также вызовами функций из таблицы виртуальных методов того же COM-объекта (в данном случае в качестве метода коммуникации используется PUT).

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

Стоит отметить, что для каждого из типов подключенных к компьютеру дисков используется свой тип поиска (рисунок 36). Также есть возможность кражи файлов с удаленных серверов — в данном случае имена пользователей и пароли (хранятся в конфигурации ВПО) передаются в качестве параметров.

Остановимся также на функции, отвечающей за непосредственный анализ содержимого сканируемых директорий (рисунок 37). Стоит отметить, что непосредственное чтение из файла выполняется не в самой приведенной функции. В частности, указатель на функцию (на рисунке pfnReadFile) передается через глобальный контекст — структуру, инициализирующуюся на начальном этапе работы приложения, и таким образом уже происходит вызов.

Сетевая инфраструктура

Все домены, которые мы обнаружили в рамках атак 2019–2021 годов, были зарегистрированы через анонимный регистратор bitdomain[.]biz. Ресурс гарантирует полную анонимность, и оплата на сервисе производится исключительно в биткойнах.

Проанализировав SOA-записи доменов, мы обнаружили, что в поле «email-адрес администратора» указаны вполне нормальные адреса электронной почты. В некоторых случаях это оказывались адреса регистранта, найденные нами в WHOIS. Поэтому в тех доменах, где WHOIS был скрыт настройками приватности, можно предположить, что email в SOA — это email регистранта.

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

Список выявленных серверов:

• checklicensekey.com;
• comparelicense.com;
• driver-updated.com;
• sync-firewall.com;
• system-logs.com;
• technology-requests.net;
• translate-news.net.

Также нами был выявлен интересный факт: злоумышленники маскировали внешний вид одного из управляющих серверов (technology-requests.net) под сайт https://www.hoosierheightsindianapolis.com (рисунок 38).

На 26 июля, по данным webcache.googleusercontent.com, вредоносный сайт выглядел так, как показано на рисунке 39.

Непосредственно во вредоносных инструментах коммуникация осуществляется через облачный сервис (как и в предыдущие годы), а именно OpenDrive (https://www.opendrive.com/). Сервис используется как для хранения загружаемых ВПО-модулей, так и для загрузки собранных данных. При этом в качестве логинов используется tempmail-почта.

Заключение

Группа Cloud Atlas активна уже долгие годы и продумывает свои атаки до мелочей. Инструментарий группировки не меняется годами — она старается тщательно скрывать свое ВПО от исследователей, проверяя или используя одноразовые запросы на получение полезной нагрузки. Группа использует техники ухода от сетевых и файловых средств обнаружения атак, применяя легитимные облачные хранилища, а также документированные возможности ПО, в частности Microsoft Office.

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

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

Авторы: Денис Кувшинов, Александр Григорян, Даниил Колосков, Positive Technologies

Авторы благодарят за помощь в подготовке статьи команды incident response и threat intelligence PT Expert Security Center.

Выявление активности группировки CloudAtlas продуктами Positive Technologies

MP SIEM

Следующие правила корреляции правила анализируют запускаемые процессы и помогают выявить описанную активность:

• Suspicious_Connection
• Malicious_Office_Document
• Windows_Autorun_Modification

Следующие правила корреляции анализируют запускаемые скрипты и помогают выявить описанную активность:

• Execute_Malicious_Powershell_Cmdlet
• Execute_Malicious_Command

Реализация техник D3FEND в MP SIEM, которые помогут в выявлении активности группировки CloudAtlas

PT NAD

PT NAD содержит репутационный список CloudAtlas, который поможет в выявлении активности группировки CloudAtlas

Реализация техник D3FEND в PT NAD, которые помогут в выявлении расследовании активности группировки CloudAtlas

PT Sandbox

Вердикты PT Sandbox на активность группировки CloudAtlas:

• Trojan.Win32.Generic.a
• Trojan.Win32.RegLOLBins.a
• Backdoor.Win32.CloudAtlas.a
• Trojan-Downloader.Win32.Generic.a

Правила анализа сетевого трафика, которые помогут в выявлении активности группировки CloudAtlas:

• LOADER [PTsecurity] Possible CloudAtlas
• SUSPICIOUS [PTsecurity] PROPFIND method in http request
• SUSPICIOUS [PTsecurity] MKCOL method in http request

Yara-правила, которые помогут в выявлении активности группировки CloudAtlas:

• PTESC_tool_win_ZZ_OfficeTemplate__Downloader__DOC
• PTESC_exploit_win_ZZ_MalDoc__CVE201711882__Rtf__CA

Реализация техник D3FEND в PT Sandbox, которые помогут в выявлении активности группировки CloudAtlas

Yara

    

rule PTESC_tool_win_ZZ_OfficeTemplate__Downloader__DOC
{
	strings:
		$a = {00 A5 06 6E 04 B4}
		$b = {FF FF FF 7F FF FF FF 7F}
		$c = {B4 00 B4 00 81 81 12 30 00}
		$pref_1 = {68 00 74 00 74 00 70 00 3A 00 2F 00 2F}
		$pref_2 = {68 00 74 00 74 00 70 00 73 00 3A 00 2F 00 2F}
	condition:
		uint16be ( 0 ) == 0xd0cf and ( for any i in ( 300 .. 400 ) : ( uint8be ( @a + i ) == 0x68 and uint8be ( @a + i + 2 ) == 0x74 and uint8be ( @a + i + 4 ) == 0x74 and uint8be ( @a + i + 6 ) == 0x70 ) or for any j in ( 100 .. 200 ) : ( uint8be ( @b + j ) == 0x68 and uint8be ( @b + j + 2 ) == 0x74 and uint8be ( @b + j + 4 ) == 0x74 and uint8be ( @b + j + 6 ) == 0x70 ) or for any k in ( 200 .. 400 ) : ( uint8be ( @c + k ) == 0x68 and uint8be ( @c + k + 2 ) == 0x74 and uint8be ( @c + k + 4 ) == 0x74 and uint8be ( @c + k + 6 ) == 0x70 ) ) and ( ( for any l in ( 14 .. 70 ) : ( uint8be ( @pref_1 + l ) == 0x2f ) ) or ( for any y in ( 16 .. 70 ) : ( uint8be ( @pref_2 + y ) == 0x2f ) ) )
}

    

rule PTESC_exploit_win_ZZ_MalDoc__CVE201711882__Rtf__CA
{
 strings:
 $equation = "4571756174696F6E" nocase ascii //180000004571756174696F6E
 $msftedit = "generator Msftedit 6.39.15" nocase ascii //generator Msftedit 6.39.15.1401
 $objclass = "objclass weaseoijsd" nocase ascii
 condition:
 uint32be ( 0 ) == 0x7B5C7274 and ($equation and ($msftedit or $objclass) or (for any i in (50..350) : (uint8be (@equation + i) == 0x64 and uint8be (@equation + i + 2) == 0x64 and uint8be (@equation + i + 4) == 0x64 and uint8be (@equation + i + 6) == 0x38)))
}

IOCs

Файловые индикаторы

Сетевые индикаторы

• api-help.com
• driver-updated.com
• sync-firewall.com
• system-logs.com
• technology-requests.net
• translate-news.net
• checklicensekey.com
• comparelicense.com
• msupdatecheck.com
• protocol-list.com

Имена файлов с полезной нагрузкой (из конфигурации):

• callicrates
• tinh
• amianthium
• mandarinduck
• cushioning
• kingsclover

E-mail, с которых рассылались вредоносные письма:

• ano.spectr@yandex.ru
• ancentr@lenta.ru

MITRE TTPs

Общие меры по противодействию TTP, которые использует группировка CloudAtlas

Базовые меры защиты

Дополнительные меры защиты