What are my options to prevent token theft?

thecomputerguy

Well-Known Member
Reaction score
1,407
Client called with the usual account compromised. Rules were setup today and I know it was today because we had been in contact prior to this. Funny thing about this one is that they actually made a rule for MY EMAIL so that anything I sent her also got moved to the RSS feeds folder so they must have seen some correspondence indicating I was IT.

The malicious actors were trying to get a few grand from someone in her contacts through a Venmo transaction. Typical stuff...

Revoked MFA Sessions
Reset MFA
Reset Password

I asked her if she clicked on something bad today and of course she said no. I looked through her search history and nothing popped out at me.

Upon further investigation it looks like she originally had her token stolen some time ago 10-20 days ago ... it's hard to tell exactly because she was travelling internationally over the holidays and I had to open up her Conditional Access Policy to allow for international logins.

Any easy options I can employ either by CA or something?

Lastly ... Does anyone know is there is a powershell command or some easy way to see when a rule was created exactly? I know it doesn't really matter but I was trying to identify an exact time. MS says to audit the account in Security but by golly ... that place is messy. I tried this command but it wouldn't give me a timestamp

Get-InboxRule -Mailbox john@doe.com | fl
 
Token theft is managed via either SOC monitoring OR phishing resistant MFA.

That means either limiting M365 services to registered / joined devices, Intune compliant devices, use of Certificate based authentication, or finally FIDO2 keys.

That last item is the "easiest".

Note, Geographic controls are no security, not even a modicum of security. All you've done is security theater, and deprived yourself of valuable telemetry. They are a value add check, for risk based sign-on, nothing more.
 
Upon further investigation it looks like she originally had her token stolen some time ago 10-20 days ago ... it's hard to tell exactly because she was travelling internationally over the holidays and I had to open up her Conditional Access Policy to allow for international logins.
Just curious as to what you saw that caused you to arrive at that particular conclusion? Just wanted to know what to look for even if it is nebulous.
 
Just curious as to what you saw that caused you to arrive at that particular conclusion? Just wanted to know what to look for even if it is nebulous.

Entra sign-in logs. Common fraudulent logins I see come from

Ashburn, Virginia
San Jose, CA
New York, New York
Denver, Colorado

All very common VPN points which is why @Sky-Knight said a CA policy blocking countries outside the US is only somewhat useful which I agree with. Most of these fraud logins come in through a VPN tunnel.

I believe it also only blocks forward facing logins like going to outlook.office.com and trying to log your way into the account. Doesn't do anything about token theft.

Still doesn't hurt to block the OBVIOUS bad logins from another country ... why not.
 
Last edited:
I believe it also only blocks forward facing logins like going to outlook.office.com and trying to log your way into the account. Doesn't do anything about token theft.
This is correct, because CA only fires on login. Token theft is using the cookie that's the result of the login, no additional login is required, that already happened!

You control that via Defender for Identity's impossible travel controls, or Entra ID P2's Risk Based sign-on.

You also control is by limiting access to Entra ID Joined devices, or Intune compliant devices, OR use of a Certificate OR a FIDO2 key.

The latter two may seem odd, but the auth token is encrypted by the certificate or the FIDO2 key, so if you steal it... it's rather useless because you lack the private key to decrypt it before you send it to the web server.

An intelligent SOC service among many other things will note the impossible travel error, note the risk ramping up, and block sign-in, and revoke all auth tokens on the account... which halts access.
 
Back
Top