CobInt. Разбираем известный бэкдор и практикуемся в реверсе

PowerShell loader

В начале 2024 года наша коман­да по рас­сле­дова­нию инци­ден­тов (PT ESC Positive Technologies) выяви­ла при­мене­ние мал­вари CobInt в инфраструк­туре заказ­чика. Про­ана­лизи­ровав логи EVTX на ском­про­мети­рован­ной машине, мы извлек­ли силь­но обфусци­рован­ный вре­донос­ный скрипт PowerShell.

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

Код фун­кции выг­лядит сле­дующим обра­зом:

В этой фун­кции на осно­ве раз­мера ука­зате­ля опре­деля­ется раз­рядность ОС, в зависи­мос­ти от которой перемен­ной $d90qSK прис­ваивает­ся соот­ветс­тву­ющее зна­чение. Оно опре­деля­ет сме­щение к фун­кции рас­шифров­ки шелл‑кода. Шелл‑код для опре­делен­ной архи­тек­туры декоди­рует­ся из Base64, пос­ле чего переда­ется в фун­кцию RgEGGBTGL вмес­те со сме­щени­ем. Что­бы сох­ранить рас­кодиро­ван­ный шелл‑код на диск, сра­зу пос­ле вызова фун­кции FromBase64String добавим в код сле­дующую стро­ку:

Те­перь убе­дим­ся, что шелл‑код сох­ранил­ся кор­рек­тно. Закиды­ваем его в IDA, перехо­дим по сме­щению 1331 (0x533) в слу­чае с x64 и пре­обра­зуем бай­ты в код.

Расшифровка тела шелл-кода

Код, который отве­чает за рас­шифров­ку самого себя в памяти, выг­лядит сле­дующим обра­зом.

Нам нуж­но пре­обра­зовать шелл‑код в исполня­емый файл. Я это делаю с помощью shellcode2exe:

Те­перь мы можем заг­рузить получив­ший­ся исполня­емый файл в x64dbg. Пос­ле заг­рузки жмем RUN, что­бы перей­ти к EntryPoint.

Код на текущий момент еще не рас­шифро­ван и пред­став­ляет собой воль­ную интер­пре­тацию мешани­ны из бай­тов, выдан­ной дебаг­гером. Нуж­но перей­ти по извес­тно­му сме­щению 0x533 + ImageBase, то есть в нашем слу­чае по адре­су 0x401533.

Мы видим уже зна­комую фун­кцию для рас­шифров­ки тела шелл‑кода. Выпол­нять код мы нач­нем с текущей стро­ки. Для это­го жмем Set RIP Here, пос­ле чего адрес Instruction Pointer при­мет необ­ходимое зна­чение.

С помощью F8 нуж­но прой­тись по инс­трук­циям рас­шифров­ки и най­ти ту, которая отве­чает за выход из цик­ла. Эта инс­трук­ция находит­ся по адре­су 0x401538.

Ста­вим брейк‑пой­нт на сле­дующей за jne инс­трук­ции и нажима­ем F9, что­бы вруч­ную не ходить по каж­дой ите­рации цик­ла рас­шифров­ки. Пос­ле оста­нов­ки на нашем брейк‑пой­нте про­ходим по коду нем­ного даль­ше и пры­гаем на начало уже рас­шифро­ван­ного кода в ори­гиналь­ной EntryPoint.

На этом эта­пе мы можем сдам­пить PE в рас­шифро­ван­ном виде для удобс­тва даль­нейше­го дебага. Я исполь­зую в этих целях пла­гин OllyDumpEx.

Код для рас­шифров­ки себя в памяти содер­жит сле­дующий алго­ритм:

1. XOR пер­вых четырех бай­тов (Little Endian) с зашитым клю­чом 0x4498D9DE.
2. По­бито­вый сдвиг вле­во на один бит для клю­ча (rol xor_key, 1).
3. XOR сле­дующих четырех бай­тов с модифи­циро­ван­ным клю­чом и так далее.

Исследование загрузчика

Unhashing functions

Нас­тало вре­мя поковы­рять­ся в заг­рузчи­ке. Откры­ваем сдам­плен­ный файл в x64dbg. В коде встре­чает­ся мно­жес­тво вызовов фун­кции 401380, в которую переда­ются раз­личные Hex-зна­чения. Обыч­но такой пат­терн свой­стве­нен фун­кци­ям, отве­чающим за вос­ста­нов­ление имен биб­лиотек и фун­кций из хеш‑зна­чений. Как вид­но на скрин­шоте, пер­вый вызов вер­нул имя фун­кции LoadLibraryA биб­лиоте­ки Kernel32, а так­же ее адрес в RCX.

Рас­смот­рим эту фун­кцию под­робнее. Обра­ти вни­мание на сле­дующий код.

Этот модуль сна­чала получа­ет ука­затель на PEB (Process Environment Block) через сме­щение 0x60 в TEB (Thread Environment Block), дос­туп к которо­му осу­щест­вля­ется через регистр gs. Затем код перехо­дит по сме­щени­ям 0x18 и 0x20. Что­бы понять, что это за сме­щения, мож­но обра­тить­ся к опи­санию струк­туры PEB или про­верить их в WinDbg. Для это­го:

• заг­ружа­ем исполня­емый файл в WinDbg;
• вво­дим коман­ду bp $exentry для уста­нов­ки брейк‑пой­нта на EntryPoint;
• за­пус­каем исполне­ние коман­дой g;
• пе­реме­щаем­ся нажати­ем F8 к рас­смат­рива­емо­му учас­тку кода.

Ко­ман­да dt ntdll!_PEB @$peb покажет струк­туру PEB со сме­щени­ями.

Пер­вое сме­щение ука­зыва­ет на струк­туру PEB_LDR_DATA, которая содер­жит в себе све­дения о заг­ружен­ных модулях для про­цес­са. Изу­чим ее пов­ниматель­нее, для это­го в WinDbg вве­дем коман­ду dt -r1 _PEB_LDR_DATA.

Вто­рое сме­щение ука­зыва­ет на двус­вязный спи­сок InMemoryOrderModuleList, который содер­жит заг­ружен­ные модули для про­цес­са. Каж­дый эле­мент в этом спис­ке явля­ется ука­зате­лем на струк­туру LDR_DATA_TABLE_ENTRY. Сме­щение на него лежит в rbx, поэто­му берем адрес из rbx и нак­ладыва­ем на него струк­туру _LDR_DATA_TABLE_ENTRY.

Та­ким обра­зом, по сме­щению 0x50 код получа­ет дос­туп к полю buffer с име­нем модуля. Далее вызыва­ется фун­кция, в которую аргу­мен­тами переда­ется ука­затель на стро­ку с име­нем модуля и дли­на стро­ки.

Эта фун­кция выпол­няет хеширо­вание стро­ки. Алго­ритм выг­лядит сле­дующим обра­зом.

По­лучив хеш, алго­ритм про­веря­ет получен­ное зна­чение с передан­ным ранее аргу­мен­том. Если зна­чения не сов­пада­ют, выпол­няет­ся переход к сле­дующе­му име­ни модуля. Если сов­пада­ют, то сох­раня­ется ука­затель на адрес биб­лиоте­ки, к которо­му при­бав­ляют­ся сме­щения.