SPN Scanning

SPN scanning is reconnaissance in which an attacker enumerates Service Principal Names in Active Directory to find service accounts and high-value services. The goal is usually to identify targets for Kerberoasting, privilege escalation, or lateral movement. The activity is often subtle because it uses normal directory query behavior.

Expanded Definition

SPN scanning is the deliberate enumeration of Service Principal Names in Active Directory to map service-linked identities, discover exposed application endpoints, and identify accounts that are likely to support Kerberoasting or privilege escalation. In NHI security, it matters because SPNs frequently point to service accounts that are more privileged, less monitored, and less frequently rotated than human identities. That makes the activity useful to attackers and a priority signal for defenders.

Definitions vary across vendors and red-team playbooks, but the practical meaning is consistent: an operator is querying directory metadata to build a target list, not yet exploiting a credential. It sits adjacent to reconnaissance, service account discovery, and credential-access preparation, and it often precedes password attack paths rather than triggering them directly. For governance teams, the right lens is asset visibility, credential exposure, and permission scope, not just authentication events. NIST Cybersecurity Framework 2.0 helps frame this as an identification and protection problem tied to directory hygiene and least privilege.

The most common misapplication is treating SPN scanning as harmless directory traffic, which occurs when unusual enumeration patterns are not separated from normal administrative queries.

Examples and Use Cases

Implementing detection and response for SPN scanning rigorously often introduces alert volume and tuning overhead, requiring organisations to weigh visibility into attacker reconnaissance against the cost of analyst triage.

• An attacker queries Active Directory for service accounts tied to database, backup, or middleware services, then targets those identities for offline password cracking.
• A security team hunts for repeated SPN enumeration from a workstation that should only access a limited set of directory objects, using the pattern as an early warning for Kerberoasting prep.
• During an assessment, a tester enumerates SPNs to identify which service accounts have the broadest permissions before attempting privilege escalation paths.
• A blue team correlates SPN lookups with later ticket requests and sees a sequence that suggests reconnaissance before lateral movement.
• Governance teams use findings from the Ultimate Guide to NHIs alongside directory review workflows to understand how service accounts become visible targets in large estates.

For technical context, service account enumeration is often discussed in relation to Active Directory reconnaissance and Kerberoasting techniques in the broader identity security ecosystem, including guidance from NIST Cybersecurity Framework 2.0 on managing identity risk.

Because SPN scanning is often just one step in a longer attack chain, detection logic should focus on who is enumerating, how broadly, and whether the query behavior aligns with the account’s normal administrative role.

Why It Matters in NHI Security

SPN scanning matters because it exposes the discovery phase that turns ordinary service accounts into attackable NHI assets. In environments with weak service account governance, an attacker can identify high-value targets long before defenders see credential abuse. That is especially important when organisations have limited visibility into service accounts, because the discovery problem and the compromise problem become hard to separate.

NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which means most environments struggle to distinguish authorized service discovery from hostile enumeration. The same research also shows that 97% of NHIs carry excessive privileges, so an SPN hit list often includes identities that can unlock broad access far beyond the service they support. Those numbers reinforce why SPN scanning is not just a detection issue, but a governance signal that identity inventory, privilege design, and secret rotation are failing together.

That is why defenders should pair monitoring with hardening, including service account review, constrained delegation checks, and rotation discipline informed by the Ultimate Guide to NHIs. Organisations typically encounter the consequences only after a service account is abused for Kerberoasting or lateral movement, at which point SPN scanning becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How do I implement secrets scanning in a CI/CD pipeline?
• Why is proactive secret scanning important for NHI security?
• What is the difference between code scanning and runtime identity monitoring?
• How should security teams use AI in secret scanning without creating new blind spots?