The ransomware threat landscape has long been dominated by disciplined syndicates like LockBit, ALPHV, and Ragnar Locker, groups that rely on industrial-scale extortion and polished malware tooling. But in 2024 and 2025, a different kind of name started making waves: DragonForce.
What makes DragonForce stand out isn’t just its malware, but its story. Once recognized as a hacktivist, DragonForce has since rebranded itself as a profit-driven ransomware gang. The transition from protest hacking to professionalized cybercrime mirrors a wider trend in the threat ecosystem ideology giving way to money.
Technically, DragonForce ransomware demonstrates clear signs of maturity. The malware performs environment and privilege checks, uses sandbox-evasion tricks, and validates elevation before execution. In the samples we analyzed, DragonForce implements a ChaCha-based scheme to encrypt files, appending a structured 534-byte footer with keys, nonces, and identifiers. The footer is encrypted with the RSA Public key of the group before appending to the file.
Unlike intermittent encryption families such as Medusa, DragonForce’s observed samples often encrypt files in full, with only trailing sections skipped for speed. Combined with its operational logging (for example, C:\Users\Public\log.log) and ransom notes (readme.txt) dropped across directories, the malware leaves victims with few easy paths to recovery.
Perhaps most concerning, DragonForce campaigns exhibit clear signs of double extortion. The ransomware incorporates networking libraries and data-handling routines that enable exfiltration, and its associated leak sites confirm that stolen data is weaponized to pressure victims.
Once dismissed as “hacktivists with slogans,” DragonForce has now become a serious player in the ransomware economy and defenders can no longer afford to underestimate them.
DragonForce ransomware does not rush headlong into encryption. Instead, it carefully prepares the battlefield, layering anti-analysis checks and stealthy behaviors before executing its core routine.
The executable itself is obfuscated and uses delayed library loading, a deliberate design to frustrate static analysis and evade endpoint detection platforms. Rather than importing all necessary functions directly, DragonForce resolves many APIs at runtime including uncommon calls such as GetCurrentPackageId and GetTempPath2W. These behaviors complicate detection and demonstrate the presence of custom loader logic.
Before touching any files, the ransomware runs environment and privilege checks. Using functions like GetCurrentProcess and OpenProcessToken, DragonForce determines whether it has elevated rights, and it employs sandbox detection techniques such as time synchronization calls to w32time.dll (W32TimeSyncNow). DragonForce is designed to terminate execution in virtualized or instrumented sandbox environments, a deliberate defensive measure to evade analysis.
If elevation is confirmed, DragonForce transitions to its operational phase. It logs its own execution into a file named log.log at C:\Users\Public\log.log.
At execution, the ransomware drops a kernel driver named rentdrv2_x64.sys, a previously legitimate but vulnerable driver known to be weaponized in BYOVD campaigns. This driver is capable of terminating protected processes like EDR or antivirus services enabling stealthy persistence and evasion from detection tools.
At this stage, DragonForce also prepares its ransom note, readme.txt, which is dropped into multiple directories during or after encryption. By distributing the note widely, the attackers ensure victims cannot overlook the instructions, even if backups exist in certain locations.
Once its groundwork is laid, DragonForce shifts into encryption mode and this is where the malware shows both speed and sophistication. Unlike ransomware families that rely heavily on AES in CBC mode, DragonForce’s analyzed samples implement a ChaCha-based stream cipher. This choice strikes a balance between efficiency and cryptographic strength, allowing encryption to run quickly while consuming minimal system resources.
Each targeted file is encrypted in its entirety, a design that contrasts with intermittent strategies used by modern families like LockBit. While some trailing portions beyond a set offset remains untouched for speed, the result is still the same: files are rendered unusable to the victim.
File size analysis shows that encrypted files consistently become slightly larger than their originals. This uniform growth points to DragonForce’s methodical approach in how it processes data during encryption. For defenders, this means traditional recovery techniques are effectively useless.
In addition, every file receives a structured block of extra data appended at the end, along with a small identifier. This mechanism ensures each encrypted file remains uniquely tied to the ransomware’s system, making recovery without attacker cooperation practically impossible. This consistency across samples highlights DragonForce’s structured approach to cryptographic handling.
In parallel, DragonForce generates unique keys and nonces for each file, reducing the chance of victims recovering data through key reuse attacks. Combined with its logging mechanisms and process tracking, this gives the group a reliable audit of which files were encrypted and how.
The net effect is clear: DragonForce’s encryption design is built for completeness, repeatability, and irreversibility. Every technical choice from ChaCha based encryption rounds to appended footers ensures that once files are locked, victims are left with only one option: negotiation.
Encryption alone is no longer enough to guarantee a payout, and DragonForce appears to know this well. Beyond locking files, the ransomware exhibits behaviors and components that suggest a strong orientation toward double extortion.
Networking libraries embedded in the executable indicate the ability to perform data exfiltration prior to encryption. DragonForce samples demonstrate data exfiltration capabilities, and the group’s operational pattern aligns with a double-extortion model where stolen data is used as leverage. Victims therefore face not only encrypted files, but also the threat of public exposure of their most sensitive information.
DragonForce further reinforces its position with persistent ransom messaging. The malware writes a ransom note titled readme.txt into multiple directories across the system. These notes contain recovery instructions and serve as unavoidable reminders of the attacker’s control. By spreading the message so widely, DragonForce ensures that no user or administrator can overlook the demand, even if partial restoration from backups is attempted.
Operationally, DragonForce also leaves behind a log file at C:\Users\Public\log.log, recording activity during execution. The logging behavior serves multiple purposes: aiding affiliates in verifying attack success, providing attackers with a forensic footprint, and functioning as a debugging trace. This logging underscores DragonForce’s structured and repeatable workflow.
The combined effect of these tactics is significant. Encryption guarantees disruption, while exfiltration and public leak threats amplify pressure on victims to pay. With DragonForce, the ransom is not just about recovering files it’s about preventing escalation and reputational damage.
Table to be inserrted here
Defending against DragonForce requires a strategy that balances early detection, prevention, and resilience. By the time encryption begins, options for response are already limited. Security teams must therefore focus on disrupting the ransomware’s pre-execution checks and operational footprint.
DragonForce exemplifies a modern ransomware operator’s philosophy: fast, structured, and persistent. Security teams that treat it only as a file locker risk overlooking the bigger picture of a well-coordinated extortion machine. Proactive monitoring, layered defenses, and tested recovery plans remain the strongest safeguards.
01f1e82d4c2b04a4652348fb18bb480396db2229c4fd22d2be1ea58e6bf4a570
1ccf8baf11427fae273ffed587b41c857fa2d8f3d3c6c0ddaa1fe4835f665eba
24e8ef41ead6fc45d9a7ec2c306fd04373eaa93bbae0bd1551a10234574d0e07
312ca1a8e35dcf5b80b1526948bd1081fed2293b31d061635e9f048f3fe5eb83
6782ad0c3efc0d0520dc2088e952c504f6a069c36a0308b88c7daadd600250a9
70afd8efb34382badead93ae104d958256de6be8054227ccc85fe95d5c5f9db0
80e3a04fa68be799b3c91737e1918f8394b250603a231a251524244e4d7f77d9
822ceefb12b030f2ff28dcda6776addda77b041dbb48d2e3a8c305721f4cc8ef
8a193db0ff08237f63c036d422f52276a4e575476763dc391455ed5b12269c07
a399a293cc3f25f6250ebee65e6e60e818831925769d540354275e9ad87bb5bb
b10129c175c007148dd4f5aff4d7fb61eb3e4b0ed4897fea6b33e90555f2b845
b714cb02cfd5d67e1502b45242636ee6b35c1b609072d3082378c50a177df15d
b9bba02d18bacc4bc8d9e4f70657d381568075590cc9d0e7590327d854224b32
ba1be94550898eedb10eb73cb5383a2d1050e96ec4df8e0bf680d3e76a9e2429
c844d02c91d5e6dc293de80085ad2f69b5c44bc46ec9fdaa4e3efbda062c871c
d06b5a200292fedcfb4d4aecac32387a2e5b5bb09aaab5199c56bab3031257d6
d4de7d7990114c51056afeedb827d880549d5761aac6bdef0f14cb17c25103b3
d626eb0565fac677fdc13fb0555967dc31e600c74fbbd110b744f8e3a59dd3f9
d67a475f72ca65fd1ac5fd3be2f1cce2db78ba074f54dc4c4738d374d0eb19c7
df5ab9015833023a03f92a797e20196672c1d6525501a9f9a94a45b0904c7403
f5df98b344242c5eaad1fce421c640fadd71f7f21379d2bf7309001dfeb25972
