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

// 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:

golden_dropped

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:

uac_highest

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.

win10_petya

 The high-level part (former Mischa)

On the first stage of the attack, files are being encrypted one by one. The malware drops the following note in TXT format:

mischa_note

Files that are encrypted are added random extensions:

encrypted_files

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:

enc_square1  enc_square1-bmp-yc5pdbhp

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:

yellow1

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

yellow2

Page for the victim

On every edition all the pieces of the ransomware had a consistent theme. This time is no different. The page for the victim, that is hosted on a Tor-based site comes in very similar theme like the ransomware itself:

victim_page

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

decryptor

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

password_dec

Affiliate program

In the past, Petya/Mischa combo was available as RaaS (Ransomware as a Service). Following the changes in the layout, the Twitter account associated with the criminal(s) behind the malware, also changed the theme of the profile, and updated the information about the affiliate program status:

janus

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.

core_dll

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):

core_dll

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:

add_resource

Result:

spoofed_res

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.

read_encrypt

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.

aes_key

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

decompiled1

The disk locker (former Petya)

This part of the Goldeneye ransomware is written at the disk beginning and is independent from the operating system. It is made up of a bootloader and a tiny, 16-bit kernel. At the very first sight we can suspect, that it is nothing more than a refactored Petya. That’s why, for the simplicity I will refer this part as Petya Goldeneye.

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:

no_change

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:

changes

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:

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:

thumbnail__golden_eye2-jpg


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.

https://blog.malwarebytes.com/feed/