After Authentication: What Should Security Monitor?

Multi-factor authentication checks a sign-in. It does not check the session, token or application grant that the sign-in produces. Monitoring has to pick up at that point.

Microsoft’s token theft playbook states the problem plainly: when an attacker replays a stolen token, the authentication requirements have already been met, so access is granted. MITRE ATT&CK records the same behavior for web session cookies (T1550.004) and notes that it can bypass some MFA protocols because the session is already authenticated. Real actors use it. ATT&CK cites APT29 using stolen cookies, and Star Blizzard using cookies stolen with EvilGinx, to get into email accounts despite MFA.

What a sign-in leaves behind

A successful sign-in does not end with a yes. The identity provider issues artifacts, and each one can be stolen, replayed or abused on its own.

• Session cookie. Keeps a browser session authenticated. A copy imported into another browser carries the session with it.

• Access token. Short-lived. Sent to APIs and applications as proof that the holder is allowed in.

• Refresh token. Longer-lived. Lets a client obtain new access tokens without prompting the user, so a stolen one can extend access well past the original session.

• Primary refresh token. Used on some Windows devices to provide single sign-on. Microsoft Defender for Endpoint raises detections for suspicious access to it.

• Application grants. When a user or administrator consents to an app, the app receives tokens that last until the grant is revoked. ATT&CK describes consent phishing as giving long-term access without the attacker ever obtaining the user’s credentials.

The last item changes how you respond. A password reset does not remove an app grant, and it should never be the only containment step. Microsoft’s playbook pairs password changes with explicit revocation of user access, and lists checks for added authentication methods, enrolled devices and mailbox rules.

Six signals worth monitoring

No single signal is conclusive. Traveling staff sign in from new places, and administrators consent to apps for good reasons. The signal is the sequence. Consider a hypothetical chain: a password reset requested by phone, a new MFA method registered from an unfamiliar network ten minutes later, then an inbox forwarding rule. Each event is explainable alone. Together they describe an account takeover, and a rule that matches the sequence can fire with far higher confidence than any one of its parts.

Speed sets the design

CrowdStrike reports an average eCrime breakout time of 29 minutes in 2025, with the fastest at 27 seconds. Mandiant reports a median of 22 seconds between initial access and hand-off to a secondary group. These are figures about attacker pace in different datasets, not about your environment. They still say something about design: a daily review of identity logs is too slow for the first hops.

Our interpretation is that high-confidence sequences deserve automated containment. Revoke sessions and refresh tokens, disable the newly added authentication method, suspend the app grant, and page an analyst. Lower-confidence signals can queue for human review. Whichever way you split them, write the split down before the incident.

The data you need before you can detect

• Collect non-interactive sign-ins. Microsoft’s playbook asks responders to give immediate attention to unfamiliar non-interactive sign-in detections. If they are not ingested, that view is missing.

• Collect audit logs for changes, not only sign-ins. Authentication methods, app grants, roles, federation and policy all live in audit logs. Collect them from the identity provider, each critical SaaS platform and the cloud control plane.

• Keep logs long enough. Microsoft notes that Defender XDR advanced hunting covers up to 30 days of native event data, and Mandiant warns that standard 90-day retention can leave organizations blind to how a long intrusion began. Retain identity logs in your SIEM for longer than the console does.

• Check what each SaaS platform really records. Depth varies by product and license. Google’s Drift guidance told Salesforce customers to review Event Monitoring logs and connected-app authentication activity. Confirm those exist for your critical applications before you need them.

• Bring in the help desk. Reset and MFA-change events only become signals when matched to the ticket that requested them.

• Build baselines per user, app and location. Contractors, VPNs and mobile carriers create noise. A baseline is what turns “new IP” from an annoyance into evidence.

Prevention that makes monitoring easier

Detection works better when some paths are closed. FBI and CISA recommend phishing-resistant MFA, such as FIDO or WebAuthn, for webmail, VPNs and critical systems. ATT&CK lists blocking end-user consent to OAuth apps as a mitigation for token theft through consent phishing. Google recommends restricting connected-app scopes, enforcing IP restrictions and limiting API-enabled permissions for Salesforce. Microsoft points to continuous access evaluation and token protection controls where they are available. Each one reduces the volume of ambiguous events your team has to judge.

What monitoring cannot do

Logs show actions, not intent. A legitimate administrator and an attacker with the administrator’s session produce the same entries until context separates them. Baselines drift, and false positives from travel, mobile networks and shared devices wear down analyst trust if rules are not tuned. Monitoring also assumes the logs are complete. If a SaaS platform does not record the action, no rule will catch it.

Test the detection

Take your last few identity incidents, or the identity findings from your latest red team exercise. For each hop in the chain, ask four things. Which log would have shown it? Do we collect that log? Does any rule fire on it? How long until a person looks? Then replay the pattern in a test tenant: a session replay, an app consent, a help desk reset. Record what fired, how fast, and whether containment actually removed the access. The gaps are your detection backlog, in priority order.

Sources

1. Microsoft. Token theft playbook (Microsoft Learn, Security operations)

2. MITRE ATT&CK. T1550.004 Use Alternate Authentication Material: Web Session Cookie

3. MITRE ATT&CK. T1528 Steal Application Access Token

4. Google Threat Intelligence Group. The Cost of a Call: From Voice Phishing to Data Extortion (4 June 2025, updated August 2025)

5. Google Threat Intelligence Group. Data Theft From Salesforce Instances via Salesloft Drift (UNC6395)

6. FBI and CISA. Scattered Spider, Advisory AA23-320A (November 2023)

7. Google Cloud / Mandiant. M-Trends 2026: Data, Insights, and Strategies From the Frontlines (23 March 2026)

8. CrowdStrike. 2026 Global Threat Report (press release)