Analyzing Elysium, a Variant of the Ghost (Cring) Ransomware Family

Summary

In February 2025, the Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) published a cybersecurity advisory to share information about the Ghost (Cring) ransomware and its techniques.

The group behind this ransomware started its activities around 2021 by attacking public-facing applications running outdated versions. Among the affected industries are healthcare, critical infrastructure, and government.

Once inside the network, the attackers use several different tools and techniques to complete the attack. Some examples are Cobalt Strike framework to control the system, BadPotato and GodPotato to elevate privilege, Mimikatz to dump credentials, SharpShares for network discovery, and WMI for lateral movement (a complete list with all the tools used can be found in the official advisory). Once the attacker has proper access to the infrastructure, the final ransomware payload is deployed.

The group behind the ransomware is referred to by multiple names, including Ghost, Cring, and Crypt3r. The ransomware payloads also vary depending on the victim. In this blog post, we present a detailed analysis of one of the ransomware payloads, named Elysium (d1c5e7b8e937625891707f8b4b594314), demonstrating how it works and how it encrypts the affected systems.

Key takeaways

• The Ghost/Cring/Crypt3r group has been around since 2021 and gains initial access by exploiting known vulnerabilities in outdated applications.
• The top targets include critical infrastructure, healthcare, and government organizations.
• The group uses many well-known tools along the killchain, including Cobalt Strike and Mimikatz.

Details

The malware is written in .NET and employs a few obfuscation techniques, such as string obfuscation, to make analysis harder. To make our analysis easier, we renamed many method names and deobfuscated the strings using the famous de4dot tool. The specific command we used to deobfuscate the strings was the following:

de4dot <file> –strtyp emulate –strtok <method_token>

Using this command, we emulate all of the calls to the specified method, and the calls themselves are replaced by their call results, simplifying our analysis.

Upon execution, the malware checks if an argument was passed via the command line. If that’s not the case, it simply exits and does not encrypt anything. If an argument is found, it checks if it is the string “all”. This check determines if the malware will encrypt the whole system or only a specific file/directory.

To evade analysis, the malware performs two simple checks to ensure it’s not running under a debugger. One uses the CheckRemoteDebuggerPresent API function, and the other uses the Debugger.IsAttached property.

If the argument passed via the command line is a file or directory, the malware encrypts it directly without extra actions. Now, if it’s the string “all”, it performs some additional steps before starting the encryption.

The first action is to stop a list of services hardcoded in the binary. The following are the services the malware looks for.

"sql"
"oracle"
"veeam"
"backup"
"acronis"
"sophos"
"endpoint"
"exchange"

Another step it takes is to attempt to stop Hyper-V VMs via PowerShell if it finds any.

It then disables system backups, deletes shadow copies, and modifies the boot status policy to make system recovery harder. It does so by running the following commands via PowerShell.

At this point, the ransomware starts to prepare to encrypt the files. It enumerates the machine drives and queues their content for encryption. For each Desktop folder found, it writes a ransom note named “HvTovz-README.txt” to it. The ransom note name is formatted by concatenating the ransomware extension (“HvTovz”) with the string “-README.txt”.

The ransom note content is base64 encoded and decoded right before the file is written.

The content of the ransom note varies depending on the victim. In the analyzed payload, the content presented was the following:

To avoid encrypting files important for the system, the payload prevents the following directories and file extensions from being encrypted.

File extensions:

".exe",
".dll",
".lib",
".ini",
".sys",
".ax",
".acm",
".bin",
".log",
".mui",
".msi",
".pyc",
".tlb",
".rll",
".tmp"

Directories:

"Windows"
"WindowsApps"
"WinSxS"
"Recycle.Bin"
"Logs"
"Boot"
"ProgramData"
"Program Files"
"Temp"
"AppData"
"Cache"
"System Volume Information"

Once the files are queued, the malware starts its encryption tasks. The ransomware creates a new random AES-256 key and initialization vector (IV) for each file and encrypts the file in CFB block cipher mode of operation. The key is then encrypted using RSA and appended to the end of the encrypted file.

The final step after the file encryption is to rename the encrypted file by adding the extension “.HvTovz”

Conclusion

The Ghost (Cring) Ransomware group has been active for quite a while and is still active, targeting industries such as critical infrastructure, healthcare, government, and more. Its arsenal is vast to achieve different parts of the infection chain and its final payloads will change depending on the victim. Netskope Threat Labs will continue to track how this ransomware evolves and its TTP.

Netskope Detection

Netskope Advanced Threat Protection provides proactive coverage against the reported threat.

• Netskope Threat Protection
  • ByteCode-MSIL.Trojan.Zilla