Herstel van 8Base-ransomware: Encryptiesleutel achterhalen en bestanden herstellen

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: 

Blog Categories

Bedreigingen en Kwetsbaarheden

About the author

Eye Security

Eye Security is a leading European cybersecurity company specialising in advanced cyber protection, Managed Detection and Response (MDR), and 24/7 Security Operations Centre (SOC) services. Founded by former Dutch national security experts, Eye Security helps businesses across Europe protect against ransomware, phishing attacks, data breaches and evolving cyber threats. Through its AI-powered cybersecurity platform, Eye Cyber Guard, the company delivers comprehensive cyber threat detection, incident response, vulnerability management, security awareness training and integrated cyber insurance . Supporting organisations across industries including logistics, manufacturing, healthcare and professional services, Eye Security helps businesses strengthen their cyber resilience, improve information security and navigate European cybersecurity regulations, including NIS2, GDPR and DORA. With a focus on proactive threat prevention, cyber risk management and business continuity, Eye Security provides expert cybersecurity insights, practical guidance and industry best practices to help organisations stay secure in an increasingly complex digital landscape.

Recent Blogs

De staat van incident response: inzichten uit 630 onderzoeken

Eye Security analyseerde tussen januari 2023 en november 2025 630 cybersecurity-incidenten in heel Europa. De analyse biedt inzicht in detectie, dwell time, onderliggende oorzaken en operationele impact. Van ransomware tot business email compromise laat de incidentdata zien hoe dreigingsactoren vertrouwen, tijd en technologie misbruiken en hoe Managed Detection and Response (MDR) de uitkomst verandert. De cijfers achter de inbreuk Productie en industrie (18,6%), vastgoed en bouw (12,1%) en transport en logistiek (10,3%) waren samen goed voor meer dan 40% van alle incidenten. Business Email Compromise (BEC) was verantwoordelijk voor 70% van alle incidenten. Phishing, spearphishing en social engineering vormden gezamenlijk 33% van alle incidenten. In MDR-omgevingen werden incidenten tot 90% sneller opgelost. Bij BEC daalde de gemiddelde dwell time van 24 dagen (ongeveer 3,5 week) naar minder dan 24 minuten. In 70% van de ransomware-incidenten werd onderhandeld over het losgeld. Slechts 27% leidde daadwerkelijk tot betaling. De gemiddelde losgeldeis bedroeg 613.000 dollar.

Van checklists naar operationele weerbaarheid onder de NIS2

Organisaties in heel Europa bewegen zich in hoog tempo van compliance-checklists naar echte operationele cyberweerbaarheid. In Nederland heeft de aankomende NIS2-richtlijn al geleid tot een golf aan zelfevaluaties, gap-analyses en beleidsdocumenten. Maar zodra die rapporten zijn afgerond en de knelpunten zijn benoemd, volgt de belangrijkste vraag: hoe zorg je er in de praktijk voor dat je organisatie structureel veilig blijft?

Vertrouwde AI-tools, onverwachte risico’s: wat bestuurders moeten weten

Recent onderzoek van Eye Security laat zien dat gedeelde AI-canvassen overtuigend legitieme zakelijke content kunnen nabootsen, zoals HR-enquêtes of interne inlogpagina’s. Wanneer deze canvassen worden verspreid via e-mail of berichtenplatforms, ogen ze betrouwbaar. Ze zijn immers gehost op domeinen van bekende AI-diensten. En precies dát vertrouwen vormt vandaag de dag de kern van veel succesvolle cyberaanvallen. In deze blog leggen we uit waarom AI-canvassen geen op zichzelf staand nieuw aanvalstype introduceren, maar wél een nieuw distributiekanaal vormen voor bekende social-engineeringtechnieken, en waarom dat relevant is voor bestuurders en IT-leiders. Lees meer in de volledige technische analyse.