The Cybereason Global Security Operations Center (GSOC) issues Cybereason Threat Analysis reports to inform on impacting threats. The Threat Analysis reports investigate these threats and provide practical recommendations for protecting against them.
In this Threat Analysis Report, the Cybereason GSOC Team investigates infections with a recent version of the Magniber ransomware in which the initial attack vector against the compromised systems is the exploitation of the notorious PrintNightmare vulnerability described in CVE-2021-34527.
Critical Vulnerabilities: CVE-2021-34527 and CVE-2021-34481 are critical, remotely exploitable vulnerabilities in the Windows Print Spooler service that allow attackers to execute arbitrary code with administrative privileges on target systems. The vulnerabilities exist in the Point and Print capability on Windows systems and allow non-privileged users to install or update remote printers. CVE-2021-34527 and CVE-2021-34481 are collectively referred to as PrintNightmare.
Significant Ransomware Threat to Corporate Networks: Shortly after the public disclosure of PrintNightmare CVE-2021-34527, malicious actors started exploiting this vulnerability. Ransomware groups find PrintNightmare particularly attractive:
The Magniber Ransomware and PrintNightmare: Malicious actors deploy the Magniber ransomware on compromised systems by exploiting PrintNightmare CVE-2021-34527. The Magniber ransomware is continuously under active development, with frequent significant code changes and improvements to obfuscation features, evasion tactics, and encryption mechanisms.
Detected and Prevented: The Cybereason Defense Platform detects and prevents the Magniber ransomware.
Cybereason Managed Detection and Response (MDR): The Cybereason GSOC has zero tolerance towards attacks that involve ransomware groups, such as Magniber, and categorizes such attacks as critical, high-severity incidents. The Cybereason GSOC MDR team issues a comprehensive report to customers when such an incident occurs. The report provides an in-depth overview of the incident, which helps to scope the extent of compromise and the impact on the customer’s environment. In addition, the report provides attribution information when possible as well as recommendations for mitigating and isolating the threat.
PrintNightmare CVE-2021-34527 is a critical vulnerability in the Windows Print Spooler service that allows attackers to execute arbitrary code with administrative privileges on target systems. An adversary who successfully exploits CVE-2021-34527 could achieve full control over a target system by executing, for example, a dynamic link library (DLL) or a Windows executable with administrative privileges.
The CVE-2021-34527 vulnerability exists in the Point and Print capability of Windows systems, which allows non-privileged users to install or update remote printers, without disks or other installation media, by establishing a connection to a remote printer.
Following the public disclosure of the CVE-2021-34527 vulnerability on July 1, 2021, Microsoft released an Out-of-Band Security Update addressing the vulnerability on July 6, 2021. Then, on July 15, 2021, Microsoft publicly disclosed another critical vulnerability in the Print Spooler service: CVE-2021-34481. As with CVE-2021-34527, this vulnerability exists in the Point and Print capability and allows non-privileged users to execute arbitrary code with administrative privileges.
Due to their similarities, CVE-2021-34527 and CVE-2021-34481 are now collectively referred to as PrintNightmare. To address the PrintNightmare vulnerabilities, Microsoft released an update on August 10, 2021 that modifies the behavior of Point and Print such that non-privileged users cannot install or update printers.
Shortly after the public disclosure of PrintNightmare CVE-2021-34527, malicious actors started exploiting the vulnerability. Ransomware groups find PrintNightmare particularly attractive because this vulnerability enables the execution of arbitrary code with administrative privileges.
In addition, the PrintNightmare vulnerabilities exist in the Windows Point and Print capability, which is actively used in large corporate networks, which are frequent targets of ransomware groups and where the use of remote printers by non-privileged users is common.
For example, the ransomware groups Vice Society and Magniber actively exploited CVE-2021-34527 to deploy ransomware shortly after the public disclosure of the vulnerability. Ransomware groups often exploit newly disclosed vulnerabilities to deploy ransomware before vendors publicly release patches.
Threat researchers first observed the Magniber ransomware on compromised systems in 2017. At that time, malicious actors delivered Magniber primarily via the Magnitude exploit kit, which had often been used for delivering the Cerber, Locky, and Cryptowall ransomware.
Early versions of the Magniber ransomware targeted only Korean systems, since the ransomware only executed on operating systems where the system language was set to Korean. However, the Magniber ransomware is continuously under active development, with frequent significant code changes and improvements to obfuscation features, evasion tactics, and encryption mechanisms.
More recent implementations of the Magniber ransomware do not restrict the ransomware to Korean systems or to any specific geographical region. The Magniber ransomware may be executed on any system, irrespective of the system’s geographical location.
PrintNightmare CVE-2021-34527 is present in the Windows Print Spooler service, which executes as the spoolsv.exe process in Windows systems. An adversary who successfully exploits CVE-2021-34527 could achieve full control over a target system by executing arbitrary code, such as a dynamic link library (DLL) or a Windows executable, with administrative privileges.
The adversary must be authenticated to the Print Spooler service to take advantage of CVE-2021-34527. The RpcAddPrinterDriverEx function, implemented in the Print Spooler service, allows authenticated users to deploy arbitrary DLLs or Windows executables on systems where the Print Spooler service runs and execute these files with administrative (SYSTEM) privileges. According to the CERT Coordination Center at Carnegie Mellon University:
The RpcAddPrinterDriverEx() function is used to install a printer driver on a system. One of the parameters to this function is the DRIVER_CONTAINER object, which contains information about which driver is to be used by the added printer. The other argument, dwFileCopyFlags, specifies how replacement printer driver files are to be copied. An attacker can take advantage of the fact that any authenticated user can call RpcAddPrinterDriverEx() and specify a driver file that lives on a remote server. This results in the Print Spooler service spoolsv.exe executing code in an arbitrary DLL file with SYSTEM privileges.
When an adversary exploits CVE-2021-34527, the Print Spooler service writes any attacker-provided DLL in the %SYSTEM%\System32\spool\drivers\ directory (for example, in C:\Windows\System32\spool\drivers\x64\3\New). The vulnerable Print Spooler service (spoolsv.exe) then loads and executes the attacker-provided DLL with administrative privileges.
The actors behind the Magniber ransomware distribute the ransomware in the form of a Windows DLL file. They take advantage of CVE-2021-34527 to deploy and execute this DLL file on compromised systems. By exploiting CVE-2021-34527, adversaries write the DLL file of the Magniber ransomware in the %SYSTEM%\System32\spool\drivers\ directory (for example, in C:\Windows\System32\spool\drivers\x64\3\New) and execute it in the context of the Print Spooler service:
The Print Spooler service writes the attacker-provided calc.dll file (the DLL that implements the Magniber ransomware) when malicious actors exploit CVE-2021-34527
The following chart provides an overview of the operation of the Magniber ransomware, implemented as a 64-bit DLL, referred to as Magniber DLL:
Overview of the operation of the Magniber ransomware
When executed in the context of spoolsv.exe, the Magniber ransomware first unpacks code stored in its data section. The ransomware then enumerates all running processes on the compromised system to identify processes in which the ransomware can inject the unpacked code. Magniber injects the unpacked code into each process that fulfills the following criteria:
Magniber also executes the unpacked code in the context of spoolsv.exe itself as a backup mechanism that guarantees the execution of the code if the ransomware cannot inject the code into a process.
To inject the unpacked code into a process, the Magniber ransomware invokes the following sequence of Windows system calls:
The Magniber ransomware does not execute Windows system calls by invoking functions implemented in the DLL file ntdll.dll for that purpose, such as NtCreateSection or NtMapViewOfSection. Instead, the ransomware invokes assembly code that first switches the execution context to the kernel and then executes the system call routines implemented as part of the kernel, a technique known as direct system call execution. This technique is used to avoid detection by security mechanisms that monitor Windows system call execution via hooks in ntdll.dll.
To directly execute a system call, the Magniber ransomware allocates a memory region in its virtual address space and stores in this region the assembly language opcodes that conduct the direct execution of the system call in Windows systems. The ransomware then executes the content of the memory region, therefore directly executing the system call.
On 64-bit Windows systems, direct system call execution involves storing the system call identification number (system call ID, a number that uniquely identifies the system call) in the eax register and then invoking the syscall instruction. The system call ID of a specific system call may differ for different releases and builds of Windows systems.
To use the correct system call ID when directly executing a given system call, the Magniber ransomware differentiates between Windows releases (for example, Windows 10 or pre-Windows 10 systems, such as Windows 7), down to specific build numbers (for example, Windows 10 build 18363 or build 17763):
The Magniber ransomware conducts direct system call execution (direct execution of the NtCreateSection system call)
Once injected and executed in the context of a remote thread, the code first unpacks itself and then executes a code segment. This code segment, referred to as the Magniber ransomware for simplicity, first creates and locks a mutex object named, for example, zarkzonn or dihlxbl, to ensure that only one instance of the Magniber ransomware runs at a time.
This technique also prevents redundant executions of the same code injected into other processes. The name of the mutex object is different for different versions of the Magniber ransomware.
The Magniber ransomware then builds a string based on the computer name of the compromised system and the serial number of a volume present on the system. The ransomware then appends the name of the mutex object to this string. The resulting string is specific to the compromised system and is called the compromised system identifier.
Magniber then enumerates drives with removable and fixed media that are attached to the compromised system, as well as remote drives. These are drives for which the Windows Application Programming Interface (API) function GetDriveTypeW returns 0x2 (DRIVE_REMOVABLE), 0x3 (DRIVE_FIXED), or 0x4 (DRIVE_REMOTE), such as hard disks or network shares. For each such drive, the Magniber ransomware conducts file enumeration and encryption in two phases.
In the first phase, Magniber encrypts files that the ransomware considers higher encryption priority. These files have one of 714 file name extensions, and include .doc and .xls. In the second phase, Magniber encrypts files that are of lower encryption priority. These files have one of 33 file name extensions, and include .zip and .swf. As an anti-analysis technique, the Magniber ransomware stores an obfuscated form of the file name extensions of files of higher and lower encryption priority in its context.
File name extensions in obfuscated form
In both phases, the Magniber ransomware encrypts only files that are allowlisted for encryption. Magniber does not encrypt the following files:
File or Directory Attribute |
Description |
FILE_ATTRIBUTE_SYSTEM |
A file or directory that the Windows operating system uses. |
FILE_ATTRIBUTE_HIDDEN |
A hidden file or directory. |
FILE_ATTRIBUTE_ENCRYPTED |
A file that the Encrypted Filesystem (EFS) encrypts, or a directory in which the EFS encrypts every new file. |
FILE_ATTRIBUTE_READONLY |
A read-only file. |
FILE_ATTRIBUTE_TEMPORARY |
A file used for temporary storage. |
FILE_ATTRIBUTE_VIRTUAL |
A file reserved for system use. |
Attributes of files and directories that Magniber does not encrypt
The Magniber ransomware encrypts files by applying a hybrid encryption approach that combines the use of the Advanced Encryption Standard (AES) and the Rivest, Shamir, Adleman (RSA) encryption algorithms. This approach maximizes both encryption performance and security. The Magniber ransomware first encrypts a file by using the symmetric encryption algorithm AES.
AES is by design more performant but less secure than the RSA encryption algorithm. AES relies on a symmetric encryption key and an initialization vector (IV) for encryption security. To compensate for this disadvantage of AES, the ransomware then encrypts the AES symmetric key and IV by using the RSA encryption algorithm. The Magniber ransomware uses the Microsoft CryptoAPI for encryption.
For each file being encrypted, Magniber first generates two random arrays of 16 bytes. The first byte array is an AES symmetric encryption key and the second is an IV. The Magniber ransomware then encrypts equal-sized data blocks of the file being encrypted using the AES key and IV, such that each data block is 1048576 bytes in size.
After encrypting a data block, the Magniber ransomware writes the encrypted form of the data block in the file, replacing the original data block. This encryption procedure ends in Magniber encrypting the last data block of the file, which may be less than 1048576 bytes in size, by setting the parameter final of the CryptEncrypt CryptoAPI function to 1:
Unencrypted and encrypted form of a data block, encrypted using an AES key and IV
After encrypting all file data blocks, Magniber concatenates the AES key and IV and encrypts the resulting data by using a 2048-bit RSA public key. The file that implements the Magniber ransomware also stores the public key. The ransomware then appends the encrypted form of the concatenated AES key and IV to the end of the file.
Magniber then changes the file name extension of the file being encrypted by appending a file name extension that is the same as the name of the mutex object that the ransomware creates, such as zarkzonn or dihlxbl. The ransomware then proceeds to encrypt the next file designated for encryption.
After it encrypts all files stored in a folder, the Magniber ransomware places a readme.txt file that contains a ransom note in the folder. The ransom note contains Uniform Resource Locators (URLs) unique to the compromised system such that the URL subdomain is the compromised system identifier that the ransomware generates.
According to available open-source intelligence (OSINT), the URLs point to a payment website that instructs users to purchase software called My Decryptor to restore the files that the ransomware has encrypted. The URLs in the ransom note that Magniber left on the systems that the Cybereason GSOC analyzed were unreachable:
The Magniber ransomware ransom note
After finishing the two phases of file enumeration and encryption, if the Magniber ransomware has encrypted more than 1000000 bytes in total, Magniber places the readme.txt file in the %PUBLIC% folder (for example, C:\Users\Public) and displays the file with the Notepad application (notepad.exe). Magniber also opens the default browser on the compromised system to display a payment website.
By doing this, Magniber also exfiltrates information about its operation on the compromised system by storing the following values in URL query parameters:
The Magniber ransomware exfiltrates information about its operation via URL query parameters
The Magniber ransomware then releases and closes the named mutex object it has previously locked, and executes the command vssadmin.exe Delete Shadows /all /quiet to delete shadow copies so that encrypted files cannot be recovered. Magniber executes this command with elevated privileges by bypassing Windows User Account Control (UAC), as follows:
One way in which Magniber deletes shadow copies is by writing the command C:\Windows\System32\wbem\wmic process call create "vssadmin.exe Delete Shadow /all /quiet" in the (Default) registry value under the registry key HKCU\Software\Classes\ms-settings\shell\open\command or HKCU\Software\Classes\mscfile\shell\open\command.
Another way in which Magniber deletes shadow copies on Windows 10 systems is by writing the JScript script depicted below in the %PUBLIC%\readme.txt file, followed by writing the command regsvr32.exe scrobj.dll /s /u /n /i:%PUBLIC%\readme.txt in the (Default) registry value under the registry key HKCU\Software\Classes\ms-settings\shell\open\command. After regsvr32.exe is finished executing, the Magniber ransomware deletes the %PUBLIC%\readme.txt file.
Both approaches result in the execution of vssadmin.exe as a child process of the Windows Management Instrumentation (WMI) Provider Host process (wmiprvse.exe) with elevated privileges:
A Jscript script that executes vssadmin.exe
The Cybereason platform detects the Magniber ransomware deleting shadow copies. After deleting shadow copies, the Magniber ransomware terminates its operation:
The Magniber ransomware deletes shadow copies
The Cybereason GSOC recommends the following:
$Path = "C:\Windows\System32\spool\drivers $Acl = Get-Acl $Path $Ar = New-Object System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny") $Acl.AddAccessRule($Ar) |
The Cybereason GSOC recommends the following:
The following YARA rule is useful for detecting the presence of the Magniber ransomware in the context of running processes or in the filesystem:
rule Magniber_ransomware { meta: description = "YARA rule for identifying the Magniber ransomware." author = "Aleksandar Milenkoski" date = "2021-08" strings: $code1 = { C7 45 F0 4C 8B D1 B8 C7 45 F4 00 00 00 00 66 C7 45 F8 0F 05 C6 45 FA C3 } $code2 = { 81 F9 39 38 00 00 ?? ?? ?? ?? ?? ?? 81 F9 D7 3A 00 00 ?? ?? ?? ?? ?? ?? 81 F9 AB 3F 00 00 ?? ?? ?? ?? ?? ?? 81 F9 EE 42 00 00 ?? ?? ?? ?? ?? ?? 81 F9 63 45 00 00 ?? ?? ?? ?? ?? ?? 81 F9 BA 47 00 00 } $code3 = { 83 3C 25 6C 02 FE 7F 0A } condition: uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $code3 and 2 of ($code1,$code2) } |
YARA rule for identifying the Magniber ransomware
Magniber creates and locks a mutex object named, for example, zarkzonn or dihlxbl, such that the name of the mutex is different for different versions of the Magniber ransomware. If this mutex object already exists and is therefore locked, the ransomware terminates without encrypting any data.
This is to the advantage of defenders, as a mutex object named, for example, zarkzonn or dihlxbl, can be locked by a legitimate process on a given system with the intention to stop any potential future execution of the Magniber ransomware on the system.
The PowerShell script below demonstrates this defense technique. The script creates, opens, and locks a mutex object named dihlxbl, and releases the object when the user issues the Ctrl+C command. Users can execute the script by issuing the command powershell.exe ./magniber_mutex_lock.ps1 in the directory where the script file is stored, where magniber_mutex_lock.ps1 is the filename of the script file:
function create_mutex { $created = $False $mutex = New-Object -TypeName System.Threading.Mutex($true, "dihlxbl", [ref]$created) Write-Host "Mutex object named dihlxbl created, opened, and locked: $created." return $mutex } function release_mutex { param ( $mutex ) $mutex.ReleaseMutex() $mutex.Dispose() } $mutex = create_mutex try { while($true) { Start-Sleep -Seconds 1 } } finally{ release_mutex($mutex) Write-Host "Mutex object released." } |
PowerShell script that locks a mutex object named dihlxbl
In addition to specific recommendations for PrintNightmare and the Magniber ransomware, Cybereason offers the following general security recommendations:
Cybereason is dedicated to teaming with defenders to end cyber attacks from endpoints to the enterprise to everywhere—including modern ransomware. Learn more about ransomware defense here or schedule a demo today to learn how your organization can benefit from an operation-centric approach to security.
Executables |
SHA-256 hash: 10B9B1D8F6BAFD9BB57CCFB1DA4A658F10207D566781FA5FB3C4394D283E860E File size: 21504 bytes |
Associated files |
readme.txt |
Mutex objects |
dihlxbl |
File name extensions |
dihlxbl |
Domains |
l5nmxg2syswnc6s3724evnip5uktj7msy3pgowkbcidbei3nbysi7ead.onion uponmix.xyz flysex.space partscs.site codehes.uno |
Registry keys |
HKCU\Software\Classes\ms-settings\shell\open\command\(Default) HKCU\Software\Classes\mscfile\shell\open\command\(Default) HKCU\Software\Classes\ms-settings\shell\open\command\DelegateExecute |
Execution |
Privilege Escalation |
Defense Evasion |
Discovery |
Impact |
Abuse Elevation Control Mechanism: Bypass User Account Control |
||||
Aleksandar Milenkoski, Senior Threat and Malware Analyst, Cybereason Global SOC
Eli Salem, Senior Security Analyst, Cybereason Global SOC