RATKing: nieuwe campagne met Trojaanse paarden voor externe toegang
Eind mei ontdekten we een campagne om Remote Access Trojan (RAT)-malware te verspreiden: programma's waarmee aanvallers een geïnfecteerd systeem op afstand kunnen besturen.
De door ons onderzochte groep onderscheidde zich door het feit dat zij geen specifieke RAT-familie voor infectie selecteerde. Bij aanvallen binnen de campagne werden verschillende Trojaanse paarden opgemerkt (die allemaal algemeen verkrijgbaar waren). Met dit kenmerk deed de groep ons denken aan de rattenkoning - een mythisch dier dat bestaat uit knaagdieren met ineengestrengelde staarten.
Het origineel is ontleend aan de monografie van K. N. Rossikov "Muizen en muisachtige knaagdieren, de economisch belangrijkste" (1908)
Ter ere van dit wezen hebben we de groep die we overwegen RATKing genoemd. In dit bericht gaan we gedetailleerd in op hoe de aanvallers de aanval hebben uitgevoerd, welke tools ze hebben gebruikt, en delen we ook onze mening over de attributie voor deze campagne.
Voortgang van de aanval
Alle aanvallen in deze campagne vonden plaats volgens het volgende algoritme:
De gebruiker heeft een phishing-e-mail ontvangen met een link naar Google Drive.
Met behulp van de link downloadde het slachtoffer een kwaadaardig VBS-script dat een DLL-bibliotheek specificeerde om de laatste payload in het Windows-register te laden en startte PowerShell om het uit te voeren.
De DLL-bibliotheek injecteerde de laatste payload (in feite een van de RAT's die door aanvallers worden gebruikt) in het systeemproces en registreerde een VBS-script in autorun om voet aan de grond te krijgen op de geïnfecteerde machine.
De laatste lading werd uitgevoerd in een systeemproces en gaf de aanvaller de mogelijkheid om de geïnfecteerde computer te besturen.
Schematisch kan het als volgt worden weergegeven:
Vervolgens zullen we ons concentreren op de eerste drie fasen, omdat we geïnteresseerd zijn in het mechanisme voor het afleveren van malware. We zullen het werkingsmechanisme van de malware zelf niet in detail beschrijven. Ze zijn overal verkrijgbaar - verkocht op gespecialiseerde forums, of zelfs verspreid als open source-projecten - en zijn daarom niet uniek voor de RATKing-groep.
Analyse van aanvalsfasen
Fase 1. Phishing-e-mail
De aanval begon toen het slachtoffer een kwaadaardige brief ontving (de aanvallers gebruikten verschillende sjablonen met tekst; de onderstaande schermafbeelding toont een voorbeeld). Het bericht bevatte een link naar een legitieme repository drive.google.com, wat zogenaamd zou hebben geleid tot een downloadpagina voor een PDF-document.
Voorbeeld van een phishing-e-mail
In feite was het echter helemaal geen PDF-document dat werd geladen, maar een VBS-script.
Wanneer u op de link uit de e-mail in de bovenstaande schermafbeelding klikte, werd een bestand met de naam Cargo Flight Details.vbs. In dit geval probeerden de aanvallers niet eens het bestand als een legitiem document te vermommen.
Tegelijkertijd ontdekten we, als onderdeel van deze campagne, een script met de naam Cargo Trip Detail.pdf.vbs. Het zou al kunnen doorgaan voor een legitieme PDF, omdat Windows standaard bestandsextensies verbergt. Het is waar dat in dit geval nog steeds argwaan kon worden gewekt door het pictogram, dat overeenkwam met het VBS-script.
In dit stadium kon het slachtoffer het bedrog herkennen: bekijk de gedownloade bestanden even van dichtbij. Bij dergelijke phishing-campagnes vertrouwen aanvallers echter vaak op een onoplettende of overhaaste gebruiker.
Fase 2. VBS-scriptbewerking
Het VBS-script, dat de gebruiker onbedoeld kon openen, registreerde een DLL-bibliotheek in het Windows-register. Het script was onduidelijk: de regels erin waren geschreven als bytes, gescheiden door een willekeurig teken.
Voorbeeld van een versluierd script
Het deobfuscatie-algoritme is vrij eenvoudig: elk derde teken werd uitgesloten van de versluierde string, waarna het resultaat werd gedecodeerd van base16 naar de originele string. Bijvoorbeeld van de waarde 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (gemarkeerd in de schermafbeelding hierboven) was de resulterende regel WScript.Shell.
Om tekenreeksen te verduidelijken, hebben we de Python-functie gebruikt:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Hieronder, op de regels 9-10, markeren we de waarde waarvan de deobfuscatie resulteerde in een DLL-bestand. Hij was het die in de volgende fase werd gelanceerd met behulp van PowerShell.
Tekenreeks met versluierde DLL
Elke functie in het VBS-script werd uitgevoerd terwijl de tekenreeksen werden gedeobfusceerd.
Nadat het script was uitgevoerd, werd de functie aangeroepen wscript.sleep — het werd gebruikt om uitgestelde executie uit te voeren.
Vervolgens werkte het script met het Windows-register. Hij gebruikte hiervoor WMI-technologie. Met zijn hulp werd een unieke sleutel gemaakt en werd de hoofdtekst van het uitvoerbare bestand naar zijn parameter geschreven. Het register is toegankelijk via WMI met behulp van de volgende opdracht:
Een vermelding in het register door een VBS-script
Fase 3. Werking van de DLL-bibliotheek
In de derde fase laadde de kwaadaardige DLL de laatste payload, injecteerde deze in het systeemproces en zorgde ervoor dat het VBS-script automatisch werd gestart wanneer de gebruiker inlogde.
Uitgevoerd via PowerShell
De DLL werd uitgevoerd met behulp van de volgende opdracht in PowerShell:
ontvangen registerwaardegegevens met naam rnd_value_name — deze gegevens waren een DLL-bestand geschreven op het .Net-platform;
laadde de resulterende .Net-module in het procesgeheugen powershell.exe met behulp van de functie [System.Threading.Thread]::GetDomain().Load()(gedetailleerde beschrijving van de functie Load(). beschikbaar op de Microsoft-website);
voerde de functie uit GUyyvmzVhebFCw]::EhwwK() - de uitvoering van de DLL-bibliotheek begon ermee - met parameters vbsScriptPath, xorKey, vbsScriptName. Parameter xorKey heeft de sleutel opgeslagen voor het decoderen van de uiteindelijke lading, en de parameters vbsScriptPath и vbsScriptName werden overgebracht om een VBS-script in autorun te registreren.
Beschrijving van de DLL-bibliotheek
In gedecompileerde vorm zag de bootloader er als volgt uit:
Lader in gedecompileerde vorm (de functie waarmee de uitvoering van de DLL-bibliotheek begon, is rood onderstreept)
De bootloader wordt beschermd door de .Net Reactor-protector. Het hulpprogramma de4dot doet uitstekend werk bij het verwijderen van deze beschermer.
Deze lader:
heeft de payload in het systeemproces geïnjecteerd (in dit voorbeeld is het svchost.exe);
Ik heb een VBS-script toegevoegd aan autorun.
Injectie van lading
Laten we eens kijken naar de functie die het PowerShell-script heeft aangeroepen.
Functie aangeroepen door PowerShell-script
Deze functie voerde de volgende acties uit:
twee datasets gedecodeerd (array и array2 in de schermafdruk). Ze werden oorspronkelijk gecomprimeerd met behulp van gzip en gecodeerd met het XOR-algoritme met de sleutel xorKey;
gekopieerde gegevens naar toegewezen geheugengebieden. Data van array - naar het geheugengebied waarnaar wordt verwezen intPtr (payload pointer in de schermafbeelding); data van array2 - naar het geheugengebied waarnaar wordt verwezen intPtr2 (shellcode pointer in de schermafbeelding);
de functie genoemd CallWindowProcA(описание Deze functie is beschikbaar op de Microsoft-website) met de volgende parameters (de namen van de parameters staan hieronder vermeld, in de schermafbeelding staan ze in dezelfde volgorde, maar met werkwaarden):
lpPrevWndFunc - verwijzing naar gegevens van array2;
hWnd — verwijzing naar een string die het pad naar het uitvoerbare bestand bevat svchost.exe;
Msg - verwijzing naar gegevens van array;
wParam, lParam — berichtparameters (in dit geval werden deze parameters niet gebruikt en hadden ze waarden van 0);
een bestand gemaakt %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlWaar <name> - dit zijn de eerste 4 tekens van de parameter vbsScriptName (in de schermafbeelding begint het codefragment met deze actie met het commando File.Copy). Op deze manier voegde de malware een URL-bestand toe aan de lijst met autorun-bestanden toen de gebruiker inlogde en raakte zo verbonden met de geïnfecteerde computer. Het URL-bestand bevatte een link naar het script:
Om te begrijpen hoe de injectie werd uitgevoerd, hebben we de data-arrays gedecodeerd array и array2. Om dit te doen hebben we de volgende Python-functie gebruikt:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Als gevolg hiervan kwamen we erachter dat:
array was een PE-bestand - dit is de uiteindelijke lading;
array2 was de shellcode die nodig was om de injectie uit te voeren.
Shellcode uit een array array2 doorgegeven als een functiewaarde lpPrevWndFunc in een functie CallWindowProcA. lpPrevWndFunc — callback-functie, het prototype ziet er als volgt uit:
Dus wanneer u de functie uitvoert CallWindowProcA met parameters hWnd, Msg, wParam, lParam shellcode uit de array wordt uitgevoerd array2 met argumenten hWnd и Msg. hWnd is een verwijzing naar een string die het pad naar het uitvoerbare bestand bevat svchost.exeEn Msg - verwijzing naar de uiteindelijke lading.
De shellcode ontving functieadressen van kernel32.dll и ntdll32.dll op basis van hashwaarden uit hun namen en injecteerde de uiteindelijke payload in het procesgeheugen svchost.exemet behulp van de Process Hollowing-techniek (hierover leest u meer статье). Bij het injecteren van de shellcode:
een proces gecreëerd svchost.exe in een onderbroken toestand met behulp van de functie CreateProcessW;
verborg vervolgens de weergave van de sectie in de adresruimte van het proces svchost.exe de functie gebruiken: NtUnmapViewOfSection. Zo maakte het programma het geheugen van het oorspronkelijke proces vrij svchost.exeom vervolgens geheugen toe te wijzen voor de payload op dit adres;
toegewezen geheugen voor de payload in de procesadresruimte svchost.exe de functie gebruiken: VirtualAllocEx;
Begin van het injectieproces
schreef de inhoud van de payload in de procesadresruimte svchost.exe de functie gebruiken: WriteProcessMemory (zoals in de onderstaande schermafbeelding);
hervatte het proces svchost.exe de functie gebruiken: ResumeThread.
Het injectieproces voltooien
Downloadbare malware
Als gevolg van de beschreven acties werd een van de vele malware van de RAT-klasse op het geïnfecteerde systeem geïnstalleerd. De onderstaande tabel vermeldt de malware die bij de aanval is gebruikt en die we met zekerheid kunnen toeschrijven aan één groep aanvallers, aangezien de voorbeelden toegang hadden tot dezelfde command-and-control-server.
Voorbeelden van gedistribueerde malware met dezelfde controleserver
Hierbij zijn twee zaken opmerkelijk.
Ten eerste het feit dat de aanvallers verschillende RAT-families tegelijk gebruikten. Dit gedrag is niet typisch voor bekende cybergroepen, die vaak ongeveer dezelfde set tools gebruiken die zij kennen.
Ten tweede gebruikte RATKing malware die ofwel op gespecialiseerde forums voor een lage prijs wordt verkocht, ofwel zelfs een open source-project is.
Aan het eind van het artikel vindt u een completere lijst met malware die in de campagne wordt gebruikt (met één belangrijk voorbehoud).
Over de groep
We kunnen de beschreven kwaadaardige campagne niet toeschrijven aan bekende aanvallers. Voorlopig denken wij dat deze aanvallen zijn uitgevoerd door een fundamenteel nieuwe groep. Zoals we in het begin schreven, noemden we het RATKing.
Om het VBS-script te maken, gebruikte de groep waarschijnlijk een tool die vergelijkbaar was met het hulpprogramma VBS-Crypter van de ontwikkelaar NYAN-x-CAT. Dit wordt aangegeven door de gelijkenis van het script dat dit programma maakt met het script van de aanvallers. Concreet hebben ze allebei:
voer een vertraagde uitvoering uit met behulp van de functie Sleep;
gebruik WMI;
registreer de hoofdtekst van het uitvoerbare bestand als registersleutelparameter;
voer dit bestand uit met PowerShell in zijn eigen adresruimte.
Vergelijk voor de duidelijkheid de PowerShell-opdracht om een bestand uit het register uit te voeren, dat wordt gebruikt door een script dat is gemaakt met VBS-Crypter:
Merk op dat de aanvallers een ander hulpprogramma van NYAN-x-CAT als een van de payloads gebruikten: LimoenRAT.
De adressen van de C&C-servers duiden op een ander onderscheidend kenmerk van RATKing: de groep geeft de voorkeur aan dynamische DNS-diensten (zie de lijst met C&C's in de IoC-tabel).
IoC
De onderstaande tabel geeft een volledige lijst met VBS-scripts die hoogstwaarschijnlijk aan de beschreven campagne kunnen worden toegeschreven. Al deze scripts zijn vergelijkbaar en voeren ongeveer dezelfde reeks acties uit. Ze injecteren allemaal RAT-klasse malware in een vertrouwd Windows-proces. Ze hebben allemaal C&C-adressen geregistreerd met behulp van dynamische DNS-services.
We kunnen echter niet beweren dat al deze scripts door dezelfde aanvallers zijn verspreid, met uitzondering van voorbeelden met dezelfde C&C-adressen (bijvoorbeeld kimjoy007.dyndns.org).