Security researchers have published an in‑depth technical analysis of the DragonForce ransomware operation, along with details of working decryptors for both Windows and ESXi systems targeting specific victims.
By the time its dedicated Data Leak Site (DLS) was identified later that month, 17 victim organizations had already been listed.
DragonForce markets itself as a cartel and operates a service branded “Ransombay, which lets affiliates request customized payloads and configuration options.
Under its RaaS model, formalized via a June 2024 recruitment post on the RAMP forum, DragonForce actively recruits initial access brokers, solo pentesters, and organized teams, offering affiliates up to 80% of ransom proceeds, underlining its aggressive growth ambitions.
Technically and operationally, DragonForce does not exist in isolation. The ransomware is heavily based on leaked LockBit 3.0 (Black) and Conti code, with one analyzed sample assessed as a Conti‑lineage DragonForce variant.
Binary similarity analysis has shown over 90% functional overlap with LockBit 3.0, strongly suggesting use of the leaked LockBit Black builder, while maintaining Conti‑style logic and configuration behavior.
Infrastructure and code overlaps have tied DragonForce to several other prominent groups, including BlackLock and RansomHub, with evidence of infrastructure migration, shared or duplicated code, and nearly identical ransom notes.
In one notable case, DragonForce operators compromised BlackLock’s DLS through a misconfiguration and LFI vulnerability, hijacking its infrastructure and exposing internal data.
First observed on December 13, 2023, when a BreachForums user “@dragonforce” advertised stolen data under the title “aglgases.com gigabytes of data!”, the group quickly emerged as a serious player in the Ransomware‑as‑a‑Service (RaaS) ecosystem.
Forum posts have also claimed that RansomHub infrastructure was transferred or taken over by DragonForce, with “DragonNews” branding appearing on a new DLS.
Separately, VX‑Underground reported that DragonForce attempted to form a coordination alliance with LockBit and Qilin, proposing shared communication channels and a mutual non‑aggression stance to avoid public infighting and strengthen collective influence.
Technical Breakdown
Under the hood, DragonForce ransomware uses custom string obfuscation, decrypting strings at runtime via a bespoke algorithm. It supports five command‑line arguments, with the -m flag controlling encryption mode (local, network, or mixed).
File encryption relies on the ChaCha8 stream cipher, with each file receiving a randomly generated session key per file. Before encryption completes, the ransomware appends 534 bytes of metadata to the end of each encrypted file. This metadata blob contains:
- An RSA‑4096–encrypted structure with the ChaCha8 key and nonce.
- A 1‑byte encryption type constant (full, header‑only, or partial).
- A 1‑byte encryption ratio.
- An 8‑byte field storing the original file size.
DragonForce applies full, header, or partial encryption depending on file type and size, fully encrypting database‑like formats and partially encrypting virtual machine and disk image files to balance impact and performance. .
Network encryption mode enumerates private‑range IP addresses, connects via SMB, and targets only specific share types while skipping ADMIN$.
If configured, the malware also renames files and alters the user interface. With the encrypt_file_name flag enabled, DragonForce Base32‑encodes the original filename using a custom alphabet, then appends its extension.
For at least one lineage, the extension .dragonforce_encrypted is used. Additional options allow the ransomware to change the icon of encrypted files using a bundled ICO image and replace the desktop wallpaper with a custom ransom‑themed background.
Decryptor for Windows and ESXi Targets
In a significant development, the S2W Threat Research and Intelligence Center (TALON) obtained a DragonForce decryptor during threat‑hunting operations against the group.
The toolkit is tailored to specific victims and consists of one Windows decryptor and three ESXi decryptors, each bound to particular configuration and key material.
On Windows, the decryptor locates encrypted data by scanning for files with the .RNP extension.
For each file, it reads the metadata at the end of the file, uses the embedded RSA‑4096 private key to decrypt the ChaCha8 session key and nonce, and then restores the original content with the same ChaCha8 routine used by the ransomware.
The Windows tool also supports network share decryption, mirroring the ransomware’s ARP and SMB‑based discovery of private‑range hosts and shares.
For ESXi, encrypted files are identified by a dedicated extension (such as .RNP_esxi) and a magic value derived from a per‑victim “build_key”.
Because the metadata of DragonForce‑encrypted files embeds the ChaCha8 session key under the attacker’s RSA public key, access to the corresponding RSA private key inside the S2W decryptor enables complete recovery of affected data for those specific victims.
Before attempting decryption, the ESXi decryptor checks the final 8 bytes of a candidate file; only if they match the embedded build_key does it proceed.
Once validated, it parses the RSA‑encrypted metadata, extracts the ChaCha8 session key and nonce, decrypts the content, removes the metadata trailer, and restores the file to its original name.
While the toolset is not a universal cure for all DragonForce incidents, its existence provides a rare opportunity for recovery and additional insight into the group’s Conti‑derived encryption design.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.