Soms wil je gewoon in de ogen kijken van een virusschrijver en vragen: waarom en waarom? We kunnen de vraag ‘hoe’ zelf beantwoorden, maar het zou heel interessant zijn om erachter te komen wat deze of gene malware-maker dacht. Zeker als we zulke ‘parels’ tegenkomen.
De held van het artikel van vandaag is een interessant voorbeeld van een cryptograaf. Het was blijkbaar bedoeld als de zoveelste “ransomware”, maar de technische implementatie ervan lijkt meer op iemands wrede grap. We zullen het vandaag over deze implementatie hebben.
Helaas is het bijna onmogelijk om de levenscyclus van deze encoder te traceren - er zijn te weinig statistieken over, omdat deze gelukkig niet wijdverspreid is geworden. Daarom laten we de oorsprong, infectiemethoden en andere verwijzingen achterwege. Laten we het gewoon hebben over ons geval van ontmoeting met Wulfric-ransomware en hoe we de gebruiker hielpen zijn bestanden op te slaan.
I. Hoe het allemaal begon
Mensen die slachtoffer zijn geworden van ransomware nemen vaak contact op met ons antiviruslaboratorium. Wij bieden hulp, ongeacht welke antivirusproducten ze hebben geïnstalleerd. Deze keer werden we gecontacteerd door een persoon wiens bestanden werden beïnvloed door een onbekende encoder.
Goedemiddag Bestanden werden gecodeerd op een bestandsopslag (samba4) met wachtwoordloze login. Ik vermoed dat de infectie afkomstig is van de computer van mijn dochter (Windows 10 met standaard Windows Defender-bescherming). Daarna werd de computer van de dochter niet meer ingeschakeld. De bestanden zijn voornamelijk gecodeerd in .jpg en .cr2. Bestandsextensie na codering: .aef.
We hebben van de gebruikers voorbeelden van gecodeerde bestanden ontvangen, een losgeldbriefje en een bestand dat waarschijnlijk de sleutel is die de auteur van de ransomware nodig had om de bestanden te decoderen.
Hier zijn al onze aanwijzingen:
- 01c.aef (4481K)
- gehackt.jpg (254K)
- gehackt.txt (0K)
- 04c.aef (6540K)
- toegangssleutel (0K)
Laten we de notitie eens bekijken. Hoeveel bitcoins deze keer?
Vertaling:
Let op, uw bestanden zijn gecodeerd!
Het wachtwoord is uniek voor uw pc.Betaal het bedrag van 0.05 BTC op het Bitcoin-adres: 1ERtRjWAKyG2Edm9nKLLCzd8p1CjjdTiF
Stuur mij na betaling een e-mail met het pass.key-bestand als bijlage [e-mail beveiligd] met bericht van betaling.Na bevestiging stuur ik u een decryptor voor de bestanden.
U kunt op verschillende manieren online voor bitcoins betalen:
— betaling met bankkaart
Over Bitcoins:
Als u vragen heeft, kunt u mij schrijven op [e-mail beveiligd]
Als bonus vertel ik u hoe uw computer is gehackt en hoe u deze in de toekomst kunt beschermen.
Een pretentieuze wolf, ontworpen om het slachtoffer de ernst van de situatie te laten zien. Het had echter nog erger kunnen zijn.
Rijst. 1. -Als bonus zal ik u vertellen hoe u uw computer in de toekomst kunt beschermen. -Lijkt legitiem.
II. Laten we beginnen
Allereerst hebben we gekeken naar de structuur van het verzonden monster. Vreemd genoeg leek het niet op een bestand dat beschadigd was door ransomware. Open de hexadecimale editor en kijk eens. De eerste 4 bytes bevatten de oorspronkelijke bestandsgrootte, de volgende 60 bytes zijn gevuld met nullen. Maar het meest interessante is aan het einde:
Rijst. 2 Analyseer het beschadigde bestand. Wat springt meteen in het oog?
Alles bleek hinderlijk eenvoudig: 0x40 bytes uit de header werden naar het einde van het bestand verplaatst. Om gegevens te herstellen, zet u deze eenvoudigweg terug naar het begin. De toegang tot het bestand is hersteld, maar de naam blijft gecodeerd, en de zaken worden er ingewikkelder mee.
Rijst. 3. De gecodeerde naam in Base64 ziet eruit als een uitgebreide reeks tekens.
Laten we proberen het uit te zoeken toegangssleutel, ingediend door gebruiker. Daarin zien we een reeks ASCII-tekens van 162 bytes.
Rijst. 4. Er staan nog 162 tekens op de pc van het slachtoffer.
Als je goed kijkt, zul je merken dat de symbolen met een bepaalde frequentie worden herhaald. Dit kan wijzen op het gebruik van XOR, dat zich kenmerkt door herhalingen waarvan de frequentie afhangt van de sleutellengte. Nadat we de string in zes tekens hadden gesplitst en een XOR-bewerking hadden uitgevoerd met enkele varianten van XOR-reeksen, bereikten we geen enkel betekenisvol resultaat.
Rijst. 5. Zie je de herhalende constanten in het midden?
We besloten constanten te googlen, want ja, dat kan ook! En uiteindelijk leidden ze allemaal tot één algoritme: Batch Encryption. Na bestudering van het script werd het duidelijk dat onze lijn niets meer is dan het resultaat van zijn werk. Er moet worden vermeld dat dit helemaal geen encryptor is, maar slechts een encoder die tekens vervangt door reeksen van 6 bytes. Geen sleutels of andere geheimen voor jou :)
Rijst. 6. Een stukje van het originele algoritme van onbekend auteurschap.
Het algoritme zou niet werken zoals het zou moeten als er niet één detail was:
Rijst. 7. Morpheus goedgekeurd.
Met behulp van omgekeerde substitutie transformeren we de string van toegangssleutel in een tekst van 27 tekens. De menselijke (hoogstwaarschijnlijke) tekst 'asmodat' verdient bijzondere aandacht.
Afb.8. USGFDG=7.
Google zal ons weer helpen. Na een beetje zoeken vinden we een interessant project op GitHub - Folder Locker, geschreven in .Net en met behulp van de 'asmodat'-bibliotheek van een ander Git-account.
Rijst. 9. Folder Locker-interface. Zorg ervoor dat u controleert op malware.
Het hulpprogramma is een encryptor voor Windows 7 en hoger, die als open source wordt gedistribueerd. Tijdens de codering wordt een wachtwoord gebruikt, dat nodig is voor de daaropvolgende decodering. Hiermee kunt u zowel met individuele bestanden als met hele mappen werken.
De bibliotheek maakt gebruik van het Rijndael symmetrische encryptie-algoritme in CBC-modus. Het is opmerkelijk dat er voor de blokgrootte 256 bits is gekozen - in tegenstelling tot de waarde die in de AES-standaard is aangenomen. In het laatste geval is de grootte beperkt tot 128 bits.
Onze sleutel wordt gegenereerd volgens de PBKDF2-standaard. In dit geval is het wachtwoord SHA-256 uit de string die in het hulpprogramma is ingevoerd. Het enige dat overblijft is het vinden van deze string om de decoderingssleutel te genereren.
Laten we terugkeren naar onze reeds gedecodeerde toegangssleutel. Ken je die regel nog met een reeks cijfers en de tekst 'asmodat'? Laten we proberen de eerste 20 bytes van de string te gebruiken als wachtwoord voor Folder Locker.
Kijk, het werkt! Het codewoord kwam tevoorschijn en alles werd perfect ontcijferd. Afgaande op de tekens in het wachtwoord is het een HEX-weergave van een specifiek woord in ASCII. Laten we proberen het codewoord in tekstvorm weer te geven. We krijgen 'schaduw Wolf'. Voel je al de symptomen van lycantropie?
Laten we nog eens kijken naar de structuur van het getroffen bestand, nu we weten hoe het kluisje werkt:
- 02 00 00 00 – naamcoderingsmodus;
- 58 00 00 00 – lengte van de gecodeerde en base64-gecodeerde bestandsnaam;
- 40 00 00 00 – grootte van de overgedragen header.
De gecodeerde naam zelf en de overgedragen header worden respectievelijk rood en geel gemarkeerd.
Rijst. 10. De gecodeerde naam is rood gemarkeerd, de overgedragen header is geel gemarkeerd.
Laten we nu de gecodeerde en gedecodeerde namen vergelijken in hexadecimale weergave.
Structuur van gedecodeerde gegevens:
- 78 B9 B8 2E – afval gecreëerd door het hulpprogramma (4 bytes);
- 0С 00 00 00 – lengte van de gedecodeerde naam (12 bytes);
- Vervolgens komt de daadwerkelijke bestandsnaam en opvulling met nullen tot de vereiste bloklengte (opvulling).
Rijst. 11. IMG_4114 ziet er veel beter uit.
III. Conclusies en conclusie
Terug naar het begin. We weten niet wat de auteur van Wulfric.Ransomware motiveerde en welk doel hij nastreefde. Voor de gemiddelde gebruiker zal het resultaat van het werk van zelfs zo'n encryptor natuurlijk een grote ramp lijken. Bestanden worden niet geopend. Alle namen zijn verdwenen. In plaats van de gebruikelijke afbeelding is er een wolf op het scherm. Ze dwingen je om over bitcoins te lezen.
Het is waar dat deze keer, onder het mom van een 'verschrikkelijke encoder', zo'n belachelijke en domme poging tot afpersing verborgen was, waarbij de aanvaller kant-en-klare programma's gebruikt en de sleutels op de plaats delict achterlaat.
Trouwens, over de sleutels. We hadden geen kwaadaardig script of Trojaans paard dat ons kon helpen begrijpen hoe dit gebeurde. toegangssleutel – het mechanisme waarmee het bestand op een geïnfecteerde pc verschijnt, blijft onbekend. Maar ik herinner me dat de auteur in zijn notitie het unieke karakter van het wachtwoord noemde. Het codewoord voor decodering is dus net zo uniek als de gebruikersnaam shadow wolf uniek is :)
En toch, schaduwwolf, waarom en waarom?
Bron: www.habr.com