Մայիսի վերջին մենք հայտնաբերեցինք Remote Access Trojan (RAT) չարամիտ ծրագրերի տարածման արշավ՝ ծրագրեր, որոնք թույլ են տալիս հարձակվողներին հեռակա կարգով կառավարել վարակված համակարգը:
Մեր հետազոտած խումբը առանձնանում էր նրանով, որ վարակի համար չի ընտրել հատուկ RAT ընտանիք: Մի քանի տրոյացիներ նկատվեցին արշավի ընթացքում հարձակումների ժամանակ (որոնք բոլորն էլ լայնորեն հասանելի էին): Այս հատկանիշով խումբը մեզ հիշեցրեց առնետների թագավորին՝ առասպելական կենդանու, որը բաղկացած է միահյուսված պոչերով կրծողներից:
Բնօրինակը վերցված է Կ. Ն. Ռոսիկովի «Մկները և մկան նման կրծողները, տնտեսապես ամենակարևորը» մենագրությունից (1908 թ.)
Ի պատիվ այս արարածի, մենք անվանեցինք այն խումբը, որը մենք համարում ենք RATKing: Այս գրառման մեջ մենք մանրամասնորեն կանդրադառնանք, թե ինչպես են հարձակվողներն իրականացրել հարձակումը, ինչ գործիքներ են նրանք օգտագործել, ինչպես նաև կկիսվենք այս քարոզարշավի վերագրման վերաբերյալ մեր մտքերով:
Հարձակման առաջընթացը
Այս արշավի բոլոր հարձակումները տեղի են ունեցել հետևյալ ալգորիթմի համաձայն.
Օգտատերը ստացել է ֆիշինգ նամակ՝ Google Drive-ի հղումով:
Օգտագործելով հղումը՝ տուժողը ներբեռնեց վնասակար VBS սկրիպտը, որը նշում էր DLL գրադարան՝ վերջնական բեռնվածությունը Windows ռեեստրի մեջ բեռնելու համար և գործարկեց PowerShell-ը՝ այն գործարկելու համար:
DLL գրադարանը ներարկեց վերջնական ծանրաբեռնվածությունը՝ իրականում հարձակվողների կողմից օգտագործվող RAT-ներից մեկը, և գրանցեց VBS սկրիպտը autorun-ում՝ վարակված մեքենայի մեջ տեղ գրավելու համար:
Վերջնական ծանրաբեռնվածությունը իրականացվել է համակարգային գործընթացում և հարձակվողին տվել է վարակված համակարգիչը կառավարելու հնարավորություն:
Սխեմատիկորեն այն կարող է ներկայացվել այսպես.
Հաջորդիվ, մենք կկենտրոնանանք առաջին երեք փուլերի վրա, քանի որ մեզ հետաքրքրում է չարամիտ ծրագրերի առաքման մեխանիզմը: Մենք մանրամասն չենք նկարագրի չարամիտ ծրագրի գործարկման մեխանիզմը: Դրանք լայնորեն հասանելի են՝ կա՛մ վաճառվում են մասնագիտացված ֆորումներում, կա՛մ նույնիսկ բաշխվում են որպես բաց կոդով նախագծեր, և, հետևաբար, եզակի չեն 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 — այս տվյալները .Net հարթակում գրված DLL ֆայլ էին;
ստացված .Net մոդուլը բեռնել է գործընթացի հիշողության մեջ powershell.exe օգտագործելով գործառույթը [System.Threading.Thread]::GetDomain().Load()(Load() ֆունկցիայի մանրամասն նկարագրությունը հասանելի է Microsoft-ի կայքում);
կատարել է գործառույթը GUyyvmzVhebFCw]::EhwwK() - DLL գրադարանի կատարումը սկսվեց դրանով `պարամետրերով vbsScriptPath, xorKey, vbsScriptName. Պարամետր xorKey պահվում է վերջնական օգտակար բեռի և պարամետրերի վերծանման բանալին vbsScriptPath и vbsScriptName փոխանցվել են VBS սկրիպտը autorun-ում գրանցելու համար:
DLL գրադարանի նկարագրությունը
Ապակոմպիլացված ձևով bootloader-ն այսպիսի տեսք ուներ.
Loader ապակոմպիլացված ձևով (գործառույթը, որով սկսվել է DLL գրադարանի կատարումը, ընդգծված է կարմիրով)
Bootloader-ը պաշտպանված է .Net Reactor պաշտպանով: De4dot կոմունալը հիանալի աշխատանք է կատարում այս պաշտպանիչը հեռացնելու համար:
Այս բեռնիչը.
ներարկել է օգտակար բեռը համակարգի գործընթացին (այս օրինակում այն svchost.exe);
Ես ավելացրել եմ VBS սցենար autorun-ում:
Օգտակար բեռի ներարկում
Դիտարկենք այն ֆունկցիան, որը կանչել է 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 ֆայլ է ավելացրել autorun ֆայլերի ցանկում, երբ օգտատերը մուտք է գործել և այդպիսով կցվել վարակված համակարգչին: 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 ներարկումն իրականացնելու համար պահանջվող shell կոդը էր:
Shellcode զանգվածից array2 փոխանցվել է որպես ֆունկցիայի արժեք lpPrevWndFunc ֆունկցիայի մեջ CallWindowProcA. lpPrevWndFunc — հետ կանչելու գործառույթը, դրա նախատիպն ունի հետևյալ տեսքը.
Այսպիսով, երբ դուք գործարկում եք գործառույթը CallWindowProcA պարամետրերով hWnd, Msg, wParam, lParam զանգվածի shellcode-ը կատարվում է array2 փաստարկներով hWnd и Msg. hWnd գործարկվող ֆայլի ուղին պարունակող տողի ցուցիչ է svchost.exeԻսկ Msg - ցուցիչ դեպի վերջնական օգտակար բեռ:
Shellcode-ը ստացել է ֆունկցիայի հասցեներ kernel32.dll и ntdll32.dll հիմնվելով դրանց անունների հեշ արժեքների վրա և ներարկել վերջնական ծանրաբեռնվածությունը գործընթացի հիշողության մեջ svchost.exeօգտագործելով Process Hollowing տեխնիկան (այս մասին ավելին կարող եք կարդալ այստեղ Հոդված) Shellcode-ը ներարկելիս.
գործընթաց է ստեղծել svchost.exe կասեցված վիճակում՝ օգտագործելով ֆունկցիան CreateProcessW;
ապա թաքցրեց բաժնի ցուցադրումը գործընթացի հասցեների տարածքում svchost.exe օգտագործելով գործառույթը NtUnmapViewOfSection. Այսպիսով, ծրագիրը ազատեց սկզբնական գործընթացի հիշողությունը svchost.exeայնուհետև այս հասցեում հիշողություն հատկացնել օգտակար բեռի համար.
Գործընթացի հասցեների տարածությունում հատկացված հիշողությունը օգտակար բեռի համար svchost.exe օգտագործելով գործառույթը VirtualAllocEx;
Ներարկման գործընթացի սկիզբ
գրել է օգտակար բեռի բովանդակությունը գործընթացի հասցեների տարածության մեջ svchost.exe օգտագործելով գործառույթը WriteProcessMemory (ինչպես ստորև ներկայացված սքրինշոթում);
վերսկսել է գործընթացը svchost.exe օգտագործելով գործառույթը ResumeThread.
Ներարկման գործընթացի ավարտը
Ներբեռնվող չարամիտ ծրագիր
Նկարագրված գործողությունների արդյունքում վարակված համակարգում տեղադրվել է RAT դասի մի քանի չարամիտ ծրագրերից մեկը։ Ստորև բերված աղյուսակը թվարկում է հարձակման ժամանակ օգտագործվող չարամիտ ծրագիրը, որը մենք կարող ենք վստահորեն վերագրել հարձակվողների մեկ խմբին, քանի որ նմուշները մուտք են գործել նույն հրամանի և կառավարման սերվերը:
Բաշխված չարամիտ ծրագրերի օրինակներ նույն վերահսկիչ սերվերով
Այստեղ ուշագրավ է երկու բան.
Նախ, հենց այն փաստը, որ հարձակվողները օգտագործել են միանգամից մի քանի տարբեր RAT ընտանիքներ: Այս վարքագիծը բնորոշ չէ հայտնի կիբեր խմբերին, որոնք հաճախ օգտագործում են մոտավորապես նույն գործիքները, որոնք ծանոթ են իրենց:
Երկրորդ, RATKing-ն օգտագործել է չարամիտ ծրագրեր, որոնք կամ վաճառվում են մասնագիտացված ֆորումներում ցածր գնով, կամ նույնիսկ բաց կոդով նախագիծ է:
Արշավում օգտագործվող չարամիտ ծրագրերի ավելի ամբողջական ցանկը՝ մեկ կարևոր նախազգուշացմամբ, տրված է հոդվածի վերջում:
Խմբի մասին
Մենք չենք կարող նկարագրված չարամիտ արշավը վերագրել որևէ հայտնի հարձակվողի: Առայժմ մենք կարծում ենք, որ այդ հարձակումներն իրականացվել են սկզբունքորեն նոր խմբի կողմից։ Ինչպես սկզբում գրել էինք, մենք այն անվանեցինք RATKing:
VBS սկրիպտը ստեղծելու համար խումբը հավանաբար օգտագործել է օգտակար գործիքին նման գործիք VBS-Crypter մշակողից ՆՅԱՆ-x-ԿԱՏ. Սա ցույց է տալիս սցենարի նմանությունը, որը ստեղծում է այս ծրագիրը հարձակվողների սցենարի հետ: Մասնավորապես, նրանք երկուսն էլ.
կատարել հետաձգված կատարում՝ օգտագործելով ֆունկցիան 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):