DAEMON Tools Backdoor: Inside the Supply Chain Attack on a Dev Staple

Kaspersky disclosed on May 5 that DAEMON Tools — the Windows utility widely used to mount disk images and create virtual drives — was the target of a supply chain attack: its official website served backdoored installers for at least 29 days, beginning April 8, 2026. The suspected actor is a Chinese state-linked group. Thousands of infection attempts have been recorded; Kaspersky confirms at least a dozen successful compromises.

This is not a generic consumer malware campaign. DAEMON Tools is a staple on Windows development machines, and that changes the risk profile considerably.

How the supply chain attack worked

The malicious installers were distributed from DAEMON Tools’ own domain and were digitally signed, so every standard check — “is this from the official site?”, “does Windows show a valid signature?” — would have passed cleanly. Kaspersky has not yet published the full capability set of the backdoor, but the attack pattern is consistent with a remote-access implant intended for persistent espionage and initial access brokering.

Supply chain attacks of this class work by breaching the vendor’s distribution infrastructure: the build server, the release pipeline, or the CDN serving downloads. The attacker inserts a payload into the artifact before it leaves the official domain. The signing certificate stays valid because it is the real certificate. The vendor’s own reputation becomes the delivery mechanism.

This is worth saying plainly: the attack did not exploit a vulnerability in the installer. The installer itself was the attack.

Why developer machines are the target

A developer workstation is not one compromised machine in isolation. It typically holds SSH private keys, cloud credentials, Git commit-signing keys, and — if you work in mobile — App Store Connect certificates or Play Console upload keys. A persistent implant on a dev machine is a potential path to signing legitimate releases with a valid certificate, pushing to production repositories, or pivoting directly into CI/CD pipelines.

State-sponsored groups consistently choose developer tooling over general-purpose consumer software for this reason. One well-positioned developer machine can silently propagate compromise across an entire product stack before any downstream security tooling notices anything unusual.

Signed does not mean safe

Every time a supply chain attack makes the news, the same lesson resurfaces: a digital signature proves that an artifact was signed with a specific key at a specific time. It says nothing about whether the entity controlling that key was uncompromised at the moment of signing, or whether the binary is what it claims to be.

The XZ utils backdoor (2024) used years of social engineering to earn commit access. The 3CX supply chain attack (2023) compromised an upstream library 3CX depended on. SolarWinds (2020) modified the build system directly. DAEMON Tools appears to follow the same template: compromise the distribution channel and let the vendor’s own certificate do the delivery.

Trusting a signed installer from an official website is a reasonable default heuristic — but it is a heuristic, not a guarantee. The attack surface is the vendor’s own infrastructure.

Immediate steps for affected teams

If anyone on your team uses Windows and has DAEMON Tools installed, act on this now:

• Determine when it was installed or last updated. Any install or update between April 8 and approximately May 5, 2026 should be treated as potentially compromised. Check Kaspersky’s securelist advisory for the definitive list of affected versions.
• Run a full EDR scan. Kaspersky, CrowdStrike, and Microsoft Defender for Endpoint have updated signatures. Do not rely on a quick scan or a cloud reputation check.
• Rotate all secrets accessible from the machine. SSH private keys, API tokens, cloud access keys, certificate keystores, and any mobile app signing credentials should be rotated regardless of scan results. A clean scan does not mean a clean machine — it means no known indicator was found.
• Audit recent release artifacts. If the host was involved in signing builds, verify released artifacts against expected checksums and review commits from the affected window for anything unexpected.
• Check for persistence. Look for unusual scheduled tasks, startup registry entries under HKCU\Software\Microsoft\Windows\CurrentVersion\Run, and outbound connections to unfamiliar hosts.

Hardening the development supply chain

A few practices we apply consistently that reduce the blast radius of attacks like this:

Separate signing from development. Code signing should happen in CI, not on a developer laptop. The pipeline step that signs your iOS or Android release should have the narrowest possible access surface — no browser, no personal utilities, no ad-hoc installs. A DAEMON Tools-style compromise on a developer machine then affects only that machine, not your entire release chain. This is a core part of how we structure delivery on every engagement; the full approach is in our process overview.

Use managed package managers for internal tooling. Homebrew, winget, and Scoop all support hash pinning and can be configured to pull from an internal mirror where binaries are inspected before distribution. Installing dev utilities by downloading from vendor websites — on machines with production-level trust — is the single easiest thing to eliminate.

Pin and lock all dependencies. npm lockfiles, Gradle dependency locks, CocoaPods Podfile.lock — if a hash changes unexpectedly between CI runs, that is a signal worth investigating before merging. Treat lockfile drift as a potential security event, not just a maintenance chore.

Monitor for behavior, not just signatures. Signature-based detection is always a trailing indicator. An EDR configured to flag credential access patterns, unusual process spawns, and anomalous outbound connections will catch supply chain implants that have no known hash. Behavioral baselines catch novel variants; hash matching catches yesterday’s attacks.

What we’re watching

Whether Kaspersky’s full technical report, when published, confirms additional affected software from the same campaign. The attribution to a Chinese state-linked group places DAEMON Tools in a pattern of systematic developer-toolchain targeting — 3CX, XZ utils, and now this — that shows no sign of slowing. If your team builds on Windows, now is a reasonable time to audit which utilities are installed on developer machines, where those binaries came from, and whether any of those machines have signing authority over production systems.

Sources

1. DAEMON Tools supply chain attack compromises official installers with malware — The Hacker News, May 5, 2026
2. Kaspersky suspects Chinese hackers planted a backdoor into Daemon Tools in ‘widespread’ attack — TechCrunch (Zack Whittaker), May 5, 2026
3. DAEMON Tools trojanized in supply-chain attack to deploy backdoor — BleepingComputer, May 5, 2026
4. Kaspersky Securelist — Primary research, May 2026