Goldeneye Ransomware – the Petya/Mischa combo rebranded

From March 2016 we’ve observed the evolution of an interesting low-level ransomware, Petya – you can read about it here. The second version (green) Petya comes combined with another ransomware, packed in the same dropper – Mischa. The latter one was deployed as an alternative payload: in case if the dropper was run without administrator privileges and the  low-level attack was impossible. This combo is slowly reaching its maturity – the authors fixed bugs that allowed for decryption of the two earliest versions. Now, we are facing an outbreak of the fourth version – this time under a new name – Goldeneye, and, appropriately, a new, golden theme.

In this post we will take a look inside, in order to answer the question of whether or not any internal changes followed the external alterations.

Analyzed sample

• e068ee33b5e9cb317c1af7cecc1bacb5 – original sample (packed)
  • 08b079609c2a3a4deb4f11cf373f9278 – core.dll (dropper) // UPDATE: replaced with a fixed dump
    • 0cd94baa2dccc0e7c2008b7948cebfe3 – elevate_x86.dll
    • 54fb6dbad73eee5d8638c0869c35ed8f – elevate_x64.dll
    • e5a2cc00d1ad8d409576bc6d24a346bd – Petya Golden (dump from the disk)

• 435076f9c8900cbdfc48a15713b1c431 – Goldeneye Decrypter (original)

// special thanks to @procrash

Distribution

Currently Goldeneye is distributed by phishing e-mails, in campaigns targeting Germany. The same pattern of distribution was observed in first editions of Petya ransomware. Germany seems to be an environment familiar to this ransomware author (who is probably a German native speaker) and his testing campaigns are always released in this country. However, the threat will probably go global again, as the affiliate program for other criminals is going to be released soon.

Behavioural analysis

After being run, the malware installs its copy in the %APPDATA% directory, under the name of a random application found in the system:

The installed copy is automatically executed and proceeds with malicious actions.

In the past, the dropper of Petya/Mischa used to trigger a UAC popup window. If the user had agreed to run the sample as the Administrator, he/she was attacked by the low-level payload: Petya. Otherwise, the high-level Mischa was deployed.

In the current case the model of the attack is different and looks more like a case of Satana ransomware.

First, the high-level attack is deployed and the files are encrypted one by one. Then, the malware tries to bypass UAC and elevate its privileges by its own, in order to make the second attack, this time at low-level: installing Petya at the beginning of the disk. The bypass works silently if the UAC is set to default or lower. In cases where the UAC is set to max, the following window pops up repeatedly, till the user accepts the elevation:

The used bypass techniques works on both –  32-bit and 64-bit – versions of Windows, up to Windows 8.1. On Windows 10, even if the UAC is set to default a popup is displayed – but not revealing the real name of the infecting program, i.e.

Files that are encrypted are added random extensions:

If we have two files with the same plaintext they turn into two different cipher-texts – that indicates that each file is encrypted with a new key or an initialization vector. The high entropy suggests AES in CBC mode.

Visualization – original file vs encrypted one:

The low-level part (former Petya)

The second stage of infection is deployed after encrypting the files. The behavior of second payload is no different than in the previous versions of Petya. After the malware is deployed, system crashes and starts with a fake CHKDSK. It pretends to be checking the disk for errors, but in reality it performs Master File Table encryption, using Salsa20. After it is completed, we are facing a familiar blinking skull – this time in yellow/golden color:”>

After pressing a key, we can see the screen with the ransom note:

After paying the ransom, the victim is provided with a key to decrypt the first (bootlocker) stage and a decrypter to recover the files:

The decrypter requires having a proper key in order to work:

It confirms that the actor behind Goldeneye as well as the methods of redistributing it didn’t change.

Inside

This ransomware is very complex, having multiple pieces that have already been described in our previous articles. That’s why, in this one we will focus only on the differences comparing to the previous editions. Let’s start from the core.dll, that is the PE file that we get after unpacking the first layer.

The core.dll

Just like in the previous versions, the main application is a DLL (core.dll), packed by various crypters and loaded by a technique known as Reflective Loader.

In the past Petya and Mischa were two separate modules delivered by this DLL. The dropper was deciding which one of them to deploy, by making an attempt to run the sample with Administrator privileges – no UAC bypass was used, only social engineering. Now, however, it comes with two DLLs that perform UAC bypass – one for 32 bit and another for 64 bit variant of Windows. It decides which one to deploy, basing on the detected architecture.

The internal logic of this module changed a bit. There is no Mischa.dll separated. Instead, the core.dll covers the functionality of encrypting files as well as of installing disk locker afterwards. The payloads are XOR encrypted and stored in the last section of the PE file (.xxxx):

Section .xxxx contains:

• the low level part (former Petya)
• 32 bit DLL (elevate_x86.dll)
• 64 bit DLL (elevate_x64.dll)

(The two DLLs used to UAC bypass are based on the technique similar to the one described here.)

At first run, the core module makes its own copy into %APPDATA% and applies some tricks to blend into the environment:

• Choosing the application name at random, out of various applications in System folder
• Changing own timestamp to the timestamp of Kernel32.dll (the so called “timestomping” technique).
• Adding to its resources the resource of the genuine Microsoft application, under which name it is installed:

Result:

Some of those tricks remind us of Cerber ransomware and they were probably inspired by it.

Then, the dropper deploys the installed copy and proceeds with encryption.

The file cryptor (former Mischa)

The file cryptor feature is now implemented inside the core.dll.

It behaves similarly to the former Mischa ransomware – the only difference is that now it is employed before the low-level attack, rather than being an alternative.

Attacked targets

Files are attacked with the following extensions:

doc docx docm odt ods odp odf odc odm odb xlsm xlsb xlk xls xlsx  pps ppt pptm pptx pub epub pdf  jpg jpegB rtf txt frm wdb ldf myi vmx xml xsl wps cmf vbs accdb cdr svg conf cfg config wb2 msg azw  azw1 azw3 azw4 lit apnx mobi p12 p7b p7c pfx pem cer key der mdb  htm html class java cs asp aspx cgi h cpp php jsp bak dat pst eml  xps sqllite sql js jar py wpd crt csv prf cnf indd number pagesN  po dcu pas dfm	directory pbk yml dtd rll cert p12 cat inf mui  props idl result localstorage ost default json db sqlite bat x3f  srw pef raf orf nrw nef mrw mef kdc dcr crw eip fff iiq k25 crwl  bay sr2 ari srf arw cr2 raw rwl rw2 r3d 3fr ai eps pdd dng dxf dwg  psd ps png jpe bmp gif tiff gfx jge tga jfif emf 3dm 3ds max obj  a2c ddspspimage yuv 3g2 3gp asf asx mpg mpeg avi mov flv wma wmv  ogg swf$ ptx ape aif wav ram ra m3u movie mp1 mp2 mp3 mp4 mp4v mpa  mpe mpv2 rpf vlc m4a aac aa aa3 amr mkv dvd mts qt vob 3ga ts m4v  rm srt aepx camproj dash  zip rar gzip vmdk mdf iso bin cue dbf  erf dmg toast vcd ccd disc nrg nri cdi 

Encryption

Files are read in chunks, each is 1024 bytes long. Then, they are processed by the built-in implementation of AES.

The easiest way to analyze the encryption algorithm used, is by reversing the original decrypter, provided by the ransomware author to victims that paid the ransom. The decrypter is written in .NET and not obfuscated.

Looking at the decrypter code we can confirm that each file is encrypted using AES in CBC mode. The AES key is 32 byte long, and it is the taken from the beginning of SHA512 hash of the password.

The initialisation vector is random for every file and it is stored in its content:

Indeed, comparing the current edition with Petya 3 (described here) we can see, that the encryption algorithm and the codebase hasn’t changed. Yet, we can spot some differences.

Encryption

All versions of Petya use Salsa20 to encrypt MFT. In the current edition, the implementation of Salsa20 is identical like in the former version.

See the BinDiff screenshot below – Petya Goldeneye vs Petya 3:

We can safely assume, that just like in the previous case the Salsa20 has been implemented correctly – means, this edition of Petya is not decryptable by external tools.

What has changed in the code?

Although the main parts of the code didn’t change, still we can notice that some refactoring has taken place:

The most important changes are about the way in which the encryption/decryption is applied. The author added more checks and simplified the decryption function. Yet, the changes are rather about improving the code quality rather than introducing some new ideas.

Layout

Just like in the previous cases, Petya’s code is written at the beginning of the disk – however, now the layout is more compact. The code of Petya’s kernel starts just after MBR, without any padding. Due to this, other important sectors are also shifted. For example, the data sector, where the random salsa key is saved*, is now placed in sector 32:

* just like in all previous editions, this key is erased after use. Read more about the full procedure here.

Summing up, all the sectors are shifted towards the beginning of the disk.

Data sector:

• Petya3: 54
• Petya Goldeneye: 32

Verification sector:

• Petya3: 55
• Petya Goldeneye: 33

Original MBR (xored with 7)

• Petya3: 56
• Petya Goldeneye: 34

Conclusion

Goldeneye ransomware is yet another step in the development of the Petya/Mischa bundle. The redesigned dropper coupled both elements together in a new way, that makes it even more dangerous. At the current stage the product doesn’t seem decryptable by external tools. We strongly advise to be very vigilant about opening e-mail attachments, because this is still the main way of distribution of this ransomware.

During the tests, Malwarebytes has proven to protect against the malicious payloads attached to Goldeneye phishing e-mails:

This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.