RATKing: ny kampanje med trojanere med ekstern tilgang
I slutten av mai oppdaget vi en kampanje for å distribuere Remote Access Trojan (RAT) malware – programmer som lar angripere fjernkontrollere et infisert system.
Gruppen vi undersøkte var kjennetegnet ved at den ikke valgte noen spesifikk RAT-familie for infeksjon. Flere trojanere ble lagt merke til i angrep i kampanjen (som alle var allment tilgjengelig). Med denne funksjonen minnet gruppen oss om rottekongen - et mytisk dyr som består av gnagere med sammenflettede haler.
Originalen er hentet fra monografien av K. N. Rossikov "Mus og muslignende gnagere, de mest økonomisk viktige" (1908)
Til ære for denne skapningen kalte vi gruppen vi vurderer RATKing. I dette innlegget vil vi gå i detalj om hvordan angriperne utførte angrepet, hvilke verktøy de brukte, og også dele våre tanker om attribusjon for denne kampanjen.
Fremdriften av angrepet
Alle angrep i denne kampanjen fant sted i henhold til følgende algoritme:
Brukeren mottok en phishing-e-post med en lenke til Google Disk.
Ved å bruke lenken lastet offeret ned et ondsinnet VBS-skript som spesifiserte et DLL-bibliotek for å laste den endelige nyttelasten inn i Windows-registeret og startet PowerShell for å kjøre det.
DLL-biblioteket injiserte den endelige nyttelasten - faktisk en av RAT-ene som brukes av angripere - i systemprosessen og registrerte et VBS-skript i autorun for å få fotfeste i den infiserte maskinen.
Den endelige nyttelasten ble utført i en systemprosess og ga angriperen muligheten til å kontrollere den infiserte datamaskinen.
Skjematisk kan det representeres slik:
Deretter vil vi fokusere på de tre første stadiene, siden vi er interessert i leveringsmekanismen for skadelig programvare. Vi vil ikke beskrive i detalj virkemekanismen for selve skadevare. De er allment tilgjengelige - enten solgt på spesialiserte fora, eller til og med distribuert som åpen kildekode-prosjekter - og er derfor ikke unike for RATKing-gruppen.
Analyse av angrepsstadier
Trinn 1. Phishing-e-post
Angrepet begynte med at offeret mottok et ondsinnet brev (angriperne brukte forskjellige maler med tekst; skjermbildet nedenfor viser ett eksempel). Meldingen inneholdt en lenke til et legitimt depot drive.google.com, som visstnok førte til en nedlastingsside for PDF-dokument.
Eksempel på phishing-e-post
Imidlertid var det faktisk ikke et PDF-dokument som ble lastet inn i det hele tatt, men et VBS-skript.
Når du klikket på lenken fra e-posten i skjermbildet ovenfor, ble en fil kalt Cargo Flight Details.vbs. I dette tilfellet forsøkte ikke angriperne engang å skjule filen som et legitimt dokument.
Samtidig, som en del av denne kampanjen, oppdaget vi et manus som heter Cargo Trip Detail.pdf.vbs. Det kan allerede passere for en legitim PDF fordi Windows skjuler filutvidelser som standard. Riktignok kunne mistanke i dette tilfellet fortsatt vekkes av ikonet, som tilsvarte VBS-skriptet.
På dette stadiet kunne offeret gjenkjenne bedraget: bare se nærmere på de nedlastede filene et sekund. Men i slike phishing-kampanjer er angripere ofte avhengige av en uoppmerksom eller forhastet bruker.
Trinn 2. VBS-skriptoperasjon
VBS-skriptet, som brukeren kunne åpne utilsiktet, registrerte et DLL-bibliotek i Windows-registeret. Skriptet ble tilslørt: linjene i det ble skrevet som byte atskilt med et vilkårlig tegn.
Eksempel på et obfuskert skript
Deobfuskeringsalgoritmen er ganske enkel: hvert tredje tegn ble ekskludert fra den obfuskerte strengen, hvoretter resultatet ble dekodet fra base16 til den originale strengen. For eksempel fra verdien 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (uthevet i skjermbildet ovenfor) den resulterende linjen var WScript.Shell.
For å deobfuskere strenger brukte vi Python-funksjonen:
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, fremhever vi verdien hvis deobfuskering resulterte i en DLL-fil. Det var han som ble lansert på neste trinn ved hjelp av PowerShell.
String med obfuskert DLL
Hver funksjon i VBS-skriptet ble utført da strengene ble deobfuskert.
Etter å ha kjørt skriptet ble funksjonen kalt wscript.sleep — den ble brukt til å utføre utsatt utførelse.
Deretter fungerte skriptet med Windows-registeret. Han brukte WMI-teknologi til dette. Med dens hjelp ble en unik nøkkel opprettet, og kroppen til den kjørbare filen ble skrevet til parameteren. Registeret ble åpnet via WMI ved å bruke følgende kommando:
På det tredje stadiet lastet den ondsinnede DLL-en den endelige nyttelasten, injiserte den i systemprosessen og sørget for at VBS-skriptet startet automatisk når brukeren logget på.
Kjør via PowerShell
DLL-en ble utført ved å bruke følgende kommando i PowerShell:
mottatt registerverdidata med navn rnd_value_name — disse dataene var en DLL-fil skrevet på .Net-plattformen;
lastet den resulterende .Net-modulen inn i prosessminnet powershell.exe ved å bruke funksjonen [System.Threading.Thread]::GetDomain().Load()(detaljert beskrivelse av Load()-funksjonen tilgjengelig på Microsofts nettsted);
utførte funksjonen GUyyvmzVhebFCw]::EhwwK() - utførelsen av DLL-biblioteket begynte med det - med parametere vbsScriptPath, xorKey, vbsScriptName. Parameter xorKey lagret nøkkelen for å dekryptere den endelige nyttelasten, og parametrene vbsScriptPath и vbsScriptName ble overført for å registrere et VBS-skript i autorun.
Beskrivelse av DLL-biblioteket
I dekompilert form så bootloaderen slik ut:
Loader i dekompilert form (funksjonen som utførelsen av DLL-biblioteket startet med er understreket med rødt)
Bootloaderen er beskyttet av .Net Reactor-beskytteren. De4dot-verktøyet gjør en utmerket jobb med å fjerne denne beskytteren.
Denne lasteren:
injiserte nyttelasten i systemprosessen (i dette eksempelet svchost.exe);
Jeg la til et VBS-skript for autorun.
Nyttelastinjeksjon
La oss se på funksjonen som PowerShell-skriptet kalte.
Funksjon kalt av PowerShell-skript
Denne funksjonen utførte følgende handlinger:
dekrypterte to datasett (array и array2 i skjermbildet). De ble opprinnelig komprimert ved hjelp av gzip og kryptert med XOR-algoritmen med nøkkelen xorKey;
kopierte data til tildelte minneområder. Data fra array - til minneområdet peker på intPtr (payload pointer i skjermbildet); data fra array2 - til minneområdet peker på intPtr2 (shellcode pointer i skjermbildet);
kalt funksjonen CallWindowProcA(описание Denne funksjonen er tilgjengelig på Microsofts nettsted) med følgende parametere (navnene på parameterne er oppført nedenfor, i skjermbildet er de i samme rekkefølge, men med arbeidsverdier):
lpPrevWndFunc - peker til data fra array2;
hWnd — peker til en streng som inneholder banen til den kjørbare filen svchost.exe;
Msg - peker til data fra array;
wParam, lParam — meldingsparametere (i dette tilfellet ble disse parametrene ikke brukt og hadde verdier på 0);
opprettet en fil %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlDer <name> - dette er de første 4 tegnene i parameteren vbsScriptName (i skjermbildet begynner kodefragmentet med denne handlingen med kommandoen File.Copy). På denne måten la skadevaren en URL-fil til listen over autorun-filer når brukeren logget på og ble dermed knyttet til den infiserte datamaskinen. URL-filen inneholdt en lenke til skriptet:
For å forstå hvordan injeksjonen ble utført, dekrypterte vi datamatrisene array и array2. For å gjøre dette brukte vi følgende Python-funksjon:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Som et resultat fant vi ut at:
array var en PE-fil - dette er den endelige nyttelasten;
array2 var skallkoden som kreves for å utføre injeksjonen.
Shellcode fra en matrise array2 sendt som en funksjonsverdi lpPrevWndFunc inn i en funksjon CallWindowProcA. lpPrevWndFunc — tilbakeringingsfunksjon, prototypen ser slik ut:
Så når du kjører funksjonen CallWindowProcA med parametere hWnd, Msg, wParam, lParam shellcode fra arrayet kjøres array2 med argumenter hWnd и Msg. hWnd er en peker til en streng som inneholder banen til den kjørbare filen svchost.exeOg Msg — peker til den endelige nyttelasten.
Skallkoden mottok funksjonsadresser fra kernel32.dll и ntdll32.dll basert på hashverdier fra navnene deres og injiserte den endelige nyttelasten i prosessminnet svchost.exeved hjelp av Process Hollowing-teknikken (du kan lese mer om det i denne artikkel). Når du injiserer skallkoden:
opprettet en prosess svchost.exe i suspendert tilstand ved hjelp av funksjonen CreateProcessW;
deretter gjemte delens visning i prosessens adresserom svchost.exe ved å bruke funksjonen NtUnmapViewOfSection. Dermed frigjorde programmet minnet til den opprinnelige prosessen svchost.exefor deretter å allokere minne for nyttelasten på denne adressen;
tildelt minne for nyttelasten i prosessadresserommet svchost.exe ved å bruke funksjonen VirtualAllocEx;
Start av injeksjonsprosessen
skrev innholdet av nyttelasten inn i prosessadresserommet svchost.exe ved å bruke funksjonen WriteProcessMemory (som i skjermbildet nedenfor);
gjenopptok prosessen svchost.exe ved å bruke funksjonen ResumeThread.
Fullføring av injeksjonsprosessen
Nedlastbar skadelig programvare
Som et resultat av de beskrevne handlingene ble en av flere skadelig programvare av RAT-klassen installert på det infiserte systemet. Tabellen nedenfor viser skadelig programvare som ble brukt i angrepet, som vi trygt kan tilskrive én gruppe angripere, siden prøvene fikk tilgang til den samme kommando- og kontrollserveren.
Eksempler på distribuert skadelig programvare med samme kontrollserver
To ting er verdt å merke seg her.
For det første det faktum at angriperne brukte flere forskjellige RAT-familier samtidig. Denne oppførselen er ikke typisk for kjente cybergrupper, som ofte bruker omtrent det samme settet med verktøy som er kjent for dem.
For det andre brukte RATKing skadelig programvare som enten selges på spesialiserte fora til en lav pris, eller til og med er et åpen kildekode-prosjekt.
En mer fullstendig liste over skadelig programvare brukt i kampanjen – med ett viktig forbehold – er gitt på slutten av artikkelen.
Om gruppen
Vi kan ikke tilskrive den beskrevne ondsinnede kampanjen til noen kjente angripere. Foreløpig tror vi at disse angrepene ble utført av en fundamentalt ny gruppe. Som vi skrev i begynnelsen, kalte vi det RATKing.
For å lage VBS-skriptet brukte gruppen sannsynligvis et verktøy som ligner på verktøyet VBS-krypter fra utbygger NYAN-x-CAT. Dette indikeres av likheten mellom skriptet som dette programmet lager med angripernes skript. Nærmere bestemt, de begge:
utføre forsinket utførelse ved hjelp av funksjonen Sleep;
bruk WMI;
registrere kroppen til den kjørbare filen som en registernøkkelparameter;
kjør denne filen ved å bruke PowerShell i sitt eget adresserom.
For klarhet, sammenlign PowerShell-kommandoen for å kjøre en fil fra registret, som brukes av et skript opprettet med VBS-Crypter:
Merk at angriperne brukte et annet verktøy fra NYAN-x-CAT som en av nyttelastene - LimeRAT.
Adressene til C&C-serverne indikerer et annet særtrekk ved RATKing: gruppen foretrekker dynamiske DNS-tjenester (se listen over C&C-er i IoC-tabellen).
IoC
Tabellen nedenfor gir en fullstendig liste over VBS-skript som mest sannsynlig kan tilskrives den beskrevne kampanjen. Alle disse skriptene er like og utfører omtrent samme sekvens av handlinger. Alle av dem injiserer skadelig programvare i RAT-klassen i en pålitelig Windows-prosess. Alle har C&C-adresser registrert ved hjelp av dynamiske DNS-tjenester.
Vi kan imidlertid ikke påstå at alle disse skriptene ble distribuert av de samme angriperne, med unntak av prøver med samme C&C-adresser (for eksempel kimjoy007.dyndns.org).