RATKing: нова кампанія з троянами віддаленого доступу
Наприкінці травня ми виявили кампанію розповсюдження ВПО класу Remote Access Trojan (RAT) — програм, які дозволяють зловмисникам віддалено керувати зараженою системою.
Розглянуте нами угруповання відзначилося тим, що воно не обрало для зараження якесь певне сімейство RAT. В атаках у рамках кампанії було помічено відразу кілька троянів (все у широкому доступі). Цією рисою угруповання нагадало нам про щурого короля — міфічну тварину, яка складається з гризунів з переплетеними хвостами.
Оригінал взято з монографії К. Н. Россікова «Миші та мишоподібні гризуни, найважливіші у господарському відношенні» (1908 р.)
На честь цієї істоти ми назвали угруповання RATKing, яке ми розглядаємо. У цьому пості ми розповімо докладно про те, як зловмисники проводили атаку, які інструменти вони використовували, а також поділимося своїми міркуваннями щодо атрибуції цієї кампанії.
Хід атаки
Усі атаки в цій кампанії проходили за наступним алгоритмом:
Користувач отримував лист фішингу з посиланням на Google Drive.
За посиланням жертва завантажувала шкідливий VBS-скрипт, який прописував DLL-бібліотеку для завантаження кінцевого пейлоаду до реєстру Windows і запускав PowerShell, щоб виконати її.
DLL-бібліотека впроваджувала кінцевий пейлоад - власне, один із використовуваних зловмисниками RAT - у системний процес і прописувала VBS-скрипт в автозапуск, щоб закріпитися в зараженій машині.
Кінцевий пейлоад виконувався у системному процесі та давав зловмисникові можливість керувати зараженим комп'ютером.
Схематично це можна так:
Далі ми зосередимося перших трьох етапах, оскільки нас цікавить саме механізм доставки ВПО. Ми не будемо докладно описувати механізм роботи самих шкідників. Вони знаходяться у широкому доступі — або продаються на спеціалізованих форумах, або взагалі поширюються як проекти з відкритим вихідним кодом, а отже, не є унікальними для угрупування RATKing.
Аналіз етапів атаки
Етап 1. Фішингове розсилання
Атака починалася з того, що жертва отримувала шкідливий лист (зловмисники використовували різні шаблони з текстом, на скріншоті нижче наведено один із прикладів). У повідомленні було посилання на легітимне сховище drive.google.comяка нібито вела на сторінку завантаження документа у форматі PDF.
Приклад фішингового листа
Однак насправді завантажувався не PDF-документ, а VBS-скрипт.
При переході на посилання з листа на скріншоті вище завантажувався файл з ім'ям Cargo Flight Details.vbs. І тут зловмисники навіть намагалися замаскувати файл під легітимний документ.
У той же час, у рамках цієї кампанії ми виявили скрипт з ім'ям Cargo Trip Detail.pdf.vbs. Він уже міг зійти за легітимний PDF, тому що за умовчанням Windows приховує розширення файлів. Щоправда, у цьому випадку підозра все ще могла викликати його іконку, що відповідала VBS-скрипту.
На цьому етапі жертва могла розпізнати обман: достатньо на секунду придивитися до файлів, що завантажуються. Однак у таких фішингових кампаніях зловмисники найчастіше розраховують саме на неуважного користувача.
Етап 2. Робота VBS-скрипту
VBS-скрипт, який користувач міг відкрити необережно, прописував DLL-бібліотеку в реєстр Windows. Скрипт був обфусцирован: рядки в ньому записані у вигляді байтів, розділених довільним символом.
Приклад скрипту
Алгоритм деобфускації досить простий: з обфусцированного рядка виключався кожен третій символ, після чого результат декодувався з base16 вихідний рядок. Наприклад, із значення 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (виділено на скріншоті вище) виходив рядок WScript.Shell.
Для деобфускації рядків ми використовували функцію Python:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Нижче на рядках 9-10 виділено значення, при деобфускації якого виходив DLL-файл. Саме він запускався на наступному етапі за допомогою PowerShell.
Рядок з обфузованим DLL
Кожна функція у VBS-скрипті виконувалася в міру деобфускації рядків.
Після запуску скрипта викликалася функція wscript.sleep - З її допомогою виконувалося відкладене виконання.
Далі скрипт працював із реєстром Windows. Він використав для цього технологію WMI. З її допомогою створювався унікальний ключ, і його параметр записувалося тіло виконуваного файла. Звернення до реєстру через WMI виконували за допомогою наступної команди:
На третьому етапі шкідлива DLL-бібліотека завантажувала кінцевий пейлоад, впроваджувала його у системний процес та забезпечувала автозапуск VBS-скрипту при вході користувача до системи.
Запуск через PowerShell
DLL-бібліотека виконувалася за допомогою наступної команди PowerShell:
отримувала дані значення реєстру з ім'ям rnd_value_name — ці дані були DLL-файл, написаний на платформі .Net;
завантажувала отриманий .Net-модуль на згадку про процес powershell.exe за допомогою функції [System.Threading.Thread]::GetDomain().Load()(Докладний опис функції Load() доступно на сайті Microsoft);
виконувала функцію GUyyvmzVhebFCw]::EhwwK() - з неї починалося виконання DLL-бібліотеки - з параметрами vbsScriptPath, xorKey, vbsScriptName. Параметр xorKey зберігав ключ для розшифрування кінцевого пейлоаду, а параметри vbsScriptPath и vbsScriptName передавалися для того, щоб прописати VBS-скрипт автозапуск.
Опис DLL-бібліотеки
У декомпільованому вигляді завантажувач виглядав так:
Завантажувач у декомпільованому вигляді (червоним підкреслено функцію, з якої починалося виконання DLL-бібліотеки)
Завантажувач захищений протектором .Net Reactor. Зі зняттям даного протектора чудово справляється утиліта de4dot.
Цей завантажувач:
здійснював інжект пейлоаду в системний процес (у цьому прикладі це svchost.exe);
прописував VBS-скрипт в автозапуск
Інжект пейлоаду
Розглянемо функцію, яку викликав PowerShell скрипт.
Функція, що викликається PowerShell-скриптом
Ця функція здійснювала такі действия:
розшифровувала два масиви даних (array и array2 на скріншоті). Спочатку вони були стиснуті за допомогою gzip та зашифровані алгоритмом XOR з ключем xorKey;
копіювала дані у виділені області пам'яті. Дані з array — в область пам'яті, яку вказував intPtr (payload pointer на скріншоті); дані з array2 — в область пам'яті, яку вказував intPtr2 (shellcode pointer на скріншоті);
викликала функцію CallWindowProcA(опис цієї функції є на сайті Microsoft) з наступними параметрами (нижче перераховані імена параметрів, на скріншоті вони йдуть у тому порядку, але з робочими значеннями):
lpPrevWndFunc - покажчик на дані з array2;
hWnd — покажчик на рядок, що містить шлях до файлу, що виконується. svchost.exe;
Msg - покажчик на дані з array;
wParam, lParam — параметри повідомлення (у разі ці параметри не використовувалися і мали значення 0);
створювала файл %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.url, Де <name> — це перші 4 символи параметра vbsScriptName (на скріншоті фрагмент коду з цією дією починається з команди File.Copy). Таким чином шкідливість додавала URL-файл до списку файлів для автозапуску при вході користувача в систему і тим самим закріплювалася на зараженому комп'ютері. URL-адреса містить посилання на скрипт:
Для того, як здійснювався інжект, ми розшифрували масиви даних array и array2. Для цього ми використовували наступну функцію на Python:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
В результаті ми з'ясували, що:
array являв собою PE-файл - це і є кінцевий пейлоад;
array2 являв собою шелл-код, необхідний здійснення інжекта.
Шелл-код із масиву array2 передавався як значення функції lpPrevWndFunc у функцію CallWindowProcA. lpPrevWndFunc функція зворотного виклику, її прототип виглядає так:
Таким чином, при запуску функції CallWindowProcA з параметрами hWnd, Msg, wParam, lParam виконується шелл-код із масиву array2 з аргументами hWnd и Msg. hWnd — це покажчик на рядок, що містить шлях до файлу, що виконується. svchost.exe, а Msg - Покажчик на кінцевий пейлоад.
Шелл-код отримував адреси функцій з kernel32.dll и ntdll32.dll за значеннями хешей від їхніх імен і виконував інжект кінцевого пейлоаду на згадку про процес svchost.exe, використовуючи техніку Process Hollowing (докладно про неї можна прочитати в цій статті). При інжекті шелл-код:
створював процес svchost.exe у зупиненому стані за допомогою функції CreateProcessW;
потім приховував відображення секції в адресному просторі процесу svchost.exe за допомогою функції NtUnmapViewOfSection. Таким чином, програма звільняла пам'ять оригінального процесу svchost.exeщоб потім за цією адресою виділити пам'ять для пейлоада;
виділяв пам'ять для пейлоаду в адресному просторі процесу svchost.exe за допомогою функції VirtualAllocEx;
Початок процесу інжекту
записував вміст пейлоаду в адресний простір процесу svchost.exe за допомогою функції WriteProcessMemory (як на скріншоті нижче);
відновлював процес svchost.exe за допомогою функції ResumeThread.
Завершення процесу інжекту
ВПО, що завантажується
Внаслідок описаних дій у зараженій системі встановлювалася одна з кількох шкідливих програм класу RAT. У таблиці нижче перераховані використані в атаці шкідливі дії, які ми з впевненістю можемо приписати одній групі зловмисників, оскільки семпли зверталися до одного і того ж сервера управління.
Приклади поширюваного ВПО з одним і тим самим сервером управління
Тут примітні дві речі.
По-перше, сам факт, що зловмисники використали відразу кілька різних сімейств RAT. Така поведінка не характерна для відомих кіберугруповань, які найчастіше використовують приблизно однаковий набір звичних для них інструментів.
По-друге, RATKing використовували шкідливі дані, які або продаються на спеціалізованих форумах за невелику ціну, або взагалі є проектами з відкритим вихідним кодом.
Більш повний перелік використаного в кампанії ВПО з одним важливим застереженням наведено наприкінці статті.
Про угруповання
Ми не можемо віднести описану шкідливу кампанію до якихось відомих зловмисників. Поки що ми вважаємо, що ці атаки зробило принципово нове угруповання. Як ми вже писали на початку, ми назвали її RATKing.
Для створення VBS-скрипту угруповання, ймовірно, використало інструмент, схожий на утиліту VBS-Crypter від розробника NYAN-x-CAT. На це вказує схожість скрипта, який створює ця програма зі скриптом зловмисників. Зокрема, вони обидва:
здійснюють відкладене виконання за допомогою функції Sleep;
використовують WMI;
прописують тіло виконуваного файлу як параметр ключа реєстру;
виконують цей файл за допомогою PowerShell у його адресному просторі.
Для наочності порівняйте команду PowerShell для запуску файлу з реєстру, яку використовує скрипт, створений за допомогою VBS-Crypter:
Зауважимо, що як один з пейлоадів зловмисники використовували іншу утиліту від NYAN-x-CAT. LimeRAT.
Адреси C&C-серверів вказують на ще одну відмінну рису RATKing: угруповання віддає перевагу сервісам динамічного DNS (див. перелік C&C в таблиці з IoC).
IoC
У таблиці нижче наведено повний перелік VBS-скриптів, які з великою ймовірністю можна віднести до описаної кампанії. Всі ці скрипти схожі та здійснюють приблизно однакову послідовність дій. Всі вони інжектять ВПО класу RAT у довірений процес Windows. Всі адреси C&C зареєстровані з використанням Dynamic DNS-сервісів.
Тим не менш, ми не можемо стверджувати, що всі ці скрипти поширювалися тими самими зловмисниками, за винятком семплів з однаковими адресами C&C (наприклад, kimjoy007.dyndns.org).