Code-Signing Trust Crisis: GoldenEyeDog's CylindricalCanine and the DigiCert Breach
We all saw the headline about Expel attributing the April 2026 DigiCert incident to "CylindricalCanine," a subgroup of the notorious GoldenEyeDog (APT-Q-27). While the gambling and gaming focus is interesting, the technical implication of code-signing certificate theft is what keeps me up at night.
If they have valid certs, standard trust chains—like Microsoft SmartScreen and default AppLocker rules based on publisher—are effectively bypassed. We can't just block DigiCert, so we need to pivot to granular auditing.
I'm currently scripting a check to validate specific certificate serial numbers against our known baseline. Here is a quick snippet to scan a directory for files signed by a specific issuer and flag them if the serial number isn't on your allowlist:
$targetPath = "C:\Program Files\SomeVendor"
$allowedSerials = @("1234567890", "0987654321") # Replace with known good serials
Get-ChildItem -Path $targetPath -Recurse -Include *.exe, *.dll | ForEach-Object {
$sig = Get-AuthenticodeSignature $_.FullName
if ($sig.SignerCertificate.Issuer -like "*DigiCert*") {
if ($sig.SignerCertificate.SerialNumber -notin $allowedSerials) {
Write-Warning "Untrusted Serial Found: $($_.FullName) - Serial: $($sig.SignerCertificate.SerialNumber)"
}
}
}
This doesn't replace a proper EDR, but it helps identify anomalies before they execute if the serials are published. Given the sophistication of APT-Q-27, I suspect they'll use these certs to sign loaders that look like legitimate gaming utilities.
Is anyone else shifting their AppLocker policies from "Publisher" to "Hash" or "Path" specific rules in light of this, or is that too operationally heavy?
Shifting entirely to Hash/Path rules is a management nightmare for larger environments, but we've started implementing a hybrid approach. We keep Publisher rules for major vendors (Microsoft, Adobe) but enforce stricter 'Deny' lists for specific serials we flag in threat intel feeds.
Also, make sure your Sysmon config is actually catching the signature changes. This KQL query has been helpful for us in Sentinel to spot binaries with the DigiCert issuer that appeared recently:
DeviceProcessEvents
| where SigningStatus == "Valid"
| where Issuer contains "DigiCert"
| where Timestamp > ago(7d)
| summarize count() by SHA1, FolderPath, AccountName
The tricky part with CylindricalCanine isn't just the certificate theft, it's their targeting of the gaming sector. They often bundle these signed binaries with game cheats or overlays, effectively social-engineering the user into accepting the SmartScreen override.
We've started adding specific gaming directories to our exclusion scans for endpoints, just to monitor for dropped payloads that shouldn't be there. If you have a lot of remote workers, validating the CRL (Certificate Revocation List) distribution points is critical right now—if the attacker can disrupt CRL checking, they can reuse those certs indefinitely.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access