Ransomware operators are always on the lookout for a way to take their ransomware to the next level. That’s particularly true of the gang behind LockBit. Following the lead of the Maze and REvil ransomware crime rings, LockBit’s operators are now threatening to leak the data of their victims in order to extort payment. 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 September, a new ransomware brand emerged just as the Maze ransomware gang began shuttering its operation. Named Egregor (from an occult term derived from the Greek word ἑγρήγορος, “wakeful”—a term used to refer to an angel-like spirit or group mind), the ransomware leverages data stolen during the attack to extort the victim for payment, following a trail blazed by Maze.

Egregor’s ransom note tells its victims “soon mass media, your partners and clients WILL KNOW about your PROBLEM…If you do not contact us in the next 3 DAYS we will begin DATA publication.”

Like Maze, Egregor uses the ChaCha and RSA encryption algorithms to encrypt victims’ files. Also like Maze, Egregor is suspected to be a ransomware-as-a-service operation—dependent on affiliates who receive payment for dropping the malware on victims’ networks.

But Egregor’s code is not a derivative of the malware used by Maze; rather, it is a variant of a ransomware family known as Sekhmet. Sekhmet’s operators started publishing data from victims in March 2020, but their “Sekhmet Leaks” website is no longer accessible, and only six victims were publicly exposed by the ring before the site went down—which coincided with the launch of the Egregor site. It’s not clear if the creators of Egregor and Sekhmet are the same, but Egregor’s ransomware is clearly derived from the Sekhmet malware.

We first detected Egregor in September during an attack against a customer. As of November 25, the ring has posted details on over 130 victims on its Tor hidden services (.onion) website. The alleged victims of these attacks are diverse, both in terms of location and organization type—they include schools, manufacturers, logistics organizations, financial institutions, and technology companies. The Egregor gang specifically called out two gaming companies—Crytek and Ubisoft—in a “press release” in October.

The spirit descends

Commodity malware is the vehicle most commonly associated with Egregor. Some of the attacks we’ve tracked were linked with Qbot malware activity, though it was not clear how long Qbot had been present on the victims’ networks. Qbot (also known as Qakbot) deploys from a malicious document file attached to an e-mail message. Earlier this year, ZDNet reported that Qbot’s operators engaged in “thread hijacking,” sending the maldocs as replies to ongoing email threads in order to dupe targets into opening the malicious attachments.

Egregor has no way to spread itself, so it requires the attackers to move laterally themselves, using built-in Windows capabilities and other exploitation tools. In some cases, Cobalt Strike exploitation tools have been detected as part of Egregor attacks. The attacker(s) used these tools to execute scripts, gather information about other systems on the network, extract additional credentials, and spread the ransomware. In one case, the Cobalt Strike agent was used to create an RDP connection to other machines on the targeted network, and copy the Egregor executable to them—copying the files to the directory C:perflogs.

In the same attack, another malware called SystemBC—a Tor network proxy—was used to create an obfuscated backchannel for data exfiltration and attack communications. The use of Cobalt Strike, SystemBC and the C:perflogs directory in this case match the behavior seen in a Ryuk attack we investigated in September 2020. (We’ve also seen Cobalt Strike tools used in connection with earlier Sekhmet attacks.)

After exfiltrating data, the attackers launch the ransomware. The approach to launching the ransomware varied across the incidents we examined; in some cases, it was launched by a script, and in others it was configured as a scheduled Windows task.

As with Sekhmet, the Egregor ransomware itself is not an executable, but a dynamic link library (DLL) that is executed using Windows’ rundll32.exe utility. To evade sandbox detection, the DLL will only execute when given a password as a command line parameter, along with a flag for the type of the attack to be executed. We’ve seen three different passwords used in attacks we investigated, in addition to other parameters:

The DLL is a two-stage package. The first stage is an unpacker that verifies the password is correct by checking against its SHA256 value. The second stage is the actual decrypted ransomware DLL, which contains the ransom note format, along with a hardcoded RSA key and list of files and process names to kill or terminate. There’s also a number of “spaghetti” functions included for the purpose of deterring analysis of the code.

Paying the piper

Once Egregor executes, it encrypts a wide variety of data files, including images, videos, documents, SQL and other database-related files, Web pages, JavaScript files, and executables. Encrypted files have their names appended with an extension made up of random characters. As with Sekhmet, the ransomware drops a ransom demand in a text file named RECOVER-FILES.txt:

The “special technical block” at the end of the ransom note is unique to the victim. Following the note’s instructions to connect via a Tor browser or via a public internet to the Egregor web portal, which instructs victims to upload their RECOVER-FILES.txt file.

From there, victims can engage with Egregor’s “customer service” organization to receive the ransom demand and negotiate payment.

More of the same

The use of crafted spam messages with malicious attachments, commodity malware and exploitation tools, and exfiltration of data for extortion purposes have become common tactics as ransomware developers have shifted to an “as-a-service” model. These threats require a defense in depth to prevent theft and encryption of data, including educating employees on the tactics that might trick them into executing the malware that gives ransomware attackers their foothold on the network.

Given that the group behind Egregor claims to sell stolen data if ransoms are not paid, it’s not enough to have good backups of organizational data as a mitigation for ransomware. Organizations need to assume that their data has been breached if they suffer an Egregor (or any other ransomware) attack. Blocking common exfiltration routes for data—such as preventing Tor connections—can make stealing data more difficult, but the best defense is to deny attackers access through email attachment malware and other common entry points.

Malware protection throughout the organization can help prevent commodity malware attacks such as Qbot, and lateral spread through tools such as Cobalt Strike. (Sophos detects Egregor in multiple ways, and also detects Cobalt Strike and Qbot, as noted in the indicators of compromise posted on SophosLabs’ GitHub.)

Acknowledgments

SophosLabs would like to acknowledge the contributions of Anand Aijan, Gabor Szappanos, and Mark Loman to this report, as well as Peter Mackenzie, Syed Shahram, Bill Kearney, and Sergio Bestulic of Sophos MTR’s Rapid Response team.

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.

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.

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

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

Sophos Anti Ransomware

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.

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.

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:usersAdministratorAppDataRoamingMicrosoftWindowsStart MenuStartup, 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.

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.

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.

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.

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

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

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

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

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

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

Sophos Maze Ransomware Update

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 Maze Ransomware

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.