Signed, Delivered, Compromised
DAEMON Tools installers downloaded from the official website between April 8 and May 5 were backdoored — signed with the developer's own certificate, distributed through the legitimate domain, and undetected for nearly a month. Here's how the trust model that code signing is built on became the attack's primary weapon.
On April 8, 2026, anyone who downloaded DAEMON Tools Lite from the official website got more than a disk image utility. The installers had been modified — three core binaries replaced with trojanized versions — and every one of them carried a valid digital signature from AVB Disc Soft, the software's developer. The attack ran undetected for nearly a month. Kaspersky disclosed it publicly on May 5.
This is a supply chain attack, and the signature is not incidental to how it worked. It was the mechanism.
What Code Signing Is Supposed to Do
When you run a Windows executable, the operating system can check whether it carries a valid Authenticode signature — a cryptographic seal produced by the developer using a private key tied to a certificate issued by a trusted Certificate Authority. If the seal checks out, Windows displays "Verified publisher: [developer name]" in the UAC prompt. If it doesn't, you get a warning.
The guarantee code signing actually provides is narrow: the binary has not been modified since the developer signed it. That's it. Signing proves integrity and identity at the moment of signing. It says nothing about what the binary does.
In practice, that narrow guarantee is widely misread as a broader one. Users and security tools treat a valid signature as a meaningful signal of safety. Windows Defender and most endpoint protection products apply lower scrutiny to signed binaries from known publishers. Enterprise allowlisting policies frequently permit signed software without further inspection. This is rational behavior given that the vast majority of signed software is safe — but it creates a specific failure mode when the signing process itself is compromised.
What Actually Happened
AVB Disc Soft confirmed in a statement published on May 7 that their build environment had been compromised. The attackers reached the infrastructure where software is compiled and packaged, and modified three binaries before they were signed: DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe. The resulting installers were then signed using the legitimate developer certificate and pushed to the official download site as normal releases.
This is the worst-case variant of a supply chain attack. The attackers did not steal the signing certificate and apply it themselves. They inserted their code upstream of the signing step, so the certificate was applied to their modified binaries by the developer's own build process. The signature is genuine. There is no forgery to detect.
The command-and-control domain — env-check.daemontools[.]cc — was registered on March 27, twelve days before the first trojanized build appeared. The attackers had already built their infrastructure before touching the build environment.
What the Payload Does
Each of the three modified binaries activates at system startup. On first execution, the malware sends an HTTP GET request to the C2 domain and receives a shell command executed via cmd.exe. That command downloads two payloads: envchk.exe, a .NET-based information collector that gathers the machine's hostname, MAC address, DNS domain, language settings, running processes, and installed software list; and cdg.exe, a shellcode loader that decrypts and launches a minimalist backdoor capable of downloading additional payloads, running shell commands, and executing shellcode in memory.
For a small subset of targets — Kaspersky identified just over a dozen machines, primarily in government, scientific, manufacturing, and retail organizations in Russia, Belarus, and Thailand — the C2 responded with a more sophisticated implant: QUIC RAT, a full remote access trojan that communicates over multiple protocols and injects payloads into legitimate Windows processes (notepad.exe and conhost.exe) to hide its activity.
Most infected machines — the majority being home users — receive only the initial information collector. The collector's output is what determines whether a target receives the advanced payload — the C2 evaluates what it's looking at before committing to a deeper intrusion. Kaspersky assessed the campaign as targeted, with Chinese-speaking threat actor artifacts identified in the malicious implants.
Why It Went Undetected for a Month
Three factors combined. First, the signature: signed binaries from a known publisher are treated as lower risk by endpoint tools, and the DAEMON Tools certificate had no prior history of misuse. Second, the C2 domain was constructed to look plausible — env-check.daemontools[.]cc is a typosquat of the legitimate domain, and a routine HTTP GET to what looks like a software environment check is the kind of traffic that blends into normal post-installation behavior. Third, the initial payload is passive: it collects information and waits. It doesn't encrypt files, exfiltrate bulk data, or do anything that would trigger behavioral alerts in a standard EDR configuration.
The combination of a clean signature, a plausible domain, and a low-noise first stage is exactly the profile of an operation designed to survive initial detection and wait for a human to decide which targets are worth pursuing further.
The Pattern Behind This Attack
This is the fourth supply chain compromise Kaspersky has investigated in 2026 alone, following eScan in January, Notepad++ in February, and CPUID in April. The same logic runs through all four: widely used, broadly trusted software, with an installer that gets executed with elevated privileges as a normal part of setup. Disk emulation software is a precise target — DAEMON Tools routinely receives administrative privileges because mounting virtual drives requires kernel-level access. The malware inherits those privileges at first startup.
The 3CX supply chain attack in 2023 ran undetected for a similar duration. SolarWinds in 2020 went undetected for months. All three targeted the trust infrastructure software distribution relies on. Users and organizations extend implicit trust to software they download from official domains. Attackers are systematically working out how to make that trust work against them.
What to Do
If DAEMON Tools Lite was installed between April 8 and May 5, 2026 (versions 12.5.0.2421 through 12.5.0.2434), treat the machine as compromised. The clean version is 12.6.0.2445, released May 6.
Check for the presence of envchk.exe, cdg.exe, and cdg.tmp in temporary directories. Look for outbound connections to env-check.daemontools[.]cc. Audit PowerShell execution logs for unusual download activity. Monitor for code injection into notepad.exe or conhost.exe. On organizational networks, isolate affected machines before remediation.
The broader takeaway is not to stop using signed software — the signature still provides what it has always provided. The takeaway is to stop treating a valid signature as a proxy for behavioral safety. Signed and safe are not the same thing. They never were.
For a related read on how attackers chain privilege escalation once inside a Linux host, the Copy Fail and Dirty Frag mechanics are covered in depth here.