What do defenders get wrong about detecting SPN scanning in Active Directory?

A common mistake is assuming standard alerting will catch SPN scanning quickly. In practice, attackers often use legitimate AD and Kerberos functions, so defenders need behavioral signals such as unusual LDAP or Kerberos activity, non-routine service account usage, and repeated SPN lookups from the same source. Detection depends on patterns, not a single obvious indicator.

Why This Matters for Security Teams

SPN scanning is easy to miss because it often looks like ordinary directory activity until the attacker starts turning enumeration into privilege escalation. In active directory, service principal names are a map of reachable services, so repeated lookups can reveal high-value targets, service accounts, and opportunities for Kerberos abuse. Defenders who wait for a single high-confidence alert usually learn too late that the traffic was valid authentication machinery being used offensively. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is exactly why SPN-focused activity blends into routine identity noise.

Modern detection must treat SPN scanning as an identity-behaviour problem, not just a network problem. That means correlating LDAP queries, Kerberos ticket requests, account context, host role, and timing. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need for continuous monitoring rather than periodic review. In practice, many security teams encounter SPN scanning only after lateral movement has already begun, rather than through intentional detection design.

How It Works in Practice

Defenders get better results when they watch for patterns that indicate reconnaissance, not just compromise. SPN scanning typically appears as repeated LDAP searches for service principal attributes, bursts of Kerberos-related requests, or a sequence of lookups from a source that does not normally perform directory inventory. The important detail is context: a domain controller, management server, or identity sync host may generate similar activity for legitimate reasons, while a workstation or odd service account doing the same work is far more suspicious.

Useful detections usually combine several signals:

• Repeated SPN queries from one host over a short period
• Unusual service account usage from non-standard endpoints
• Kerberos activity that does not match the account’s normal workload
• Directory searches outside business-hours or outside change windows
• New sources querying many service objects across multiple OUs

This is also where identity governance matters. The NHI Lifecycle Management Guide is relevant because service accounts, key material, and delegated privileges should already be known and bounded. When defenders can distinguish expected service account behaviour from abnormal discovery behaviour, they can flag the scanning phase before ticket abuse or lateral movement begins. The CISA cyber threat advisories also remain useful for mapping these reconnaissance patterns to known attacker tradecraft. These controls tend to break down in large enterprises with many legitimate automation systems because the baseline itself is noisy, distributed, and poorly documented.

Common Variations and Edge Cases

Tighter detection often increases false positives, requiring organisations to balance visibility against analyst workload. That tradeoff is real in Active Directory environments where patch tools, identity sync jobs, vulnerability scanners, and SSO integrations can all generate directory lookups that resemble SPN enumeration. Current guidance suggests treating “known noisy” systems as a baseline problem rather than exempting them entirely.

Edge cases matter. Attackers may slow SPN scanning to avoid threshold-based alerts, spread queries across multiple hosts, or use compromised service accounts that already have routine directory access. In those cases, static rules tied to a single event type are weak. Better practice is evolving toward correlation across host identity, source subnet, query volume, and downstream Kerberos use. For deeper background on how SPN abuse fits into broader identity compromise paths, the Top 10 NHI Issues page is a useful companion reference, especially when service account hygiene and credential exposure are already weak.

Defenders should also be cautious about assuming every SPN lookup is malicious. The better question is whether the source, cadence, and target set are consistent with the account’s normal role. In environments with delegated administration, cross-domain trusts, or third-party identity tooling, this guidance becomes harder to apply because the “normal” pattern is broader than most alert logic expects.

Related resources from NHI Mgmt Group

• What do security teams get wrong about blocking policies in Active Directory?
• What do security teams get wrong about Active Directory synchronization?
• What do security teams get wrong about hybrid Active Directory governance?
• What do security teams get wrong about privileged access reviews in Active Directory?