CCOA (ISACA): Zero-Detection Document, Dead Domain

No. Both observations have innocent explanations that say nothing about execution.

0/63 is content reputation for a two-day-old document from a single submission. Macro documents are trivially re-obfuscated, so a unique hash with zero detections is the normal shape of targeted mail, not an exoneration. NXDOMAIN means the name does not resolve today - takedown, sinkhole, rotation to a new domain, or infrastructure not yet live. From DNS alone, a failed beacon and a macro that never ran look identical.

Check in this order:

1. Process tree in EDR: did WINWORD.EXE spawn certutil, regsvr32, mshta or powershell, and does the timestamp match the file-open time? A 24-hour window proves nothing if the document was opened last week - widen to 30 days.
2. Execution artefacts: Prefetch and Amcache for regsvr32, existence of %TEMP%\a.txt, and SRUM bytes attributed to regsvr32 or certutil.
3. Proxy and firewall logs, not just DNS. The proxy resolves names independently of your internal resolvers and may hold the only record of the request.
4. Where the macro could have run: PowerShell 4104 script blocks, and whether Protected View was ever exited. If Protected View was never dismissed and no 'Enable Content' occurred, the macro did not execute.

Report it as 'no evidence of execution in available telemetry', not 'did not execute'. The difference is the whole point.

Scope from the mail side first. The endpoint is one host; the mail path is where the other recipients are.

Email scoping: query the mail gateway and journal for the sender address, subject pattern, attachment SHA-256 and SMTP Message-ID. The document name carries a sequence number (4471), so hunt the naming pattern rather than the exact filename - the next one will be 4472. Note that SPF, DKIM and DMARC all passed: that means the supplier's own mailbox is compromised and every recipient in that thread is in scope. That fact alone should trigger a call to the supplier.

Endpoint detection, behavioural because the hash is worthless:

• Office applications spawning certutil, regsvr32, mshta or powershell (parent-child anomaly).
• regsvr32 with /i:http, /i:https, scrobj.dll, or a scriptlet in %TEMP%.
• certutil with -urlcache, -decode or -split.
• A .txt or .dat written to %TEMP% and then loaded by regsvr32 or rundll32.

Hunt these across 30 days estate-wide. Expect the parent-child rule to fire on legitimate admin scripts; tune by requiring the Office parent, not by excluding regsvr32 - squiblydoo depends on regsvr32 being normal.

Do not close the case because one endpoint scanned clean. The sender's contact list decides the blast radius, not the EDR console.

Rank by what survives the adversary's next move, not by how technical the indicator looks.

1. Behavioural pattern - highest. Word spawning certutil urlcache, then regsvr32 /i:http with scrobj.dll. This is tradecraft, not infrastructure. It will reappear next week with a different domain and a different hash, and it is the only indicator you can hunt retroactively across existing telemetry.
2. Email artefacts - sender address, Message-ID, subject, attachment naming pattern. These find the other recipients, which the hash cannot, and they support the supplier-compromise notification.
3. Domain cdn-metrics[.]top - medium and already decaying. Worth a watchlist entry and a proxy block for retro-hunting and intel sharing, but it is NXDOMAIN, so the block catches nothing today and the actor rotates shortly.
4. File hash 0/63 - lowest for blocking, still useful for retro-match. It identifies exactly one document and nothing else. Its value is confirming that the same file reached other mailboxes.

Put this sentence in the report: 'hash-based blocking provides no protection against this campaign because the sample is unique and undetected; detection must be behavioural.' Without it, someone will write 'blocked the hash, case closed' into the ticket and the next variant will land cleanly - with a new hash, on a new domain, against the same supplier relationship.