A high-value financial institution was reviewing evidence connected with exposed credentials, infected devices and browser-profile material. Its security team asked the question almost every executive asks once two-factor authentication enters the conversation:
How could anyone get through 2FA?
The answer begins inside a browser.
An employee enters a password. A second-factor challenge appears. The employee approves it. The identity provider checks both factors and issues a session token. From this point forward, most applications stop asking for proof at every click. The token carries the proof. It tells email, document storage, messaging and other services: this person has already authenticated.
Steal the token and a criminal acquires trust already granted.
The user completed MFA. The identity provider recorded a successful challenge. Every control involved may have behaved exactly as designed. An attacker holding the resulting session can still open the account.
This distinction matters for private banks, wealth managers, trustees, family offices and investment firms. Their people hold authority across email, payments, client records, data rooms, portfolio systems and third-party platforms. One trusted identity can reach several institutions. One convincing message can move money. One browser can hold every ingredient required to become a senior employee in digital form.
MFA remains one of the strongest and most important security controls available. Criminals have responded by moving their effort into the machinery surrounding the prompt.
To understand where exposure lives, map five positions in the authentication chain: before, during, after, beneath and above.
One prompt inside a much larger system
Two-factor authentication is a form of multifactor authentication. It asks for evidence from at least two categories: something a person knows, possesses or is. A password plus a mobile approval is a familiar example. A security key unlocked with a PIN or biometric offers a stronger model.
Each successful sign-in produces a decision. Applications then need a practical way to remember it. They issue cookies, access tokens, refresh tokens and other authentication artifacts. Those artifacts keep people working as they move between pages and services.
Convenience creates duration. A thirty-second authentication ceremony may create hours or weeks of access.
Executives often measure identity security by one question: “Is MFA enabled?” Security teams need a wider one: Where can trust be created, captured, transferred, extended, reset or forged?
Call this the MFA Trust Map.
1. Before the prompt: take control of recovery
Every authentication system has a way to enrol a user, replace a lost device, reset a password or register a new factor. Criminals study these recovery paths because a successful reset lets them install their own authenticator.
The target may be a mobile carrier, an internal help desk, a managed service provider or an administrator. Personal information gathered from breaches and social media supplies answers, employee numbers, reporting lines and convincing context. Voice cloning can add a familiar sound. Urgency does the rest.
The FBI and CISA documented this pattern in their joint advisory on Scattered Spider. Operators used phishing and SIM swapping, collected personal details and persuaded help-desk personnel to reset passwords or MFA tokens. They then registered their own factors inside victim single-sign-on environments.
At this point, MFA operates normally. The criminal’s device has become an approved factor because a recovery process granted it legitimacy.
Recovery therefore belongs inside the security perimeter. Ask:
- Can one support agent reset a privileged user?
- Which evidence proves identity during a recovery call?
- Can caller-provided telephone numbers participate in verification?
- Does a senior executive receive an independent alert when a factor changes?
- Can a newly enrolled factor immediately approve sensitive actions?
- Are recovery events recorded, reviewed and correlated with subsequent access?
For people able to move assets, approve transactions or administer identity systems, recovery deserves transaction-level controls: independent callbacks to pre-registered channels, dual approval, cooling periods and rapid alerts.
2. During the prompt: relay the whole ceremony
Classic phishing steals a password for later use. Adversary-in-the-middle phishing keeps the victim engaged while a criminal signs into the real service in real time.
A convincing link opens a page which mirrors the legitimate login. Malicious infrastructure sits between the victim and the actual service. It relays each screen and response. The victim enters a password. The real service sends an MFA challenge. The victim completes it. The service then issues a valid session through the criminal-controlled connection.
Microsoft has observed these campaigns at scale. Its incident-response team describes attackers using proxy frameworks to capture credentials and session cookies during a legitimate authentication flow. A campaign analysed by Microsoft targeted over 10,000 organisations and used stolen sessions for mailbox access and payment fraud.
The FBI issued similarly blunt guidance in 2025 concerning fake employee self-service websites. Criminals captured credentials and solicited one-time passcodes through fraudulent pages or telephone calls. A familiar logo, a plausible search advertisement and a live MFA prompt were enough to create a valid session under criminal control.
Push fatigue uses a cruder route. Repeated approval requests arrive until a user accepts one to clear the interruption or responds to a caller posing as support. Number matching raises resistance. FIDO2 and WebAuthn change the protocol by binding authentication to the legitimate service domain, which blocks a proxy from replaying the ceremony elsewhere.
During-prompt defence therefore requires authentication designed to resist relay, plus controls around links, browsers and user reporting.
3. After the prompt: steal the session
Once authentication succeeds, the session becomes the prize.
The FBI warns criminals can steal “remember me” cookies and enter webmail accounts through an existing authenticated state. The stolen cookie removes any need to repeat a username, password or MFA challenge during its valid life.
Cloudflare’s 2023 response to an Okta support-system compromise offers a powerful real-world example. Cloudflare enforced hardware security keys. An attacker obtained an administrative session token from a file uploaded in a support case and used the open session to enter Cloudflare’s Okta instance. Rapid detection and additional access controls contained the event. Hardware keys protected the authentication ceremony; a stolen session arrived after the ceremony had already succeeded.
Session theft can begin through:
- infostealer malware extracting browser databases;
- adversary-in-the-middle phishing capturing the issued cookie;
- support files containing diagnostic traces or session material;
- malicious browser extensions;
- endpoint access and browser-profile theft;
- token leakage in logs, repositories or developer tooling.
Password resets often leave sessions, refresh tokens, application passwords and OAuth grants alive. Response must explicitly revoke each form of durable access. Security teams should know how quickly their identity provider can invalidate sessions across every connected application, including third-party platforms.
Look for a session arriving from a new device, unusual network, unexpected client, unfamiliar browser state or improbable sequence of actions. Location alone offers weak comfort. Criminals use residential proxies and compromised devices to appear near a victim’s normal geography.
4. Beneath the prompt: own the device
MFA assumes the device participating in authentication can be trusted enough to handle secrets and sessions. Malware changes the premise.
An infostealer can collect saved passwords, session cookies, browser history, autofill data, cryptocurrency wallets and local files. Remote-access malware can observe activity, capture keystrokes or interact with an authenticated browser. A stolen browser profile can carry both identity and context into criminal hands.
NSA guidance states the principle plainly: authentication measures depend on endpoint security, and a compromised device can defeat them. Mandiant has documented browser-in-the-middle tooling which extracts session cookies after a victim completes login and MFA. Operators can also capture entire browser profiles, making session reuse fast and operationally simple.
This is the decisive issue when external intelligence reveals infected-device records or cookie-like material. A list of exposed passwords suggests credential risk. A browser payload suggests control over the place where authentication happens and where trusted sessions live.
The investigation should move toward the endpoint:
- Which device produced the material?
- Who used it at capture time?
- Was it managed, personal or supplied by a contractor?
- Which browsers and profiles were present?
- Which sessions existed during infection?
- Which password managers, wallets and local files were accessible?
- Does persistence remain?
- Which replacement credentials were entered after the suspected infection began?
Rotating credentials from the same infected browser can deliver fresh secrets to the collector. Isolate and clean the source before rebuilding trust.
5. Above the prompt: compromise the authority issuing trust
Identity providers sit above individual users. Their signing keys, administrative sessions, token services and federation relationships decide which identities every connected application will accept.
The 2023 Microsoft Exchange Online intrusion revealed the scale of this layer. According to the US Cyber Safety Review Board, a China-linked actor used authentication tokens signed with a Microsoft key created years earlier. Forged tokens opened mailboxes belonging to 22 organisations and over 500 people, including senior US government officials. Access continued for weeks, and the actor downloaded roughly 60,000 emails from the US State Department alone.
Every affected user could have completed MFA perfectly. A forged token entered higher in the trust hierarchy. Services accepted the signature because their identity architecture recognised its authority.
Similar exposure can arise through:
- compromised identity-provider administrators;
- stolen token-signing keys;
- weak federation configuration;
- overprivileged service accounts;
- malicious OAuth application consent;
- leaked API keys and client secrets;
- dormant emergency accounts;
- support-provider access;
- token-validation flaws.
Protecting this layer requires isolated administrative identities, phishing-resistant authenticators, privileged-access workflows, strong key custody, short-lived credentials, comprehensive logging and regular review of federation and application trust.
Why private wealth carries a sharper consequence
Identity architecture becomes financial architecture inside a private bank, wealth manager, trustee or family office.
Email can initiate a transaction. Messaging can accelerate it. A document store can supply signatures, deeds, valuations, ownership structures and previous instructions. Calendar access reveals timing. Client records identify relationships. A compromised adviser account provides tone, history and credibility.
Criminals can assemble these pieces into a fraudulent instruction delivered through an authentic account during a plausible transaction window. An attacker reading a mailbox can wait for a capital call, property completion, custody movement or executive trip. Existing context answers the questions a cautious recipient might ask.
MFA coverage figures give leadership a comforting percentage. Criminal capability lives in exceptions and chains: one session, one recovery agent, one infected executive laptop, one unmanaged adviser, one powerful OAuth grant or one identity administrator.
Measure protection against outcomes:
- Can a criminal acquire an authenticated session?
- Can a criminal enrol or reset a factor?
- Can a compromised device expose fresh credentials and sessions?
- Can an application or service account retain access outside the normal user flow?
- Can a privileged operator create trust for someone else?
- Can defenders revoke access everywhere within minutes?
- Can investigators reconstruct who accessed which information and when?
These questions expose the working strength of identity security.
Strong MFA starts with phishing resistance
CISA identifies FIDO/WebAuthn as the widely available phishing-resistant standard. NIST’s current Digital Identity Guidelines define phishing resistance around cryptographic protocols which prevent a verifier impersonator from relaying authentication across a different protected channel. The UK National Cyber Security Centre’s 2026 assessment similarly places FIDO2 credentials and passkeys ahead of traditional MFA against common credential attacks.
Strength follows a practical hierarchy:
- FIDO2 security keys or properly governed passkeys for privileged users, executives and high-value identities.
- Certificate-based authentication or enterprise PKI where operating maturity supports it.
- Authenticator applications with number matching as an interim control.
- Time-based one-time codes for services with limited support.
- SMS and voice codes as high-exposure fallbacks requiring a migration plan.
Authentication strength also depends on coverage. Protect email, identity administration, VPN, remote support, cloud consoles, portfolio systems, document rooms, code repositories, password managers and external supplier portals. Close legacy protocols and recovery routes able to fall back to weaker factors.
Then secure the rest of the trust chain:
- managed and monitored devices;
- device compliance inside access decisions;
- shorter session lifetimes for powerful roles;
- reauthentication for sensitive actions;
- rapid token revocation;
- independent factor-enrolment alerts;
- tightly governed help-desk recovery;
- OAuth and service-account review;
- separate privileged identities;
- endpoint and identity telemetry correlated in one investigation path.
MFA is strongest when device, session, recovery and identity-provider controls reinforce it.
When exposed browser or session material appears
Treat session-like evidence as a potential access event until internal telemetry clears or confirms it. Evidence in an external source establishes criminal availability. Internal logs establish activity inside the institution.
Use a strict sequence.
Isolate
Remove suspected devices from operational access. Preserve evidence. Identify every user and browser profile connected with the record.
Revoke
Invalidate sessions, refresh tokens, cookies, application passwords, trusted devices, API keys and suspicious OAuth grants across connected services.
Rebuild
Reset credentials from a clean device. Re-enrol authenticators. Review recovery channels. Rotate shared secrets and keys exposed to the device or identity.
Hunt
Search authentication, endpoint, email, application and transaction logs from the earliest plausible capture time. Review mailbox rules, forwarding, downloads, new devices, factor changes, admin actions, consent grants and payment activity.
Prove
Confirm the collection source has been removed, previous access has ended and new exposure has stopped appearing. Continue monitoring identities, devices and criminal sources for recurrence.
A successful password change proves one secret changed. A successful response proves the attacker’s entire access chain has collapsed.
Questions leadership should ask tomorrow morning
- Which MFA methods protect our executives, administrators and transaction authorities?
- Which accounts still permit SMS, voice or one-time-code fallback?
- Can our help desk enrol a new factor for a senior user, and who approves it?
- How quickly can we revoke every active session across every important application?
- Do password resets invalidate refresh tokens, application passwords and trusted devices?
- Which personal and contractor devices can hold corporate sessions?
- Can our security team detect session replay and suspicious OAuth consent?
- Which service accounts or federation relationships bypass the human MFA flow?
- Do support tickets, diagnostic files or logs ever contain session material?
- Have we tested this response with a real exercise?
An “MFA enabled” dashboard answers an implementation question. These ten questions answer an exposure question.
A green checkmark is the beginning
MFA forces criminals to work harder. Strong, phishing-resistant authentication shuts down broad classes of attack. Its value is enormous.
Modern access still moves through a chain. Recovery creates factors. Live proxies relay approvals. Browsers hold sessions. Devices store secrets. Identity providers sign trust. Administrators and applications extend it.
Security begins with MFA and follows trust wherever it travels.
When a security report contains exposed credentials, infected-device evidence or browser artifacts, ask one question before taking comfort from a second factor:
What else did the attacker acquire after successful authentication?