Het Eye Security Incident Response-team hielp onlangs bij het onderzoek naar een ransomware-incident dat we gekoppeld hebben aan de 8Base-ransomwaregroep. We ontdekten snel dat de encryptor nog draaide op sommige hosts. Daarop besloten we om uit te zoeken of we via een geheugendump van het proces voldoende informatie konden verzamelen om de encryptiesleutels te achterhalen.
We kwamen erg dichtbij en als we iets eerder betrokken waren geweest, voor het versleutelproces voltooid was, waren we hier waarschijnlijk in geslaagd. Hieronder beschrijven we de stappen die we genomen hebben en de stappen die we hadden moeten nemen om succesvol te zijn, als we eerder betrokken waren geweest.
Een nadere blik op het 8Base-encryptieproces
Bestanden die minder dan 1,5 MB groot zijn, zijn volledig versleuteld. Maar bij grotere bestanden zijn slechts drie delen van 256 KB versleuteld. Dit zijn de eerste en laatste 256 KB en een 256 KB-stuk in het midden van het bestand.
Dit is een veelgebruikte tactiek om zoveel mogelijk schade te doen en de kans op bestandsherstel te verkleinen, terwijl de versleutelingssnelheid wordt verhoogd en de kans op detectie wordt geminimaliseerd. Het begin en einde van een bestand bevatten kritieke headers, metadata, formatinformatie en indextabellen. Zonder deze delen is het bestand waarschijnlijk nutteloos. Maar bepaalde tools kunnen nog altijd informatie terughalen uit specifieke bestandstypen. Daarom versleutelt de ransomware ook een willekeurig deel van de data in het midden van het bestand. Dat verstoort de structuur en integriteit.
Het creatieproces van de sleutel in deze 8Base-ransomware-aanval
De malware genereert een nieuwe (set) AES-sleutel(s) voor iedere schijf of share die het probeert te versleutelen. Deze willekeurige generator is al aangevallen door CERT Polska, met beperkt succes (zie ook: ’A Tale of Phobos: How we almost cracked a ransomware using CUDA’). Daarom lijkt het onwaarschijnlijk dat we de AES-sleutels konden brute-forcen.
Elke sleutel wordt vervolgens versleuteld met een RSA-publieke sleutel. De versleutelde data bevatten ook het volumeserienummer van de systeemschijf en een identificatiecode. Hierdoor kan de aanvaller de AES-sleutels gericht vrijgeven voor specifieke systemen
struct rsa_encrypted_data {
char key[32];
int volume_serial_nr;
int identifier; // config variable 1
};
Nadat beide sleutels zijn aangemaakt, worden ze samengevoegd in één structuur, die ook een CRC-checksum bevat. Deze checksum wordt berekend door beide sleutels aan elkaar te koppelen, zoals te zien is in de onderstaande code.
Als de AES-sleutel nog aanwezig is in het geheugen, zouden we een structuur moeten vinden met de volgende vorm:
struct key_combo {
char aes_key[32];
char rsa_encrypted_aes_key[128];
int crc_checksum;
};
Uitdagingen bij het terughalen van de encryptiesleutels uit het geheugen
Om de ruwe geheugendump te doorzoeken hebben we het volgende Python-script gebruikt om deze structuur te detecteren:
# data is raw memory dump
import struct,zlib
for i in range(len(data)-128-32-4):
mem_crc = struct.unpack('I',data[i+32+128:i+32+128+4])
calc_crc = zlib.crc32(data[i:i+32+128])
if mem_crc == calc_crc:
print(f'Found aes key: {data[i:i+32]}')
Helaas konden we de sleutels niet vinden, aangezien ze direct verwijderd werden nadat de malware klaar was met het versleutelen van een schijf. Hierdoor hadden we een extreem kort tijdsvenster waarin de sleutels beschikbaar waren.
De alternatieve uitkomst – het ontsleutelen van de bestanden
De omgeving van de klant was volledig hersteld. Daar kun je meer over lezen in ons recente artikel ‘Onderzoek naar 8Base-ransomware levert verrassende inzichten op’. Maar dit proces zou wat anders zijn verlopen als we de sleutels hadden kunnen achterhalen. Dit zijn de stappen die we genomen zouden hebben om de bestanden te herstellen.
Aan het einde van ieder versleuteld bestand zijn twee datastructuren toegevoegd. De eerste is de versleutelde metadata, de laatste is een plaintext footer. Om het bestand te herstellen, begonnen we met het lezen van de plaintext footer aan het einde van het bestand. Dit bevat de informatie die we nodig hebben om de versleutelde metadata te vinden en te ontsleutelen. Dit is de structuur:
struct __declspec(align(1)) phobos_file_footer {
char always_zero[20];
char iv[16];
int padding_size;
char rsa_encrypted_part[128];
int metadata_offset;
char attacker_id[6];
};
Het belangrijkste veld is metadata_offset, wat een offset is vanaf het einde van het bestand naar de versleutelde metadata. Deze kunnen worden ontsleuteld met behulp van de teruggehaalde AES-sleutel en de iv uit de footer, waarbij AES-256 in CBC-modus wordt gebruikt. Dit onthult de volgende structuur.
struct phobos_file_metadata {
int always_zero;
int encryption_mode;
int magic;
int nr_chunks;
int chunk_len;
int crc_checksum;
int orig_filename_offset; // offset from start of structure phobos_file_metadata
int padding;
//chunks for large files only if encryption mode == 1
LARGE_INTEGER chunk_offsets[nr_chunks];
char chunk_data[nr_chunks][chunk_len];
};
Het belangrijkste veld is de encryption_mode. Mode 1 bestaat uit verschillende stukken en wordt gebruikt voor bestanden groter dan 1,5 MB. Deze mode heeft een magische waarde van 0xAF77BC0F. Mode 2 is het versleutelen van het gehele bestand en heeft een magische waarde van 0xF0A75E12.
Voor volledig versleutelde bestanden (mode 2) kun je dezelfde AES-sleutel en initialisatievector gebruiken om ze te ontsleutelen. Verwijder de footer, metadata en de laatste paar bytes aan padding door het padding_size-veld te gebruiken.
Voor grotere bestanden (mode 1) is de data toegevoegd aan de structuur. Om het bestand te herstellen, zoek je naar chunk_offsets[idx] en schrijf je chunk_data[idx] naar die offset. Verwijder ook de metadata en footer aan het einde van het bestand.
Effectief herstel van ransomware: lessen van de 8Base-zaak
Als we eerder betrokken waren geweest bij dit proces, hadden we het versleutelproces gezien voordat het afgerond was en de sleutels vernietigd werden. Het herstellen van bestanden was dan gemakkelijker geweest. Gelukkig – zoals je kunt lezen in ons artikel over de incident recovery – konden we de omgeving van de klant herstellen met minimale downtime.
Ben jij klaar om te praten over het verbeteren van je securitypositie? Neem contact met ons op voor alle details:
