DAEMON Tools Supply-Chain Compromise (Apr 8 – Ongoing), What to Do If You Installed It

Kaspersky GReAT disclosed today that the official installers for DAEMON Tools, a widely used Windows disk-image-mounting utility published by AVB Disc Soft, have been distributing malware since April 8, 2026, signed with the legitimate AVB Disc Soft Authenticode certificate and served directly from the vendor's primary domain. Kaspersky identified versions 12.5.0.2421 through the then-current 12.5.0.2434 as compromised, with three binaries inside each install (DTHelper.exe, DiscSoftBusServiceLite.exe, DTShellHlp.exe) modified to launch a backdoor at every machine startup. The campaign affected thousands of machines across more than 100 countries, with about 10% of infections in business or organizational environments. Kaspersky compares the sophistication and undetected duration to the 2023 3CX supply-chain attack, and flags Chinese-language artifacts in the implants while declining to attribute the campaign to a specific actor. Kaspersky has notified AVB Disc Soft. The campaign is reported as still active at time of Kaspersky's writeup (May 5).

Framing note: this is not a vulnerability in DAEMON Tools as software; it is a compromise of the vendor's official binary distribution and code-signing trust chain. There is no CVE. The response is detection, host triage, and reimaging where warranted, not patching. AVB Disc Soft has not, at time of writing, issued a public advisory, named a clean-version cutoff, or announced a signing-cert rotation.

Priorities, by environment

How to triage this depends on whether DAEMON Tools is in your environment at all, who installed it, and what that host could reach. The compromise is not a transitive dependency problem like the npm/PyPI campaigns of April; the affected population is "people who deliberately downloaded DAEMON Tools from the official vendor site between April 8 and now."

Categorization source: Bulletin's framing based on Kaspersky's victimology breakdown. Targeting bands reflect Kaspersky's reported sector / geography distribution of stage-two payloads, not a Kaspersky-issued priority schema.

Am I affected?

Quick checks (Windows, PowerShell, run as admin)

Is DAEMON Tools installed at all? Check both 64-bit and WOW6432Node uninstall hives, since the registered uninstall entry can land in either depending on installer type:

$uninstall = @(
  "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
  "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

Get-ItemProperty $uninstall -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName -like "*DAEMON Tools*" } |
  Select-Object DisplayName, DisplayVersion, InstallDate, InstallLocation

InstallDate can be missing, stale, or formatted inconsistently across installers, so don't rely on it alone. Use file timestamps and embedded version metadata as well:

$paths = @(
  "C:\Program Files\DAEMON Tools Lite\DTHelper.exe",
  "C:\Program Files\DAEMON Tools Lite\DiscSoftBusServiceLite.exe",
  "C:\Program Files\DAEMON Tools Lite\DTShellHlp.exe"
)

Get-Item $paths -ErrorAction SilentlyContinue |
  Select-Object FullName, CreationTime, LastWriteTime,
    @{n="ProductVersion"; e={$_.VersionInfo.ProductVersion}},
    @{n="FileVersion";    e={$_.VersionInfo.FileVersion}}

Get-Item $paths -ErrorAction SilentlyContinue |
  Get-FileHash -Algorithm SHA1

Compare the installer hash (if you still have the installer) and the DiscSoftBusServiceLite.exe SHA-1 against Kaspersky's published IOCs — these are the two classes for which Kaspersky enumerated multiple known-bad hashes. For DTHelper.exe and DTShellHlp.exe, Kaspersky does not appear to have published full per-version SHA-1 coverage in the public IOC list, so a non-match for those two binaries is not by itself sufficient to clear the host. A known-clean pre-April-8 baseline from your golden image, an unaffected machine in the same fleet, or a clean snapshot is the more reliable comparison for those files. If the version is in the affected range and the install or update happened on or after April 8, treat the host as suspect regardless of the per-binary hash result.

Beacon artifacts — historical first. Live lookups should not be your first move; they can interact with attacker infrastructure or sinkholes and they tell you nothing about whether the host beaconed earlier. Check, in this order: DNS server logs, proxy logs, firewall logs, EDR network telemetry, and SIEM for connections to env-check.daemontools[.]cc or 38.180.107[.]76 at any point on or after April 8. Then, on the host itself, inspect the local DNS resolver cache:

Get-DnsClientCache |
  Where-Object { $_.Entry -like "*daemontools.cc*" -or $_.Name -like "*daemontools.cc*" }

Get-NetTCPConnection -State Established |
  Where-Object { $_.RemoteAddress -eq "38.180.107.76" }

An empty result is not exonerating — the cache only shows recent entries and the active-connection list is a snapshot. Historical telemetry from your network and EDR stack is the authoritative signal.

Dropped-payload presence:

Get-ChildItem `
  "C:\Windows\Temp\envchk.exe", `
  "C:\Windows\Temp\cdg.exe", `
  "C:\Windows\Temp\imp.tmp", `
  "C:\Windows\Temp\piyu.exe", `
  "C:\Windows\Temp\crypto.dll", `
  "C:\ProgramData\Microsoft\mcrypto.chiper", `
  "$env:APPDATA\Microsoft\mcrypto.dat" `
  -ErrorAction SilentlyContinue

Any hit here is high-confidence compromise, not just "exposed installer." Note that the loader cleans up after itself in observed command sequences (del %TEMP%\cdg.exe and similar), so live filesystem absence does not rule out historical execution — pivot to EDR process telemetry and command-line logging if you have it.

Response, if a host installed an affected version on or after April 8

1. Isolate the host. Pull it off the network or restrict outbound traffic to your forensic-collection path only. Do not uninstall yet — uninstalling DAEMON Tools may wipe artifacts you want for triage. If you are not running formal IR, snapshot the affected files first (DTHelper.exe, DiscSoftBusServiceLite.exe, DTShellHlp.exe, plus any matches from the dropped-payload check) to a separate location for hash and scanner verification.
2. Identify the scope of credential exposure. For the overwhelming majority of observed infections the first-stage payload is the info-stealer (envchk.exe), which collects process list, software list, hostname, MAC, DNS domain, and locale — not credentials directly. But the host has been running attacker code with elevated privileges since first boot after install. Treat as exposed: any credential cached in browsers, cloud-CLI configs (%USERPROFILE%\.aws, .azure, .config\gcloud, .kube), SSH keys (%USERPROFILE%\.ssh), VPN client profiles, Git credential manager, password manager auto-unlock state, and any tokens in %APPDATA% for tools the user runs. Rotate them. If the host had domain credentials, treat the AD account as suspect and follow your standard credential-theft response (force password change, audit Kerberos / NTLM artifacts, review for lateral movement).
3. Run a full EDR / AV scan with current signatures. Kaspersky's products detect this campaign by name; Microsoft Defender, Sophos, and other major vendors should pick it up within hours of the public Securelist post if not already. For organizations: feed the SHA-1 hashes from the IOC block into your EDR's custom-IOC mechanism so detection does not wait on the vendor's own signature ship cycle.
4. Hunt for the second-stage backdoor and QUIC RAT. Even on hosts where the first-stage info-stealer was the observed payload, check for second-stage artifacts: presence of cdg.exe / piyu.exe in %TEMP%, presence of mcrypto.chiper / mcrypto.dat under ProgramData\Microsoft or APPDATA\Microsoft, rundll32 invocations against unusual DLLs (especially ones with mcrypto_clean as the export), and process injection into notepad.exe or conhost.exe (the QUIC RAT's documented injection targets). Hunt your EDR telemetry, not just live state — the loader cleans up after itself (del %TEMP%\cdg.exe etc. are present in the observed command sequences).
5. Block the campaign infrastructure. At your egress proxy, DNS resolver, or firewall: env-check.daemontools[.]cc and 38.180.107[.]76. The legitimate vendor domain is daemon-tools[.]cc — note the typosquat is without the hyphen, the legitimate one has it. Allowlist by string match risks blocking the wrong one.
6. Uninstall DAEMON Tools and clean residual drivers. After artifact preservation, uninstall via Apps & Features. DAEMON Tools installs low-level virtual-drive drivers that Windows may retain after uninstall — clean them up via sc query type= driver for Disc Soft service names and sc delete any that remain. Reboot. Do not reinstall DAEMON Tools (or any AVB Disc Soft / Disc Soft Ltd. product) until the vendor publishes a clean build, explains the remediation, and clarifies the status of its build pipeline and signing certificate. If the workflow that relied on DAEMON Tools cannot wait, evaluate alternatives (Windows native ISO mounting via Mount-DiskImage on Windows 8+, OSFMount, WinCDEmu) for the interim.
7. Reimage where the host's role warrants it. For any host that handled corporate credentials, source control, production access, or sensitive data: wipe and rebuild from known-clean media. Targeted second-stage payloads, including the QUIC RAT, are not fully enumerated in public reporting yet — Kaspersky's analysis is ongoing. Don't try to clean piecewise on a host whose role makes residual compromise expensive.
8. Audit your software-acquisition policy. DAEMON Tools is a useful prompt to ask: which "signed by a known vendor" desktop tools are in your environment that are not centrally managed? Disk-image emulators, screen-capture tools, ISO writers, USB-creation utilities, download managers, and similar utilities frequently arrive on workstations via individual user installs from vendor sites. They run with administrative privileges, are usually excluded from EDR allowlists (because they're signed by their publisher), and rarely appear in centrally tracked software inventory. This compromise pattern works against any of them.
9. Document the rotation and timeline. Standard incident hygiene: record which credentials were rotated, which hosts were reimaged, and when. Given the targeted second-stage activity (gov / sci / manufacturing / retail in specific geographies), additional Kaspersky or partner reporting may surface in the coming weeks; you want the timeline reconstructable.

The broader pattern

A few observations worth flagging in the context of this Bulletin's recent series:

First, this is the second model of supply-chain compromise in the same window as the npm / PyPI campaigns ("Mini Shai-Hulud" and the Bitwarden CLI / xinference / Lightning / Lovable / Vercel / Checkmarx run). The npm/PyPI campaigns hijacked package-registry distribution; this one hijacked vendor-direct binary distribution. The defense surface is different: package-pinning, lockfile hygiene, and registry-side malware scanning don't apply here. EDR allowlists and Authenticode trust did apply — and were circumvented by signing the malware with the legitimate publisher cert.

Second, Kaspersky's "fourth supply-chain attack of 2026" framing (eScan in January, Notepad++ in February, CPU-Z in April, DAEMON Tools in May) is a real acceleration. The targeting overlap between this campaign and the others is unclear, but the operational tempo is what operators should plan against: at least one publicly disclosed vendor-distribution compromise per month, none of them detectable by package-registry hygiene.

Third, the two-stage targeting — wide info- stealer net, narrow second-stage backdoor on selected hosts — is a tradecraft pattern operators should recognize. Most affected machines see only fingerprinting; targeted second- stage activity is reserved for hosts that look interesting after the profile comes back. If your environment does not look like an obvious target geography or sector, you may be in the broad group regardless of how interesting your data is to the right adversary. "We didn't see a backdoor get deployed" is not the same as "we weren't compromised."