Phishing Resilience Testing: Prove What a Stolen Session Still Opens

TL;DR

CISA and the FBI's warning about phishing and smishing ahead of the 2026 U.S. midterms describes a delivery method, not the damage. The testable question is what a stolen password, one-time code, or session cookie still grants once an attacker holds it. Capture a session for a test account you control, replay it from a second browser profile on a different egress IP, and diff the response against the original. If the replay returns the account's data, survives a password reset, or lets you enroll a new MFA method without re-authentication, you have a finding with an HTTP transcript attached — which is worth more than any click-rate number.

What this is

Post-credential phishing resilience testing is the part of phishing defense you can actually measure on the identity surface. Instead of asking whether a user clicks, it assumes the credential is already in an attacker's hands and asks what the identity provider (IdP) and the applications behind it do next.

Concretely, it is three testable artifacts:

• Session and token behavior — cookie attributes, refresh-token lifetime, revocation on password change, and whether a token is bound to anything (device, IP, ASN, client certificate).
• Authentication policy enforcement — whether every protocol and every client actually obeys MFA and conditional access, or whether legacy paths sidestep it.
• Recovery and enrollment paths — password reset, MFA method registration, OAuth consent. These are the persistence mechanisms an attacker reaches for after the first login.

It is not a phishing simulation platform, and click rate is not an output.

Why it matters

Election offices, campaign staff, and party organizations are small-IT, high-value targets. They hold voter registration data, contact lists for current officials, and internal strategy documents, and they frequently run on a handful of administrators with no dedicated security team. CISA and the FBI published the PSA precisely because that asymmetry is exploitable.

The failure mode is quiet. Adversary-in-the-middle phishing kits proxy the real login page, so the victim completes MFA on the genuine IdP and the attacker receives a valid session cookie. From the SIEM's perspective the login succeeded, from a device the tenant has seen before, with a correct password and a correct code. Nothing looks like an intrusion, because technically nothing was intruded upon — valid credentials were used.

If you never test past the credential, three things stay unknown: how long a stolen session lives, whether a password reset actually evicts the attacker, and which protocols in the tenant still accept a password alone. Those are the questions that decide whether one phish is a nuisance or a month of mailbox access.

How it works

The mechanics are consistent across IdPs, and so is the test.

The capture. Three common paths:

1. Reverse-proxy (adversary-in-the-middle) phishing. The victim authenticates to a proxy that relays to the real IdP. The proxy steals the session cookie after MFA completes.
2. Code relay and smishing. A text message or push prompt harvests an OTP or an MFA approval in real time, then the attacker signs in with the password plus that code.
3. Consent phishing. The victim grants an OAuth application access to mail or files; no password is ever captured, and the token survives a password change.

The replay. Once an attacker holds a cookie or refresh token, impact depends on configuration, not on user behavior:

• Whether the session cookie or token is bound to the device or network it was issued to. Most bearer tokens are not.
• Refresh-token lifetime, and whether a password reset, session revoke, or "sign out everywhere" action actually invalidates outstanding tokens.
• Conditional access: device compliance requirements, named locations, token protection, continuous access evaluation.
• Legacy authentication protocols (IMAP, POP, SMTP AUTH, EWS, older ActiveSync configurations) that can bypass MFA policy entirely when still enabled.
• Authenticator strength. NIST SP 800-63B's authenticator assurance levels are the reference point: SMS and voice OTP sit at a lower bar than FIDO2/passkeys, and push with number matching is a mitigation, not an equivalent.
• Whether a user can register a new MFA method from an existing session without re-authenticating.

No patch level to check. There is no "affected version" in the CVE sense. The affected configuration is any tenant where a replayed token still resolves to a live session, or where a protocol or enrollment path ignores the MFA policy. Test procedures are standardized in the OWASP Web Security Testing Guide's authentication chapter and the ASVS authentication requirements; cite both in the report so the finding is not read as opinion.

Validation. The proof is a two-profile comparison, run step by step below.

Detection and response

The telemetry that matters sits in the IdP, not the endpoint.

• Sign-in logs with device ID, IP, ASN, and client app. Look for the same session or user principal active from two ASNs within a short window.
• Token replay and anomalous-token detections where the IdP offers them. Enable them; they are frequently off by default in smaller tenants.
• MFA method registration events — a new authenticator added shortly after a sign-in from a new location is the highest-signal persistence indicator in this entire scenario.
• OAuth consent grants for newly registered or low-reputation applications.
• Mailbox rule creation and forwarding changes, especially rules that move or delete messages matching a domain name or words like "invoice" or "password".
• Legacy authentication sign-ins, logged separately in most tenants and easy to miss.

The check a responder should run first: after any suspected credential compromise, reset the password, revoke sessions and refresh tokens explicitly, then verify in the sign-in log that the old session actually stopped working. A reset that leaves a live refresh token in place is a false sense of containment.

What to do

Run this against a tenant you are authorized to test, with accounts you own. Get the scope in writing — IdP tenant, mail tenant, and every application behind SSO.

1. Create two test accounts in the same tenant with different roles. Account A is the victim; account B is the control that proves you are measuring session binding, not authorization.
2. Baseline A. Sign in from an isolated browser profile over a known egress IP. Record the session cookie, the refresh token, and the exact request that returns A's profile or mailbox data.
3. Replay from a second profile on a different egress IP. Send the same request. Capture status code, response body, and timestamp.
4. Confirm the control. With the same replayed session, request a resource that belongs to B. It should fail. If it succeeds, you have a separate authorization finding and the session result is contaminated.
5. Test revocation. Reset A's password, then replay the old refresh token. Record whether it still mints an access token.
6. Test enrollment. From A's session, attempt to register a new MFA method. Note whether re-authentication is required.
7. Test legacy paths. If the tenant still permits IMAP, POP, SMTP AUTH, or EWS, attempt authentication with A's password alone and note whether MFA policy applies.
8. Assemble the evidence. Two transcripts (capture and replay), the control request, timestamps, egress IP and ASN for both sides, account identifiers, and a one-line expected-versus-actual statement.
9. Retest after the fix with the identical script and attach the second transcript to the same finding. A remediation claim without a retest is a hypothesis.

The deliverable is not "MFA can be phished." It is "session issued at 14:02 UTC remained valid after a password reset at 14:31 UTC and returned 412 messages from account A" — with the requests to back it up.

FAQ

Is this the same as phishing simulation? No. Simulation measures whether people click. This measures what happens after they do, on systems the defender controls. Both are useful; only one produces a reproducible technical finding.

Do I need to run a real phishing campaign to test this? No. You seed the test account's credential yourself and simulate the post-capture state. That is also the safer option, since it avoids targeting real users — which matters in an election context where staff are already on edge.

What if the client only uses SMS or push MFA? Then the finding is stronger, not weaker. OTP and push approval are relayable in real time by adversary-in-the-middle kits and smishing. NIST SP 800-63B's authenticator assurance levels explain why phishing-resistant authenticators are the target state, and the gap is straightforward to document.

Does a password reset fix a stolen session? Only if the IdP revokes refresh tokens and active sessions on reset, and only if that behavior is verified rather than assumed. Test it.

Where does smishing fit if there is no link to click? The mobile flow is still an SSO flow. Test whether the IdP's mobile browser path enforces the same conditional access as desktop, and whether push notifications carry number matching and location context.

What is the single highest-value remediation? Phishing-resistant MFA (FIDO2/passkeys) for administrators and anyone with access to voter or donor data, plus verified session revocation on credential reset. The rest is defense in depth.

Sources

• CISA and FBI, "Cyber Threat Actors Use a Variety of Techniques to Target Election and Campaign Officials" — https://www.cisa.gov/resources-tools/resources/cyber-threat-actors-use-variety-techniques-target-election-and-campaign-officials
• CISA, "More Than a Password" (phishing-resistant MFA guidance) — https://www.cisa.gov/MFA
• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management — https://pages.nist.gov/800-63-4/sp800-63b.html
• OWASP Web Security Testing Guide, Authentication Testing — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/
• OWASP Application Security Verification Standard — https://owasp.org/www-project-application-security-verification-standard/
• Trusteed, CTEM and vulnerability intelligence — https://trusteed.io