A blind spot that recurs across financial-sector monitoring programs is deceptively small: a well-documented, low-cost detection for a common credential-theft technique that quietly falls out of coverage and stays missing. The rule itself is trivial. Why it goes absent, and why it tends to stay absent in otherwise mature environments, is the more instructive part.

This piece publishes the rule, walks through the operational reasons monitoring programs commonly lose it, and lays out how to close the gap before an adversary comes to rely on it.

1. The rule

title: NTDS Access via VSS Shadow Copy
logsource: { product: windows, service: security }
detection:
  selection:
    EventID: 4656
    ObjectName|endswith: '\NTDS\NTDS.dit'
  condition: selection

Two lines. A handle request against NTDS.dit, the Active Directory database on a domain controller, is rarely legitimate outside of backup and maintenance windows, and it is a strong early signal of an attempt to extract every domain credential at once. The underlying audit event has been part of Microsoft's recommended baselines for years, yet across the industry this detection is one of the more commonly absent, even in well-resourced security operations.

2. Why it goes missing

The pattern behind the gap is almost always operational rather than technical. Object-access auditing on high-value targets can be noisy: EventID 4656 fires on far more than credential theft, and a frequent response is to filter or silence the channel to reduce alert volume in the SOC. That suppression tends to outlive the engineer who introduced it. Documentation of why the channel was muted is thin, tuning notes are lost to staff turnover, and after a few years no one on the team remembers the detection was ever expected to exist. The rule doesn't fail, it is quietly deprecated by attrition.

3. Why it matters

Access to NTDS.dit, whether via a Volume Shadow Copy, a raw disk read, or DCSync-style replication, is a precursor to full domain compromise. Where this telemetry is present and alerting, activity consistent with credential-database extraction surfaces early, inside the window where a responder can still contain it. Where it is absent, the same activity can proceed through the noisiest, most detectable phase of an intrusion without generating a single signal, extending dwell time and handing an adversary the keys to the directory before anyone is aware.

4. How to close it

Closing the gap is mostly a matter of coverage hygiene rather than new tooling:

  • Confirm the detection actually exists in your SIEM and is firing, test it, don't assume the baseline is intact.
  • Where noise was the original problemtune the rule (scope to domain controllers, allowlist known backup service accounts and maintenance windows) rather than silencing the channel outright.
  • Give every suppressed or muted detection a sunset date, a named owner, and a recurring review, a muted rule with no owner is a rule already on its way out.
  • Pair the object-access signal with adjacent telemetry, VSS creation, suspicious use of ntdsutil or vssadmin, and directory-replication requests from non-DC hosts, so a single tuning decision can't blind the whole detection.

5. The lesson is not really about the rule

It is about institutional memory. A two-line detection is easy to write and easy to lose, and the environments that lose it are rarely the ones with the weakest tools, they are the ones without a process for remembering why a control was there in the first place. Every silenced detection needs a sunset date, an owner, and a scheduled review, or it becomes exactly the kind of gap an adversary is counting on.