What Is a Privileged Threat Scan (PTS)?

A domain admin account had not logged in interactively for eight months. Its password was set in 2019 and never rotated. It was a member of three nested groups that, followed to the end, granted control over the domain controller. No one on the team knew it existed, because it was created by a contractor who left, and the offboarding ticket only disabled their named user account. An attacker who lands one phished credential does not need to break anything to reach that account. They need to find it. A privileged threat scan finds it first.

A privileged threat scan, PTS, is an assessment that inventories every privileged account and credential in an environment and grades each one by how exposed it is to abuse. It is not waiting for an alert. It is going out and looking for the standing exposures that make a privileged-account takeover cheap: stale passwords, shadow admins, cached credentials, excess standing privilege, and the attack paths that connect an ordinary foothold to a domain-dominating one. This guide covers what a PTS is, why privileged accounts are the target, what the scan actually checks, how it runs, how it differs from a vulnerability scan and from live detection, and how to turn its output into fixed exposures rather than another report no one reads.

What is a privileged threat scan?

A privileged threat scan is a point-in-time or scheduled assessment of the privileged identity attack surface. It enumerates the accounts and credentials that carry elevated rights, human admins, service accounts, machine identities, break-glass accounts, and the groups and roles that confer privilege, then evaluates each against the conditions an attacker exploits.

The unit of assessment is the privileged account, not the host or the network segment. The scan answers three questions for every privileged identity it finds. What can this account do if it falls into the wrong hands? How likely is it to fall, given its password age, exposure, and protection? And what does an attacker reach next once they hold it? The output is a ranked list of exposures, worst first, with enough context to fix them.

The point is proactive. Most identity security watches for an attack in progress. A PTS runs before the attack, on the assumption that the cheapest intrusion is the one that finds a privileged account already misconfigured and waiting. It shrinks that surface so the live-detection tools have less to catch.

Why privileged accounts are the target

Attackers go after privilege because privilege is leverage. A standard user account gets an attacker a foothold. A privileged account gets them the environment.

The economics favor finding privilege over earning it. CrowdStrike's 2026 Global Threat Report found that 82% of detections in 2025 were malware-free, with adversaries leaning on valid credentials and trusted identity flows rather than dropping tooling a scanner would flag. The same report puts average breakout time, from initial access to lateral movement, at 29 minutes. An attacker who phishes one credential and then locates an over-privileged or unprotected admin account compresses the entire intrusion: no exploit, no malware, just a login and a short walk to the goal.

Privileged accounts are also where defenders are weakest by default. They accumulate. A service account gets domain admin "temporarily" for an install and keeps it for years. A help-desk group gets nested into a privileged group during a reorg. A break-glass account is created, documented in a wiki, and never rotated. Each is invisible to a tool watching for malware and live until something or someone goes looking. That is the gap a privileged threat scan is built to close.

What a PTS scans for

A privileged threat scan looks for the specific, recurring conditions that turn a privileged account into an easy target. The findings cluster into five categories.

Excess and standing privilege. Accounts with more rights than their function needs, and privilege that sits permanently rather than being granted on demand. This includes over-privileged users, service accounts holding admin, and roles that violate least privilege. Standing privilege is the raw material every other finding builds on. Just-in-time (JIT) access is the structural fix the scan points toward.

Shadow and orphaned admins. Accounts that hold privilege through paths no one tracks: nested group membership, direct ACL grants on the directory, accounts created by an attacker for persistence, and admins whose owner has left. A shadow admin does not appear in the obvious privileged groups, so it survives audits that only check group membership.

Stale and weak credentials. Passwords that have not been rotated, accounts with weak or reused passwords, service accounts with passwords that never expire, and credentials exposed in scripts, GPOs, or SYSVOL. Old credentials are the ones most likely to appear in an info-stealer log or a prior breach dump.

Cached and exposed credentials. Privileged credentials sitting in memory on workstations, cached on machines the admin logged into, or recoverable from disk. These are what feed credential theft techniques like credential dumping. A scan flags privileged accounts whose credentials are exposed on lower-trust hosts an attacker is likely to reach first.

Protection and attack-path gaps. Privileged accounts without MFA, accounts vulnerable to Kerberoasting or AS-REP roasting, accounts that can be reached through a chain of permissions from an ordinary user, and missing controls like the Protected Users group or logon restrictions. This is where the scan maps the path: from a low-value foothold, through each escalation, to the domain controller.

The thread across all five is that none of them is an active attack. They are the conditions that make an attack trivial, sitting in the environment right now.

How a privileged threat scan works

A PTS runs in four stages, and the value compounds across them. The first two find the accounts; the last two grade and rank them.

Discover. The scan enumerates privileged identities everywhere they live: directory groups and their nesting, directory ACLs, local administrator groups on endpoints and servers, service accounts and their service principal names, cloud and SaaS admin roles, and break-glass accounts. Discovery is the step that catches shadow admins, because it follows the actual grant of privilege rather than trusting a list of "the admin accounts."

Assess. For each account it grades the conditions: password age and strength, MFA status, last interactive logon, where the credential is cached, whether the account is Kerberoastable, and how much privilege it actually holds versus needs. This is the raw exposure data.

Map attack paths. The scan connects the dots into chains. An ordinary user can modify a group; that group is nested into a privileged group; that privileged group can reset a domain admin's password. Three benign permissions become one path to domain dominance. Mapping the path is what turns a list of accounts into a prioritized target list, because the accounts on the shortest, highest-impact paths are the ones to fix first.

Rank and report. Finally it scores each exposure by impact and reachability and ranks them worst first. The output is not "here are 4,000 accounts." It is "these twelve privileged accounts are reachable from a standard user and protected by nothing, fix them this week."

Run once, a PTS is a snapshot of today's exposure. Run on a schedule, it becomes a trend: privilege creeps back, new service accounts appear, a merger drops an unmanaged forest into scope, and the recurring scan catches the regression before an attacker does.

PTS vs vulnerability scanning vs live detection

A privileged threat scan is easy to confuse with the tools on either side of it. The cleanest way to separate them is by what they look at and when they act.

A vulnerability scan finds software that needs patching: a missing update, an exposed service, a known CVE. It says nothing about a domain admin with a six-year-old password, because that account is not a software flaw. A PTS finds exactly that, the identity exposures a CVE scanner cannot see.

Live identity detection sits on the other side. It watches privileged accounts in real time and alerts when one is abused, the job of identity threat detection and response (ITDR). It is reactive by design and only fires once the attack starts. A PTS runs before that, removing the exposures so the live tools have fewer attacks to catch and the attacks they do catch start from a worse position for the adversary. The three are complementary: patch the software, shrink the privileged surface, then watch what is left.

Acting on a PTS

A scan that produces a report no one acts on is overhead. The output earns its place only when it drives change, and the change follows the ranking.

Fix the reachable-and-unprotected first. The accounts that are both reachable from a low-trust foothold and protected by nothing are the ones an attacker reaches in the 29-minute window. They top the list. Add MFA, break the attack path, rotate the credential, the order depends on the finding, but these go first.

Remove standing privilege. For the accounts that hold privilege they rarely use, the durable fix is to stop the privilege from standing: move to just-in-time elevation, convert service accounts to managed accounts that rotate automatically, and strip privilege back to what the function actually needs. This shrinks the surface the next scan has to grade.

Deprovision and flatten. Shadow and orphaned admins get owners or get disabled. Deeply nested group structures that hide privilege get flattened so membership reflects reality. This is identity hygiene, and it is where most of the long-term reduction comes from.

Rescan and trend. Privilege creep is constant, so a one-time fix decays. Scheduling the scan turns it from an audit into a control: each run shows whether exposure went down or crept back, and the trend line is what tells you the program is working.

None of this is automatic. A PTS is the input to a privilege-reduction program, not a substitute for one. The scan finds the exposure; the team closes it; the rescan proves it stayed closed.

Where a PTS falls short

A privileged threat scan is powerful and has real limits. Knowing them keeps it honest.

It is a snapshot, not a monitor. A scan reflects the moment it ran. An account created an hour later, or privilege granted after the scan, is invisible until the next run. This is why scheduling and live detection both matter; a PTS does not replace either.

Coverage decides accuracy. The scan only grades what it can see. An unmanaged forest, a SaaS admin role outside the identity provider, a local account on an unscanned host, all are blind spots, and attackers find them. Incomplete coverage produces a falsely clean report, which is worse than no report.

Findings need context to rank well. Not every over-privileged account is a real risk, and not every stale password is reachable. Without attack-path context and asset-criticality data, a scan buries the twelve accounts that matter under four thousand that do not, and the team tunes out.

It finds exposure, not intent. A PTS tells you an account could be abused, never that it is being abused. That distinction is the whole reason it pairs with live detection rather than standing alone.

These are reasons to run a PTS as part of a program, with full coverage, good context, and a rescan cadence, not reasons to skip it. The exposures it finds are real and sitting in the environment whether or not anyone scans for them.

Frequently Asked Questions

What is a privileged threat scan in simple terms?

A privileged threat scan is an assessment that finds every privileged account and credential in an environment and grades how exposed each one is to attack. It looks for stale passwords, hidden or orphaned admins, excess standing privilege, exposed credentials, and the attack paths that lead to high-privilege accounts, then ranks them worst first so the team can fix the riskiest ones before an attacker exploits them.

How is a privileged threat scan different from a vulnerability scan?

A vulnerability scan finds software flaws: missing patches, exposed services, known CVEs. A privileged threat scan finds identity exposures: over-privileged accounts, stale admin passwords, shadow admins, and attack paths to privilege. A CVE scanner cannot see a domain admin with a six-year-old password because that is not a software bug. The two are complementary, one covers software, the other covers privileged identities.

What does a privileged threat scan check for?

It checks five categories: excess and standing privilege, shadow and orphaned admins, stale and weak credentials, cached and exposed credentials, and protection and attack-path gaps such as missing MFA or Kerberoastable accounts. For each privileged account it grades password age, MFA status, last logon, credential exposure, and how reachable the account is from a lower-trust foothold.

Does a PTS stop attacks?

Not directly. A PTS is proactive: it finds and ranks the exposures that make a privileged-account takeover easy, so the team can remove them before an attack. Stopping an attack in progress is the job of live identity detection. The two work together, the scan shrinks the privileged attack surface, and live detection catches abuse of what remains.

How often should you run a privileged threat scan?

On a schedule, not once. Privilege creep is constant: new service accounts appear, nested groups change, mergers add unmanaged directories, and accounts created after a scan are invisible until the next run. Recurring scans turn the assessment into a control and produce a trend line that shows whether privileged exposure is going down or creeping back.

What is an attack path in a privileged threat scan?

An attack path is a chain of individually benign permissions that, followed end to end, lets a low-privilege account reach a high-privilege one. For example, an ordinary user can edit a group, that group is nested into a privileged group, and that group can reset a domain admin password. Mapping these paths is what lets a PTS rank exposures by real reachability rather than listing accounts in isolation.

The bottom line

A privileged threat scan exists because the cheapest intrusion is the one that finds a privileged account already misconfigured and waiting. With 82% of detections malware-free and breakout times under half an hour, an attacker who lands one credential and then locates an unprotected, over-privileged, reachable admin account has the whole environment in minutes, and no malware fired to warn anyone.

A PTS closes that gap before the attack. It discovers every privileged account, including the shadow admins no audit catches, grades each against the conditions attackers exploit, maps the paths that connect an ordinary foothold to domain dominance, and ranks the result worst first. Then the work is the team's: fix the reachable-and-unprotected first, remove standing privilege, deprovision the orphans, and rescan to prove the surface stayed small. It is a snapshot, not a monitor, and it finds exposure, not intent, so it pairs with live detection rather than replacing it. Run it as a program and the domain admin no one remembered, with the password from 2019, gets found and fixed by you instead of by whoever phishes their way in first.