DAEMON Tools Supply Chain Attack: Official Installers Compromised
Just saw the report from Kaspersky researchers Igor Kuznetsov, Georgy Kucherin, and Leonid regarding a concerning supply chain attack targeting DAEMON Tools.
It appears the official installers distributed from the vendor's legitimate website have been tampered with to serve a malicious payload. The most dangerous aspect here is that these binaries are signed with valid digital certificates belonging to the DAEMON Tools developers. This effectively bypasses standard trust validations that rely solely on certificate checking.
Technical Breakdown
- Vector: Supply chain compromise (build infrastructure or distribution server).
- Affected: Official DAEMON Tools installers.
- Signed: Yes (Valid developer certificates).
If you have DAEMON Tools in your environment, I recommend verifying file hashes immediately against known-good values. While we wait for specific IOCs (hashes) to drop, you can run a quick check on the signing certificate validity chain or recent install dates using this PowerShell snippet to flag recent installs:
Get-ChildItem "C:\Program Files\DAEMON Tools" -Recurse -Filter *.exe |
Get-ItemProperty |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } |
Select-Object FullName, LastWriteTime, VersionInfo
This is a stark reminder that "Signed by Trusted Publisher" doesn't always mean "Safe" if the signing infrastructure is owned.
Question: For those managing endpoints with AppLocker or similar SRPs, are you enforcing path-based rules or hash-based rules for utilities like this? Path-based won't stop a replaced binary, and hash-based is a management nightmare for frequent updates. How are you handling this trust gap?
We moved away from DAEMON Tools years ago precisely because of the adware/bloatware issues that plagued the free versions, shifting to built-in Windows mounting or open-source alternatives like WinCDEmu. This attack justifies that paranoia. For those who can't deprecate it immediately, I'd suggest blocking execution via AppLocker using a publisher rule that specifically enforces the specific thumbprint of the previous trusted certificate, assuming the attackers generated a new cert or the old one was revoked/compromised.
From a SOC perspective, we're hunting for this by looking for the parent-child process chains. The malicious loader usually spawns a shell or a LOLBin (Living Off The Land binary). Keep an eye out for daemon.exe spawning powershell.exe or cmd.exe with network connections.
Here is a basic KQL query for Sentinel users to hunt unusual child processes:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "daemon.exe"
| where FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe")
| project Timestamp, DeviceName, InitiatingProcessCommandLine, FileName, CommandLine
Does anyone have the specific hash ranges or version numbers affected yet? Kaspersky's post mentions the installers are malicious, but I need to know if it's the Pro version or Lite version. I have a few dev teams that rely heavily on this for mounting legacy ISOs. I'm tempted to pull it from the software repository entirely until the vendor posts a clean build, but I need confirmation on scope.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access