Wulfric Ransomware is a cryptor that doesn't exist

Sometimes one really wants to look into some kind of virus writer and ask: why and why? We will deal with the answer to the question “how” ourselves, but it would be very interesting to find out what the malware creator was guided by. Especially when we come across such "pearls".

The hero of today's article is an interesting copy of the cryptographer. He thought, apparently, as another ransomware, but its technical implementation is more like someone’s evil joke. We’ll talk about this implementation today.

Unfortunately, it is practically impossible to trace the life cycle of this encoder - there are too few statistics on it, since, fortunately, it has not received distribution. Therefore, we leave out of origin the origin, methods of infection, and other references. We will only talk about our case of meeting with Wulfric Ransomware and how we helped the user save his files.

I. How it all began


Our anti-virus lab is often contacted by people who have been affected by cryptographers. We provide assistance no matter what antivirus products they have installed. This time we were approached by a person whose files were struck by an unknown encoder.
Good afternoon! Files on file storage (samba4) with passwordless entry were encrypted. I suspect that the infection went from my daughter's computer (Windows 10 with native Windows Defender protection). The daughter’s computer was not turned on after that. Files are mainly encrypted .jpg and .cr2. File extension after encryption: .aef.


We received from the user samples of encrypted files, a ransom note and a file, which is probably the key that the encryption author needs to decrypt the files.

That's all our leads:

  • 01c.aef (4481K)
  • hacked.jpg (254K)
  • hacked.txt (0K)
  • 04c.aef (6540K)
  • pass.key (0K)

Let's take a look at the note. How many bitcoins this time?

Transfer:
, !
.

0.05 BTC -: 1ERtRjWAKyG2Edm9nKLLCzd8p1CjjdTiF
, pass.key Wulfric@gmx.com .

.

:
buy.blockexplorer.com
www.buybitcoinworldwide.com
localbitcoins.net

:
en.wikipedia.org/wiki/Bitcoin
- , Wulfric@gmx.com
, .

Pathos wolf, designed to show the victim the seriousness of the situation. However, it could have been worse.


Fig. 1. -As a bonus, I will tell you how to protect your computer in the future. –Seems legit.

II. Getting to work


First of all, we looked at the structure of the sent sample. Oddly enough, it did not look like a file that suffered from an encryptor. We open the hex editor and look. The first 4 bytes contain the original file size, the next 60 bytes are filled with zeros. But the most interesting is at the end:


Fig. 2 Analyze the damaged file. What immediately catches your eye?

Everything turned out to be offensively simple: 0x40 bytes from the header were moved to the end of the file. To recover data, simply return them to the beginning. Access to the file was restored, but the name remained encrypted, and with it everything is more complicated.


Fig. 3. The encrypted name in Base64 looks like an incoherent character set.

Let's try to parse pass.keysent by user. In it we see a 162-byte character sequence in ASCII.


Fig. 4. 162 characters left on the victim's PC.

If you look closely, you will notice that the characters are repeated with a certain frequency. This may indicate the use of XOR, where repetitions are characteristic, the frequency of which depends on the length of the key. Having broken a line of 6 characters and performed with some variants of XOR sequences, we did not achieve any meaningful result.


Fig. 5. See duplicate constants in the middle?

We decided to google the constants, because yes, that’s also possible! And all of them eventually led to one algorithm - Batch Encryption. After studying the script, it became clear that our line is nothing but the result of its work. It should be mentioned that this is not an encryptor at all, but only an encoder replacing characters with 6-byte sequences. No keys or other secrets for you :(


Fig. 6. A piece of the original algorithm of unknown authorship.

The algorithm would not work as it should, if not for one detail:


Fig. 7. Morpheus approved.

Using reverse substitution, we turn the string from pass.key into text of 27 characters. Of particular note is the human (most likely) text 'asmodat'.


Fig. 8. USGFDG = 7.

Google will help us again. After a short search, we find an interesting project on GitHub - Folder Locker, written in .Net and using the 'asmodat' library from another account on the Gita.


Fig. 9. Folder Locker interface. Be sure to check for malware.

The utility is an encryptor for Windows 7 and above, which is distributed open source. When encrypting, the password required for subsequent decryption is used. Allows you to work with individual files as well as with entire directories.

Her library uses the symmetric Rijndael encryption algorithm in CBC mode. It is noteworthy that the block size was chosen equal to 256 bits - in contrast to that adopted in the AES standard. In the latter, the size is limited to 128 bits.

Our key is formed according to the PBKDF2 standard. In this case, the password is SHA-256 from the line entered in the utility. It remains only to find this line to form the decryption key.

Well, back to our already decoded pass.key . Remember that line with a set of numbers and the text 'asmodat'? We try to use the first 20 bytes of the string as the password for the Folder Locker.

Look, it works! The code word came up, and everything was perfectly deciphered. Judging by the password characters, this is a HEX representation of a specific word in ASCII. Let's try to display the code word in text form. We get ' shadowwolf '. Already feeling the symptoms of lycanthropy?

Let's take another look at the structure of the affected file, now knowing the mechanism of the locker:

  • 02 00 00 00 - name encryption mode;
  • 58 00 00 00 - length of the file name encrypted and encoded in base64;
  • 40 00 00 00 - the size of the transferred title.

The encrypted name itself and the transferred title, respectively, are highlighted in red and yellow.


Fig. 10. The encrypted name is highlighted in red, the transferred title is yellow.

Now compare the encrypted and decrypted names in hexadecimal representation.

The structure of the decrypted data:

  • 78 B9 B8 2E - garbage created by the utility (4 bytes);
  • 0 00 00 00 - length of the decrypted name (12 bytes);
  • next comes the actual file name and padding with zeros to the desired block length (padding).


Fig. 11. IMG_4114 looks much better.

III. Conclusions and Conclusion


Returning to the beginning. We do not know what the author of Wulfric.Ransomware was guided by and what purpose he pursued. Of course, for the average user, the result of even such an encryptor will seem like a big disaster. Files do not open. All names are gone. Instead of the usual picture - a wolf on the screen. They make me read about bitcoins.

True, this time under the guise of a “terrible encoder” was hidden such an absurd and stupid attempt to extort, where an attacker uses ready-made programs and leaves the keys right at the scene of the crime.

Speaking of keys. We didn’t have a malicious script or trojan to understand how this pass.key originated- the mechanism for the appearance of the file on the infected PC remains unknown. But, I remember, in his note, the author mentioned the uniqueness of the password. So, the code word for decryption is as unique as the shadow wolf username is unique :)

And yet, shadow wolf, why and why?

Source: https://habr.com/ru/post/undefined/


All Articles