DragonForce weaponized legitimate software to accelerate ransomware

At a glance

What this is: Halcyon describes how DragonForce weaponised legitimate, signed software to bypass trust assumptions and speed ransomware execution.

Why it matters: For IAM and NHI practitioners, the key lesson is that trusted binaries, signed installers, and approved software channels still need runtime scrutiny because identity and privilege can be hijacked before conventional controls react.

By the numbers:

• Only 7 out of 73 vendors on VirusTotal flagged the file, and those were just generic remote access tool alerts.

Context

Ransomware operators increasingly exploit trust in legitimate software rather than relying only on obvious malware indicators. In this case, the malicious file was digitally signed and appeared to come from a real remote access vendor, which is exactly the kind of trust boundary that many endpoint and user-approval workflows assume is safe.

That makes the problem broader than malware detection alone. When signed software can be repackaged, preconfigured to reach attacker infrastructure, and executed by a user, the security decision shifts from simple reputation checking to runtime validation of privilege, behavior, and provenance.

Key questions

Q: What breaks when legitimate software is used to deliver ransomware?

A: When attackers weaponise legitimate software, signature trust and standard allowlists stop being reliable safety signals. The file can appear approved while still enabling remote access, privilege escalation, and command-and-control. Security teams need behavioral detection, execution policy, and egress controls that judge what the software does after launch, not just who signed it.

Q: Why do trusted installers and remote access tools increase ransomware risk?

A: Trusted installers lower user suspicion and often pass basic reputation checks, which gives attackers a cleaner entry path. If the software can call home to attacker infrastructure or spawn privileged activity, the attacker gains control before many defenses react. The risk is not trust itself, but trust without runtime verification.

Q: How can security teams spot weaponised legitimate software before encryption starts?

A: Look for abnormal child processes, unexpected outbound connections, privilege changes, and execution from unusual user contexts. A legitimate binary that suddenly phones unknown servers or starts administrative activity should be treated as suspicious. Early detection depends on correlating process lineage with network telemetry rather than waiting for encryption indicators.

Q: Should organisations treat digital signatures as enough proof that software is safe?

A: No. Digital signatures confirm provenance, not intent or current behavior. Attackers can exploit vulnerable signed software, bundle malicious components, or preconfigure legitimate tools to operate on their behalf. Organisations should treat signatures as one trust input, then verify runtime behavior, destination risk, and privilege use before allowing broad execution.

Technical breakdown

How trusted software becomes an initial access path

Attackers can take legitimate remote access software, modify or bundle it with malicious components, and preserve enough of the original trust signals to fool users and some controls. Digital signatures, familiar vendor names, and normal-looking filenames lower suspicion, especially when the binary is delivered through routine download or execution flows. The security failure is not that the software is always malicious, but that defenders often treat trust indicators as sufficient proof of safety. In practice, that means the user and the endpoint both make an allow decision before the real behavior is visible. See the Ransomware Prevention Guide.

Practical implication: Treat signed software as untrusted until its runtime behavior matches an approved baseline.

Why ransomware chains move so fast once execution starts

Once the payload runs, ransomware groups try to convert execution into control as quickly as possible. That typically means SYSTEM-level privilege, discovery, lateral movement, data theft, and encryption in one compressed sequence. The point is speed: defenders may have only minutes, not hours, to notice the transition from a benign-looking process to destructive activity. This is why static indicators often fail. By the time file reputation changes, the attacker may already have established persistence or begun encrypting data. See the Ransomware Groups Guide.

Practical implication: Prioritise controls that interrupt post-execution activity before privilege escalation completes.

Why traditional detections miss weaponised legitimate tools

General-purpose endpoint tools are tuned to spot broad malware patterns, not every abuse of approved software. When attackers use legitimate remote access tooling, detection has to distinguish normal administrative use from hostile staging, command-and-control, and pre-encryption activity. That requires correlation across process lineage, network destinations, child processes, and privilege changes. In this kind of attack, a file can look innocuous to reputation services while still being operationally dangerous. The control gap is not visibility alone, but the ability to interpret normal software behaving abnormally.

Practical implication: Build detections around behavior, lineage, and destination risk, not file verdicts alone.

Threat narrative

Attacker objective: The objective was to gain remote control fast enough to move laterally, steal data, and encrypt systems before defenders could react.

1. Entry occurred through a signed, legitimate-looking executable that a healthcare user downloaded and ran.
2. Credentialed control followed when the payload delivered remote access and SYSTEM-level privileges to attacker-controlled infrastructure.
3. Escalation and impact would have included lateral movement, data theft, and ransomware encryption if the file had not been stopped.

Breaches seen in the wild

• Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted software abuse is the new trust-bypass problem. The article shows that ransomware actors do not need to defeat trust models head-on when they can ride inside legitimate software channels instead. Signed binaries, familiar vendor names, and approved download paths all reduce suspicion before the malicious behavior begins. Practitioners should treat software trust as conditional, not categorical.

Detection needs to move from reputation to runtime governance. File verdicts, signer checks, and remote-access labels are not enough once attackers can repackage legitimate tools. The governance gap is that many environments still assume a good signer implies good behavior, which is no longer defensible. Legitimate software handling needs behavior-based inspection and tighter execution policy.

Ransomware speed compresses the response window into the pre-encryption phase. The article’s timeline is the important signal, not just the tooling. Once attackers gain control through legitimate software, the window to stop lateral movement and encryption shrinks dramatically. That makes pre-execution and immediate post-execution controls more important than downstream containment alone.

Weaponised trust signal: the specific failure mode here is overreliance on approved software attributes as proof of safety. The attack worked because defenders and users treated legitimacy as static, when the threat emerged only after execution and network reachability. Practitioner implication: govern trust at the point of use, not just at download or procurement.

Ransomware operations now depend on dual deception, not just malware disguise. Actors increasingly combine legitimate software with attacker-controlled infrastructure so both the binary and its communications look plausible. That means security teams must connect application trust, endpoint control, and network egress policy. Practitioner implication: do not evaluate the file in isolation from where it phones home.

Read next: Ransomware Prevention Guide

What this signals

Software provenance and software behavior are now separate governance questions. A signed binary may satisfy procurement or identity trust expectations while still acting as a delivery vehicle for ransomware. Security programmes need to treat provenance as necessary but insufficient, with runtime controls deciding whether execution is allowed to continue.

The more attackers reuse legitimate software, the more endpoint policy has to shift left and right at once. Left of boom controls must reduce execution exposure, and runtime controls must catch the moment a trusted process starts behaving like an attacker tool.

For practitioners

• Tighten execution policy for signed software Require additional scrutiny for signed binaries that are not on an approved administrative allowlist, especially remote access tools and installers.
• Inspect process behavior after launch Correlate parent-child process chains, privilege changes, and outbound destinations so a benign-looking file cannot silently pivot into attacker control.
• Block attacker-controlled callback infrastructure Use egress controls and DNS monitoring to stop newly executed software from reaching unknown command-and-control servers.
• Harden ransomware response priorities Treat pre-encryption interruption as the operational objective, with containment steps focused on stopping lateral movement before damage spreads.
• Reassess trust in remote access software Review how users approve remote support and admin tools, then remove implicit trust in software just because it is signed or familiar.

Key takeaways

• The incident shows how ransomware actors can exploit trust in legitimate software instead of relying on obvious malware alone.
• The article says only 7 out of 73 VirusTotal vendors flagged the file, which shows how narrow the visibility window can be.
• Runtime behavior controls, egress restrictions, and pre-encryption interruption matter more than static trust signals when signed software is weaponised.

Related NHI Mgmt Group resources: Ransomware Prevention Guide · Ransomware Groups Guide · Information Security Policy Template

Key terms

• Weaponised Legitimate Software: Legitimate software that has been repackaged, modified, or configured to support malicious activity while preserving enough trust signals to evade suspicion. In practice, the danger comes from the software's runtime behavior, not its appearance or source branding.
• Runtime Trust: Runtime trust is the idea that access should remain valid only while current context justifies it. Instead of trusting a setup decision indefinitely, teams continuously re-evaluate whether a workload or agent still deserves privilege. This approach is especially important for AI agents that can change behaviour mid-task.
• Pre-Encryption Interruption: Stopping a ransomware chain before file encryption begins by detecting execution, privilege gain, lateral movement, or command-and-control early enough to block the destructive stage. This is the most valuable window in modern ransomware defense because damage accelerates quickly once execution succeeds.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security decisions that shape access and trust.