Дослідники CrowdStrike ідентифікували зразок HijackLoader (він же IDAT Loader), який використовує складні методи ухилення, щоб посилити складність загрози. HijackLoader, дедалі популярніший інструмент серед зловмисників для розгортання додаткових корисних навантажень і інструментів, продовжує розвиватися, оскільки його розробники експериментують і розширюють його можливості.
У своєму аналізі нещодавнього зразка HijackLoader дослідники CrowdStrike виявили нові методи, призначені для підвищення можливостей захисту від уникнення завантажувача. Розробник зловмисного програмного забезпечення використав стандартну техніку видалення процесів у поєднанні з додатковим тригером, який активувався батьківським процесом, який записував у канал. Цей новий підхід потенційно може зробити ухилення від оборони більш прихованим.
Другий варіант техніки включав незвичайну комбінацію методів дублювання процесів і методів порожнення процесу. Цей варіант збільшує складність аналізу та здатність HijackLoader уникати захисту. Дослідники також помітили додаткові методи відключення, які використовуються для приховування шкідливих дій.
У цьому блозі присвячено різноманітним методам ухилення, які використовує HijackLoader на кількох етапах шкідливого програмного забезпечення.
Аналіз HijackLoader
Огляд ланцюга зараження
Зразок HijackLoader, який проаналізував CrowdStrike, реалізує складну багатоступеневу поведінку, у якій виконуваний файл першого етапу (streaming_client.exe) деобфусцує вбудовану конфігурацію, яка частково використовується для динамічного вирішення API (використовуючи структуру PEB_LDR_DATA без іншого використання API), щоб захистити від статичного аналізу.
Після цього зловмисне програмне забезпечення використовує WinHTTP API, щоб перевірити, чи має система активне підключення до Інтернету, підключившись до https[:]//nginx[.]org.
Якщо початкова перевірка з’єднання пройшла успішно, виконання продовжується, і він підключається до віддаленої адреси, щоб завантажити blob конфігурації другого етапу. Якщо перша URL-адреса, указана нижче, не працює, зловмисне програмне забезпечення повторює наступний список:
● https[:]//gcdnb[.]pbrd[.]co/images/62DGoPumeB5P.png?o=1
● https[:]//i[.]imgur[.]com/gyMFSuy.png;
● https[:]//bitbucket[.]org/bugga-oma1/sispa/downloads/574327927.png
Після успішного отримання конфігурації другого етапу зловмисне програмне забезпечення повторює завантажений буфер, перевіряючи початкові байти заголовка PNG. Потім він переходить до пошуку магічного значення C6 A5 79 EA, яке передує ключу XOR (32 B3 21 A5 у цьому зразку), який використовується для розшифровки решти блоку конфігурації.
Після дешифрування XOR конфігурація розпаковується за допомогою API RtlDecompressBuffer із COMPRESSION_FORMAT_LZNT1. Після розпакування конфігурації зловмисне програмне забезпечення завантажує законну бібліотеку DLL Windows, указану в blob-файлі конфігурації (у цьому прикладі C:\Windows\SysWOW64\mshtml.dll).
Позиційно-незалежний шелл-код другого етапу, отриманий із блоку конфігурації, записується в розділ .text щойно завантаженої DLL перед виконанням. Другий етап, незалежний від позиції шелл-код HijackLoader потім виконує деякі дії з ухилення (детальніше описано нижче), щоб обійти перехоплення режиму користувача за допомогою Heaven’s Gate та впроваджує наступний шелл-код у cmd.exe. Впровадження шелл-коду третього етапу здійснюється за допомогою варіації порожнення процесу, що призводить до введення порожнього mshtml.dll у щойно створений дочірній процес cmd.exe.
Шел-код третього етапу реалізує обхід гаків режиму користувача перед введенням остаточного корисного навантаження (маяка Cobalt Strike для цього зразка) у дочірній процес logagent.exe. Механізм ін’єкції, який використовується шеллкодом третього етапу, використовує такі методи:
● Примітиви процесу Doppelgänging: ця техніка використовується для видалення розділу Transacted (mshtml.dll) у віддаленому процесі, щоб містити остаточне корисне навантаження.
● Процес/DLL Hollowing: ця техніка використовується для введення шелл-коду четвертого етапу, який відповідає за виконання ухилення перед передачею виконання до кінцевого корисного навантаження в межах транзакційного розділу з попереднього кроку.
Основні методи ухилення, які використовуються HijackLoader і Shellcode
Основні методи ухилення, які використовує HijackLoader, включають методи обходу гаків, такі як Heaven’s Gate, і відключення шляхом переналаштування системних DLL, які контролюються продуктами безпеки. Крім того, зловмисне програмне забезпечення реалізує різновиди видалення процесів і техніку ін’єкцій, яка використовує видалення транзакцій, що поєднує в собі методи дублювання розділу транзакцій і процесу з видаленням DLL.
Hook Bypass: Heaven’s Gate і Unhooking
Подібно до інших варіантів HijackLoader, цей зразок реалізує обхід гаків режиму користувача за допомогою Heaven’s Gate (під час запуску в SysWOW64) — це подібно до існуючих реалізацій (функція x64_Syscall).
Ця реалізація Heaven’s Gate є потужною технікою, яка дозволяє уникнути перехоплень режиму користувача, розміщених у SysWOW64 ntdll.dll, шляхом прямого виклику інструкції syscall у версії ntdll x64.
Кожен виклик до Heaven’s Gate використовує такі аргументи:
● Номер системного виклику
● Кількість параметрів системного виклику
● Параметри (відповідно до системного виклику)
Ця варіація шелл-коду включає додатковий механізм обходу гаків, щоб уникнути будь-яких гаків режиму користувача, які продукти безпеки могли розмістити в x64 ntdll. Ці хуки зазвичай використовуються для моніторингу як x32, так і x64 ntdll.
На цьому етапі зловмисне програмне забезпечення переназначає розділ .text x64 ntdll, використовуючи Heaven’s Gate для виклику NtWriteVirtualMemory і NtProtectVirtualMemory, щоб замінити зіставлений у пам’яті ntdll на .text зі свіжої ntdll, прочитаної з файлу C:\windows\system32\ ntdll.dll. Ця техніка відключення також використовується в процесі, де розміщено остаточне корисне навантаження Cobalt Strike (logagent.exe), щоб остаточно спробувати уникнути виявлення.
Варіація порожнистого процесу
Щоб ін’єктувати наступний шелл-код у дочірній процес cmd.exe, зловмисне програмне забезпечення використовує загальні методи випорожнення процесу. Це передбачає відображення законної бібліотеки DLL Windows mshtml.dll у цільовий процес, а потім заміну її розділу .text на код оболонки. Додатковий крок, необхідний для ініціювання виконання віддаленого шелл-коду, детально описано в наступному розділі.
Щоб налаштувати видалення, зразок створює два канали, які використовуються для переспрямування стандартного вводу та стандартного виводу дочірнього процесу (вказаного у згаданому вище blob конфігурації, C:\windows\syswow64\cmd.exe), розміщуючи канали ‘ ручки в структурі STARTUPINFOW, створеній за допомогою CreateProcessW API.
Тут можна помітити одну ключову відмінність між цією реалізацією та типовим «стандартним» видаленням процесу: у стандартному видаленні процесу дочірній процес зазвичай створюється в призупиненому стані. У цьому випадку дитина явно не створюється в підвішеному стані, що робить її менш підозрілою. Оскільки дочірній процес очікує вхідних даних із каналу, створеного раніше, його виконання зависає на отриманні даних з нього. По суті, ми можемо назвати це інтерактивним процесом порожнистої варіації.
У результаті нещодавно створений cmd.exe читатиме вхідні дані з каналу STDIN, фактично чекаючи нових команд. На цьому етапі його EIP (вказівник розширеної інструкції) спрямований на повернення від системного виклику NtReadFile.
У наступному розділі детально описано кроки, які виконує шелл-код другого етапу для налаштування дочірнього процесу cmd.exe, який у кінцевому підсумку використовується для виконання наступних ін’єкцій, які використовуються для виконання остаточного корисного навантаження.
Батьківський процес streaming_client.exe ініціює NtDelayExecution у сплячий режим, очікуючи завершення завантаження cmd.exe. Після цього він зчитує законну DLL Windows mshtml.dll із файлової системи та продовжує завантажувати цю бібліотеку в cmd.exe як спільний розділ. Це досягається за допомогою техніки Heaven’s Gate для:
● Створення спільного об’єкта розділу за допомогою NtCreateSection
● Відображення цього розділу у віддаленому cmd.exe за допомогою NtMapViewOfSection
Потім він замінює розділ .text бібліотеки DLL mshtml шкідливим кодом оболонки, використовуючи:
● Heaven’s Gate для виклику NtProtectVirtualMemory у cmd.exe для встановлення дозволів RWX для розділу .text попередньо зіставленого розділу mshtml.dll
● Heaven’s Gate для виклику NtWriteVirtualMemory у розділі .text бібліотеки DLL, щоб натиснути на модуль і написати шелл-код третього етапу
Нарешті, щоб ініціювати виконання віддаленого шелл-коду, зловмисне програмне забезпечення використовує:
● Heaven’s Gate для призупинення (NtSuspendThread) віддаленого основного потоку
● Новий КОНТЕКСТ (за допомогою NtGetContextThread і NtSetContextThread) для зміни EIP для вказівки на раніше написаний шелл-код
● Heaven’s Gate для відновлення (NtResumeThread) віддаленого основного потоку cmd.exe
Однак, оскільки cmd.exe очікує на введення користувача з каналу STDINPUT, введений шелл-код у новому процесі фактично не виконується після відновлення потоку. Навантажувач повинен зробити додатковий крок:
● Батьківському процесу streaming_client.exe потрібно записати (WriteFile) рядок \r\n у канал STDINPUT, створений раніше, щоб надіслати вхідні дані в cmd.exe після виклику NtResumeThread. Це фактично відновлює виконання основного потоку в точці входу шелл-коду в дочірньому процесі cmd.exe.
Варіація інтерактивного процесу ковбання: ремісничий аналіз
Ми успішно відтворили безрізьбовий процес порожнистої техніки, щоб зрозуміти, як труби запускають його. Після написання шелл-коду, як описано, його потрібно активувати. Ця активація базується на концепції, згідно з якою, коли програма виконує системний виклик, потік очікує, поки ядро поверне значення.
По суті, техніка інтерактивного процесу порожнистості включає наступні кроки:
● CreateProcess: цей крок передбачає створення процесу cmd.exe для введення шкідливого коду шляхом перенаправлення STDIN і STDOUT на канали. Примітно, що цей процес не призупинено, що робить його менш підозрілим. Очікуючи читання вхідних даних із каналу, системний виклик NtReadFile встановлює стан головного потоку на Очікування, а _KWAIT_REASON — на Виконавчий, що означає, що він очікує на виконання операцій коду ядра та їх повернення.
● WriteProcessMemory: тут записується шелл-код у дочірній процес cmd.exe.
● SetThreadContext: на цьому етапі батьківський процес встановлює умови для перенаправлення потоку виконання дочірнього процесу cmd.exe на адресу попередньо написаного коду оболонки, змінюючи EIP/RIP у віддаленому CONTEXT потоку.
● WriteFile: тут дані записуються в канал STDIN, надсилаючи вхідні дані до процесу cmd.exe. Ця дія відновлює виконання дочірнього процесу з операції NtReadFile, таким чином запускаючи виконання шелл-коду. Перед поверненням у простір користувача ядро читає та відновлює значення, збережені в структурі _KTRAP_FRAME (що містить значення реєстру EIP/RIP), щоб продовжити роботу з місця виклику системного виклику. Змінюючи КОНТЕКСТ на попередньому кроці, завантажувач перехоплює відновлення виконання до адреси шелл-коду без необхідності призупиняти та відновлювати потік, що зазвичай вимагає ця техніка.
Transacted Hollowing² (Transacted Section/Doppelgänger + Hollowing)
Зловмисне програмне забезпечення записує остаточне корисне навантаження в дочірній процес logagent.exe, породжений шелл-кодом третього етапу в cmd.exe, створюючи транзакційний розділ для відображення у віддаленому процесі. Згодом зловмисне програмне забезпечення вставляє шелл-код четвертої стадії в logagent.exe, завантажуючи та видаляючи інший екземпляр mshtml.dll у цільовий процес. Введений шелл-код четвертого етапу виконує вищезгадану техніку обходу гака перед виконанням останнього корисного навантаження, попередньо виділеного розділом транзакції.
Проведена транзакція. Видовбування розділу
Подібно до подвійного процесу, метою транзакційного розділу є створення прихованого шкідливого розділу всередині віддаленого процесу шляхом перезапису пам’яті законного процесу транзакцією.
У цьому прикладі шелл-код третього етапу, який виконується всередині cmd.exe, розміщує зловмисний транзакційний розділ, який використовується для розміщення остаточного корисного навантаження, у цільовому дочірньому процесі logagent.exe. Шелл-код використовує наступне:
● NtCreateTransaction для створення транзакції
● RtlSetCurrentTransaction і CreateFileW з фіктивним іменем файлу, щоб замінити задокументований CreateFileTransactedW
● Heaven’s Gate для виклику NtWriteFile у циклі, записуючи остаточний шелл-код у файл у 1024-байтових фрагментах
● Створення розділу на основі цього файлу (виклик Heaven’s Gate NtCreateSection)
● Відкат раніше створеного розділу за допомогою Heaven’s Gate для виклику NtRollbackTransaction
Існуючі подібні реалізації публічно спостерігалися в цьому проекті, який реалізує видалення транзакцій.
Після створення транзакційного розділу шелл-код генерує заглушку функції під час виконання, щоб приховати від статичного аналізу. Ця заглушка містить виклик theCreateProcessW API для створення призупиненого дочірнього процесу logagent.exe (c50bffbef786eb689358c63fc0585792d174c5e281499f12035afa1ce2ce19c8), який раніше було видалено cmd.exe у папці %TEMP%.
Після створення цільового процесу зразок використовує Heaven’s Gate, щоб:
● Прочитайте його PEB, викликавши NtReadVirtualMemory, щоб отримати його базову адресу (0x400000)
● Скасуйте зіставлення зображення logagent.exe у процесі logagent.exe за допомогою NtUnMapViewofSection
● Видалити раніше створений транзакційний розділ у віддаленому процесі шляхом перевідображення розділу за тією самою базовою адресою (0x400000) за допомогою NtMapViewofSection
Процес пустотіння
Після того, як шелл-код третього етапу в cmd.exe вставляє остаточне корисне навантаження Cobalt Strike всередину транзакційного розділу процесу logagent.exe, він продовжує процес, випорожнюючи цільовий процес, щоб написати четвертий етап шелл-коду, який в кінцевому підсумку використовується для виконання остаточного корисного навантаження (завантаженого). у розділі транзакції) у віддаленому процесі. Шел-код третього етапу відображає законну бібліотеку DLL Windows C:\Windows\SysWOW64\mshtml.dll у цільовому процесі перед заміною її .text на шелл-код четвертого етапу та виконання його через NtResumeThread.
Цей додатковий шелл-код четвертого етапу, записаний у logagent.exe, виконує дії, подібні до шелл-коду третього етапу, який виконується в cmd.exe (як зазначено в розділі обходу гаків), перш ніж передавати виконання остаточному корисному навантаженню.
Покриття Falcon
CrowdStrike використовує багаторівневий підхід для виявлення шкідливих програм за допомогою машинного навчання та індикаторів атак (IOA). Як показано на малюнку 3, можливості машинного навчання датчика CrowdStrike Falcon® можуть автоматично виявляти та запобігати HijackLoader на початкових етапах ланцюжка атак; тобто, як тільки шкідливе програмне забезпечення завантажується на комп’ютер жертви. Можливості виявлення на основі поведінки (IOA) можуть розпізнавати зловмисну поведінку на різних етапах ланцюжка атак, у тому числі під час використання таких тактик, як спроби впровадження процесу.
Індикатори компромісу (IOC)
Файл: streaming_client.exe
SHA256: 6f345b9fda1ceb9fe4cf58b33337bb9f820550ba08ae07c782c2e142f7323748
