RATKing: ny kampagne med fjernadgang trojanske heste
I slutningen af maj opdagede vi en kampagne for at distribuere Remote Access Trojan (RAT) malware – programmer, der gør det muligt for angribere at fjernstyre et inficeret system.
Den gruppe, vi undersøgte, var kendetegnet ved, at den ikke valgte nogen specifik RAT-familie til infektion. Adskillige trojanske heste blev bemærket i angreb inden for kampagnen (som alle var bredt tilgængelige). Med dette indslag mindede gruppen os om rottekongen - et mytisk dyr, der består af gnavere med sammenflettede haler.
Originalen er taget fra monografien af K. N. Rossikov "Mus og muslignende gnavere, de økonomisk vigtigste" (1908)
Til ære for dette væsen navngav vi den gruppe, vi overvejer at RATKing. I dette indlæg vil vi gå i detaljer om, hvordan angriberne udførte angrebet, hvilke værktøjer de brugte, og også dele vores tanker om tilskrivning til denne kampagne.
Angrebets fremskridt
Alle angreb i denne kampagne fandt sted i henhold til følgende algoritme:
Brugeren modtog en phishing-e-mail med et link til Google Drev.
Ved at bruge linket downloadede offeret et ondsindet VBS-script, der specificerede et DLL-bibliotek til at indlæse den endelige nyttelast i Windows-registreringsdatabasen og startede PowerShell for at udføre det.
DLL-biblioteket injicerede den endelige nyttelast - faktisk en af de RAT'er, der blev brugt af angribere - i systemprocessen og registrerede et VBS-script i autorun for at få fodfæste i den inficerede maskine.
Den endelige nyttelast blev udført i en systemproces og gav angriberen mulighed for at kontrollere den inficerede computer.
Skematisk kan det repræsenteres således:
Dernæst vil vi fokusere på de første tre faser, da vi er interesserede i malware-leveringsmekanismen. Vi vil ikke beskrive i detaljer mekanismen for driften af selve malwaren. De er bredt tilgængelige - enten solgt på specialiserede fora, eller endda distribueret som open source-projekter - og er derfor ikke unikke for RATKing-gruppen.
Analyse af angrebsstadier
Trin 1. Phishing-e-mail
Angrebet begyndte med, at offeret modtog et ondsindet brev (angriberne brugte forskellige skabeloner med tekst; skærmbilledet nedenfor viser et eksempel). Meddelelsen indeholdt et link til et lovligt lager drive.google.com, hvilket angiveligt førte til en side for download af PDF-dokument.
Eksempel på phishing-e-mail
Men faktisk var det slet ikke et PDF-dokument, der blev indlæst, men et VBS-script.
Når du klikkede på linket fra e-mailen i skærmbilledet ovenfor, blev en fil navngivet Cargo Flight Details.vbs. I dette tilfælde forsøgte angriberne ikke engang at skjule filen som et legitimt dokument.
På samme tid, som en del af denne kampagne, opdagede vi et script ved navn Cargo Trip Detail.pdf.vbs. Det kunne allerede passere til en legitim PDF, fordi Windows skjuler filtypenavne som standard. Sandt nok, i dette tilfælde kunne mistanke stadig vækkes af dets ikon, som svarede til VBS-scriptet.
På dette stadie kunne offeret genkende bedraget: bare se nærmere på de downloadede filer et sekund. Men i sådanne phishing-kampagner stoler angribere ofte på en uopmærksom eller forhastet bruger.
Trin 2. VBS script operation
VBS-scriptet, som brugeren kunne åbne utilsigtet, registrerede et DLL-bibliotek i Windows-registreringsdatabasen. Scriptet var sløret: linjerne i det blev skrevet som bytes adskilt af et vilkårligt tegn.
Eksempel på et sløret script
Deobfuscation-algoritmen er ret simpel: Hvert tredje tegn blev udelukket fra den obfuscerede streng, hvorefter resultatet blev afkodet fra base16 til den originale streng. For eksempel fra værdien 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (fremhævet i skærmbilledet ovenfor) var den resulterende linje WScript.Shell.
For at deobfuscate strenge brugte vi Python-funktionen:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Nedenfor, på linje 9-10, fremhæver vi den værdi, hvis deobfuscation resulterede i en DLL-fil. Det var ham, der blev lanceret på næste trin ved hjælp af PowerShell.
String med sløret DLL
Hver funktion i VBS-scriptet blev udført, da strengene blev deobfuscerede.
Efter at have kørt scriptet, blev funktionen kaldt wscript.sleep — det blev brugt til at udføre udskudt udførelse.
Dernæst arbejdede scriptet med Windows-registreringsdatabasen. Han brugte WMI-teknologi til dette. Med dens hjælp blev der oprettet en unik nøgle, og kroppen af den eksekverbare fil blev skrevet til dens parameter. Registret blev tilgået via WMI ved hjælp af følgende kommando:
En indtastning i registreringsdatabasen af et VBS-script
Trin 3. Drift af DLL-biblioteket
På tredje trin indlæste den ondsindede DLL den endelige nyttelast, injicerede den i systemprocessen og sikrede, at VBS-scriptet autostartede, når brugeren loggede på.
Kør via PowerShell
DLL'en blev udført ved hjælp af følgende kommando i PowerShell:
modtaget registerværdidata med navn rnd_value_name — disse data var en DLL-fil skrevet på .Net-platformen;
indlæste det resulterende .Net-modul i proceshukommelsen powershell.exe ved hjælp af funktionen [System.Threading.Thread]::GetDomain().Load()(detaljeret beskrivelse af Load()-funktionen tilgængelig på Microsofts websted);
udførte funktionen GUyyvmzVhebFCw]::EhwwK() - udførelsen af DLL-biblioteket begyndte med det - med parametre vbsScriptPath, xorKey, vbsScriptName. Parameter xorKey gemt nøglen til dekryptering af den endelige nyttelast og parametrene vbsScriptPath и vbsScriptName blev overført for at registrere et VBS-script i autorun.
Beskrivelse af DLL-biblioteket
I dekompileret form så bootloaderen sådan ud:
Loader i dekompileret form (funktionen, som udførelsen af DLL-biblioteket startede med, er understreget med rødt)
Bootloaderen er beskyttet af .Net Reactor-beskytteren. De4dot-værktøjet gør et fremragende stykke arbejde med at fjerne denne beskytter.
Denne læsser:
injicerede nyttelasten i systemprocessen (i dette eksempel er det svchost.exe);
Jeg tilføjede et VBS-script til autorun.
Nyttelast indsprøjtning
Lad os se på den funktion, som PowerShell-scriptet kaldte.
Funktion kaldet af PowerShell-script
Denne funktion udførte følgende handlinger:
dekrypteret to datasæt (array и array2 på skærmbilledet). De blev oprindeligt komprimeret ved hjælp af gzip og krypteret med XOR-algoritmen med nøglen xorKey;
kopierede data til tildelte hukommelsesområder. Data fra array - til hukommelsesområdet pegede på intPtr (payload pointer på skærmbilledet); data fra array2 - til hukommelsesområdet pegede på intPtr2 (shellcode pointer på skærmbilledet);
kaldet funktionen CallWindowProcA(описание Denne funktion er tilgængelig på Microsofts websted) med følgende parametre (navnene på parametrene er angivet nedenfor, på skærmbilledet er de i samme rækkefølge, men med arbejdsværdier):
lpPrevWndFunc - pointer til data fra array2;
hWnd — markør til en streng, der indeholder stien til den eksekverbare fil svchost.exe;
Msg - pointer til data fra array;
wParam, lParam — meddelelsesparametre (i dette tilfælde blev disse parametre ikke brugt og havde værdier på 0);
oprettet en fil %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlHvor <name> - dette er de første 4 tegn i parameteren vbsScriptName (i skærmbilledet begynder kodefragmentet med denne handling med kommandoen File.Copy). På denne måde tilføjede malwaren en URL-fil til listen over autorun-filer, når brugeren loggede på og dermed blev knyttet til den inficerede computer. URL-filen indeholdt et link til scriptet:
For at forstå, hvordan injektionen blev udført, dekrypterede vi dataarrayerne array и array2. For at gøre dette brugte vi følgende Python-funktion:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Som et resultat fandt vi ud af, at:
array var en PE-fil - dette er den endelige nyttelast;
array2 var den skalkode, der krævedes for at udføre injektionen.
Shellkode fra et array array2 videregivet som en funktionsværdi lpPrevWndFunc ind i en funktion CallWindowProcA. lpPrevWndFunc — tilbagekaldsfunktion, dens prototype ser sådan ud:
Så når du kører funktionen CallWindowProcA med parametre hWnd, Msg, wParam, lParam shellcode fra arrayet udføres array2 med argumenter hWnd и Msg. hWnd er en pegepind til en streng, der indeholder stien til den eksekverbare fil svchost.exeOg Msg — viser til den endelige nyttelast.
Shellkoden modtog funktionsadresser fra kernel32.dll и ntdll32.dll baseret på hashværdier fra deres navne og injiceret den endelige nyttelast i proceshukommelsen svchost.exeved hjælp af Process Hollowing-teknikken (du kan læse mere om det i dette artiklen). Ved indsprøjtning af shell-koden:
skabt en proces svchost.exe i suspenderet tilstand ved hjælp af funktionen CreateProcessW;
gemte derefter sektionens visning i processens adresseområde svchost.exe ved hjælp af funktionen NtUnmapViewOfSection. Således frigjorde programmet hukommelsen om den oprindelige proces svchost.exefor derefter at allokere hukommelse til nyttelasten på denne adresse;
allokeret hukommelse til nyttelasten i procesadresserummet svchost.exe ved hjælp af funktionen VirtualAllocEx;
Start af injektionsproces
skrev indholdet af nyttelasten ind i procesadresserummet svchost.exe ved hjælp af funktionen WriteProcessMemory (som i skærmbilledet nedenfor);
genoptog processen svchost.exe ved hjælp af funktionen ResumeThread.
Afslutning af injektionsprocessen
malware, der kan downloades
Som et resultat af de beskrevne handlinger blev en af flere RAT-klasse malware installeret på det inficerede system. Tabellen nedenfor viser den malware, der blev brugt i angrebet, som vi trygt kan tilskrive én gruppe angribere, da prøverne fik adgang til den samme kommando- og kontrolserver.
Eksempler på distribueret malware med samme kontrolserver
To ting er bemærkelsesværdige her.
For det første selve det faktum, at angriberne brugte flere forskellige RAT-familier på én gang. Denne adfærd er ikke typisk for velkendte cybergrupper, som ofte bruger omtrent det samme sæt værktøjer, som de kender.
For det andet brugte RATKing malware, der enten sælges på specialiserede fora til en lav pris, eller endda er et open source-projekt.
En mere komplet liste over malware brugt i kampagnen - med en vigtig advarsel - er givet i slutningen af artiklen.
Om gruppen
Vi kan ikke tilskrive den beskrevne ondsindede kampagne til nogen kendte angribere. Indtil videre tror vi, at disse angreb blev udført af en fundamentalt ny gruppe. Som vi skrev i begyndelsen, kaldte vi det RATKing.
For at oprette VBS-scriptet brugte gruppen sandsynligvis et værktøj, der ligner værktøjet VBS-krypter fra udvikleren NYAN-x-CAT. Dette indikeres af ligheden mellem det script, som dette program opretter, med angriberens script. Konkret, de begge:
udføre forsinket udførelse ved hjælp af funktionen Sleep;
brug WMI;
registrere kroppen af den eksekverbare fil som en registreringsnøgleparameter;
kør denne fil ved hjælp af PowerShell i sit eget adresseområde.
For klarhedens skyld kan du sammenligne PowerShell-kommandoen for at køre en fil fra registreringsdatabasen, som bruges af et script oprettet ved hjælp af VBS-Crypter:
Bemærk, at angriberne brugte et andet hjælpeprogram fra NYAN-x-CAT som en af nyttelasterne - LimeRAT.
Adresserne på C&C-serverne indikerer et andet karakteristisk træk ved RATKing: gruppen foretrækker dynamiske DNS-tjenester (se listen over C&C'er i IoC-tabellen).
IoC
Tabellen nedenfor giver en komplet liste over VBS-scripts, der højst sandsynligt kan tilskrives den beskrevne kampagne. Alle disse scripts ligner hinanden og udfører omtrent den samme rækkefølge af handlinger. Alle injicerer RAT-klasse malware i en pålidelig Windows-proces. Alle har C&C-adresser registreret ved hjælp af dynamiske DNS-tjenester.
Vi kan dog ikke påstå, at alle disse scripts blev distribueret af de samme angribere, med undtagelse af prøver med de samme C&C-adresser (f.eks. kimjoy007.dyndns.org).