Impossible travel and MFA fatigue are familiar identity alerts because both happen around authentication. However, a growing share of identity abuse starts after the login has already succeeded.
SpyCloud’s 2026 Identity Exposure Report found 8.6 billion stolen cookies and session artifacts recaptured from criminal sources in 2025. Those artifacts can give an attacker access to a session that has already passed authentication. There may be no new password attempt, no MFA prompt, and no fresh login for an identity provider to assess.
That leaves buyers with a different question when they evaluate identity-threat tools: what can the product see once the session is already live?
The Attack Can Begin After Authentication
A phishing campaign targeting DEF CON attendees in August 2026 showed how easily that can happen.
Huntress researchers traced the campaign through social media messages and malicious Google Docs used to deliver malware. On macOS, victims were directed toward AMOS, an infostealer that targets browser passwords and cookies, cryptocurrency wallets, keychain data, and other information.
The Huntress investigation included browser cookies among the data the malware was designed to steal. The attacker did not need to trigger MFA fatigue or create an impossible-travel event first.
If a valid session cookie or token is stolen, the attacker may be able to reuse a session that the legitimate user has already authenticated. The identity provider can see a successful login from the expected device, followed by activity from a session it already trusts.
That is a very different problem from spotting a bad login. The SOC now has to decide whether the person using the session is still the person who created it.
The Useful Evidence Comes After the Login
Impossible travel and MFA bombing still catch real attacks, but detecting them is no longer much of a differentiator. Most major identity platforms already watch for both. They are far less useful when the attacker gets hold of an authenticated session.
The user signs in from a trusted device. MFA succeeds. The device passes whatever compliance checks are in place, and the session token is issued. Now, assume that the token is stolen.
The original authentication still looks fine. So does the device that established the session. Depending on how the token is used, there may be nothing obvious in the login record to suggest that somebody else has taken over.
With session theft, the evidence may only start to appear after authentication. A token might refresh from several IP addresses within minutes without another login. The user agent may change between requests, while the legitimate user remains active at the same time. Analysts then have to work out whether that activity is expected or whether the token is being used somewhere it should not be.
In one investigation documented by Prophet Security, the initial alert contained little evidence of compromise. Looking beyond the alert revealed PRT-based token refreshes coming from multiple IP addresses within a short period. The user agent also changed, but there had been no fresh password entry or MFA challenge that would explain why the session was behaving differently.
The stolen token still carried the device compliance posture from the original authentication, so the identity system kept seeing a trust signal inherited from the legitimate session. Device compliance, in other words, did not tell the investigator who was using the token now.
This approach to identity investigation looks at the technique behind the activity, including session behavior and evidence from elsewhere in the security stack, rather than relying on a single login-time indicator.
Who Is Tackling Session-Level Identity Threats?
Prophet Security works the problem as an investigation rather than a detection. Its AI SOC Analyst takes an identity alert and pulls session behavior, token refresh activity, device compliance state, and evidence from the endpoint, cloud, and email systems around it, then documents the queries and evidence behind the determination. That matters most when the login itself looks clean and the answer sits somewhere else in the stack.
Permiso follows identity activity across cloud environments, including human, machine, and AI identities. That gives investigators a way to look at what an identity does after authentication instead of judging the session only by how it began.
Push Security approaches session theft from inside the browser. Its marker-injection method can identify when a session turns up without the marker placed in the legitimate browser, indicating that the session may have been copied and replayed elsewhere.
Silverfort works at the authentication protocol layer. It can apply policy to authentication requests and block access or require another authentication step when the risk justifies it, including for resources that do not support modern identity controls natively.
Vectra AI brings identity activity together with network and cloud behavior. That gives investigators more to work with when the identity logs alone do not explain what an account or session is doing.
The products take different routes, but the buying question is the same: what can they see once an attacker is operating inside a session that already looks trusted?
Give the Vendor a Session That Looks Clean
A useful vendor test starts with nothing obviously wrong. The user enters the right credentials, MFA succeeds, the device is compliant, and the session is established normally. Then the token is stolen and replayed somewhere else.
Ask the vendor to investigate from that point. See what the product notices before another login occurs. Find out whether it can identify suspicious behavior around the session, explain why that behavior points to compromise, and bring in other security evidence when the identity logs do not settle the case.
If the product needs a failed MFA prompt or a suspicious login before it has anything to investigate, you have found the limit of its coverage.
Use a session that passed authentication cleanly and was compromised later. That is the case worth putting in front of the next identity-security vendor.
