Fine de majo, ni malkovris kampanjon por distribui malware de Remote Access Trojan (RAT)—programoj, kiuj permesas al atakantoj malproksime kontroli infektitan sistemon.
La grupo, kiun ni ekzamenis, distingiĝis pro la fakto, ke ĝi ne elektis iun specifan RAT-familion por infekto. Pluraj trojanoj estis rimarkitaj en atakoj ene de la kampanjo (ĉiuj el kiuj estis vaste haveblaj). Per ĉi tiu funkcio, la grupo memorigis al ni la ratan reĝon - mita besto, kiu konsistas el ronĝuloj kun interplektitaj vostoj.
La originalo estas prenita el la monografio de K. N. Rossikov "Musoj kaj mus-similaj ronĝuloj, la plej ekonomie gravaj" (1908)
Honore al ĉi tiu estaĵo, ni nomis la grupon, kiun ni konsideras RATKing. En ĉi tiu afiŝo, ni eniros en detalojn pri kiel la atakantoj faris la atakon, kiajn ilojn ili uzis, kaj ankaŭ dividos niajn pensojn pri atribuo por ĉi tiu kampanjo.
Progreso de la atako
Ĉiuj atakoj en ĉi tiu kampanjo okazis laŭ la sekva algoritmo:
La uzanto ricevis retpoŝton pri phishing kun ligilo al Google Drive.
Uzante la ligon, la viktimo elŝutis malican VBS-skripton, kiu specifis DLL-bibliotekon por ŝargi la finan utilan ŝarĝon en la Vindoza registro kaj lanĉis PowerShell por efektivigi ĝin.
La DLL-biblioteko injektis la finan utilan ŝarĝon - fakte, unu el la RAToj uzataj de atakantoj - en la sistemprocezon kaj registris VBS-skripton en aŭtorkuro por akiri piedtenejon en la infektita maŝino.
La fina utila ŝarĝo estis efektivigita en sistemprocezo kaj donis al la atakanto la kapablon kontroli la infektitan komputilon.
Skeme ĝi povas esti reprezentita jene:
Poste, ni koncentriĝos pri la unuaj tri etapoj, ĉar ni interesiĝas pri la mekanismo de livero de malware. Ni ne priskribos detale la mekanismon de funkciado de la malware mem. Ili estas vaste haveblaj - aŭ venditaj en specialigitaj forumoj, aŭ eĉ distribuitaj kiel malfermkodaj projektoj - kaj tial ne estas unikaj al la grupo RATKing.
Analizo de atakfazoj
Etapo 1. Phishing-retpoŝto
La atako komenciĝis kun la viktimo ricevanta malican leteron (la atakantoj uzis malsamajn ŝablonojn kun teksto; la ekrankopio malsupre montras unu ekzemplon). La mesaĝo enhavis ligon al legitima deponejo drive.google.com, kiu supozeble kondukis al PDF-dokumenta elŝuta paĝo.
Phishing retpoŝta ekzemplo
Tamen, fakte, ĝi tute ne estis PDF-dokumento kiu estis ŝarĝita, sed VBS-skripto.
Kiam vi alklakis la ligilon de la retpoŝto en la supra ekrankopio, oni nomis dosieron Cargo Flight Details.vbs. En ĉi tiu kazo, la atakantoj eĉ ne provis kaŝvesti la dosieron kiel legitima dokumento.
Samtempe, kadre de ĉi tiu kampanjo, ni malkovris skripton nomitan Cargo Trip Detail.pdf.vbs. Ĝi jam povus pasi por legitima PDF ĉar Vindozo kaŝas dosierajn etendaĵojn defaŭlte. Vere, en ĉi tiu kazo, suspekto ankoraŭ povus esti vekita de ĝia ikono, kiu respondis al la VBS-skripto.
En ĉi tiu etapo, la viktimo povus rekoni la trompon: nur rigardu pli detale la elŝutitajn dosierojn dum sekundo. Tamen, en tiaj phishing kampanjoj, atakantoj ofte fidas je senatenta aŭ rapida uzanto.
Etapo 2. VBS-skripto-operacio
La VBS-skripto, kiun la uzanto povis malfermi pretervole, registris DLL-bibliotekon en la Vindoza registro. La skripto estis malklarigita: la linioj en ĝi estis skribitaj kiel bajtoj apartigitaj per arbitra signo.
Ekzemplo de malklarigita skribo
La malklarig-algoritmo estas sufiĉe simpla: ĉiu tria signo estis ekskludita de la malklarigita ĉeno, post kio la rezulto estis malkodita de bazo16 en la originan ĉenon. Ekzemple, de la valoro 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (elstarigita en la supra ekrankopio) la rezulta linio estis WScript.Shell.
Por malklarigi ŝnurojn, ni uzis la Python-funkcion:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Malsupre, sur linioj 9–10, ni reliefigas la valoron, kies malklarigado rezultigis DLL-dosieron. Estis li kiu estis lanĉita ĉe la sekva etapo uzante PowerShell.
Ŝnuro kun malklarigita DLL
Ĉiu funkcio en la VBS-manuskripto estis efektivigita kiam la ŝnuroj estis malkonfuzitaj.
Post rulado de la skripto, la funkcio estis vokita wscript.sleep — ĝi estis uzata por plenumi prokrastan ekzekuton.
Poste, la skripto funkciis kun la Vindoza registro. Li uzis WMI-teknologion por tio. Kun ĝia helpo, unika ŝlosilo estis kreita, kaj la korpo de la plenumebla dosiero estis skribita al ĝia parametro. La registro estis alirita per WMI per la sekva komando:
En la tria etapo, la malica DLL ŝarĝis la finan utilan ŝarĝon, injektis ĝin en la sisteman procezon kaj certigis, ke la VBS-skripto aŭtomate ekfunkciis kiam la uzanto ensalutis.
Kuru per PowerShell
La DLL estis ekzekutita per la sekva komando en PowerShell:
ricevis registrajn valorajn datumojn kun nomo rnd_value_name — ĉi tiu datumo estis DLL-dosiero skribita sur la platformo .Net;
ŝarĝis la rezultan .Net-modulon en procezmemoron powershell.exe uzante la funkcion [System.Threading.Thread]::GetDomain().Load()(detala priskribo de la funkcio Load(). disponebla en la retejo de Microsoft);
plenumis la funkcion GUyyvmzVhebFCw]::EhwwK() - la ekzekuto de la DLL-biblioteko komenciĝis per ĝi - kun parametroj vbsScriptPath, xorKey, vbsScriptName... Parametro xorKey stokis la ŝlosilon por deĉifri la finan utilan ŝarĝon, kaj la parametrojn vbsScriptPath и vbsScriptName estis transdonitaj por registri VBS-skripton en aŭtorun.
Priskribo de la DLL-biblioteko
En malkompilita formo, la ekŝargilo aspektis jene:
Ŝargilo en malkompilita formo (la funkcio kun kiu la ekzekuto de la DLL-biblioteko komenciĝis estas substrekita ruĝe)
La ekŝargilo estas protektita de la protektanto .Net Reactor. La ilo de4dot faras bonegan laboron forigi ĉi tiun protektanton.
Ĉi tiu ŝargilo:
injektis la utilan ŝarĝon en la sistemprocezon (en ĉi tiu ekzemplo ĝi svchost.exe);
Mi aldonis VBS-skripton al aŭtorun.
Utilŝarĝa injekto
Ni rigardu la funkcion, kiun la PowerShell-skripto vokis.
Funkcio vokita de PowerShell-skripto
Ĉi tiu funkcio plenumis la sekvajn agojn:
deĉifris du datumajn arojn (array и array2 en la ekrankopio). Ili estis origine kunpremitaj uzante gzip kaj ĉifritaj per la XOR-algoritmo per la ŝlosilo xorKey;
kopiitaj datumoj al asignitaj memorareoj. Datumoj de array - al la memorareo indikita intPtr (payload pointer en la ekrankopio); datumoj de array2 - al la memorareo indikita intPtr2 (shellcode pointer en la ekrankopio);
nomita la funkcio CallWindowProcA(la priskribo Ĉi tiu funkcio disponeblas en la retejo de Microsoft) kun la sekvaj parametroj (la nomoj de la parametroj estas listigitaj malsupre, en la ekrankopio ili estas en la sama ordo, sed kun laborvaloroj):
lpPrevWndFunc - montrilo al datumoj de array2;
hWnd — montrilo al ĉeno enhavanta la vojon al la plenumebla dosiero svchost.exe;
Msg - montrilo al datumoj de array;
wParam, lParam - mesaĝaj parametroj (en ĉi tiu kazo, ĉi tiuj parametroj ne estis uzataj kaj havis valorojn de 0);
kreis dosieron %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlkie <name> - ĉi tiuj estas la unuaj 4 signoj de la parametro vbsScriptName (en la ekrankopio, la kodfragmento kun ĉi tiu ago komenciĝas per la komando File.Copy). Tiamaniere, la malware aldonis URL-dosieron al la listo de aŭtorunaj dosieroj kiam la uzanto ensalutis kaj tiel aliĝis al la infektita komputilo. La URL-dosiero enhavis ligon al la skripto:
Por kompreni kiel la injekto estis farita, ni malĉifris la datumajn tabelojn array и array2. Por fari tion ni uzis la sekvan Python-funkcion:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Kiel rezulto, ni eksciis, ke:
array was a PE-dosiero - ĉi tio estas la fina ŝarĝo;
array2 estis la ŝelkodo postulata por efektivigi la injekton.
Ŝelkodo de tabelo array2 pasita kiel funkciovaloro lpPrevWndFunc en funkcion CallWindowProcA. lpPrevWndFunc — revokfunkcio, ĝia prototipo aspektas jene:
Do kiam vi rulas la funkcion CallWindowProcA kun parametroj hWnd, Msg, wParam, lParam shellcode de la tabelo estas ekzekutita array2 kun argumentoj hWnd и Msg. hWnd estas montrilo al ĉeno enhavanta la vojon al la plenumebla dosiero svchost.exekaj Msg — montrilo al la fina utila ŝarĝo.
La ŝelkodo ricevis funkcio-adresojn de kernel32.dll и ntdll32.dll surbaze de hash valoroj de iliaj nomoj kaj injektis la finan utilan ŝarĝon en la procezmemoron svchost.exeuzante la Process Hollowing-teknikon (vi povas legi pli pri ĝi en ĉi tio artikolo). Injektante la ŝelkodon:
kreis procezon svchost.exe en suspendita stato uzante la funkcion CreateProcessW;
tiam kaŝis la ekranon de la sekcio en la adresspaco de la procezo svchost.exe uzante la funkcion NtUnmapViewOfSection. Tiel, la programo liberigis la memoron pri la origina procezo svchost.exepor tiam asigni memoron por la utila ŝarĝo ĉe ĉi tiu adreso;
asignis memoron por la utila ŝarĝo en la proceza adresspaco svchost.exe uzante la funkcion VirtualAllocEx;
Komenco de injekta procezo
skribis la enhavon de la utila ŝarĝo en la procezan adresspacon svchost.exe uzante la funkcion WriteProcessMemory (kiel en la ekrankopio malsupre);
rekomencis la procezon svchost.exe uzante la funkcion ResumeThread.
Kompletigante la injektan procezon
Elŝutebla malware
Kiel rezulto de la priskribitaj agoj, unu el pluraj RAT-klaso malware estis instalita sur la infektita sistemo. La suba tabelo listigas la malware uzatan en la atako, kiun ni povas memfide atribui al unu grupo de atakantoj, ĉar la specimenoj aliris la saman komandon kaj kontrolservilon.
Ekzemploj de distribuita malware kun la sama kontrolservilo
Du aferoj estas rimarkindaj ĉi tie.
Unue, la fakto mem, ke la atakantoj uzis plurajn malsamajn RAT-familiojn samtempe. Ĉi tiu konduto ne estas tipa por konataj cibergrupoj, kiuj ofte uzas proksimume la saman aron de iloj kiuj estas konataj al ili.
Due, RATKing uzis malbonware kiu estas aŭ vendita sur specialigitaj forumoj por malalta prezo, aŭ eĉ estas malfermfonta projekto.
Pli kompleta listo de malware uzataj en la kampanjo—kun unu grava averto—estas donita ĉe la fino de la artikolo.
Pri la grupo
Ni ne povas atribui la priskribitan malican kampanjon al iuj konataj atakantoj. Nuntempe, ni kredas, ke ĉi tiuj atakoj estis faritaj de fundamente nova grupo. Kiel ni skribis komence, ni nomis ĝin RATKing.
Por krei la VBS-skripton, la grupo verŝajne uzis ilon similan al la utileco VBS-Crypter de la programisto NYAN-x-CAT. Ĉi tio estas indikita per la simileco de la skripto, kiun ĉi tiu programo kreas kun la skripto de la atakantoj. Specife, ili ambaŭ:
plenumi prokrastitan ekzekuton uzante la funkcion Sleep;
uzu WMI;
registri la korpon de la plenumebla dosiero kiel registra ŝlosila parametro;
ekzekuti ĉi tiun dosieron uzante PowerShell en sia propra adresspaco.
Por klareco, komparu la PowerShell-komandon por ruli dosieron el la registro, kiu estas uzata de skripto kreita per VBS-Crypter:
Notu, ke la atakantoj uzis alian ilon de NYAN-x-CAT kiel unu el la utilaj ŝarĝoj - KalkoRAT.
La adresoj de la C&C-serviloj indikas alian karakterizaĵon de RATKing: la grupo preferas dinamikajn DNS-servojn (vidu la liston de C&C en la IoC-tabelo).
IoC
La suba tabelo provizas kompletan liston de VBS-skriptoj, kiuj plej verŝajne povas esti atribuitaj al la priskribita kampanjo. Ĉiuj ĉi tiuj skriptoj estas similaj kaj plenumas proksimume la saman sinsekvon de agoj. Ĉiuj ili injektas RAT-klasan malware en fidindan Vindozan procezon. Ĉiuj ili havas C&C-adresojn registritajn per Dinamika DNS-servoj.
Tamen ni ne povas aserti, ke ĉiuj ĉi tiuj skriptoj estis distribuitaj de la samaj atakantoj, escepte de specimenoj kun la samaj C&C-adresoj (ekzemple, kimjoy007.dyndns.org).