Interpreting "Risky Users" in Microsoft Entra admin center

[HCHTech]

Got a ticket today from a client user - they couldn't open a spreadsheet that was sent to them encrypted via M365. My client is on Business Premium licenses, and 2FA is enabled tenant-wide.

The message came into her Outlook, and on trying to open the message, she got an M365 login box (we have their logo enabled on the M365 tenant, so I know this was a legitimate login request. She was already logged in to her Office apps, but once she logged in again in response to this request, she got a message that

"Your account is blocked - We've detected suspicious activity on your account. Sorry, the organization you are trying to access restricts at-risk users. Please contact your [company name] admin,."

There was a 'more details' link, which brought up this dialog:

Then, finally, this dialog:


Logging onto the MS Entra admin center, and selecting "Risky activities", I do indeed see her username listed on the "Risky users" report. Status is "at risk". If I click on "User signins", I see many with status 'Success' and showing the town they are in under "Location". I also see a bunch of entries with status "Failure" from various locations in China, AE, Bengal, etc. I went through the entire list and all of the attempted logins shown for locations that weren't their office location have status "Failure". I'm presuming this means that none of these login attempts were successful.

If I choose to display just the "Risky signins", no entries are displayed.

If I choose to display "Users risk detections" I also get no entries.

Also, if you drill into the details of one of the failure entries, it says:

==========
Failure reason
Error validating credentials due to invalid username or password.
Additional Details
The user didn't enter the right credentials. It's expected to see some number of these errors in your logs due to users making mistakes.
==========

So I'm left wondering why a bunch of unsuccessful foreign logins (which have to happen for almost any address these days) put her in the "Risky User" category, and further what the right action to take is. Since there were no actual successful logins from abroad, I'm tempted to choose "Dismiss user(s) risk", which will likely fix the problem. I'm concerned however about how to determine the risk of doing this. It clearly says "Users can also have detections not linked to sign-in activity - To see all the detections, go to Risk Detections". Going there, however shows an empty list.

I see 2 other users on the risky users list as well, and the data for them looks similar, so they are NOT giving me much comfort either way.

 

[Markverhyden]

"we have their logo enabled on the M365 tenant, so I know this was a legitimate login request."

Anybody can copy a logo if they are on a spear phishing expedition. Did you look at the hyperlink code? Not long ago I had a phishing email looking for a M365 login. Don't remember the exact details but it ended up being someone who created a free MS account with website loaded with a fake portal. Looking at the actual address in the hyper link is what made me look deeper into it.

 

[HCHTech]

The email wasn't phishing - we did look at the details. I think the block was legitimate, but I'm questioning the assignment of the "risky user" status to this particular user.

 

[callthatgirl]

because of this

probably their email signature has a bad link, just a guess

 

[YeOldeStonecat]

"Risk Alerts" can be quite....gray. It's not just sign in locations, or a few sign in attempts from overseas.
There are a LOT of various "things" that Risk Alerts will watch over.
And there are a couple of categories that Risk Alerts will list things under....sign in risks, and user risks. Which...are different from each other.

A lot of times I do find them to be head scratchers.
Review some of them here on this link...scroll down a bit for a list of risks that the security engine takes into consideration.

What are risks in Microsoft Entra ID Protection - Microsoft Entra ID Protection

Learn about risk detections, risk levels, and how they map to risk event types in Microsoft Entra ID Protection

learn.microsoft.com

One area I'm going to work hard on is "token theft". I know how it works, but I'm not fully up on how to combat it. And Microsofts security engine is working on getting better at detecting and combating this token theft stuff.

Basically to sum it up, token theft has become widespread ...the bad guy will use one or more of several methods to "steal the token that allows MFA to be bypassed". You know, when you sign in...type in username, password, and then you get the MFA prompt. Once you approve MFA...a token gets passed to your computer so the rest of your activity that day doesn't keep getting prompted for MFA. If the bad guys get their hands on the token, they can log into your account...bypassing MFA...because 365 sees that token and says "OK, this person already must approved MFA so they're trusted right now".

Do you have security defaults enabled on the tenant? Or...a list of CA policies? Security defaults tend to be a bit more "vague".

 

[Sky-Knight]

"we have their logo enabled on the M365 tenant, so I know this was a legitimate login request."

Anybody can copy a logo if they are on a spear phishing expedition. Did you look at the hyperlink code? Not long ago I had a phishing email looking for a M365 login. Don't remember the exact details but it ended up being someone who created a free MS account with website loaded with a fake portal. Looking at the actual address in the hyper link is what made me look deeper into it.

Good habit, terrible logic. As Stonecat has already pointed out.

Modern MFA bypass uses a man in the middle assault, that proxies the live M365 environment. The user will get a real M365 prompt with all your configured details, login, and the authorization cookie is lifted and returned to the hacker which enables another browser anywhere in the world to access the account without any further authentication happening.

The only way to avoid this at present is to limit access to M365 services to Entra ID Joined machines, enforce the use of FIDO2 keys, or upgrade to Entra ID P2 so you can use risk based Conditional Access policies.

TLDR, SMBs even with fully fleshed out MFA can and will be phished.

 

[YeOldeStonecat]

The custom logo's no longer work. Many of the "token thieves" set up a "proxy" for the browser session to pass through..and continue on to the proper www.office.com. So the victims land on the proper login page, (and will see their custom logo..and theme....)...but what they don't know is there's a man in the middle proxy "sniffing the sessions"...and "capturing that token.

 

[britechguy]

So the victims land on the proper login page, (and will see their custom logo..and theme....)...but what they don't know is there's a man in the middle proxy "sniffing the sessions"...and "capturing that token.

Which just goes to show two (possibly more) things:

1. The bad guys will always figure out a way to get the result they want, eventually.

2. There comes a point where the complexity of the security makes it more difficult for the person/entity compromised to even realize that they have been. This is a problem (and one that is likely only going to get worse, not better).

I can understand, entirely, why cost-benefit analyses include "how much fraud, and of what type, can we tolerate." The cure(s) are often as bad as the diseases, and even worse when they can be silently compromised, often for extended periods.

 

[Metanis]

There comes a point where the complexity of the security makes it more difficult for the person/entity compromised to even realize that they have been.

I hate the thought that my systems are always compromised and I'll never know how. I sometimes think the worst possible job in the industry would be Chief Security Officer for a Fortune 500. Because you'll know you can never shut all the holes and every day could be the one you wake up to a massive breach.

 

[Sky-Knight]

I hate the thought that my systems are always compromised and I'll never know how. I sometimes think the worst possible job in the industry would be Chief Security Officer for a Fortune 500. Because you'll know you can never shut all the holes and every day could be the one you wake up to a massive breach.

It's easier than you'd think. Fortune 500 companies have resources for a proper SOC and utilize world class monitoring tools. Azure Sentinel is one of these, designed by Microsoft to keep M365 online and available for any of us to use.

The problem... how do you mine your data? But the good news? Everyone else has the same problem, so every day better means to parse that data are created providing absurd amounts of visibility into any device, anywhere, regardless of how it's connected.

No... the Fortune 500 is fine. It's the SMB that's screwed, because the product to perform the above is out of their reach to start with, much less the labor to staff the SOC required to operate it. The company I work for is among the cheapest in this space, and it's still $50 / device / month just to perform this task, and we're about to raise our rates.

Before the SMB considers SIEM / SOAR, I seriously recommend they focus on disaster planning.

Get a plan together that can format C: every device they own, and configure the entire environment in less than 24 hours. If you can perform that, doesn't really matter what the bad guys do. You'll have your backups, you'll have a means to deploy them, and turn back time. SIEM / SOAR is there because the nuke and pave the entire enterprise approach is too expensive, and we're investing to prevent that risk. But an office with 20 or less machines in it? If it's M365'd correctly when something happens you just run over there with a bunch of USB drives, nuke the entire thing from orbit and hope the malware isn't buried in someone's firmware somewhere.

 

[Markverhyden]

Modern MFA bypass uses a man in the middle assault, that proxies the live M365 environment. The user will get a real M365 prompt with all your configured details, login, and the authorization cookie is lifted and returned to the hacker which enables another browser anywhere in the world to access the account without any further authentication happening.

I wonder how wide spread token pillaging really is? I'm sure that there are black hats offering TTaaS (Token Theft as a Service). And the benefits of successfully executing that is in only in an SSO environment. At any rate the pickings are very slim in the consumer/home/small business market.

Found what I had mentioned above and it was a bit different than what I remembered. Instead of login credentials it was a $399 MS Defender type scam that was actually hosted on .NET.

 

[Sky-Knight]

I wonder how wide spread token pillaging really is? I'm sure that there are black hats offering TTaaS (Token Theft as a Service). And the benefits of successfully executing that is in only in an SSO environment. At any rate the pickings are very slim in the consumer/home/small business market.

Found what I had mentioned above and it was a bit different than what I remembered. Instead of login credentials it was a $399 MS Defender type scam that was actually hosted on .NET.

View attachment 15509

Extremely, if it's a MITM, it does this. If they can get a trojan on your box... they'll steal all the cookies looking for them. Teams is a browser, new Outlook is a browser... these auth tokens are THE THING to steal. Because they aren't limited to use on the device they're intended for UNLESS you have a TPM module to provide machine level authentication.

Which incidentally is why Windows 11 exists.

 

[YeOldeStonecat]

I wonder how wide spread token pillaging really is?

In one of the FB tech groups I'm in, IT BOG, I see frequent posts from frustrated IT guys of yet another client of theirs that got poached via this approach.

 

[britechguy]

In one of the FB tech groups I'm in, IT BOG, I see frequent posts from frustrated IT guys of yet another client of theirs that got poached via this approach.

The problem is that this tells you virtually nothing about the real prevalence of the approach.

Venues like that one, here at Technibble, BleepingComputer, ToyotaNation, and any support-type group is composed of a self-selected sample that is constantly dealing with problems. If we were to believe what we read right here on Technibble or what I read on ToyotaNation were characteristic of the majority of computers/Toyotas, I'd be left scratching my head as to how either of these things became as popular and nearly ubiquitous as they have.

If you have a 500K incidents, all of which might be reported on forums such as this one, but the user base is 1 billion, that doesn't make whatever that incident is "common." That's the thing I think gets forgotten far too often.

We, here, are going to far more commonly see reports of very uncommon phenomena because of the very nature of this venue. The fact that the reports are common here does not make those phenomena common in any meaningful sense.

 

[YeOldeStonecat]

The problem is that this tells you virtually nothing about the real prevalence of the approach.

Venues like that one, here at Technibble, BleepingComputer, ToyotaNation, and any support-type group is composed of a self-selected sample that is constantly dealing with problems. If we were to believe what we read right here on Technibble or what I read on ToyotaNation were characteristic of the majority of computers/Toyotas, I'd be left scratching my head as to how either of these things became as popular and nearly ubiquitous as they have.

Well, not really. While IT BOG consists of ~6,500 members, as per the usual....there are mostly a smaller handful that regularly post. And there are a few that I communicate with regularly outside of IT BOG....direct Teams conferencing, phone calls, email, etc. Several of them I have met in person, one of them being another MSP about the same size....1x hour north, I've stopped by his office a few times to hang 'n chat for hours, and visa versa. HE was the one that had one of his clients poached via this method..and it's the 3rd in 1x year that had the token theft. He has less 365 tenants that I do (I'm around 200 tenants). He's not bad with this typical tenant setup either.

 

[britechguy]

@YeOldeStonecat

We're just going to have to agree to disagree here. I'd also suggest you take a look at what population number-crunchers call incidence and prevalence.

3 Times in a year isn't "frequent" to me, and there are often periods where a given nefarious actor is active where they find a collection of convenient targets.

I do not believe that this is common in any meaningful sense of the word "common." It happens, but relative to the total user base of the technology being discussed, it's just not common. If it were, the tech press (at the very least) would be awash in hand-wringing articles about how this "is no longer adequate" and how a replacement is necessary yesterday.

 

[Sky-Knight]

The tech press is ignorant and at least two years behind prevailing trends. Why, I'm not entirely clear on and could wax conspiratorial on it... but the fact remains the tech press has been way behind my entire career, often patently wrong on critical details, and generally not useful for anything other than the broadest understanding.

This applies to the press as a whole as well, but in tech it's particularly bad. Or at least I think it's such because I know better.

 

[britechguy]

because I know better.

Yes, you are The World's Foremost Authority.

 

[YeOldeStonecat]

@YeOldeStonecat

We're just going to have to agree to disagree here. I'd also suggest you take a look at what population number-crunchers call incidence and prevalence.

3 Times in a year isn't "frequent" to me, and there are often periods where a given nefarious actor is active where they find a collection of convenient targets.

I do not believe that this is common in any meaningful sense of the word "common." It happens, but relative to the total user base of the technology being discussed, it's just not common. If it were, the tech press (at the very least) would be awash in hand-wringing articles about how this "is no longer adequate" and how a replacement is necessary yesterday.

Yeah we will. For an IT company that focuses on businesses only (like my friend an hour north of me)...to have 3x clients breached with the token theft is a huge wake-up call to make any responsible MSP re-think their approach with their clients.

If you sit down with a dozen or two dozen people every week...and you hear one or two or three of them tell a similar story every couple of weeks if not every single week...it's getting common. It's a hot topic because it's relevant.

I'm taking a deep dive into this to figure out how to:
*discover it/find it/get alerted when it happens
*Remediate it when it happens.

Across around 200 clients, I'd not be surprised if a few dozen of my clients are compromised by it.

I just can't be that lackadaisical with business clients.

 

[Sky-Knight]

@YeOldeStonecat It's a waste of energy sir, britechguy thinks he knows how infosec works, he's just incapable of seeing how far behind he is. Your approach is correct, and you're wise to be proactive. The devil is already within the walls, and as I mentioned before the only tools we have are risk based sign on protection (Entra ID P2), or using Conditional Access to limit M365 access to Entra ID Joined Machines... OR directing customers to use FIDO2 keys for authentication.

FIDO2 keys have an encryption key buried in them that's required to unlock the authtoken. They can steal the cookie all they want, FIDO flat stops it. Hello for Business uses it as the only means to be passwordless for the endpoint login too if you want to go that far as the TPM module becomes a FIDO key of sorts.

In the meantime, your trip wire is the impossible login. Can't have someone login in Pittsburgh at 10am, and then connect from LA a half hour later. It's not perfect, but it's all we've got until Microsoft upgrades something.

New Microsoft Purview Audit enhancements increase security visibility | Microsoft Security Blog

We have been making significant efforts to enhance the access of Microsoft Purview's audit logging, with more updates coming in future weeks.

www.microsoft.com

This didn't happen by accident... it was specifically this issue and how it's impacting large business and government clients that forced Microsoft to eat the costs of extended logging.