Analyse van de BlackMatter ransomware

Om te voorkomen dat er informatie over de werking van malware bekend wordt, zorgen de criminelen er vaak voor dat de adressen van Win32 API-functies pas tijdens runtime worden omgezet. Op die manier zijn de namen van functies niet zichtbaar in de Import Address Table (IAT) van de binary en is het dus voor statische analysetools niet mogelijk om daar informatie uit op te halen. BlackMatter maakt eveneens gebruik van dynamische Win32 API-omzetting. De adressen van de functies die worden gebruikt, worden door BlackMatter pas na het starten omgezet. In het onderstaande screenshot zien we dat BlackMatter eerst de functies HeapCreate en HeapAlloc omzet. Vervolgens worden er functies geladen uit meer dan 10 verschillende bibliotheken.

Als we inzoomen op de functie ‘decrypt_and_resolve_funcs’, dan zien we dat deze meerdere hashes uit een bepaald blok ontsleutelt en omzet. Voor elke bibliotheek waaruit BlackMatter functies nodig heeft, bevat de malware een blok versleutelde hashes, gevolgd door de code 0xCCCCCCCC. Elk van die versleutelde hashes wordt eerst ontsleuteld met behulp van een 32-bits XOR met de sleutel 0x22065FED. Na de ontsleuteling wordt de hash omgezet. De hash van een functienaam wordt berekend met behulp van twee hashfuncties die sterk op elkaar lijken: H₀ en H₁. H₀ berekent de hash van een Unicode-bibliotheeknaam (inclusief de terminator NULL) en H₁ berekent de hash van een ASCII-functienaam (eveneens inclusief de terminator NULL). De twee hashfuncties, die allebei ROR-13 bewerkingen uitvoeren, worden weergegeven in het onderstaande screenshot.

De hash voor een functienaam wordt berekend door eerst x = H₀ aan te roepen voor de bibliotheeknaam. De initiële waarde voor deze hash is nul. Om de uiteindelijke hash te berekenen, wordt H₁ vervolgens aangeroepen met ‘x’ als initiële waarde.

Voor elke Win32 API-functie die door BlackMatter wordt omgezet, maakt de malware handmatig een zogenoemde ‘call stub’ voor de functie. Deze stub is een klein stukje Assembly-code dat fungeert als proxy of doorstuurmechanisme voor een API-functieaanroep. Soms springt een call stub alleen naar de vereiste API-functie, maar in andere gevallen voert deze ook extra bewerkingen uit, zoals ontsleuteling of decodering. In het onderstaande screenshot zien we dat de call stub wordt gemaakt nadat ‘func_addr’ is omgezet.

Wanneer er nu een API-functie wordt aangeroepen, wordt in plaats daarvan de call stub aangeroepen. Het adres van de echte functie blijft versleuteld in het geheugen en de call stub zorgt ervoor dat dit adres wordt ontsleuteld voordat de aanroep wordt doorgestuurd. Zoals we in het onderstaande screenshot kunnen zien, is de call stub eigenlijk heel eenvoudig. Deze versleutelt het functieadres met behulp van dezelfde 32-bits XOR die we al eerder zijn tegengekomen. De waarde 0xDEADBEEF in de screenshot is een plaatshouder voor het echte adres van de API-functie.

Binnen malware wordt string encryptie gewoonlijk gebruikt om statische analyse te verijdelen. Ook BlackMatter maakt gebruik van een simpel string encryptie algoritme, vergelijkbaar met het algoritme dat wordt gebruikt voor API-omzetting. Overal in de code worden versleutelde strings op de stack geconstrueerd met behulp van DWORDs in plaats van tekens. De buffers die daarvan het resultaat zijn, worden inline ontsleuteld met behulp van een simpele XOR. Het string decryptie algoritme wordt weergegeven in het onderstaande screenshot.

BlackMatter bevat ook een ingebedde configuratie, en deze is op dezelfde manier gecodeerd als die van DarkSide. In dit geval bevindt de configuratie zich in het segment “.rsrc”. De configuratie begint met een 32-bits waarde voor de initial state van het decryptie algoritme. In dit geval is die waarde 0xFFCAA1EA. Daarna komt er een DWORD dat de grootte aangeeft, gevolgd door de versleutelde configuratie. Het decryptie algoritme, dat in het onderstaande screenshot wordt getoond, is gebaseerd op een enigszins aangepaste lineaire congruentiegenerator.

De ontsleutelde content wordt vervolgens gecomprimeerd met behulp van het aPlib algoritme. De ontsleutelde en gecomprimeerde configuratie begint met een openbare RSA-1024 sleutel. Verder omvat de configuratie een aantal Base64-gecodeerde strings voor:

• Command & control hostnamen
• Een AES-128 encryptiesleutel voor command & control
• Namen van services die uitgeschakeld moeten worden
• Bestanden en mappen die vermeden moeten worden
• Losgeldbericht (eveneens versleuteld met het bovenstaande algoritme)

Uiteraard willen we weten hoe het encryptieproces in de BlackMatter ransomware werkt. Net als DarkSide zorgt de BlackMatter ransomware er eerst voor dat blacklisted processen en services geforceerd worden uitgeschakeld, dat de prullenbakken voor alle drives worden leeggemaakt en dat alle schaduwkopieën worden gewist. Vervolgens gaat BlackMatter op het bestandssysteem op zoek naar bestanden die versleuteld moeten worden.

Het bestandsencryptieproces werkt met behulp van I/O completion ports. Dergelijke voltooiingspoorten bieden een efficiënt model voor het afhandelen van grote aantallen gelijktijdige I/O-bewerkingen op een systeem met meerdere CPU’s. Er wordt een I/O completion port met een bepaald aantal threads aangemaakt met behulp van de functie CreateIoCompletionPort. Hierna wordt er intern een wachtrij aangemaakt waar de threads de voltooiingsstatussen naartoe kunnen pushen. Dergelijke statussen kunnen in de wachtrij worden geplaatst met de functie PostQueuedCompletionStatus en ze kunnen door een thread uit de wachtrij worden opgehaald met de functie GetQueuedCompletionStatus.

Om de variabelen tijdens de encryptie bij te houden, kan er een door de gebruiker gedefinieerde datacontextstructuur aan een status worden gekoppeld. Dit is van belang als de eerste member een OVERLAPPED-structuur is. Met behulp van de voltooiingsstatuswachtrij kan er een controleflow van I/O-acties worden samengesteld. De bestandsencryptiefunctie in de BlackMatter ransomware gebruikt de statusnummers 0 t/m 3 voor het samenstellen van een controleflow. Deze controleflow is te zien in het onderstaande screenshot.

Zoals we zien, begint de encryptie met een nul: lees het volgende blok data uit het bestand. De status verandert dan in 1: versleutel het eerder gelezen blok data en schrijf het terug naar het bestand. De bestandsfooter wordt weggeschreven zodra de status verandert in 2. En nadat alle I/O-taken zijn voltooid, wordt de encryptie beëindigd met statusnummer 3.

De creatie van de door de gebruiker gedefinieerde contextstructuur is te zien in het onderstaande screenshot. De code bevat bijvoorbeeld het aantal bytes dat in een bestand versleuteld moet worden. Als het bestand kleiner is dan 1MiB, wordt het hele bestand versleuteld. Is het bestand groter, dan wordt de eerste 1MiB versleuteld.

De bestanden worden versleuteld met behulp van het stream cipher algoritme Salsa20, en de bijbehorende sleutels met behulp van RSA-1024. Als we inzoomen op de functie ‘inits_salsa20_state’, zien we dat de Salsa20-matrix geheel willekeurig wordt geïnitialiseerd, zonder sleutel en nonce. In het onderstaande screenshot wordt de matrix opgebouwd met random 8-byte waarden. De waarde van de nonce blijft nul.

BlackMatter controleert eerst of de CPU in het systeem van het slachtoffer de instructie RDRAND wel ondersteunt. Als dat zo is, wordt het volgende random getal gegenereerd door twee aanroepen van deze instructie te combineren. Ondersteunt de CPU van het slachtoffer de instructie RDRAND niet, dan wordt de timestamp counter van de CPU gebruikt. Het volgende random getal wordt dan samengesteld door de onderste 32 bits van twee timestamp counters te combineren. De ene wordt 13 bits naar links gerold, de andere 13 bits naar rechts. In het onderstaande screenshot is te zien hoe deze twee random getallen worden gegenereerd.

De random Salsa20-matrix wordt versleuteld met de in de configuratie aanwezige openbare RSA-1024 sleutel, en wordt weggeschreven naar de footer van het versleutelde bestand. De footer bevat bepaalde informatie over het bestand, zoals de oorspronkelijke grootte ervan en een magic value aan de hand waarvan BlackMatter kan zien welke bestanden er al versleuteld zijn. Het bestandsversleutelingsproces lijkt ook sterk op dat van DarkSide.

BlackMatter legt contact met command & control hosts om informatie over het slachtoffer te verzamelen. De hostnamen waarmee contact is gelegd, worden opgeslagen in de ingebedde configuratie die we al eerder hebben besproken. BlackMatter probeert eerst of het lukt om via HTTPS contact te leggen met de command & control hosts, en valt terug op HTTP als dat niet lukt. De verzonden HTTP POST-opdrachten richten zich op een random gegenereerde URI die bestaat uit sleutel/waarde-paren met tekens uit het Base64-alfabet. De bij de opdrachten behorende HTTP-data bestaat eveneens uit dergelijke sleutel/waarde-paren. Het verschil is dat een van de paren versleutelde data bevat.

De HTTP-opdrachten worden mogelijk gemaakt door de WinInet bibliotheek, inclusief functies zoals InternetOpenW, InternetConnectW en HttpSendRequestW. Een interessant kenmerk van de opdrachten is de User-Agent header. BlackMatter bevat meerdere hardgecodeerde user agents, waarvan er steeds eentje willekeurig wordt gekozen om dienst te doen in de verbindingen. De user agents zijn korter dan de standaardversies ervan, zoals we in het onderstaande screenshot kunnen zien.

Zoals eerder vermeld, wordt de versleutelde informatie over het slachtoffer in een van de sleutel/waarde-paren in de HTTP POST-data geplaatst. De positie van het paar in de string wordt willekeurig bepaald. We kunnen vaststellen welk paar er moet worden ontsleuteld door elk paar in de datastring met Base64 te decoderen en de grootte van het resultaat te checken. We doen een poging tot ontsleuteling van alle paren met een grootte die samenvalt met een grens van 16 bytes. Het hier gebruikte encryptie algoritme is AES-128 in ECB-modus (independent block-by-block encryption). De sleutel wordt in de configuratie geplaatst, vanaf 16 bytes na de openbare RSA-1024 sleutel. In het stukje code dat we geanalyseerd hebben, is de sleutel (hexadecimaal): A6F330B09CD47B4FB9214F7836AA46AD. Na ontsleuteling krijgen we het volgende JSON-object.

We zien nu dat we versie 1.2 van BlackMatter hebben geanalyseerd. Het object bevat host- en gebruikersinformatie, zoals ID’s voor het slachtoffer, de computer- en de gebruikersnaam, en de beschikbare schijfruimte op het geïnfecteerde systeem. De informatie in het JSON-object lijkt op datgene wat DarkSide naar de command & control-hosts stuurde. DarkSide verzamelde immers ook informatie over systeem, gebruiker en schijf.