Daemon Tools Was Trojanized for a Month — and the Installer Was Properly Signed

Kaspersky disclosed on May 5, 2026 that Daemon Tools — disk-imaging software with millions of users worldwide — has been distributing trojanized installers from its official website since April 8, 2026. The compromised binaries were signed with valid AVB Disc Soft developer certificates. Thousands of machines across approximately 100 countries received a first-stage information collector; only about a dozen high-value systems at government, scientific, manufacturing, and retail organizations in Russia, Belarus, and Thailand received second-stage backdoors. A Russian educational institution received a more sophisticated C++ implant called QUIC RAT. Disc Soft acknowledged the breach on May 6 and shipped clean version 12.6.0.2445.

On May 5, 2026, Kaspersky's Securelist research team published a detailed analysis of an active supply-chain compromise targeting Daemon Tools, a long-running disk-imaging utility with millions of users. From April 8, 2026, the software's official daemon-tools[.]cc download site has been serving trojanized installers — versions 12.5.0.2421 through 12.5.0.2434 — signed with the legitimate AVB Disc Soft developer certificate. Three core binaries inside the installation directory were tampered with: DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe. The backdoor was implanted in the C runtime startup code, ensuring it activates every time the affected binaries launch — which on most Windows systems is at boot. The implant then beacons to env-check.daemontools[.]cc, a typosquat command-and-control domain registered on March 27, 2026, twelve days before the campaign launch.

The single most consequential element of this disclosure is the targeting profile. Kaspersky observed several thousand attempts to install additional malicious payloads — meaning the trojanized installer reached thousands of machines globally, with most victims in Russia, Brazil, Turkey, Spain, Germany, France, Italy, and China. About 90 percent of infections were on home users; 10 percent on systems running in organizations. But out of those thousands, only about a dozen systems received the second-stage backdoor — government, scientific, manufacturing, and retail organizations specifically in Russia, Belarus, and Thailand. A single Russian educational institution received the third-stage QUIC RAT. The narrow geographic and sectoral selection from a much larger pool of opportunistic infections is the operational signature of cyberespionage, not commodity crime. Kaspersky stops short of attributing this to a specific group, but identified Chinese-language artifacts in the malicious implants. The 2026 supply-chain pattern is now: eScan in January, Notepad++ in February, CPU-Z in April, and Daemon Tools in May.

How a Properly Signed Installer Became a Backdoor

The technical mechanism here is what makes the case operationally significant. Three Daemon Tools binaries — DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe — were modified to carry backdoor code, and all three were re-signed with the legitimate AVB Disc Soft developer certificate. From the perspective of every standard Windows code-signing check, every endpoint protection product that trusts publisher signatures, and every application allow-listing system that trusts "AVB Disc Soft" as a known publisher, these binaries pass. The malicious code itself is implanted in the C runtime environment startup code, meaning the backdoor is active before the application's main logic runs. Each time the operating system loads any of the three trojanized binaries — typically at boot, since they include the bus-service component that initializes virtual drives — the backdoor sends an HTTP GET to env-check.daemontools[.]cc and waits for a command-line response, which is then executed via cmd.exe. The first command is almost always to download and execute the .NET information collector.

Disc Soft has not yet publicly disclosed how the attackers obtained signing capability. Two scenarios fit the available evidence: a compromise of Disc Soft's build pipeline that allowed injection of malicious code before the legitimate signing step, or theft of the signing certificate itself. Either is consistent with what Kaspersky observed. Disc Soft says it identified and resolved the issue within twelve hours of receiving Kaspersky's notification, released clean version 12.6.0.2445 on May 5–6, and is continuing to investigate the root cause and full scope. The company emphasized that paid versions — Daemon Tools Pro and Daemon Tools Ultra — were not affected, and that the Mac version was untouched. Whether the affected certificate has been revoked is not stated in available reporting; defenders should treat re-signed binaries as still-trusted by Windows until certificate revocation propagates.

The Targeting Pattern Says "Cyberespionage," Not "Commodity Crime"

The 90/10 split between home users and organizations is the surface number; the operational story is what happened to that 10 percent. Out of thousands of stage-1 infections across about 100 countries, only about a dozen high-value systems received the second-stage minimalist backdoor — and those systems sit specifically in government, scientific, manufacturing, and retail organizations in Russia, Belarus, and Thailand. The third-stage QUIC RAT was observed on exactly one machine, a Russian educational institution. That kind of selective progression — broad opportunistic distribution funneling down to narrow targeted exploitation — is the canonical pattern of cyberespionage operations. The information collector exists to profile the infected machine and identify which ones are worth investing further attacker resources in. The targeting geography is also notable. Kaspersky's visibility is geographically limited because its software is banned in U.S. public and private sectors and restricted in several other Western nations, so a meaningful fraction of potentially affected machines never appear in its telemetry. The actual victim distribution may differ from what the public reporting reflects.

QUIC RAT itself is technically interesting. It is a C++ implant supporting an unusually broad set of C2 protocols — HTTP, UDP, TCP, WSS, QUIC, DNS, and HTTP/3 — designed to give attackers fallback channels if any individual transport is blocked. It injects payloads into legitimate Windows processes, specifically notepad.exe and conhost.exe, both of which run with normal user privileges and are common enough on Windows endpoints to evade superficial behavioral detection. The choice of QUIC and HTTP/3 as C2 transports is operationally meaningful — these are modern protocols that many enterprise security stacks do not deeply inspect, and HTTP/3 in particular is encrypted and runs over UDP, making both visibility and middlebox-level blocking harder. Kaspersky has not yet published full IOCs for QUIC RAT but has indicated detailed indicators are forthcoming on Securelist. CyberSignal's malware coverage tracks the broader pattern of supply-chain trojan deployments and signed-binary abuse.

The Fourth Supply-Chain Attack of 2026

Kaspersky's framing in the Securelist post is direct: "It has been just four months since 2026 started — and over this short period, we have observed an increasing number of reported supply chain attacks." The cumulative list is now eScan in January, Notepad++ in February, CPU-Z (CPUID) in April, and Daemon Tools in May. Four publicly disclosed code-signing supply-chain attacks against widely-trusted utility software in five months — a once-per-month cadence. Each used the same fundamental technique: legitimate signed installers replaced or modified to carry malicious code, distributed through the vendor's official channels. Each abused the implicit trust that signed-software-from-a-known-publisher carries in enterprise security architectures. And each had operational characteristics that suggest non-trivial sophistication on the attacker side — not opportunistic crews, but actors who can compromise build infrastructure, sign binaries with valid certificates, and operate the C2 infrastructure long enough to extract value from a narrow victim set.

The pattern is uncomfortable for defenders because the canonical mitigations — software bill of materials, signed-installer verification, application allow-listing on trusted publishers — are exactly the controls these attacks render useless. SBOMs do not catch a properly signed binary that has been quietly modified inside the publisher's build pipeline. Allow-listing on AVB Disc Soft, Notepad++ Team, or CPUID Inc. is precisely what gives the attacker's payload its execution privilege. The control that does work is restricting what software is installed on production endpoints in the first place: the smaller the attack surface of trusted publishers, the smaller the supply-chain risk. Disk-imaging utilities and most general-purpose freeware should not be on production systems regardless. The 2026 pattern is the empirical case for tightening that policy.

Defender Actions for Daemon Tools Users and SOC Teams

• Audit your environment for any installation of Daemon Tools Lite versions 12.5.0.2421 through 12.5.0.2434 installed on or after April 8, 2026. If any are found, isolate the host from the network, hunt for compromise indicators, and uninstall the affected version. Install clean Daemon Tools Lite 12.6.0.2445 only if the software is still required; otherwise, remove it.
• Hunt for the three compromised binaries (DTHelper.exe, DiscSoftBusServiceLite.exe, DTShellHlp.exe) outside their expected install path. Hunt for outbound DNS or HTTP requests to env-check.daemontools[.]cc and connections to 38.180.107[.]76. Hunt for the suspicious file paths C:\Windows\Temp\envchk.exe and %AppData%\Microsoft\mcrypto.dat. Hunt for process injection into notepad.exe and conhost.exe — the QUIC RAT signature.
• Specific high-fidelity SOC query: any process spawned by cmd.exe whose parent is one of the three compromised Daemon Tools binaries — particularly during system boot — is a strong detection signal. The CRT-environment persistence hook is unusual enough that legitimate Daemon Tools usage rarely produces this pattern.
• Brief your SOC and IR teams on the 90/10 split. Most affected systems are home users — but some of those home machines belong to staff who later connect to corporate VPN, sync corporate cloud accounts, or are personally-owned devices used for hybrid work. The threat surface extends beyond your formally managed fleet. Consider broadening your hunt to include known-personal-device telemetry where you collect it.
• For broader supply-chain risk: review your software allow-list and tier production-system software-install policy. Third-party utility software not on a critical-need list should be removed from production systems entirely. Code-signing trust is necessary but not sufficient; combine publisher-and-version pairing in your allow-list with active hunting for known-IOC behavior from trusted publishers. Brief executive teams that four code-signing supply-chain events in 2026 are not anomalies — they are a pattern that requires a policy response.

The CyberSignal Analysis

Signal 01 — Code-signing trust is no longer a primary security control

Microsoft's code-signing model — and the ecosystem of enterprise security tools that lean on it — was designed in an era when certificate compromise and build-pipeline injection were rare events involving a handful of high-profile targets like Stuxnet's stolen Realtek and JMicron certificates in 2010. Four publicly disclosed code-signing supply-chain compromises in the first five months of 2026 indicate this is no longer a rare event class. Code-signing should now be treated as one input to a layered security architecture, not as a sufficient trust signal on its own. For CISOs, the practical implication is that allow-listing policy needs to incorporate publisher-and-version pairing rather than publisher-only trust, with active deprecation of older signed versions and active monitoring of signed-binary behavior. The vendor side of this needs work too: certificate revocation propagation is slow, and even a revoked signing certificate may continue to validate on endpoints with stale revocation lists for days. Treat "signed by trusted publisher" as approximately equivalent to "low priority for inspection," not "trusted."

Signal 02 — The 90/10 funnel is the new operational pattern for selective espionage

The Daemon Tools campaign deployed a backdoor to about a dozen high-value targets out of several thousand stage-1 infections — roughly 0.4 percent. That ratio is operationally informative. Attackers are using widely-distributed software as a broad-cast intake mechanism, then triaging the catch with an information collector to identify the small subset of systems worth investing tradecraft in. This is more efficient than direct spearphishing for hard-to-reach targets in countries where outside operators may have limited visibility, and it reduces the signal-to-noise ratio for defensive analytics. The defensive implication is that intake-stage detection — catching the information collector before it produces enough profile data for the attacker to make a triage decision — is more valuable than late-stage detection of the second-stage backdoor. By the time stage 2 is deployed, the attacker has already decided your environment is worth investing in. For SOC teams, this argues for high-fidelity detections on .NET-based information collectors, lightweight beacon traffic from unusual installation directories, and unsigned or freshly-signed binaries spawning child processes via cmd.exe at boot.

Signal 03 — QUIC and HTTP/3 are the new C2 frontier, and visibility is incomplete

QUIC RAT's choice of supported C2 protocols — HTTP, UDP, TCP, WSS, QUIC, DNS, and HTTP/3 — is the technically forward-looking element of the disclosure. QUIC and HTTP/3 are encrypted, run over UDP, and are designed to be opaque to network middleboxes. Most enterprise security stacks do not currently inspect HTTP/3 traffic with the same depth they apply to TLS-over-TCP, and many DNS-over-QUIC and DNS-over-HTTPS deployments specifically resist inspection by design. As legitimate web traffic transitions to HTTP/3 — currently around 30 percent of large-CDN traffic and growing — the cover-traffic environment for HTTP/3 C2 channels is improving rapidly. Defenders running on traditional packet-inspection or TLS-terminating proxy stacks should plan for explicit HTTP/3 support in their network monitoring within the next 12 to 18 months. QUIC RAT is unlikely to be the last malware family to choose HTTP/3 as its preferred transport; expect this to be the new standard for C2 in serious operations within the next two to three years.

Sources