DAEMON Tools Supply Chain: Mitigating Validly Signed Malware
Hey everyone,
Just saw the Kaspersky report regarding the DAEMON Tools supply chain attack. It’s a classic nightmare scenario: the malware is being distributed directly from the official website and is signed with valid digital certificates belonging to the vendor. This effectively bypasses standard trust validations like checking for a valid publisher certificate.
Since the installers are signed, traditional allowlisting based solely on publisher reputation might fail here. If your environment uses DAEMON Tools—often seen in dev or gaming setups—you need to look beyond the certificate validity.
I've updated our hunting queries to look for anomalies in child process creation from the installer. Here is a KQL snippet I'm using to spot unsigned processes spawned by the signed DAEMON Tools binaries, which is a strong indicator of the payload unpacking:
DeviceProcessEvents
| where Timestamp > ago(3d)
| where InitiatingProcessFileName =~ "DTLite.exe" or InitiatingProcessFileName =~ "DAEMONTools.exe"
| where InitiatingProcessVersionInfoCompanyName =~ "Disc Soft Ltd."
// Check for unsigned child processes
| where isnull(SignerCertificateIssuer)
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessCommandLine, SHA256
For immediate remediation, we are blocking the specific hash indicators provided by Kaspersky at the perimeter.
How is everyone else handling the verification of signed binaries when the vendor's own infrastructure is compromised? Are we moving toward hash-allowlisting for everything?
Solid query. The signed binary issue is a huge pain point. We've started implementing a policy where we monitor for any network connections initiated by installers immediately post-execution.
You can use this PowerShell snippet to verify the signer status on a specific file if you are doing manual triage:
Get-AuthenticodeSignature "C:\Path\To\suspicious.exe" | Select-Object Status, SignerCertificate
If the status is 'Valid' but the behavior is malicious, you know you have a supply chain issue on your hands.
We actually deprecated DAEMON Tools a few years ago in favor of the native ISO mounting capabilities in Windows 10/11. It removed a massive attack surface and reduced the 'adware/bloat' complaints from users.
For those stuck with legacy requirements, I'd suggest checking the file version details against the official release notes. The malicious installers in this campaign often have version strings that don't match public release notes.
From a pentester's perspective, abusing valid certs is the ultimate evasion technique. It forces defenders to analyze behavior rather than just trust.
I'd add that you should also be looking for persistence mechanisms. This specific payload drops a DLL in C:\ProgramData\ often disguised as a system update. You can hunt for it with:
# On Linux systems analyzing mounted Windows shares
find /mnt/shares/ProgramData -name *.dll -mtime -2 -exec ls -la {} \;
Stay sharp out there.
Valid certs are tricky, but they aren't forever. Ensure your endpoints are strictly checking Online Certificate Status Protocol (OCSP) or CRLs. These keys often get revoked rapidly after disclosure. You can manually inspect a suspicious file with PowerShell to verify the signing chain status.
Get-AuthenticodeSignature "path\to\installer.exe" | Select-Object Status, SignerCertificate
Combine this with strict hash-based allowlisting for the specific DAEMON Tools versions identified in the report.
Relying solely on publisher reputation is risky in these scenarios. If you cannot deprecate the tool immediately, consider tightening your application control policies by combining publisher rules with specific file hash allowlisting.
This ensures that even if a new, validly signed version is compromised, your environment will only execute the specific vetted hash. You can quickly generate the hash for your allowlist using PowerShell:
Get-FileHash .\DTSetup.exe -Algorithm SHA256
This creates a layered defense against supply chain injection.
To expand on CISO_Michelle's suggestion, strictly coupling publisher rules with file versioning is effective. However, for critical tools like this, I prefer "Trust on First Use" (TOFU). Baseline the SHA256 hash of the last known good version and alert on any deviation. Even if signed, a modified binary fails the hash check.
Here is a simple PowerShell verification script you can schedule:
$allowedHash = "INSERT_KNOWN_SHA256"
$fileHash = (Get-FileHash -Path ".\DTLite.exe" -Algorithm SHA256).Hash
if ($fileHash -ne $allowedHash) { Write-Error "Integrity Check Failed" }
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access