RATKing: új kampány távoli hozzáférésű trójai programokkal
Május végén felfedeztünk egy kampányt a Remote Access Trojan (RAT) rosszindulatú programok terjesztésére – olyan programokra, amelyek lehetővé teszik a támadók számára, hogy távolról irányítsák a fertőzött rendszert.
Az általunk vizsgált csoportot az jellemezte, hogy egyetlen RAT-családot sem választott ki fertőzésre. A kampány során számos trójai támadást észleltek (mindegyik széles körben elérhető volt). Ezzel a funkcióval a csoport a patkánykirályra emlékeztetett bennünket – egy mitikus állatra, amely összefonódó farkú rágcsálókból áll.
Az eredeti K. N. Rossikov „Egerek és egérszerű rágcsálók, a gazdaságilag legfontosabbak” (1908) című monográfiájából származik.
Ennek a lénynek a tiszteletére RATK-nak neveztük el azt a csoportot, amelyet fontolgatunk. Ebben a bejegyzésben részletesen kitérünk arra, hogy a támadók hogyan hajtották végre a támadást, milyen eszközöket használtak, és megosztjuk gondolatainkat a kampányhoz való hozzárendelésről.
A támadás előrehaladása
Ebben a kampányban minden támadás a következő algoritmus szerint történt:
A felhasználó adathalász e-mailt kapott a Google Drive-ra mutató linkkel.
A hivatkozás segítségével az áldozat letöltött egy rosszindulatú VBS-szkriptet, amely egy DLL-könyvtárat írt elő, amely betölti a végső hasznos adatot a Windows rendszerleíró adatbázisába, és elindította a PowerShellt annak végrehajtására.
A DLL-könyvtár a végső hasznos adatot – tulajdonképpen a támadók által használt RAT-ok egyikét – a rendszerfolyamatba fecskendezte, és egy VBS-szkriptet regisztrált az automatikus futtatásban, hogy megvegye a lábát a fertőzött gépen.
A végső hasznos adatot egy rendszerfolyamatban hajtották végre, és lehetővé tette a támadó számára, hogy irányítsa a fertőzött számítógépet.
Sematikusan a következőképpen ábrázolható:
Ezután az első három szakaszra fogunk összpontosítani, mivel minket a rosszindulatú programok kézbesítési mechanizmusa érdekel. Magának a kártevőnek a működési mechanizmusát nem írjuk le részletesen. Széles körben elérhetőek - akár speciális fórumokon értékesítik, akár nyílt forráskódú projektekként terjesztik -, ezért nem csak a RATKing csoportra jellemzőek.
A támadási szakaszok elemzése
1. szakasz: Adathalász e-mail
A támadás azzal kezdődött, hogy az áldozat rosszindulatú levelet kapott (a támadók különböző sablonokat használtak szöveggel; az alábbi képernyőképen egy példa látható). Az üzenet egy hiteles adattárra mutató hivatkozást tartalmazott drive.google.com, ami állítólag egy PDF dokumentum letöltési oldalához vezetett.
Példa az adathalász e-mailekre
Valójában azonban egyáltalán nem egy PDF dokumentumot töltöttek be, hanem egy VBS-szkriptet.
Amikor rákattintott az e-mailben található hivatkozásra a fenti képernyőképen, egy fájl neve Cargo Flight Details.vbs. Ebben az esetben a támadók meg sem próbálták törvényes dokumentumnak álcázni az aktát.
Ugyanakkor ennek a kampánynak a részeként felfedeztünk egy forgatókönyvet Cargo Trip Detail.pdf.vbs. Ez már érvényes PDF-nek is megfelelhet, mert a Windows alapértelmezés szerint elrejti a fájlkiterjesztéseket. Igaz, ebben az esetben még gyanút kelthet az ikonja, amely a VBS forgatókönyvének felelt meg.
Ebben a szakaszban az áldozat felismerte a megtévesztést: csak nézze meg egy pillanatra közelebbről a letöltött fájlokat. Az ilyen adathalász kampányokban azonban a támadók gyakran egy figyelmetlen vagy rohanó felhasználóra hagyatkoznak.
2. szakasz. VBS-szkript működése
A VBS-szkript, amelyet a felhasználó véletlenül megnyithatott, egy DLL-könyvtárat regisztrált a Windows rendszerleíró adatbázisában. A forgatókönyvet elhomályosították: a benne lévő sorokat bájtokként írták, tetszőleges karakterrel elválasztva.
Példa egy homályos szkriptre
A deobfuszkálási algoritmus meglehetősen egyszerű: minden harmadik karaktert kizártak az obfuszkált karakterláncból, majd az eredményt a base16-ból az eredeti karakterláncba dekódolták. Például az értéktől 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (a fenti képernyőképen kiemelve) a kapott sor az volt WScript.Shell.
A karakterláncok deobfuszkálásához a Python függvényt használtuk:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Az alábbiakban a 9–10. sorban kiemeljük azt az értéket, amelynek deobfuszkálása DLL-fájlt eredményezett. Ő volt az, akit a következő szakaszban elindítottak a PowerShell segítségével.
Karakterlánc zavart DLL-lel
A VBS-szkriptben minden egyes funkció végrehajtásra került a karakterláncok deobfuszkálása során.
A szkript futtatása után a függvény meghívásra került wscript.sleep — halasztott végrehajtás végrehajtására szolgált.
Ezután a szkript működött a Windows rendszerleíró adatbázisával. Ehhez WMI technológiát használt. Segítségével egyedi kulcsot hoztak létre, és a paraméterébe írtuk a végrehajtható fájl törzsét. A rendszerleíró adatbázist a WMI-n keresztül a következő paranccsal lehetett elérni:
Egy VBS-szkript által a rendszerleíró adatbázisba írt bejegyzés
3. szakasz. A DLL könyvtár működése
A harmadik szakaszban a rosszindulatú DLL betöltötte a végső hasznos adatot, befecskendezte a rendszerfolyamatba, és biztosította, hogy a VBS szkript automatikusan elinduljon, amikor a felhasználó bejelentkezik.
Futtassa a PowerShell-en keresztül
A DLL-t a következő PowerShell paranccsal hajtották végre:
névvel kapott nyilvántartási érték adatot rnd_value_name — ez az adat egy .Net platformon írt DLL fájl volt;
a kapott .Net modult betöltötte a folyamatmemóriába powershell.exe funkció használatával [System.Threading.Thread]::GetDomain().Load()(a Load() függvény részletes leírása elérhető a Microsoft webhelyén);
teljesítette a funkciót GUyyvmzVhebFCw]::EhwwK() - vele kezdődött a DLL könyvtár végrehajtása - paraméterekkel vbsScriptPath, xorKey, vbsScriptName... Paraméter xorKey tárolta a kulcsot a végső hasznos adat visszafejtéséhez és a paramétereket vbsScriptPath и vbsScriptName át lettek helyezve egy VBS-szkript regisztrálása érdekében az automatikus futtatásban.
A DLL könyvtár leírása
Dekompilált formában a rendszerbetöltő így nézett ki:
Betöltő dekompilált formában (a funkció, amellyel a DLL-könyvtár végrehajtása elkezdődött, pirossal van aláhúzva)
A rendszerbetöltőt a .Net Reactor protektor védi. A de4dot segédprogram kiváló munkát végez a védő eltávolításában.
Ez a betöltő:
beadta a hasznos terhet a rendszerfolyamatba (ebben a példában ez svchost.exe);
Hozzáadtam egy VBS-szkriptet az automatikus futtatáshoz.
Teherbefecskendezés
Nézzük meg a PowerShell-szkript által meghívott függvényt.
A PowerShell-szkript által meghívott függvény
Ez a funkció a következő műveleteket hajtotta végre:
dekódolt két adatkészlet (array и array2 a képernyőképen). Eredetileg gzip használatával tömörítették, és XOR algoritmussal titkosították a kulccsal xorKey;
adatok másolása a lefoglalt memóriaterületekre. Adatok innen array - a mutatott memóriaterületre intPtr (payload pointer a képernyőképen); adatok innen array2 - a mutatott memóriaterületre intPtr2 (shellcode pointer a képernyőképen);
függvénynek nevezzük CallWindowProcA(описание Ez a funkció a Microsoft webhelyén érhető el) a következő paraméterekkel (a paraméterek nevei alább láthatók, a képernyőképen ugyanabban a sorrendben, de munkaértékekkel):
lpPrevWndFunc - mutató az adatokra array2;
hWnd — mutató a végrehajtható fájl elérési útját tartalmazó karakterláncra svchost.exe;
Msg - mutató az adatokra array;
wParam, lParam — üzenetparaméterek (ebben az esetben ezeket a paramétereket nem használták, és 0 értékük volt);
létrehozott egy fájlt %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlAhol <name> - ez a paraméter első 4 karaktere vbsScriptName (a képernyőképen az ezzel a művelettel rendelkező kódrészlet a paranccsal kezdődik File.Copy). Ily módon a kártevő hozzáadott egy URL-fájlt az automatikus futtatási fájlok listájához, amikor a felhasználó bejelentkezett, és így csatlakozott a fertőzött számítógéphez. Az URL-fájl a szkriptre mutató hivatkozást tartalmazott:
Az injektálás végrehajtásának megértéséhez dekódoltuk az adattömböket array и array2. Ehhez a következő Python függvényt használtuk:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Ennek eredményeként megtudtuk, hogy:
array PE-fájl volt – ez a végső rakomány;
array2 volt az injekció végrehajtásához szükséges shellkód.
Shellkód egy tömbből array2 függvényértékként adta át lpPrevWndFunc függvénybe CallWindowProcA. lpPrevWndFunc — visszahívási funkció, prototípusa így néz ki:
Tehát amikor futtatja a funkciót CallWindowProcA paraméterekkel hWnd, Msg, wParam, lParam shellcode a tömbből végrehajtódik array2 érvekkel hWnd и Msg. hWnd egy mutató egy karakterláncra, amely a futtatható fájl elérési útját tartalmazza svchost.exeÉs Msg — mutató a végső hasznos teherre.
A shellcode függvénycímeket kapott innen kernel32.dll и ntdll32.dll a nevükből származó hash értékek alapján, és a végső hasznos terhet a folyamatmemóriába fecskendezték svchost.exea Process Hollowing technikával (erről bővebben itt olvashat cikk). A shellkód beadásakor:
folyamatot hozott létre svchost.exe felfüggesztett állapotban a funkció használatával CreateProcessW;
majd elrejtette a szakasz megjelenítését a folyamat címterében svchost.exe funkció használatával NtUnmapViewOfSection. Így a program felszabadította az eredeti folyamat memóriáját svchost.exehogy ezután memóriát foglaljon le a hasznos adat számára ezen a címen;
lefoglalt memóriát a hasznos adat számára a folyamat címterében svchost.exe funkció használatával VirtualAllocEx;
Az injekciós folyamat kezdete
beírta a hasznos adat tartalmát a folyamat címterébe svchost.exe funkció használatával WriteProcessMemory (mint az alábbi képernyőképen);
folytatta a folyamatot svchost.exe funkció használatával ResumeThread.
Az injekciós folyamat befejezése
Letölthető rosszindulatú programok
A leírt műveletek eredményeként a fertőzött rendszerre a számos RAT-osztályú kártevő egyike került telepítésre. Az alábbi táblázat felsorolja a támadás során használt rosszindulatú programokat, amelyeket nyugodtan tulajdoníthatunk a támadók egy csoportjának, mivel a minták ugyanahhoz a parancs- és vezérlőkiszolgálóhoz fértek hozzá.
Példák elosztott rosszindulatú programokra ugyanazzal a vezérlőkiszolgálóval
Itt két dolog figyelemre méltó.
Először is az a tény, hogy a támadók több különböző RAT családot használtak egyszerre. Ez a viselkedés nem jellemző a jól ismert kibercsoportokra, amelyek gyakran hozzávetőlegesen ugyanazt az eszközkészletet használják, mint a számukra ismerős.
Másodszor, a RATKing olyan rosszindulatú programokat használt, amelyeket vagy speciális fórumokon árulnak alacsony áron, vagy akár nyílt forráskódú projektek is.
A kampányban használt rosszindulatú programok teljesebb listája – egy fontos figyelmeztetéssel – a cikk végén található.
A csoportról
A leírt rosszindulatú kampányt egyetlen ismert támadónak sem tudjuk tulajdonítani. Egyelőre úgy gondoljuk, hogy ezeket a támadásokat egy alapvetően új csoport követte el. Ahogy az elején írtuk, RATKingnak hívtuk.
A VBS-szkript létrehozásához a csoport valószínűleg a segédprogramhoz hasonló eszközt használt VBS-Crypter a fejlesztőtől NYAN-x-CAT. Ezt jelzi a program által létrehozott szkript és a támadók szkriptjének hasonlósága. Konkrétan mindkettő:
késleltetett végrehajtást hajt végre a funkció segítségével Sleep;
WMI használata;
regisztrálja a végrehajtható fájl törzsét rendszerleíró kulcsparaméterként;
futtassa ezt a fájlt a PowerShell segítségével a saját címterében.
Az egyértelműség kedvéért hasonlítsa össze a PowerShell parancsot egy fájl futtatásához a rendszerleíró adatbázisból, amelyet a VBS-Crypter segítségével létrehozott szkript használ:
Vegye figyelembe, hogy a támadók a NYAN-x-CAT másik segédprogramját használták az egyik hasznos adatként - LimeRAT.
A C&C szerverek címei jelzik az RATKing egy másik jellegzetességét: a csoport a dinamikus DNS szolgáltatásokat részesíti előnyben (lásd a C&C listát az IoC táblázatban).
IoC
Az alábbi táblázat azoknak a VBS-szkripteknek a teljes listáját tartalmazza, amelyek nagy valószínűséggel a leírt kampányhoz köthetők. Mindezek a szkriptek hasonlóak, és megközelítőleg ugyanazt a műveletsort hajtják végre. Mindegyik RAT osztályú rosszindulatú programokat juttat be egy megbízható Windows-folyamatba. Mindegyik rendelkezik C&C-címmel, amelyet a dinamikus DNS-szolgáltatások segítségével regisztráltak.
Nem állíthatjuk azonban, hogy ezeket a szkripteket ugyanazok a támadók terjesztették, kivéve az azonos C&C-című mintákat (például kimjoy007.dyndns.org).