Qilin ransomware’s newest tactics: Widespread encryption by any means necessary

Intro

The Russia-based ransomware group Qilin has rapidly ascended to become the world’s most prominent ransomware threat, claiming responsibility for over 800 attacks this year alone — a dramatic surge from just 45 incidents when the group first emerged in 2022. Qilin operates a ransomware-as-a-service (RaaS) model, offering its platform to other cybercriminals and expanding its reach across the digital threat landscape. The ThreatLocker Threat Intelligence team routinely intercepts and mitigates Qilin-related attacks. This report is a continuation of the team’s efforts to alert the cybersecurity community to the technical details of these evolving tactics.

Qilin utilizes a variety of methods to establish malicious connections and persist on an unsuspecting network. Historically, their dwell time has an average of 19 days but may be extended for further enumeration and discovery on a target. Established communication to a Command and Control server provides the means necessary to spread and execute their ransomware binary throughout a network.

Qilin ransomware binary

Dynamic analysis

Threat Intelligence analyzed a Rust variant of the Qilin encryptor binary recovered from a compromised environment. The encryptor filename includes a unique identifier associated with the victim organization, and as such will be referred to as “encryptor.exe”.

Successful execution of encryptor.exe requires the operator(s) to provide a predetermined password and execute under the context of a privileged user. If the operator fails to provide a password value, or the correct password, the encryptor will break on a fatal error and must be executed once more.

After disassembling the binary and locating the password validation routine, the logic can be circumvented by inverting the conditional check with a two-instruction patch. Applying the patched instructions to the encryptor binary allows any password to be provided.

On execution, embedded configuration and command line data is displayed on the attached console window. Encryptor.exe leverages several blacklists to target significant and sensitive files for encryption based on name, extension, and parent directory, also specifying running processes and Windows services to terminate.  

Any directories absent from the directory blacklist are targeted for encryption, including content in user profiles such as documents, attached drives, and accessible shares. A mutex is also created to prevent additional instances of the encryptor from executing simultaneously.

Within seconds, files are encrypted, renamed to append the unique victim ID, and the ransom note is written to each respective folder.

Static analysis

During the initialization process in the main function, the encryptor first verifies if the process is running under the context of a privileged user and will throw an error before exiting unless the “--no-admin” flag is set.  

The presence of a hypervisor is checked through execution of the “CPUID” instruction and checking the 31^st bit of the result register. If this bit is set to one, a hypervisor has been detected, indicating the host is a virtual machine. If the value is zero, the host is detected as a physical machine. This approach to detecting virtualization has historically been seen in malware and is easily thwarted by modern malware sandboxes.

An additional “CPUID” check with the extended information parameter (“0x80000000”) is executed, and the 25^th bit of the result register is read to determine if the processor supports the “AES-NI” (“Advanced Encryption Standard New Instructions”) instruction set. If the processor does not support hardware accelerated AES, ChaCha20 is used instead.

To identify neighboring active directory joined devices, PowerShell is leveraged to load the “ActiveDirectory” module, and the cmdlets “Get-ADComputer” and “Test-Connection” are used to discover active hosts.

An embedded copy of PsExec was discovered within the encryptor binary that matches the official signed Sysinternals binary. This binary data is written to disk on the victim host machine and used to spread the encryptor binary to all accessible active directory joined hosts using a list of provided credentials.

If PsExec is unable to successfully spread the binary, Windows networking APIs are used as a fallback. Accessible networked drives are enumerated using “WNetOpenEnum” and “WNetEnumResourceA”.

To target hypervisor hosts, such as VMware ESXi, the encryptor binary contains an embedded PowerShell script that is used to interact with VMware vCenter appliances. If the provided vCenter credentials are valid, all datacenters, clusters, and hosts managed by the appliance are queried, and the high-availability and distributed resource scheduler services are stopped and disabled. For each accessible host, an attempt is made to reset the password for the “root” account. On successful login using “root”, the SSH service is enabled, and if present, an additional payload is uploaded using SCP.

Prior to the file encryption process, remote and NFS symbolic links are enabled, allowing for navigation throughout a network that may not be immediately detected. The “EnableLinkedConnections” registry key is also created, providing non-privileged users access to restricted mapped drives. New worker threads are created to continuously remove shadow copies and terminate processes and services associated with endpoint security or backup software.

The encryptor also features an optional configuration flag to forcibly reboot the victim host into safe mode. After resetting the user password and creating startup registry entries, “BCDEdit.exe” is used to set the boot option to safe mode with networking, and the reboot command is sent. This is likely done to prevent endpoint security or backup software from interfering during the encryption process.

At this point, all initial tasks have been completed, and the encryption process initiates. Regardless of whether the safe mode flag is enabled, worker threads to execute encryption jobs are created. Early in the encryption process, target drives are queried to determine if full disk encryption (FDE) is present or if direct access storage device (DASD) capabilities are present. If either of these checks return true, the encryptor exits.

File encryption is performed using AES if the victim host CPU supports AESNI functionality, or ChaCha20, which is determined during the initial hypervisor discovery process.

Once file encryption jobs are complete, post encryption tasks are queued. First, the desktop wallpaper on victim hosts is replaced with the Qilin signature “YOUR SYSTEM HAS BEEN BLOCKED” image using the “SystemParametersInfoW” API with the “SPI_SETDESKWALLPAPER” parameter.

Following the wallpaper change function, networked printers are enumerated through the PowerShell cmdlet “Get-Printer”, and available printers are queued for a print job which delivers the ransom note.

The encryptor then attempts to clear windows event logs and self-delete from disk, executing “cmd.exe /C timeout /T 10 & del <process path>”.

The final result on a host after the encryptor completes consists of a replaced wallpaper, wiped event logs, automatic logon enabled for the compromised user, a fully encrypted filesystem, and ransom notes placed for victim follow up.  

Any host found in this state has likely taken part in network wide encryption of other machines, drives, and resources.  

Ransom note

README-RECOVER-[Unique ID].txt

‍

Directories and file extensions

• C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs 
• \..\.[Unique ID].[random file extension] 

Commands

• Import-Module ActiveDirectory ;
  Get-ADComputer -Filter * |
  Where-Object { Test-Connection -ComputerName $_.DNSHostName -Count 1 -Quiet } |
  ForEach-Object { $_. DNSHostName }

• Get-ItemProperty `
  'HKLM:\\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\' `
  -Name PortNumber |
  Select-Object -ExpandProperty PortNumber > \Windows\Temp\VPlBQcq 2>%1 

• $logs = Get-WinEvent -ListLog * |
  Where-Object {$_.RecordCount} |
  Select-Object -ExpandProperty LogName;
  ForEach ( $l in  $logs | Sort | Get-Unique ) {
  [System.Diagnostics.Eventing.Reader.EventLogSession]::GlobalSession.ClearLog($l)
  }

• Set-SCPItem -ComputerName $esxiHost.IP -Credential $credential `
  -Path "$localFolderPath\$localFileName" -Destination $remoteFolderPath `
  -NewName $localFileName -Force -AcceptKey -ErrorAction Stop

• C:\users\[USER]\appdata\local\temp\vvvivyyl.exe `
  [-accepteula \\10[.]x[.]x[.]x -c -f -h -d -i "C:\programdata\<Unique ID>_crypt.exe" `
  --password <Unique Password> --no-logs --spread --spread-process]   

• CMD.exe /C timeout /T 10 & Del \"<current process path>\"

Conclusion

The preceding analysis in this report explores the most recent techniques employed by Qilin, the leading ransomware-as-a-service (RaaS) group today. The report demonstrates the encryptor and TTPs utilized by Qilin in-the-wild. Qilin heavily employs initial access methods such as publicly disclosed CVEs, business email compromise (BEC), and purchased/stolen credentials. The use of embedded PsExec in addition to relevant dependencies allows for swift propagation of the binary across an organization’s network.  

Solutions should include deploying defense-in-depth strategies accompanied with principles of least privilege and zero-trust technical controls to configure and secure organizational networks. All new tools introduced into an environment should be scrutinized and barred from executing without proper vetting. Unvetted software introduces additional attack vectors creating areas of opportunity for threat actors.

Read Part 1: Here you'll find a recap of the initial access techniques leveraged prior to the deployment of ransomware.