DragonForce Ransomware Analysis: Inside a Verified Windows Locker

DragonForce is more than a ransomware name.

It is a ransomware service ecosystem that affiliates can use to deploy different lockers and intrusion tools.

This analysis focuses on one verified DragonForce Windows locker. The sample is a 32-bit Windows executable. It can encrypt local files, encrypt accessible SMB shares, remove shadow copies, stop selected processes, rename encrypted files with the .df_win extension, and add recovery metadata to each encrypted file.

The key finding is simple:

This sample is network-aware, but it is not a self-spreading worm.

It can damage reachable network shares by using the current security token. However, this executable does not show confirmed remote-copy or remote-execution behavior.

Executive Summary

This DragonForce sample is a verified Windows ransomware locker.

Its ransom note identifies it as “DragonForce Ransomware Cartel.” Its configuration uses the .df_win encrypted-file extension.

The locker uses ChaCha8 for file encryption. It uses RSA-4096 to protect recovery material.

The sample can:

• Encrypt local files
• Encrypt accessible SMB shares
• Delete shadow copies
• Stop selected processes
• Rename encrypted files
• Add structured recovery metadata

This sample does not include confirmed code for:

• Initial access
• Credential theft
• Data exfiltration
• Remote copying

Those activities may happen during DragonForce-related intrusions. But they are not capabilities proven inside this executable.

The highest-confidence operational conclusion is narrower: affiliates or intrusion crews obtain access, perform hands-on-keyboard activity and any theft, then deploy a locker supplied through the DragonForce ecosystem. Microsoft observed Octo Tempest deploying DragonForce ransomware, but that observation does not make Octo Tempest part of DragonForce’s internal hierarchy.

Key Findings

• The sample is a verified DragonForce Windows ransomware locker.
• Encrypted files use the .df_win extension.
• The locker can encrypt local files and accessible SMB shares.
• It uses TCP/445 scanning and NetShareEnum.
• No worm-like self-propagation was confirmed.
• No credential theft code was confirmed in this PE.
• No data exfiltration code was confirmed in this PE.
• Shadow-copy deletion uses WMI and WMIC.
• The locker uses ChaCha8 for file encryption.
• Recovery data is protected with RSA-4096.
• Each encrypted file ends with a fixed 537-byte footer.
• The operational log can be recovered offline.

What Is DragonForce Ransomware?

DragonForce can mean two things.

First, it can refer to the wider ransomware service ecosystem. Second, it can refer to the lockers distributed through that ecosystem.

In this blog:

• Sample or locker means the analyzed Windows executable.
• Service, operators, or affiliates means the wider DragonForce ecosystem.

This distinction matters. A ransomware brand can include many actors, tools, and intrusion methods. A single executable only proves what its own code can do.

Threat Group Lineage and Timeline

Public evidence places the start of recognizable DragonForce activity in the second half of 2023.

On 26 June 2024, The dragonforce account advertises an 80/20 affiliate split. A 4 July follow-up asks candidates to bring access to an organization with at least USD 5 million in revenue and to provide already-exfiltrated files. These are self-published recruitment terms. They support a service model but do not identify the person behind the account or prove that every deployment followed those terms.

The chronology becomes more directly observable in 2025. A captured 23 March forum reply shows the pseudonymous dragonforce account promoting a DragonForce-branded blog. A captured 15 September public post relays a LockBit, DragonForce, and Qilin truce claim. The captures establish that those messages circulated under those labels, not that the accounts shared infrastructure, revenue, personnel, or operations.

Government reporting added a separate impact marker in 2025 when the UK National Cyber Security Centre connected DragonForce ransomware to disruptive retail attacks. By 16 August 2026, our archived snapshot contained 634 deduplicated claims, including 145 dated April through June 2026. That growth measures public actor claims, not incident prevalence.

Affiliate Panel and Role Model

DragonForce’s affiliate panel is organized around Clients, Builder, My Team, Publications, Rules, Blog, and Profile. Its team-management view separates administrator and advertiser roles and maintains distinct activity counters. This supports a role-based service model, but it does not reveal who controlled an account or how a function was used in a particular intrusion.

The panel points to three functional layers: service operator, affiliate, and affiliate team member. It does not provide a defensible list of named leaders. Forum handles, email addresses, leaked account data, and alleged overlaps can be shared, resold, planted, or registered under false details. The public handle dragonforce is therefore treated only as an account label, and leaked personal data is excluded.

Partnership and Distribution Model

The 26 June 2024 advertisement assigns 80% to the affiliate and 20% to the service. This is a recruitment term, not an audited transaction record.

The executable contains no cryptocurrency wallet, payment amount, or automated revenue-splitting mechanism. Its ransom note instead says that the price will be negotiated according to the target’s income and insurance. The code can support an extortion workflow, but it cannot validate the service’s advertised economics.

Victimology and Public Claims

Public leak-site claims show rapid growth, but they are not a census of DragonForce intrusions. Data collected on 16 August 2026 contained 638 DragonForce listings. Deduplication by normalized domain, or victim name when no domain was available, plus event date removed four repeated rows and left 634 claims.

The charts use those 634 records consistently. They can still contain false, stale, duplicated, or misdated claims, while omitting victims that paid, remained silent, were removed, or were never published. The Belgian Centre for Cybersecurity’s 2026 profile independently stresses the limits of leak-site victim statistics.

Professional services (145) and manufacturing (140) lead the dataset, followed by technology (74), retail/e-commerce (43), healthcare (41), and transportation (35). The concentration is operationally plausible: service firms aggregate client data, while manufacturers are highly sensitive to downtime. It is context, not proof of a sector-selection rule in the malware.

The leading named countries are the United States (297), United Kingdom (45), Germany (32), Canada (20), Italy (19), and Australia (18); 25 records lack a country. These totals are limited to the 634-record dataset and should not be compared with differently scoped lists as if all collection methods used the same aliases, dates, parsers, and deduplication rules.

Government reporting provides a direct link between DragonForce and material impact in the United Kingdom. The UK NCSC’s 2025 Annual Review states that high-profile attacks by the DragonForce ransomware group disrupted customer payments and resulted in the theft of data relating to all 6.5 million Co-op members. This is evidence of impact associated with the group, but it does not establish that the analyzed executable was used in those attacks or identify the complete intrusion chain.

Separate UK Retail Investigation

The UK National Crime Agency’s 10 July 2025 announcement records four arrests in its investigation into the April 2025 attacks on M&S, Co-op, and Harrods. The announcement does not name DragonForce, identify a ransomware family, assign operational roles, or connect any arrested person to this sample. It provides law-enforcement context for the attacks on those retailers, not attribution to DragonForce.

How the DragonForce Windows Locker Works

The analyzed executable begins at the impact stage. Its code does not implement initial access, credential theft, data exfiltration, remote copying, or remote execution. If a deployment depends on those activities, they must occur outside this PE.

The only network-expansion behavior verified in this executable is TCP/445 scanning, NetShareEnum, and bulk writes to accessible disk shares. That distinction matters because encrypting a reachable share is not the same as propagating to, or executing code on, the remote host.

After parsing its embedded configuration and any command-line overrides, the locker follows the selected operating mode. With process termination enabled, it attempts to terminate processes whose names match its 38-entry configuration list. Modes 0x0A through 0x0D invoke the WMI and WMIC shadow-copy deletion path. The local and network branches then traverse the selected storage, while mode 0x0D stops without entering a file-encryption branch. File-processing modes encrypt selected content, encode the original filenames, and append the configured .df_win extension. Separate routines can apply the configured file icon and desktop wallpaper.

The network capability is damaging, but it is not autonomous propagation. The binary derives scan targets from local network information, probes TCP/445, enumerates disk shares with NetShareEnum, and writes to shares accessible under the current security token. No code path was found that copies the executable to a remote host or starts it there. This makes the sample a network-aware impact tool, not a self-propagating worm.

The incident examples below include activity that can precede locker execution, such as exploitation, identity compromise, privilege escalation, remote administration, and data exfiltration. Those steps provide deployment context only. They are not capabilities found in this PE.

Cryptographic Architecture

ChaCha8 appears in four distinct contexts, but only the per-file use creates the victim’s recovery barrier:

1. A hardcoded 32-byte key and eight-byte nonce decrypt the embedded configuration.
2. A separate hardcoded key/nonce pair decrypts the embedded ransom note.
3. A clear 16-byte session header deterministically yields the key and nonce for the encrypted operational log.
4. Fresh CryptGenRandom material supplies each victim file with its own 32-byte key and eight-byte nonce. The binary then wraps that recovery material and the original filename with an embedded RSA-4096 public key.

The first three uses obscure data from casual inspection but are recoverable offline from the sample or log itself. The fourth is the cryptographic barrier that prevents recovery without the corresponding RSA private key.

The RSA plaintext is 32-byte key || 8-byte nonce || one-byte UTF-16 character count || original UTF-16 filename. CryptEncrypt is called with Final=TRUE and flags zero, which gives the CryptoAPI RSA key-exchange key’s default PKCS#1 v1.5 padding. The resulting 512-byte RSA ciphertext is followed by 12 zero bytes, a one-byte mode, a little-endian 32-bit mode parameter, and the little-endian 64-bit original size.

No universal decryption weakness was found. The private key is absent, per-file entropy comes from CryptoAPI, and no key reuse appeared in the preserved evidence. Recovery remains possible from unaffected backups, snapshots the deletion path did not reach, or a future implementation/operational failure; no public universal decryptor was identified for this exact format as of the research date.

Data Leak Site Operations

The 1,992-byte ransom note turns encryption into a timed extortion workflow. It directs the recipient to a Tor negotiation room, provides a separate Tor blog/news site, includes a Tox fallback and victim ID, and offers a test decrypt plus an alleged list of stolen files. It names 21/05/2026 00:00 UTC as the approximate publication and decryptor-deletion deadline; that date is neither a compile time nor a reliable attack date.

Good afternoon,

As you can see you have been attacked by a ransomware program! We The
DragonForce Ransomware Cartel offer you to make a deal with us. We can make
a deal with you, all you need to do is contact us by following the
instructions below.

We are in no way connected to politics, we always keep our word. You have a
chance to decrypt your files and avoid being published on our blog! Use this
opportunity and also don't waste your time.

The approximate date of deletion of the decryptor program, as well as
publication on our blog 21/05/2026 00:00 UTC.

- # 1 Communication Process,

In order to contact us you need to click on the special link below, which is
listed in #2.

After that the negotiation process begins, in which you have the opportunity
to request several things from us,

1. make a test decrypt.
2. get a list of the files stolen from you.

At the conclusion of our negotiations we agree on a price, we set the price
ourselves based on your income/your insurance.

We scrutinize your documents and are well aware of how much income your
company has per year.

- # 2 Access to the meeting room,

To access us please download Tor Browser which is available here.
(https://www.torproject.org/)

Once you download the special anonymous browser you need to follow this link,
http://3pktcrcbmssvrnwe5skburdwe2h3v6ibdnn5kbjqihsg6eu6s6b7ryqd.onion

Your unique ID: E1CAAD24E181CCB4E1CAAD24E181CCB4 - use it to enter our
meeting room.

- # 3 Additional Support Contacts,

Tox: 1C054B722BCBF41A918EF3C485712742088F5C3E81B2FDD91ADEA6BA55F4A856D90A65E99D20

- # 4 Recommendations,

Do not try to recover your files with third-party programs, you will only do
harm.
Do not turn off / reboot your computer.
Be courteous in our meeting room.
Do not procrastinate.

- # 5 Blog and News,

Blog: http://z3wqggtxft7id3ibr7srivv5gjof5fwg76slewnzwwakjuf3nlhukdid.onion
DragonNews: http://z3wqggtxft7id3ibr7srivv5gjof5fwg76slewnzwwakjuf3nlhukdid.onion/news

DragonFiles entries use separate scheduled and published states, including PUBLISHED, TIMER STOPPED, future UTC publication values, and data-volume claims. Identifying details are redacted. These fields describe leak-site status, not proof that an organization was compromised or that the claimed data was authentic.

The published entries and exposed archive links document that DragonForce released data through its leak site. That does not change the binary finding: this PE contains no confirmed exfiltration implementation, so collection and upload would require separate operator activity or tooling. Leak-site scheduling does not imply a universal 14-day timer, automatic publication of negotiation chats, automated wallet splitting, or a fixed ransom price. No stolen file or negotiation account is reproduced in this report.

Sample Metadata

Contact Channels

Why this matters: Builder-configured IOCs can change, while the parser, network-share logic, footer layout, crypto calls, and WMI workflow are more durable. Attribution should remain limited to the note, code, preserved artifacts, and government reporting.

How DragonForce Works

1. Initialize and recover configuration. The program decrypts the container with ChaCha8 and parses fields bounded by 0xDEAD/0xBEEF markers.
2. Apply command-line overrides. The program alls CommandLineToArgvW and handles -p, -m, -log, -size, and -nomutex.
3. Enforce or bypass single-instance control. Unless -nomutex is present, it creates mutex hsfjuukjzloqu28oajh727190.
4. Check privilege and prepare processes. The binary can inspect token elevation and includes a separate SYSTEM-token relaunch path. The configured use_sys=0 disabled that option in this build. During the initial lab analysis, both elevated and non-elevated runs reached encryption; elevation increased file access.
5. Terminate configured processes. With kill=1, it matches 38 process names. The observed configuration selected user-mode termination because use_sys=0; optional TrueSight/rentdrv2 driver paths remain dormant capabilities.
6. Dispatch the selected mode. Modes 0x0A–0x0D execute the common shadow-copy workflow; 0x0A/0x0B select local encryption, 0x0A/0x0C select network-share encryption, and 0x0D stops after recovery inhibition. Explicit-path mode 0x0E handles the supplied path without the general local/network dispatch.
7. Discover and unlock data. Local enumeration applies exclusions. The network branch scans TCP/445 and enumerates accessible disk shares. Restart Manager closes non-protected holders when needed.
8. Encrypt and rename. Function 0x444C90 selects full, header, or striped encryption. A custom base32 encoder replaces the original filename and the configured .df_win extension is appended.
9. Write recovery metadata. Every preserved output ends with the 537-byte RSA/footer structure, retaining the original size and mode parameters.
10. Apply optional branding and log. Configuration enabled custom icon and wallpaper but disabled scheduled execution and time sync. Operational records were ChaCha8-encrypted and appended to C:\Users\Public\log.log.

Operating Modes and CLI Arguments

DragonForce’s four mode names are values supplied to -m, not standalone command-line switches. The VAs below identify the contiguous option/value data; the parser logic is in 0x458B30.

Why this matters: Mode names alone do not describe all side effects. Both local and net still run common preparation and shadow-copy deletion, while backups is a recovery-inhibition mode rather than arbitrary backup-server destruction. Initial lab runs show that writable data does not require elevation to be damaged; elevation mainly expands the set of files the locker can reach.

How DragonForce Spreads and Operates

Network reach is the feature most easily mistaken for self-propagation. DragonForce can discover hosts and encrypt shares accessible to the current token, but it does not copy or launch itself remotely. Function 0x463B80 uses GetIpNetTable at 0x463BAF and 0x465131, filters textual addresses beginning with 172., 192.168., 10., or broad 169., and deduplicates the first three octets to derive /24 scan targets. The 169. test is broader than link-local 169.254.0.0/16.

The scanner resolves ConnectEx with WSAIoctl, uses I/O completion ports, and probes TCP/445; function 0x4698F0 passes 0x1BD to htons. This is host/share discovery, not credential acquisition.

Function 0x466760 calls NetShareEnum at 0x4667DC with information level 1. It processes disk shares, compares names with ADMIN$ at 0x46718B, and skips an exact case-insensitive match. IPC$ is not a disk share. Other administrative disk shares such as C$ are not excluded by that comparison and can be processed if the current token can access them.

Network Preparation

The sample does not alter the firewall, create domain accounts, modify LSA policy, or enable remote management. It contains optional time synchronization through w32time.dll/W32TimeSyncNow, but the recovered configuration set time_sync=0. Local CopyFileW plus COM Task Scheduler code is a delayed local execution capability, not evidence of remote copy.

Credential Handling

No password prompt, credential dumper, browser-secret theft, LSASS access chain, LogonUser, WNetAddConnection, or embedded SMB credential was identified. Remote file access uses the running token. Credential theft reported in intrusions belongs to the affiliate/operator lane unless another artifact proves otherwise.

Data Exfiltration

No data-staging or exfiltration implementation was confirmed in this PE. The published archives establish that the extortion operation released stolen data, but this locker’s code does not collect, stage, or upload it. That part of the intrusion therefore depends on operator activity or separate tooling. Documented deployment cases include exfiltration over SSH and other mechanisms, but those capabilities cannot be assigned to this executable.

Why this matters: Defenders should expect one compromised identity and host to damage many reachable shares, but detections should focus on TCP/445 fan-out, NetShareEnum, and bulk remote writes, not an unsupported ADMIN$ remote-execution story. Segment storage and minimize writable share access even when privileged administrative shares are disabled.

Technical Analysis

The locker’s file-processing design favors speed without sacrificing per-file key separation. It fully encrypts smaller or specially classified data, selectively damages large files, wraps recovery material independently, and records enough metadata for its decryptor to reconstruct each original name and size.

How DragonForce Encrypts Files

The configuration container: 32 key bytes, an eight-byte nonce, a little-endian ciphertext length of 844, then ciphertext. Offline ChaCha8 decryption reproduces an 844-byte structured record bounded by 0xDEAD and 0xBEEF, SHA-256 EB2E349F5F772DB8D72573CB0D962453E732DC72328D9ED2B8A8B0656EDC5144. ChaCha12 and ChaCha20 do not produce valid markers. The note uses a separate container and decrypts to exactly 1,992 bytes.

The malaware then selects one of three data paths. The first 156 entries in a 190-entry extension table are database and storage formats that force full encryption. The final 34 entries are VM, disk, and container formats that force striped encryption with a hardcoded 20% argument.

Size controls the remaining files. Ordinary files at or below 2 MiB are fully encrypted. Files above 2 MiB through 10 MiB use the 3 MiB header path, while files above 10 MiB use the configurable other_encrypt_chunk_percent. The observed 16% footer came from this ordinary-large-file branch after -size 16; the special VM/container rule remained fixed at 20%.

Across 1000+ parsed encrypted outputs, every file is exactly its recorded original size plus 537 bytes. Each stored original-size field equals encrypted_file_size - 537, and all 12 reserved bytes are zero. The smallest original was 20 bytes and the largest was 11,735,040 bytes. The outputs cover full, header, and striped encryption modes and validate the reconstructed footer placement.

The per-file function obtains a 32-byte key (CryptGenRandom) and eight-byte nonce. The ChaCha implementation performs four double rounds, making it ChaCha8. The program imports a PUBLICKEYBLOB: type PUBLICKEYBLOB, version 2, CALG_RSA_KEYX, RSA1, 4,096 bits, exponent 65,537. It wraps recovery metadata with CryptEncrypt.

The footer is:

offset from footer   length   content
0x000                512      RSA-4096 ciphertext
0x200                 12      reserved, all zero in 1,102/1,102 outputs
0x20C                  1      mode: 0x64 full, 0x65 striped, 0x66 header
0x20D                  4      little-endian mode parameter
0x211                  8      little-endian original file size
total                537

Filename encryption is deterministic and reversible independently of file contents. The encoder converts the original name to an ANSI byte sequence and applies MSB-first base32 without padding using alphabet gwfn6l3bk45o2zecvi7xtyqrpsudmahj. Examples confirmed from the code are cp850.py → 2zpnvz4vlspb7 and Resources.scale-140.pri → 547r3ddye4iq5mseeziqfdnlltpxk2weews37; .df_win is then appended. The RSA-wrapped plaintext retains the original UTF-16 filename for the decryptor.

The first 156 special extensions include formats such as .sql, .sqlite, .mdb, .accdb, .edb, .nsf, .mdf, and .ndf; the final 34 include .vdi, .vhd, .vmdk, .pvm, .vmem, .vmsn, .vmsd, .nvram, .vmx, .raw, .qcow2, .subvol, .bin, .vsv, .avhd, .vmrs, .vhdx, .avdx, .vmcx, and .iso. This array controls special handling; it is not a general allowlist. The normal traversal encrypts other extensions unless an exclusion applies.

Configured excluded path components are tmp, winnt, temp, thumb, $Recycle.Bin, $RECYCLE.BIN, System Volume Information, Boot, Windows, perflogs, and Public. Excluded extensions are .exe, .dll, .lnk, .sys, .msi, .bat, and .df_win.

Why this matters: The binary can render both ordinary documents and large VM/database containers unusable quickly, while per-file entropy and RSA wrapping prevent one recovered file key from unlocking the rest. Defenders gain two stable artifacts: the exact 537-byte footer schema and deterministic filename alphabet.

How DragonForce Evades Detection

This build favors obscuration and operational interference over sophisticated anti-analysis. It encrypts configuration, note text, and operational records with ChaCha8, but the embedded containers remain recoverable because their keys and nonces are stored in the executable.

The runtime log is also recoverable because every appended session begins with a clear 16-byte header. Function 0x494110 pairs byte i of the first eight-byte half (A) with byte i of the second half (B), expands each pair to [A, B, A XOR B, A + (A XOR B) + B mod 256], and derives each nonce byte as A XOR B. Each record is a little-endian 16-bit length followed by ChaCha8 ciphertext; the stream routine starts a new 64-byte block for every record and discards unused keystream bytes.

The initial-analysis log parses cleanly with no trailing bytes, and its records produce valid plaintext throughout. Because the key schedule is derived from the clear header, this is obfuscation rather than secret logging. Repeated headers also reveal session boundaries before decryption.

The binary reconstructs some option and constant bytes arithmetically, including the ZW#WWW → UTF-16LE -m transform. It carries a bogus 1970 timestamp and strips relocations, complicating superficial triage without constituting packing. The PE does not opt into ASLR, DEP compatibility, CFG, or NO_SEH; its DllCharacteristics field is zero.

Restart Manager code registers a target file, enumerates holders, and can invoke RmShutdown to release locks. Function 0x46D980 enumerates explorer.exe PIDs, and the caller also protects the current PID; it only shuts down holders when no protected process is in the returned set. This helps encrypt live data but remains visible through Restart Manager and process telemetry.

Optional driver support can raise termination power. The sample references \\.\TrueSight/truesight.sys and \\.\rentdrv2/rentdrv2.sys, registers a demand-start kernel-driver service, and sends interface-specific IOCTLs. Neither .sys image is embedded, so its signature, version, vulnerability, and loadability cannot be inferred. The observed use_sys=0 configuration left this route inactive.

Why this matters: Encryption of configuration and logs defeats simple strings-based review, but the implementation leaks enough material for exact offline recovery. That gives responders the real configuration, timestamps, thread IDs, failures, and per-file modes without executing the sample.

How DragonForce Persists on Infected Systems

The malware implements local delayed execution through the Task Scheduler COM interfaces. It connects to the service, creates a task definition, sets a SYSTEM principal, builds a one-time ISO-8601 trigger, configures an executable action, and registers the task. Nearby CopyFileW code copies the current executable to the configured job_executable path before registering it with the local Task Scheduler.

This is a one-shot delayed-execution capability, not proof of recurring persistence. The recovered configuration has schedule_job=0, and the recovered operational log contains no task-creation record. No recurring trigger, Run key, startup-folder mechanism, or permanent ransomware service was confirmed.

The icon and wallpaper features write visual state through Software\Classes\%s\DefaultIcon, Control Panel\Desktop, and SystemParametersInfoW. They may survive process exit, but they do not relaunch the executable and should not be mapped as persistence.

Why this matters: Hunters should monitor COM-based task registration rather than relying only on schtasks.exe creation, while incident reports should not claim persistence when the builder disabled the feature and no task was observed.

How DragonForce Kills Backup and Security Services

In this build, disruption targets named processes and shadow copies rather than a generic list of Windows services. The configuration enables termination of 38 process names:

MsMpEng.exe, sql.exe, oracle.exe, ocssd.exe, dbsnmp.exe, synctime.exe,
agntsvc.exe, isqlplussvc.exe, xfssvccon.exe, mydesktopservice.exe,
ocautoupds.exe, encsvc.exe, firefox.exe, tbirdconfig.exe,
mydesktopqos.exe, ocomm.exe, dbeng50.exe, sqbcoreservice.exe, excel.exe,
infopath.exe, msaccess.exe, mspub.exe, onenote.exe, outlook.exe,
powerpnt.exe, steam.exe, thebat.exe, thunderbird.exe, visio.exe,
winword.exe, wordpad.exe, notepad.exe, calc.exe, wuauclt.exe,
onedrive.exe, SQLAGENT.exe, sqlservr.exe, SQLWriter.exe

Function 0x475EC0 uses OpenProcess and reaches TerminateProcess at 0x47705B. Optional mode 1 sends IOCTL 0x22E044 to TrueSight with a structure containing the target PID; optional mode 2 sends 0x22E010 to rentdrv2 with the expected control value. The driver-service routine creates/starts whichever external driver was supplied. Function 0x46E0C0 stops and deletes that selected driver service during cleanup; it is not an arbitrary service-kill loop. No independent list of backup or security service names was recovered.

Recovery inhibition is explicit. The WMI routine connects to ROOT\CIMV2, executes SELECT * FROM Win32_ShadowCopy, extracts each shadow-copy ID, formats cmd.exe /c C:\Windows\System32\wbem\WMIC.exe shadowcopy where "ID='%s'" delete, and launches it through CreateProcessW at 0x40892D. The strings and control flow are reachable for modes all, local, net, and backups. This build contains no confirmed vssadmin, wbadmin, bcdedit, or event-log-clearing command.

The recovered configuration sets kill=1 and use_sys=0, but the available runtime evidence does not include Procmon or ETW telemetry showing which processes terminated or whether WMIC successfully deleted a shadow copy. The process-kill and WMI workflows are therefore confirmed executable capabilities, while successful termination or deletion is not independently demonstrated.

Why this matters: DragonForce combines file-lock removal, named-process termination, and shadow-copy deletion, but defenders should hunt the exact mechanisms. Broad claims about service destruction, backup-server takeover, or additional recovery commands would create noisy detections and are not supported by this build.

Why DragonForce Matters

• Network-scale impact without worming: One sufficiently privileged token can enumerate and encrypt many writable SMB shares even though the executable does not remotely execute itself.
• Fast treatment of large assets: Header and striped modes damage VM/container data without encrypting every byte, reducing attacker dwell time during impact.
• Strong per-file recovery barrier: ChaCha8 keys and nonces are generated independently and wrapped with RSA-4096. No private key or universal implementation flaw was found.
• Recovery inhibition in every named -m mode: local, net, and backups all execute the common shadow-copy path; selecting one of those labels does not isolate its side effects.
• Privilege expands reach but is not a hard gate: Runtime records show writable-file encryption without elevation. Elevation increased successful coverage because the process could open more paths.
• External driver dependency is a defender advantage: Kernel-assisted termination requires a compatible truesight.sys or rentdrv2.sys that is absent from this PE and disabled in the recovered configuration.
• Operational log design is an OPSEC failure: The log’s clear header deterministically yields its ChaCha8 key and nonce, exposing configuration, timestamps, errors, thread IDs, and file-mode decisions.
• Ecosystem branding is not binary attribution: Initial access, credential theft, and exfiltration vary by affiliate and must be proven from incident evidence rather than imported from DragonForce reporting.

Detection, IOCs, and Defense

File-Based Indicators

Registry and Device Indicators

Network Indicators

YARA Rule

rule Windows_Ransomware_DragonForce
{
    meta:
        description = "DragonForce ransomware"
        author      = "Dark Atlas; @ELJoOker"
        date        = "2026-08-18"
    strings:
        $s1  = "Renaming: %s , %s" wide
        $s2  = "New name: %s" wide
        $s3  = "Resulting name: %s" wide
        $s4  = "Setting %s to %s with len %d" wide
        $s5  = "%04d-%02d-%02dT%02d:%02d:00Z" wide
        $s6  = "Process is elevated: %d" wide
        $s7  = "Found sid: %s" wide
        $s8  = "Run Trigger" wide
        $s9  = "expand 16-byte k" ascii
        $s10 = "expand 32-byte k" ascii

    condition:
        uint16(0) == 0x5A4D and
        8 of them
}

FAQ

What is DragonForce ransomware?

DragonForce is a ransomware service ecosystem. The analyzed sample is a Windows locker that encrypts local files and accessible SMB shares, deletes shadow copies, stops selected processes, and renames encrypted files with .df_win.

Does this DragonForce sample spread like a worm?

No. The sample can scan TCP/445 and encrypt accessible shares, but no confirmed remote-copy or remote-execution chain was found.

What encryption does this sample use?

The sample uses ChaCha8 for file encryption. It uses RSA-4096 to protect recovery material.

Can affected files be decrypted without paying?

No universal decryptor was identified for this exact format. Recovery depends on unaffected backups, untouched copies, the matching private key, or a future implementation failure.

What are the strongest detection signals?

Strong signals include TCP/445 fan-out, NetShareEnum, bulk SMB writes, shadow-copy deletion, .df_win files, and the fixed 537-byte footer.

Conclusion

The three highest-priority actions are to cut SMB reach immediately, protect/monitor shadow-copy and driver-control paths, and preserve the recoverable operational log plus representative encrypted files. Those steps limit further damage and retain the evidence most useful for scoping and recovery.

No static or runtime weakness yielded the RSA private key or plaintext file keys. For successfully encrypted files, decryption currently requires the matching private key unless backups, untouched copies, or a future implementation/operational flaw provides another route. “No public universal decryptor found” is not the same as “recovery is mathematically impossible.”

The most valuable result is the precise reconstruction of the locker itself: its CLI semantics, network-share boundaries, three file-encryption modes, deterministic filename encoding, and 537-byte footer. For defenders, that turns a configurable ransomware brand into a concrete set of behaviors and artifacts that can be hunted, scoped, and preserved.