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).