Your Session Will Get Stolen. Here's How to Make It Worthless.

Yesterday I wrote that the target has moved. It's not your password anymore, it's the proof of your login: the token and the session cookie that say "this person already authenticated, let them through." Kits like Kali365 exist to steal exactly that, and your MFA fires without stopping any of it. (That piece was "Kali365 Isn't Your Problem. Your Session Cookie Is." if you missed it.)

The fair response I got back, more than once, was some version of: okay, point taken, now what do I actually do about it on Monday morning? This is that article. Less doom, more checklist.

Start with the mindset, because it changes everything downstream. You are not going to stop every phish. Somebody is going to click, and a session is going to get lifted. Stop measuring success by whether that ever happens. Measure it by two things instead: how worthless the stolen session is when it lands in an attacker's hands, and how fast you notice it being used. Win those two and the theft stops mattering.

1. Make the login un-phishable

Most MFA is phishable. That's the whole reason these kits work. A code, a text, a simple approve/deny push: an adversary-in-the-middle proxy just relays it in real time and you helpfully approve your own compromise. The fix is MFA the proxy physically cannot replay.

That means phishing-resistant methods. FIDO2 security keys, passkeys, Windows Hello for Business, certificate-based auth. These bind the login to the actual site and the actual device, so a proxy sitting in the middle has nothing to forward. Roll them out to your admins, finance, and executives first, then everyone else. And while you're in there, turn off the weak methods. SMS, voice, and one-tap push should not be valid MFA for anyone who matters. Leaving them enabled is leaving the phishable door open next to the locked one.

2. Kill the device-code trick

One of Kali365's two main modes abuses OAuth device-code flow, the "enter this code on Microsoft's login page" pattern. Almost nobody in a normal office needs it. Write a Conditional Access policy that blocks device-code authentication for all users, with a narrow exception group for the rare service account or shared device that genuinely requires it. Guardz made this point and they're right: it's a single policy that deletes most of one entire attack mode. This is the highest-return ten minutes on the list. Do it first.

3. Bind the session to the device so a stolen cookie dies off it

This is the one that actually makes a stolen token worthless, and it's the piece most people haven't turned on. Token Protection in Entra Conditional Access cryptographically binds the session token to the device it was issued to. Lift that cookie and replay it from attacker infrastructure and it simply doesn't work, because it isn't on the machine it's bound to. Pair it with a Conditional Access rule that only allows sign-in from Intune-compliant or hybrid-joined devices, and the unmanaged laptop in some crew's basement is locked out by default.

Be honest with yourself about scope here. Token Protection is still maturing and doesn't yet cover every app and client, so it's not a magic switch you flip once. But it's real, it's available now, and where it applies it turns the entire session-theft model into wasted effort. Turn it on where you can and grow the coverage as it grows.

4. Shrink the blast radius of the tokens that do get out

Assume one slips through anyway. Your job now is to make sure it doesn't get far and doesn't last long.

Turn on Continuous Access Evaluation so that when a session goes bad, access to mail, files, and Teams can be yanked in near real time instead of waiting out a token's lifetime. Use sign-in and user risk policies to force reauthentication or block outright when the login looks wrong. Block legacy authentication protocols entirely, because they bypass modern controls and there's no reason to still allow them. And practice least privilege for real: separate admin accounts from daily-driver accounts, and don't hand standing global-admin to people who need it twice a year. A stolen session is only as dangerous as the account behind it.

5. Assume one gets through, and watch for the after-party

Prevention will not be perfect, so detection is not optional. The good news is that what attackers do after they steal a session is loud, if you're listening. Kali365's own playbook leaves fingerprints. Watch for new inbox rules that hide, delete, or forward mail, especially ones built to bury security alerts. Watch for a rogue device suddenly registering to an account. Watch for odd Microsoft Graph API activity and for OAuth consent grants to apps nobody vetted. Guardz flagged one signature worth burning into memory: a hidden inbox rule and a rogue device registration in the same hour is a near-certain sign of exactly this kind of compromise.

For most small and mid-sized shops this means turning on identity threat detection and response, whether you build it or lean on a provider who has. You don't need a 24/7 SOC of your own. You do need something watching identity around the clock and telling you when the after-party starts. If nothing is watching, you'll find out from your customers, and that's the worst way to find out.

6. Have a revoke button and know how to press it

When it happens, minutes matter. Write the playbook before you need it. Revoke the user's refresh tokens and active sessions, disable or block the account, kill any rogue registered device, pull the malicious inbox rules, rotate what needs rotating, and then hunt for the persistence they left behind so you're not cleaning this up again next week. Then actually rehearse it once, on a normal Tuesday, so the first time you run it isn't during a live incident at 2am. The teams that recover fast are the ones who practiced. Nobody rises to the occasion here, you fall to your preparation.

The honest part

None of this is a product you buy your way out of, and I'm not selling one. The uncomfortable and slightly encouraging truth is that most of what's on this list is sitting inside licenses you already pay for and never configured. Phishing-resistant MFA, Conditional Access, Token Protection, CAE, risk policies: that's Entra ID P1/P2 and Business Premium territory for a lot of you, already on the invoice. Microsoft's own data says modern MFA alone stops over 99% of identity attacks, and almost nobody has the rest of these dialed in. The gap isn't budget. It's that these got filed under "someday" and someday never came.

Bottom line

You can't stop the session from being stolen. Quit trying to win that fight alone. Make the login un-phishable, block the device-code trick, bind the session to a device you control so the stolen copy is dead on arrival, shrink what any leaked token can reach, watch for the theft the moment it's used, and be ready to revoke it in minutes.

Do that, and the next Kali365 is somebody else's problem. Skip it, and you're just waiting for your turn. The tools are already on your shelf. The only question is whether you turn them on before the phish lands or after.

The session will get stolen. Whether that becomes an incident or a footnote is entirely a function of what you configured before it happened.