IBM X-Force Incident Response and Intelligence Services (IRIS) researchers have been responding to and analyzing the MegaCortex ransomware since its emergence. MegaCortex’s rapid evolution is one of the ways by which it has adapted to its perpetrators’ goals. While malware does evolve over time, MegaCortex’s evolution has been especially speedy and significant over less than a year of its existence in actual campaigns in the wild, running from version 1 in May 2019 to version 4 by November 2019.

This post brings a concise rundown of what changed across the four MegaCortex versions released to date, including version 4. Technical information on previous MegaCortex releases can be found on X-Force Exchange: Version 1, Version 2 and Version 3.

The current version in the wild is v4, which also threatens victimized organizations that their data will be leaked online if they do not pay — but can it follow through? MegaCortex itself does not feature that sort of functionality and, even if it did, loading massive amounts of company data and attempting to exfiltrate it would either make too much noise on the network and be discovered, or take very long to exfiltrate slowly.

MegaCortex seems to be looking for ways to improve, and with each version upgrading the previous release’s functions, our team took a closer look at some of the highlights.

MegaCortex Generations — Rapid Evolution to Scale Attacks

Code signing certificates issued to fake companies, disabling security software, taking over domain controllers and living-off-the-land (LotL) tactics — MegaCortex targets company networks and continues to evolve its code to adapt.

The codebase of this ransomware most likely emerged in late 2018, with the first-ever samples uploaded to VirusTotal in January 2019. MegaCortex started appearing in attack campaigns around May 2019, at times featuring references from “The Matrix” to communicate with victims about what’s taking place on their devices.

All MegaCortex versions released to date are similar in the way they’re built. They are initially compiled using Microsoft Visual C++, and all use a cryptography library written for C++14 (a version of the ISO/IEC 14882 standard for the programming language C++) known as “mbedcrypto” to carry out the eventual file encryption process.

Bypassing Security With Signed Malware Files

To bypass the security controls that won’t run unsigned code on Windows machines, MegaCortex uses signed files to infect devices. Code signing certificates are files that contain a digital signature that can be used to sign code, such as executables and scripts. Certificates were created to generate trust and validation in software or code that we run on our devices and are checked by the operating system (OS), granting different types of files, drivers and scripts the ability to operate inside the OS.

This is why each MegaCortex version’s binary includes a digital signing certificate that was issued to what are most likely fake companies registered by fraudsters who peddle these types of certificates on the dark web, including:

• MegaCortex v1: “3AN LIMITED”
• MegaCortex v2: “ABADAN PIZZA LTD”
• MegaCortex v3: “LYUKS ELIT, LTD” and “FELIX MEDIA PTY LTD”
• MegaCortex v4: “MURSA PTY LTD”

Open-source information about these companies proves that they are not likely real entities even though they are registered as active and, in some cases, even modified their street addresses. Various vendors have contacted the issuing authorities in the past, asking that they revoke MegaCortex certificates to disable the malware’s ability to run in a more centralized fashion.

MegaCortex Shuts Off Security Processes

Much like any malware, MegaCortex’s operators do not want to see it detected too soon and halted before file encryption can commence. To that end, the malware prepares the grounds by finding and shutting off a list of security programs and related processes.

MegaCortex v1 was executed manually by threat actors using a separate batch file to kill security processes and stop/disable services related to security, backup and shadow copies. That same batch file was subsequently used to execute the MegaCortex binary with a Base64 key as a command-line argument.

MegaCortex v2 incorporated terminating processes and stopping services as a function inside the binary.

MegaCortex v3 removed process and service termination functionality from the binary. The MegaCortex developers also added multiple anti-analysis and anti-decompilation techniques in v3 to hinder research work on this malware.

In MegaCortex v4, the developers went back and incorporated features to terminate security processes and stop relevant services as a function inside the binary, similar to the way these were implemented in v2. This version continues to use the same anti-analysis and anti-decompilation technique from v3.

Executing MegaCortex

MegaCortex v1 started surfacing in attacks in May 2019 when it was observed in targeted campaigns and pushed manually to networked computers and devices after post-network exploitation. How MegaCortex gains an initial foothold has not been confirmed, but we suspect that it is loaded by Emotet, QakBot or the Rietspoof loader. This method of distribution meant that threat actors had some sort of initial access on targeted networks, allowing them to deploy a series of batch files (.bat) to manage the spread and launch of the malware infection.

The first version of MegaCortex limited the spread, in a sense, by having two requirements that had to be met before execution:

• A Base64 encoded key passed as a command-line argument.
• It had to be executed on a specific date inside a specific three-hour time frame to generate the correct AES secret key for the encryption.

This two-factor control of sorts also made it more difficult for security researchers to successfully launch or reverse engineer the sample.

By August 2019, after the release of MegaCortex v2, it was evident that some of those limitations were removed, likely to help the attackers scale the attacks or get help from other parties. The timed execution limit was completely removed, and the Base64 key could be supplied manually as a command-line argument, but also embedded into the malware’s binary, making it capable of self-execution.

MegaCortex v3 appeared in October 2019. With that version release, we saw that its developers had completely removed any execution limitations. That version also no longer required the Base64 key and could be executed in an automated manner.

In November 2019, when MegaCortex v4 appeared, there was a rollback of sorts, bringing the Base64 key back into play and using it to decrypt the malware’s components. The implementation was not the same as previous versions, with that Base64 key embedded into the binary and then passed to a decrypting function instead of passing it as an argument to the command-line.

Doing Its Bidding: MegaCortex’s Modules

This malware’s modules are what allows it to encrypt files on infected devices and the modular part has also been changing through the different versions.

MegaCortex v1 utilizes two modules that are both encrypted and embedded into the loader binary. These are two embedded DLL files that we observed and reported as payload.dll and injecthelper.dll. The functionality of these modules relies on Windows utilities to limit the ability of infected users to recover via system restore options as follows.

Module payload.dll in MegaCortex v1

1. • Contains two DLL function exports: start and start2
   • Not dropped to the disk
   • Responsible for file encryption
   • Responsible for creating multiple worker threads for encryption
   • Tasked with creating the ransom notes
   • Loads the next module, injecthelper.dll, into a newly created process: rundll32.exe
   • Responsible for deleting volume shadow copies using vssadmin.exe (vssadmin.exe is a utility that’s part of the Windows operating system. It’s located on the hard drive and contains code that can display current volume shadow copy backups and all installed shadow copy writers and providers.)
   • Responsible for wiping deleted data from all drives using cipher.exe (cipher.exe is a built-in command-line tool in the Windows operating system that can be used to display or alter the encryption of directories and files on NTFS volumes.)

Using vssadmin to prevent access to shadow copies has been a ransomware staple across a variety of malware in the past few years.

Module injecthelper.dll in MegaCortex v1

• Contains one DLL function export: _command@16
• Dropped to the disk as %TEMP%\<random>.dll
• Responsible for loading and executing a copy of payload.dll in rundll32.exe‘s memory space.

Modules in MegaCortex v2

MegaCortex v2 only uses one module, which is encrypted and embedded into the binary. This module’s name is payload.dll and its functionality encompasses the work previously performed by two modules in v1:

• Contains two DLL function exports: start and ss2
• Not dropped to the disk
• Responsible for terminating processes and stopping/disabling services related to endpoint security
• Responsible for file encryption
• Responsible for creating multiple worker threads for encryption
• Responsible for creating the ransom notes
• No longer uses the process rundll32.exe as a loader, but instead uses the MegaCortex binary as the DLL loader
• Responsible for deleting volume shadow copies using vssadmin.exe and wiping deleted data from all drives using cipher.exe

Modules in MegaCortex v3

The third version of MegaCortex does not use any DLL-based modules to carry out its ransomware functions. Instead, all ransomware functions are incorporated into the binary and are executed directly as new threads. The binary file behaves differently depending on the command-line arguments passed during execution:

• If no command-line arguments are passed, it acts as a dropper
• If a “+” character is passed as an argument, it behaves as a loader
• If any data except an “x” is passed as an argument, it behaves as an encryptor

Modules in MegaCortex v4

After analyzing MegaCortex v4, we noticed the developers went back to using DLL-based modules. Specifically, a DLL named qibfmqke.dll came with three export functions — ss0(), ss1() and ss2() — and is tasked with the functionalities of the ransomware. Note that ss1() and ss2() call the exact same function and will behave identically. These three export functions are executed depending on the argument passed to the binary. Example scenarios:

• “MegaCortex.exe” executes ss0()
• “MegaCortex.exe +” executes ss1()/ss2()
• “MegaCortex.exe -” executes ss1()/ss2()

This one DLL in v4 is tasked with both older and new functions that came into play in this latest version:

• Responsible for changing passwords of all user accounts in the system
• Drops .cmd scripts, which are responsible for deleting volume shadow copies, logging off the user, wiping deleted data and adding registry entries for ransom contact information
• Responsible for the malware’s typical ransomware payload routines

MegaCortex’s File Encryption Process

In terms of file encryption, the first two versions of the malware behaved the same, then some minor modifications were implemented in versions 3 and 4.

To avoid being run in sandboxes and emulators, all MegaCortex versions implement file encryption threading based on querying for the number of CPUs in the system. All MegaCortex versions can detect if the binary is running with administrator privileges. If it isn’t, the attacker can proceed to escalating privileges.

All MegaCortex versions adjust token privileges and enable SeDebugPrivilege. Using this privilege with any user would allow the caller full access to the process, including the ability to call TerminateProcess(), CreateRemoteThread() and other potentially dangerous Win32 APIs on the target process. They can also disable file system redirection to avoid the possibility of being redirected to a missing 32-bit version of utilities it might need later, such as vssadmin.exe and cipher.exe, which are used in the process of eliminating shadow copies.

All versions generate a list of files to encrypt by parsing the available drives and directories, but will avoid adding files that are of relevance to the malware. In each version, the list of extensions and specifics is somewhat different. The following table presents them per version:

MegaCortex v3 and v4 both use a supplemental file-filtering function in which the new process passes the filename and file extension to a custom hashing function. Any hash matching with a pre-computed list of hashes will result in the file not being encrypted.

All versions create a ransom note in the Windows root directory (C:\) and in the %DESKTOP% directory. For versions 1 and 2, that file is named !!!_READ_ME_!!!.txt. For versions 3 and 4, that file is named !-!_README_!-!.rtf.

All MegaCortex versions create a shared named memory region where the generated list of files to encrypt is copied to, along with other related details for file encryption. All will rename files before encrypting them, adding the following file extensions to the original filename:

• • MegaCortex v1: .aes128ctr
  • MegaCortex v2: .megac0rtx
  • MegaCortex v3: .m3gac0rtx
  • MegaCortex v4: .m3g4c0rtx

All MegaCortex versions use a loader binary to load the payload.dll module for file encryption. The number of worker threads created depends on the number of CPUs detected earlier in the loading process:

• • MegaCortex v1: rundll32.exe (legitimate Microsoft Windows operating system file)
  • MegaCortex v2: RAND_NAME.exe (the MegaCortex v2 binary)
  • MegaCortex v3: env.exe (the MegaCortex v3 binary)
  • MegaCortex v4: went back to using rundll32.exe for encryption process threads

Lastly, the first three MegaCortex versions encrypt 10 files from the list per worker thread, while MegaCortex v4 encrypts 11 files per worker thread.

Other changes to the malware’s versions are expected to take place when the next version is released and, judging by the rapid release of four different versions, we won’t be waiting long before we see v5 in the wild.

Working for Profit — High Value, High Stakes Ransomware Attacks

Is MegaCortex considered ransomware or a destructive wiper? This malware has been used in both types of attacks, mostly targeting organizational networks across Europe and North America.

Adept at infiltrating and spreading through networks by targeting domain controller (DC) servers, MegaCortex has been part of the rising trend of “big game hunting” attacks that prey on organizations with ransomware. In these attacks, adversaries combine the anatomy of a targeted attack, use LotL tactics, and stealthily case networks in search of valuable data before unleashing a widespread ransomware infection that impacts the network widely enough to elicit the organization to pay millions of dollars in ransom.

In just one of its more publicized cases, MegaCortex attackers asked for millions of dollars in ransom from one of its victims. The attackers typically note in their ransom demand that the price for unlocking the data could go from 2 or 3 bitcoin to 600 bitcoin, a hike that they threaten would result from a victim being disinclined to pay. The end goal is extortion, and those behind MegaCortex will change up tactics to make sure they get paid, including, in version 4, by locking out Windows users by changing their passwords and threatening to leak stolen company data online.

Indicators of Compromise (IoCs)

MegaCortex IoCs are regularly added to X-Force Exchange. To get IoCs from this comparison, please browse to that collection.