Executive TL;DR
- Token theft is increasingly driving modern identity compromise, as attackers abuse trusted sessions and authentication artifacts rather than relying on password theft alone.
- These techniques frequently survive traditional remediation because organisations invalidate passwords while overlooking active sessions, cloud refresh tokens, delegated access, or federated identity trust.
- Hybrid enterprise environments have expanded the operational impact of token theft beyond Windows domains into SaaS platforms, cloud administration, development pipelines, and third-party integrations.
- Many detection programs remain focused on intrusion attempts rather than post-authentication abuse occurring through legitimate administrative tools and trusted identity workflows.
- Attackers increasingly prioritize operational persistence, quiet lateral movement, and long-term access over immediate disruption or malware deployment.
- Offensive security assessments and adversary simulation help organisations validate whether identity controls, remediation actions, and operational visibility hold up under real attacker behaviour.
A Session the Organisation Already Trusted
Attackers may not need a password if they can inherit a trusted session.
Modern intrusions rarely look like constant break-ins. Once attackers gain access, they often stop forcing their way through controls and start blending into what the organisation already trusts: active sessions, valid tokens, approved applications, and established identity relationships. The breach continues not because security was ignored, but because trust was reused against the business.
That shift changes the risk model.
For years, enterprise security programs framed credential compromise in terms of passwords, phishing, brute-force attacks, and MFA enforcement. Today, many adversaries focus instead on what happens after authentication succeeds. A stolen password may trigger alerts. A reused session token operating inside a legitimate workflow often doesn’t.
MITRE ATT&CK’s Valid Accounts (T1078) technique documents this pattern directly: adversaries increasingly abuse legitimate authentication processes and existing account access to maintain persistence while blending into normal enterprise activity, often choosing not to use malware at all specifically to make their presence harder to detect.
This is why session and token reuse techniques continue to be operationally dangerous in modern Windows and hybrid environments. The question is no longer simply whether credentials can be stolen. It’s whether an attacker can keep operating through trusted authentication pathways after the organisation believes remediation is complete.
That distinction matters more than most enterprises realise.
A note on terminology
“Pass-the-Token” is sometimes used as shorthand for a specific technique — reusing stolen session tokens such as JWTs or OAuth tokens to impersonate a user without a password. It’s distinct from related, more established techniques: Pass-the-Hash (reusing NTLM password hashes), Pass-the-Ticket (reusing Kerberos tickets), and Pass-the-Cookie (reusing browser session cookies). In this article, we use “Pass-the-Token” more broadly, as an umbrella term covering all of these — Kerberos tickets, cloud refresh tokens, browser sessions, and delegated trust alike — because from a defender’s perspective, they share the same underlying risk: an attacker inheriting a session instead of stealing a password. When the distinction matters operationally, we highlight the specific technique.
Table of Contents
- Why Organisations Still Misunderstand Token Theft and Identity Persistence
- How Token Theft and Pass-the-Token Attacks Actually Unfold
- The Most Dangerous Part: The Organisation May Look Recovered
- Token Theft in Hybrid Identity and Cloud Sessions
- Why Token Theft Detection Frequently Fails
- Operational Consequences of Token Theft Beyond Initial Access
- Why Offensive Validation Matters
- Operational Takeaways
- A More Operational Security Conversation
- FAQ
Why Organisations Still Misunderstand Token Theft and Identity Persistence
Many enterprises still approach identity compromise as a credential problem. In practice, it has become a trust-inheritance problem.
Identity Is Operational Trust
Windows authentication ecosystems constantly create authentication artifacts to keep business operations moving. Kerberos tickets, access tokens, browser sessions, delegated authentication, cloud refresh tokens, and federated identity trust relationships all simplify access for legitimate users and administrators.
Attackers abuse that same convenience.
Instead of repeatedly stealing passwords or deploying noisy malware, attackers abuse authentication mechanisms that already operate inside trusted enterprise workflows.
A joint CISA and MS-ISAC advisory illustrates this pattern clearly. In the incident, a threat actor used credentials from a former employee account that the organisation had not disabled. The attacker authenticated to the VPN and moved through the network by relying on legitimate access rather than exploits or malware.
The misconception many organisations hold is that successful authentication represents a trustworthy user. In reality, authentication often becomes inherited operational trust, creating visibility gaps that many enterprises underestimate.
How Attackers Blend In
During real-world intrusions, attackers frequently avoid introducing new malicious binaries after initial compromise. Instead, they pivot through trusted administrative tooling such as PowerShell remoting, WMI, RDP, PsExec, cloud administration portals, or browser sessions already authenticated to enterprise SaaS platforms. To many monitoring systems, this activity looks operationally normal. We covered this same dynamic in more depth in our piece on living-off-the-land attacks, where attackers achieve persistence using nothing but tools the organisation already trusts.
In our Red Team operations, we run a baselining phase where we study how the target organisation and compromised users normally behave, then adapt our own activity to blend in. Done well, this makes it genuinely difficult for the Blue Team to distinguish Red Team activity from normal user and network behaviour.
How Token Theft and Pass-the-Token Attacks Actually Unfold
Pass-the-Token attacks are often treated as a niche technique reserved for advanced threat actors.
Operationally, they’re increasingly common because they work.
Once attackers compromise a privileged workstation, administrator session, or endpoint with active authentication artifacts, they may gain access to reusable tokens or delegated access already trusted within the environment. The objective isn’t necessarily to recover the original password — it’s to inherit access.
In mature environments, attackers often move carefully after initial compromise. Rather than escalating visibility through malware or brute force, they quietly leverage existing Kerberos tickets, cached sessions, delegated admin access, browser-based SaaS authentication, cloud refresh tokens, remote management frameworks, and federated identity trust. This lets them blend into legitimate traffic while maintaining access across systems that may never appear directly compromised.
Security teams often focus on suspicious authentication attempts originating externally. Meanwhile, attackers may already be operating through authenticated internal sessions.
What security teams monitor vs. what attackers exploit
| Security teams often focus on | Attackers frequently exploit |
|---|---|
| Failed login attempts | Valid, authenticated sessions |
| Malware execution | Trusted Windows processes |
| External brute force | Internal trust relationships |
| Password spraying | Existing authentication tokens |
| Unauthorized tools | Legitimate administrative tooling |
| Initial compromise vectors | Post-authentication persistence |
This is one reason token theft remains operationally effective even inside mature environments with strong preventive controls.
From an attacker’s perspective, a stolen authentication token is an efficient way to progress toward the objective. By reusing a valid token, the attacker operates with the privileges of the legitimate user, through the same authentication context. Because the activity happens through a valid session, it can closely resemble normal employee behaviour — making it harder for a Blue Team to tell Red Team activity apart from genuine user activity.
The Most Dangerous Part: The Organisation May Look Recovered
One of the most dangerous aspects of token theft is that organisations can appear fully recovered while attacker access quietly persists after visible indicators are removed.
This creates a false sense of containment.
Containment Can Be Incomplete
Incident response workflows often prioritize visible indicators of compromise. Teams remove malware, reset passwords, reimage endpoints, patch vulnerabilities, and disable accounts.
Those actions matter, but they may not invalidate every trust relationship or authentication artifact the attacker accessed.
Cloud refresh tokens may remain active. Federated sessions may continue functioning. Delegated administrative access may still exist. Kerberos tickets may remain valid. Privileged service accounts may stay exposed. Stale authentication pathways may continue operating behind the scenes.
In hybrid identity environments, this challenge becomes harder to control because authentication trust extends beyond individual systems. It moves across interconnected identity ecosystems. We explore this same “false remediation confidence” problem in detail in our piece on validating attacker persistence after remediation, including how compromised authentication certificates can remain usable long after a password reset.
The issue is not only whether the organisation removed malware. The issue is whether the organisation fully invalidated operational trust.
A Cloud-Based Persistence Example
During a previous Red Team operation, we obtained authentication material associated with a Microsoft Entra service principal. The service principal had extensive application permissions, including read and write access to data across Exchange Online, SharePoint Online, OneDrive, and Microsoft Teams.
We also identified a gap in the organisation’s Conditional Access configuration that made the compromised identity easier to use.
The service principal gave us an independent route to cloud-hosted information. Even if the Blue Team removed our internal network access, we could still pursue the exercise objective through that cloud identity.
That access also gave us a potential fallback path. If the Blue Team removed our existing foothold, the compromised service principal could support reentry or continued access to sensitive information.
In this case, the service principal represented both an independent route to business data and a durable fallback mechanism.
Token Theft in Hybrid Identity and Cloud Sessions
Pass-the-Token risk is no longer confined to traditional Windows domains.
Modern enterprises distribute authentication trust across Entra ID, Microsoft 365, SaaS ecosystems, VPN infrastructure, federated SSO providers, cloud workloads, browser-based enterprise applications, and development environments. As a result, the operational impact of identity compromise extends well beyond the original endpoint.
A compromised workstation can now provide indirect access not just to on-premises systems, but to cloud administration portals, SaaS collaboration environments, third-party business integrations, development pipelines, privileged cloud APIs, and identity federation infrastructure spanning interconnected business systems.
Identity has become the central dependency of enterprise operations — and attackers know it.
The 2023 Storm-0558 intrusion is a clear illustration. According to Microsoft’s own technical analysis, the threat actor used forged authentication tokens to access user email from approximately 25 organisations, including government agencies, by exploiting a validation flaw that let an acquired signing key forge valid-looking Azure AD tokens — without ever needing a password. The incident showed how identity trust itself now functions as a primary attack surface, not merely a supporting security mechanism.
This is also where many organisations underestimate their exposure. They assess compromise at the system level while attackers operate at the identity layer — and identity persistence frequently survives endpoint remediation, vulnerability patching, malware removal, and perimeter-focused containment.
When Domain Trust Becomes Long-Term Persistence
In our experience, privileged accounts with passwords configured to never expire are still common. If an attacker compromises one of these accounts, they may gain extensive control over the Active Directory environment.
Because the account sits outside the normal expiration policy, the credentials may remain valid for an extended period. The organisation must explicitly rotate the password or disable the account to remove that access.
After gaining sufficient domain privileges, an attacker may attempt a so-called “DCSync” attack. This technique abuses Active Directory replication functionality to request sensitive credential data from a domain controller.
Depending on the attacker’s permissions and the requested data, this may expose password hashes and Kerberos key material associated with domain accounts. This includes the highly sensitive krbtgt account.
If an attacker compromises krbtgt key material, they may forge Kerberos tickets and impersonate highly privileged domain identities. Recovery usually requires two krbtgt password resets, with enough time between resets for Active Directory replication to complete and existing Kerberos tickets to expire.
The organisation must also remove the attacker’s underlying access and any additional persistence mechanisms.
Once attackers obtain this authentication material, they do not need to use it immediately. They can retain it as a fallback option and use it later if they regain network access or find another path toward the intended objective.
Why Token Theft Detection Frequently Fails
Many organisations assume strong authentication controls automatically create strong visibility.
Operationally, they do not.
Modern detection programs often focus on malicious binaries, known malware signatures, failed authentications, suspicious external activity, and obvious privilege escalation attempts.
Token theft often avoids those detection paths. Attackers operate through trusted sessions, legitimate operating system behaviour, authorized administrative tools, inherited authentication trust, and normal cloud authentication patterns.
Why detection breaks down
| Security assumption | Operational reality |
|---|---|
| MFA stops account abuse | Authenticated sessions may already exist |
| Password resets remove attacker access | Existing tokens may remain valid |
| EDR detects malicious behaviour | Legitimate tooling blends into normal operations |
| Cloud authentication is centralized | Trust often spans multiple federated systems |
| Administrative activity is trustworthy | Attackers frequently inherit admin sessions |
| Remediation closes exposure | Identity persistence may survive cleanup |
The Problem Is Fragmented Context
In mature environments, security teams often discover during adversary simulation exercises that authentication telemetry exists but lacks sufficient correlation across cloud, identity, and endpoint systems. The result isn’t usually a lack of logging — it’s fragmented visibility.
Hybrid Evidence Gets Split
One example involves privilege escalation paths that cross the boundary between on-premises Active Directory and Microsoft Entra ID.
In hybrid identity environments, misconfigurations, excessive permissions, compromised identities, or weaknesses in synchronization infrastructure may allow an attacker to gain privileges in one environment by first compromising the other.
Evidence of this activity may appear across several data sources. These may include domain-controller logs, Microsoft Entra sign-in logs, audit logs, identity-protection systems, and synchronization infrastructure.
If the Blue Team reviews each event in isolation, they may miss the broader attack sequence.
As a result, defenders may lose the context they need to determine whether an action represents legitimate administration or malicious activity.
Operational Consequences of Token Theft Beyond Initial Access
One of the most dangerous misconceptions about token theft is assuming its primary risk is immediate disruption.
In reality, quiet operational access is often more valuable to attackers than immediate ransomware deployment.
Sustained identity-based persistence enables long-term reconnaissance, privilege escalation, lateral movement, SaaS data access, business email compromise, supply chain targeting, cloud control plane exposure, and delayed re-entry. By the time an organisation starts evaluating business impact, attackers may already understand its internal trust relationships, privileged access pathways, administrative workflows, cloud identity dependencies, and incident response procedures.
This is why modern ransomware groups and intrusion operators increasingly prioritize identity abuse and valid account access over malware deployment as a first move. As the CISA/MS-ISAC advisory on valid account abuse notes, legitimate authentication mechanisms — not malware — were the actor’s only tool throughout that intrusion, from initial access through lateral movement.
The most operationally dangerous attacks are often the ones that generate the least obvious disruption at the start.
Why Offensive Validation Matters
Most organisations never intentionally test whether token theft persistence could survive real-world remediation actions.
That gap matters.
Controls Need Adversarial Pressure
Traditional assessments confirm whether controls exist. Offensive security assessments validate whether those controls remain effective under adversarial conditions.
There’s a meaningful operational difference between deploying MFA and preventing session abuse, between enabling telemetry and detecting realistic identity persistence, and between resetting credentials and fully invalidating operational trust.
During adversary simulation exercises, security teams often discover that privileged access pathways remain active because identity relationships were never fully mapped operationally. Post-remediation validation frequently reveals stale sessions, overprivileged service accounts, unconstrained delegation pathways, fragmented authentication telemetry, weak token invalidation procedures, and cloud trust relationships that stayed operational long after the original incident was believed contained.
The most dangerous risks are often not the controls organisations completely lack — they’re the controls organisations assume are working correctly.
What Red Team Exercises Actually Test
The operational question is no longer whether token theft techniques exist. The better question is whether the organisation has validated how identity trust behaves under real adversarial pressure. That validation requires more than theoretical control coverage or compliance reviews.
A Red Team exercise helps answer that question by pursuing several complementary goals. The primary goal is to achieve the agreed exercise objective by emulating the actions of a realistic threat actor.
Depending on the scenario, this may involve privilege escalation, lateral movement, persistence, and the exploitation of technical or procedural weaknesses.
Throughout the operation, the Red Team may combine vulnerabilities, misconfigurations, excessive permissions, and process weaknesses to progress toward that objective.
The exercise also helps identify controls that are missing, misconfigured, ineffective, or behaving differently than expected. These findings matter, even when they are not directly required to achieve the primary objective.
The Debrief Is Where the Value Lands
A Red Team exercise also assesses the Blue Team’s detection and response capability. This includes how quickly and accurately defenders identify Red Team activity, understand its scope, contain the intrusion, and remove access and persistence mechanisms.
One of the most valuable outcomes is the post-exercise comparison between Red Team actions and Blue Team observations. That comparison shows which activities defenders detected, which ones they misunderstood, and which ones they missed.
The debrief also gives the Blue Team a chance to understand how the attack unfolded. They can ask why the Red Team made specific decisions and how an attacker may approach the environment.
These lessons help defenders improve procedures, address blind spots, refine detection logic, and respond more efficiently during future incidents.
Operational Takeaways
- Token theft is fundamentally an abuse-of-trust problem, not just a credential theft problem.
- Modern identity compromise increasingly spans cloud, SaaS, hybrid infrastructure, and federated authentication systems.
- Organisations frequently remove visible compromise indicators while underlying identity persistence stays active.
- Legitimate administrative tooling and trusted authentication workflows create major visibility challenges.
- Strong authentication doesn’t automatically guarantee strong detection capability.
- Offensive validation helps organisations test whether operational trust relationships can withstand realistic attacker behaviour.
A More Operational Security Conversation
Organisations rarely fail because they completely lacked security controls.
More often, they fail because they trusted incomplete visibility, misunderstood what “remediated” actually meant, or never validated how attackers would realistically abuse operational trust.
Token theft and Pass-the-Token attacks reinforce a broader enterprise reality: attackers increasingly succeed not by bypassing trust, but by inheriting it.
Understanding whether those trust relationships can withstand real-world adversary behaviour is becoming an increasingly important part of operational resilience, especially across hybrid identity ecosystems where authentication now extends far beyond traditional Windows environments.
For organisations looking to validate these assumptions in practice, offensive security assessments and adversary simulation exercises provide a practical way to test whether identity, authentication, visibility, and remediation controls hold up under realistic attacker behaviour.
FAQ
What is a Pass-the-Token attack?
A Pass-the-Token attack involves reusing stolen authentication tokens or session artifacts to impersonate legitimate users without needing their original password. It’s used here as an umbrella term covering related techniques such as Pass-the-Hash, Pass-the-Ticket, and Pass-the-Cookie.
Why are token theft attacks difficult to detect?
Because attackers frequently operate through valid authenticated sessions and legitimate administrative behaviour, the activity often appears operationally normal instead of overtly malicious.
Does MFA stop Pass-the-Token attacks?
MFA significantly improves security posture, but authenticated sessions or stolen tokens may still be abused after successful authentication has already occurred.
Can cloud environments be affected by token theft?
Yes. Hybrid identity systems, SaaS platforms, cloud refresh tokens, federated authentication, and delegated trust relationships can all expand token theft exposure.
Why do organisations struggle to fully remediate identity persistence?
Many remediation efforts focus on passwords, malware, or endpoints while overlooking active sessions, delegated trust, cloud authentication persistence, and token invalidation procedures.
How does adversary simulation help identify these risks?
Adversary simulation exercises, including those performed during our real-world Red Team Operations, help validate whether attackers could realistically persist through trusted authentication pathways, evade operational monitoring, or survive remediation actions.
Is token theft mainly associated with advanced nation-state actors?
No. These techniques increasingly appear across ransomware operations, financially motivated intrusions, cloud-focused attacks, and broader enterprise compromise activity, because they’re operationally effective and difficult to detect.
This article was co-authored with Raphael Nägert, Senior Security Consultant and Red Teamer at wizlynx group. Raphael specializes in offensive security, supporting organisations through focused security assessments, such as web application testing, as well as broader end-to-end red team exercises. Their work applies an adversarial perspective to challenge assumptions, uncover vulnerabilities, and identify weaknesses across complex environments. Raphael has contributed to security assessments and adversary simulation engagements across multiple industries, including the financial sector and other highly sensitive environments.
wizlynx group is a CREST-accredited offensive security company headquartered in Switzerland, operating across Europe, North America, Latin America, and Asia. wizlynx group specializes in penetration testing, red teaming, adversary simulation, social engineering, and advanced security assessments for enterprise clients.