I slutet av maj upptäckte vi en kampanj för att distribuera skadlig programvara från Remote Access Trojan (RAT) – program som tillåter angripare att fjärrstyra ett infekterat system.
Gruppen vi undersökte kännetecknades av det faktum att den inte valde ut någon specifik RAT-familj för infektion. Flera trojaner märktes i attacker inom kampanjen (som alla var allmänt tillgängliga). Med detta inslag påminde gruppen oss om råttkungen - ett mytiskt djur som består av gnagare med sammanflätade svansar.
Originalet är hämtat från monografin av K. N. Rossikov "Möss och musliknande gnagare, de ekonomiskt viktigaste" (1908)
För att hedra denna varelse döpte vi gruppen som vi överväger att RATKing. I det här inlägget kommer vi att gå in i detalj om hur angriparna utförde attacken, vilka verktyg de använde och även dela med oss av våra tankar om tillskrivning för denna kampanj.
Attackens framsteg
Alla attacker i denna kampanj ägde rum enligt följande algoritm:
Användaren fick ett nätfiskemeddelande med en länk till Google Drive.
Med hjälp av länken laddade offret ner ett skadligt VBS-skript som specificerade ett DLL-bibliotek för att ladda den slutliga nyttolasten till Windows-registret och startade PowerShell för att köra det.
DLL-biblioteket injicerade den slutliga nyttolasten - i själva verket en av de RAT som används av angripare - i systemprocessen och registrerade ett VBS-skript i autorun för att få fotfäste i den infekterade maskinen.
Den slutliga nyttolasten exekverades i en systemprocess och gav angriparen möjligheten att kontrollera den infekterade datorn.
Schematiskt kan det representeras så här:
Därefter kommer vi att fokusera på de tre första stegen, eftersom vi är intresserade av leveransmekanismen för skadlig programvara. Vi kommer inte att beskriva i detalj hur själva skadliga programvaran fungerar. De är allmänt tillgängliga - antingen säljs på specialiserade forum, eller till och med distribuerade som projekt med öppen källkod - och är därför inte unika för RATKing-gruppen.
Analys av attackstadier
Steg 1. Nätfiske-e-post
Attacken började med att offret fick ett skadligt brev (angriparna använde olika mallar med text; skärmdumpen nedan visar ett exempel). Meddelandet innehöll en länk till ett legitimt arkiv drive.google.com, vilket förmodligen ledde till en sida för nedladdning av PDF-dokument.
Exempel på nätfiske via e-post
Men i själva verket var det inte alls ett PDF-dokument som laddades in, utan ett VBS-skript.
När du klickade på länken från e-postmeddelandet i skärmdumpen ovan, heter en fil Cargo Flight Details.vbs. I det här fallet försökte angriparna inte ens maskera filen som ett legitimt dokument.
Samtidigt, som en del av den här kampanjen, upptäckte vi ett manus med namnet Cargo Trip Detail.pdf.vbs. Det kan redan passera för en legitim PDF eftersom Windows döljer filtillägg som standard. Sant, i det här fallet kunde misstankar fortfarande väckas av dess ikon, som motsvarade VBS-skriptet.
I det här skedet kunde offret känna igen bedrägeriet: ta bara en närmare titt på de nedladdade filerna för en sekund. Men i sådana nätfiskekampanjer förlitar sig angripare ofta på en ouppmärksam eller förhastad användare.
Steg 2. VBS-skriptoperation
VBS-skriptet, som användaren kunde öppna oavsiktligt, registrerade ett DLL-bibliotek i Windows-registret. Skriptet var fördunklat: raderna i det skrevs som bytes åtskilda av ett godtyckligt tecken.
Exempel på ett förvirrat manus
Deobfuskeringsalgoritmen är ganska enkel: vart tredje tecken exkluderades från den obfuskerade strängen, varefter resultatet avkodades från base16 till den ursprungliga strängen. Till exempel från värdet 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (markerad i skärmdumpen ovan) den resulterande raden var WScript.Shell.
För att deobfuskera strängar använde 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)]))
Nedan, på raderna 9–10, markerar vi värdet vars deobfuskation resulterade i en DLL-fil. Det var han som lanserades i nästa steg med hjälp av PowerShell.
Sträng med obfuskerad DLL
Varje funktion i VBS-skriptet kördes när strängarna deobfuskerades.
Efter att ha kört skriptet anropades funktionen wscript.sleep — den användes för att utföra uppskjuten utförande.
Därefter fungerade skriptet med Windows-registret. Han använde WMI-teknik för detta. Med dess hjälp skapades en unik nyckel, och kroppen av den körbara filen skrevs till dess parameter. Registret nås via WMI med följande kommando:
I det tredje steget laddade den skadliga DLL:n den slutliga nyttolasten, injicerade den i systemprocessen och såg till att VBS-skriptet startade automatiskt när användaren loggade in.
fått registervärdedata med namn rnd_value_name — dessa data var en DLL-fil skriven på .Net-plattformen;
laddade den resulterande .Net-modulen i processminnet powershell.exe använder funktionen [System.Threading.Thread]::GetDomain().Load()(detaljerad beskrivning av Load()-funktionen tillgänglig på Microsofts webbplats);
utförde funktionen GUyyvmzVhebFCw]::EhwwK() - exekveringen av DLL-biblioteket började med det - med parametrar vbsScriptPath, xorKey, vbsScriptName. Parameter xorKey lagrade nyckeln för att dekryptera den slutliga nyttolasten och parametrarna vbsScriptPath и vbsScriptName överfördes för att registrera ett VBS-skript i autorun.
Beskrivning av DLL-biblioteket
I dekompilerad form såg starthanteraren ut så här:
Loader i dekompilerad form (funktionen med vilken exekveringen av DLL-biblioteket började är understruken med rött)
Bootloadern är skyddad av .Net Reactor-skyddet. Verktyget de4dot gör ett utmärkt jobb med att ta bort detta skydd.
Denna lastare:
injicerade nyttolasten i systemprocessen (i det här exemplet det svchost.exe);
Jag lade till ett VBS-skript för autorun.
Nyttolastinsprutning
Låt oss titta på funktionen som PowerShell-skriptet anropade.
Funktion anropad av PowerShell-skript
Denna funktion utförde följande åtgärder:
dekrypterade två datamängder (array и array2 i skärmdumpen). De komprimerades ursprungligen med gzip och krypterades med XOR-algoritmen med nyckeln xorKey;
kopierade data till tilldelade minnesområden. Data från array - till minnesområdet som pekas på intPtr (payload pointer i skärmdumpen); data från array2 - till minnesområdet som pekas på intPtr2 (shellcode pointer i skärmdumpen);
kallas funktionen CallWindowProcA(описание Denna funktion är tillgänglig på Microsofts webbplats) med följande parametrar (namnen på parametrarna listas nedan, i skärmdumpen är de i samma ordning, men med arbetsvärden):
lpPrevWndFunc - pekare till data från array2;
hWnd — pekare till en sträng som innehåller sökvägen till den körbara filen svchost.exe;
Msg - pekare till data från array;
wParam, lParam — meddelandeparametrar (i det här fallet användes inte dessa parametrar och hade värden på 0);
skapade en fil %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlvar <name> - det här är de fyra första tecknen i parametern vbsScriptName (i skärmdumpen börjar kodfragmentet med denna åtgärd med kommandot File.Copy). På detta sätt lade skadlig programvara till en URL-fil till listan över autorun-filer när användaren loggade in och blev därmed kopplad till den infekterade datorn. URL-filen innehöll en länk till skriptet:
För att förstå hur injektionen genomfördes dekrypterade vi datamatriserna array и array2. För att göra detta använde vi följande Python-funktion:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Som ett resultat fick vi reda på att:
array var en PE-fil - detta är den slutliga nyttolasten;
array2 var skalkoden som krävdes för att utföra injektionen.
Skalkod från en array array2 skickas som ett funktionsvärde lpPrevWndFunc till en funktion CallWindowProcA. lpPrevWndFunc — återuppringningsfunktion, dess prototyp ser ut så här:
Så när du kör funktionen CallWindowProcA med parametrar hWnd, Msg, wParam, lParam skalkod från arrayen exekveras array2 med argument hWnd и Msg. hWnd är en pekare till en sträng som innehåller sökvägen till den körbara filen svchost.exeOch Msg — pekare till den slutliga nyttolasten.
Skalkoden fick funktionsadresser från kernel32.dll и ntdll32.dll baserat på hash-värden från deras namn och injicerade den slutliga nyttolasten i processminnet svchost.exemed hjälp av Process Hollowing-tekniken (du kan läsa mer om det i detta artikeln). När du injicerar skalkoden:
skapat en process svchost.exe i viloläge med funktionen CreateProcessW;
gömde sedan avsnittets visning i processens adressutrymme svchost.exe använder funktionen NtUnmapViewOfSection. Således frigjorde programmet minnet av den ursprungliga processen svchost.exeatt sedan allokera minne för nyttolasten på denna adress;
tilldelat minne för nyttolasten i processadressutrymmet svchost.exe använder funktionen VirtualAllocEx;
Start av injektionsprocessen
skrev innehållet i nyttolasten till processadressutrymmet svchost.exe använder funktionen WriteProcessMemory (som i skärmdumpen nedan);
återupptog processen svchost.exe använder funktionen ResumeThread.
Slutföra injektionsprocessen
Nedladdningsbar skadlig programvara
Som ett resultat av de beskrivna åtgärderna installerades en av flera skadliga program av RAT-klass på det infekterade systemet. Tabellen nedan listar den skadliga programvaran som användes i attacken, som vi med säkerhet kan tillskriva en grupp angripare, eftersom proverna fick åtkomst till samma kommando- och kontrollserver.
Exempel på distribuerad skadlig programvara med samma kontrollserver
Två saker är anmärkningsvärda här.
För det första, själva det faktum att angriparna använde flera olika RAT-familjer samtidigt. Detta beteende är inte typiskt för välkända cybergrupper, som ofta använder ungefär samma uppsättning verktyg som är bekanta för dem.
För det andra använde RATKing skadlig programvara som antingen säljs på specialiserade forum för ett lågt pris, eller till och med är ett projekt med öppen källkod.
En mer komplett lista över skadlig programvara som används i kampanjen – med en viktig varning – ges i slutet av artikeln.
Om gruppen
Vi kan inte tillskriva den beskrivna skadliga kampanjen till några kända angripare. För närvarande tror vi att dessa attacker utfördes av en i grunden ny grupp. Som vi skrev i början kallade vi det RATKing.
För att skapa VBS-skriptet använde gruppen förmodligen ett verktyg som liknar verktyget VBS-krypter från utvecklaren NYAN-x-CAT. Detta indikeras av likheten mellan skriptet som detta program skapar med angriparnas skript. Närmare bestämt, de båda:
utföra fördröjd exekvering med funktionen Sleep;
använd WMI;
registrera huvuddelen av den körbara filen som en registernyckelparameter;
kör den här filen med PowerShell i sitt eget adressutrymme.
För tydlighetens skull, jämför PowerShell-kommandot för att köra en fil från registret, som används av ett skript skapat med VBS-Crypter:
Observera att angriparna använde ett annat verktyg från NYAN-x-CAT som en av nyttolasterna - LimeRAT.
Adresserna till C&C-servrarna indikerar en annan utmärkande egenskap hos RATKing: gruppen föredrar dynamiska DNS-tjänster (se listan över C&C i IoC-tabellen).
IoC
Tabellen nedan ger en komplett lista över VBS-skript som med största sannolikhet kan tillskrivas den beskrivna kampanjen. Alla dessa skript är lika och utför ungefär samma sekvens av åtgärder. Alla injicerar skadlig programvara av RAT-klass i en pålitlig Windows-process. Alla har C&C-adresser registrerade med hjälp av dynamiska DNS-tjänster.
Vi kan dock inte hävda att alla dessa skript distribuerades av samma angripare, med undantag för prover med samma C&C-adresser (till exempel kimjoy007.dyndns.org).