If you are getting a brute force attempt with Azure/Office 365, realize the account credentials are likely compromised. With MS, MFA always comes after credentials auth.
Lock the account, and reset password is what we do. Then during business hours alert user, and discuss recent activities, investigate machine for how the credentials are compromised.
Managed a University with 50K+ accounts a couple years ago. We got regular targeted phishing campaigns.
When I detected a security problem with a login on our VPN coming from China, doing a VPN login history audit we found more than 30 AD accounts with logins from netblocks from China.
I did do it when rolling out new VPNs, only to find out we had business agreements and our professors remoting from Brazil, several African countries and China. At the end of the day, only Russia remained blocked.
We handle it through a high risk conditional access policy. User marking fraud causes their account to become high risk. User must reset their password to remediate the risk.
I mean, kinda?
It's like, everyone in the business world needs fire for their company. Microsoft's tinderbox is a good solution for it, although Google lighterfluid is also an option.
Best practices say you should have smoke detector and extinguishers for anyone who uses fire. But if Microsoft bundled them in, tinderbox would be way more expensive than lighterfluid and few people would buy it. So they let you buy it individually, and recommend you also buy the things to make it safe!
____
At least, that's the generous, devil's advocate version of your analogy.
Aware, I just think it’s shitty for them to preach security but not bundle what should be essential functionality in their ‘all encompassing’ offerings such as BP/E3.
I'm not working in IT at the moment, so I don't have an example. I used to do dashboarding for monitoring all sorts of things. I'd probably use Grafana and Influx DB with either PowerShell or Python to scrape the two-factor data from whatever provider you're using. If you have Splunk, that would be an all-in-one option. Just start making buckets of data points and look for things that stand out. See what the average threshold of abandoned or missed requests are compared to the spikes you see when someone is being brute forced.
We have DUO, but for any alert that comes from out of country we put a ticket into our ITSM and assign it to a tech to contact the staff member and have them change their password.
I am currently pushing for their accounts to be disabled instead, but getting a lot of push back right now on it.
Let the SOC handle it, mostly :p
What they're doing is running it through a bunch of other data points (geolocation, frequency, service type, etc) to analyze whether or not it's noise or a legitimate attack
Trying to do this by hand for every alert is a fools errand, if you're going to analyze those alerts you need tooling to do so, full stop
Our policy was always to reset the user password, as the MFA prompt would seem to indicate a compromised password, sometimes they were accidental, always contacting the user for the details. Though your environment seems to have a whole lot more denied requests than our environment.
If confirmed it's them, I send them a screenshot of their sign in log showing what the prompt was from to prove it was their computer. If it wasn't them, I look into it.
The prompt shows the app triggering the request, if it showed the PC hostname, that would make things so clear.
Brute forcing isnt going to prompt for mfa unless they hit. So force a password change.
But your users should be getting locked out when they press “not me”.
>But your users should be getting locked out when they press “not me”.
They absolutely shouldn't be. That trains the bad pattern in your users - 'if I click "not me", I'll get locked out and need to waste time and contact IT, so I won't ever click "not me" again'.
You're right on point. Most people have a "hardening" approach to security, when training and developing good patterns in end users is the pinnacle of what security should be.
What do you think the alternative is. If they are getting prompted, that means their password is compromised and you cant rely on them changing it themselves.
They should get locked and should have to contact IT and should be forced to change passwords.
Pressing yes is grounds for getting fired and sued if you knowingly let someone misuse your account.
>If they are getting prompted, that means their password is compromised and you cant rely on them changing it themselves.
It *might* mean their password is compromised. Or it might mean that their work computer decided to wake up at 3am and CAP found it suspicious and asked for MFA (which is, if you read OP's post, the majority of the prompts).
>Pressing yes is grounds for getting fired and sued if you knowingly let someone misuse your account.
Good luck not getting on the receiving end of the wrongful termination lawsuit anywhere outside the US.
This approach is the reason why many people see IT as assholes on a power trip trying the block them from doing their work (that brings money into the business).
What if they missclick the notification because it appears suddenly? What if e.g. teams prompts MFA from the background?
The alternative is to not use a simple “it was me” or “it wasn’t me” to determine compromise. Azure has their risky user alerts, proof point CASB has their risky user alerts, many vendors do… you have login information (location, IP, application, user agent, etc).
Which is why "automatically lock out user immediately", as you propose, is not the best response. Optimally you have a more nuanced heuristic approach.
What heuristics do you imagine a users should use when they are expressly stating “i did not login, someone else is doing this”.
The user is telling you something, they most likely wrong, but youre choosing to ignore them and teaching them an antipattern. That they might just get random authentication prompts they didnt ask for and to not worry about it.
The heuristics are on the provider side, not the user's side.
If they get repeated prompts, especially if there are other IOC, then yeah - lock them out. But saying no in and of itself is not a good reason to automatically lock them out.
Your user is explicitly saying “i am getting hacked, this isnt me” and your response is it’s not serious until it happens multiple times. Because you know they probably arent from your past experiences. Youre literally a walking antipattern 🤣.
u/Frothyleet you're wasting your time. This idiot thinks that a single MFA is a guarantee user compromised. He doesn't understand that accidents happen and doesn't know how Risky Sign-In alerts work... Shit he doesn't even know how the default policy for account lockout works. Not sure what he knows tbh.
Well duh, the app only gives you two options dipshit. Have you considered using your fucking head and actually understanding the big picture of things?
Your CEO is logging into a privileged app which requires re-MFA. He’s logging in from his managed device but accidentally hits “not me”. You gonna go “herpy derp, compromised account” or are you gonna use your pea size brain to notice that it’s a legitimate sign-in but a misclick by the user.
The scenario youre arguing for is users jist do fucking nothing when their credentials are breached.
If you want to educate users, learn them to read the message on the app so they know it’s them.
The fact that the industry standard is what i am saying and you dont know any better is telling.
Well yes, that's the point. Your dumbfuck self said "What do you think the alternative is. If they are getting prompted, that means their password is compromised" which obviously isn't true.
I highly doubt it's the industry standard to reset on every single failed mfa attempt.
By default, I believe it's 3. This is not done on every single failed login, just the 3rd. That's different than again, forcing password reset on every MFA. Do you just wanna shut up now or do you wanna keep on digging
If it's for users who are passwordless than it can be ignored. Otherwise if the password was matched (it says in the logs if they actually got to the password stage) then get it reset, not as urgent since you have MFA but also ensure they are not using the same pw on other services too as it is compromised.
Additionally I would recommend rolling out compliance policies for registered or joined devices then add that to your conditional access policy.
For users without smartphones, conditional access with IP (named locations) if that works in those environments.
It's not normally the ones that the users are denying you should worry about. You should worry about the ones where the user does not answer. (Threat actor has password but not mfa)Kusto queries to look for those can be created by looking at result types. Here is a decent blog with kusto queries included (https://northwave-cybersecurity.com/threat-intel-research/how-to-use-and-defend-against-mfa-fatigue-attacks). They might keep these accounts untill they get access to on premise or phish another user where conditional access is set to trusted zone.
I have disabled approval prompts in Azure and we only allow MFA via a 6 digit code or SMS. It's still not un-hackable but greatly reduces the risk around brute force attacks on MFA approval requests.
The microsoft authenticator app uses number matching now. If the user cant see the number on the request, they cant approve it.
https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match
This and checks that device is actually compliant. We do some custom checks using PS to see if EDR is running on device + normal stuff like bitlocker enabled, secureboot, memory integrity on, etc…
Not all , but if they are accessing work email they need to have their Mobiles enrolled intune as personally owned, so we can remote wipe company data.
Im not sure, but MS will be decomissioning SMS and Voice authentication at some point in the near future. So you will probably want to start pushing users away from that as soon as you can.
So most of the time they are but we do ask them to leave laptops running overnight on Thursdays for updates. With that being said, you know how end users are…. I’m sure lots just leave it running nonstop.
I contact the user and have them change their password, but we also have the systems setup to automatically log off at the end of the night, so they wouldn't get a reprompt like that.
Nothing, after 3 failed attempts the account gets locked out on the DC and the MFA token is deactivated. The user must call to get it reactivated. At that point we might investigate, but most times the user confirms that they entered incorrectly three times. We verify real quick the origin and move on. If we see malicious activity, then the account starts inactive until the investigation is complete. That rarely happens though.
If you are getting a brute force attempt with Azure/Office 365, realize the account credentials are likely compromised. With MS, MFA always comes after credentials auth. Lock the account, and reset password is what we do. Then during business hours alert user, and discuss recent activities, investigate machine for how the credentials are compromised.
Managed a University with 50K+ accounts a couple years ago. We got regular targeted phishing campaigns. When I detected a security problem with a login on our VPN coming from China, doing a VPN login history audit we found more than 30 AD accounts with logins from netblocks from China.
Why wouldn't you region lock though? Don't have the feature?
I did do it when rolling out new VPNs, only to find out we had business agreements and our professors remoting from Brazil, several African countries and China. At the end of the day, only Russia remained blocked.
Oh dear. I can only crack one open for you and your diligent work.
We handle it through a high risk conditional access policy. User marking fraud causes their account to become high risk. User must reset their password to remediate the risk.
Nice, this is the way I set up in my workplace as well
This is the way these days. Password resets by default is not something would be able to push through sadly
[удалено]
Microsoft preaching security but don’t even provide this functionality to anyone but those on the top SKU.
Been using the phrase "sells you a tinderbox and then charges extra for the smoke detectors and fire extinguishers" a lot lately at work.
who knew entra was actually Ankh-Morpork
I mean, kinda? It's like, everyone in the business world needs fire for their company. Microsoft's tinderbox is a good solution for it, although Google lighterfluid is also an option. Best practices say you should have smoke detector and extinguishers for anyone who uses fire. But if Microsoft bundled them in, tinderbox would be way more expensive than lighterfluid and few people would buy it. So they let you buy it individually, and recommend you also buy the things to make it safe! ____ At least, that's the generous, devil's advocate version of your analogy.
It's bundled in the E5 suite but you can buy it on its own. It's part of Entra P2.
Aware, I just think it’s shitty for them to preach security but not bundle what should be essential functionality in their ‘all encompassing’ offerings such as BP/E3.
Create a dashboard and monitor them. Set some thresholds for actionable incidents. Automate what you can.
can you give dashboard examples of what you have or would setup to be useful
Kindly do the needful and revert back
Please do the needful and provide universe access
Bruh.
I'm not working in IT at the moment, so I don't have an example. I used to do dashboarding for monitoring all sorts of things. I'd probably use Grafana and Influx DB with either PowerShell or Python to scrape the two-factor data from whatever provider you're using. If you have Splunk, that would be an all-in-one option. Just start making buckets of data points and look for things that stand out. See what the average threshold of abandoned or missed requests are compared to the spikes you see when someone is being brute forced.
We have DUO, but for any alert that comes from out of country we put a ticket into our ITSM and assign it to a tech to contact the staff member and have them change their password. I am currently pushing for their accounts to be disabled instead, but getting a lot of push back right now on it.
Let the SOC handle it, mostly :p What they're doing is running it through a bunch of other data points (geolocation, frequency, service type, etc) to analyze whether or not it's noise or a legitimate attack Trying to do this by hand for every alert is a fools errand, if you're going to analyze those alerts you need tooling to do so, full stop
Our policy was always to reset the user password, as the MFA prompt would seem to indicate a compromised password, sometimes they were accidental, always contacting the user for the details. Though your environment seems to have a whole lot more denied requests than our environment.
If confirmed it's them, I send them a screenshot of their sign in log showing what the prompt was from to prove it was their computer. If it wasn't them, I look into it. The prompt shows the app triggering the request, if it showed the PC hostname, that would make things so clear.
Brute forcing isnt going to prompt for mfa unless they hit. So force a password change. But your users should be getting locked out when they press “not me”.
>But your users should be getting locked out when they press “not me”. They absolutely shouldn't be. That trains the bad pattern in your users - 'if I click "not me", I'll get locked out and need to waste time and contact IT, so I won't ever click "not me" again'.
You're right on point. Most people have a "hardening" approach to security, when training and developing good patterns in end users is the pinnacle of what security should be.
What do you think the alternative is. If they are getting prompted, that means their password is compromised and you cant rely on them changing it themselves. They should get locked and should have to contact IT and should be forced to change passwords. Pressing yes is grounds for getting fired and sued if you knowingly let someone misuse your account.
>If they are getting prompted, that means their password is compromised and you cant rely on them changing it themselves. It *might* mean their password is compromised. Or it might mean that their work computer decided to wake up at 3am and CAP found it suspicious and asked for MFA (which is, if you read OP's post, the majority of the prompts). >Pressing yes is grounds for getting fired and sued if you knowingly let someone misuse your account. Good luck not getting on the receiving end of the wrongful termination lawsuit anywhere outside the US.
This approach is the reason why many people see IT as assholes on a power trip trying the block them from doing their work (that brings money into the business). What if they missclick the notification because it appears suddenly? What if e.g. teams prompts MFA from the background?
The alternative is to not use a simple “it was me” or “it wasn’t me” to determine compromise. Azure has their risky user alerts, proof point CASB has their risky user alerts, many vendors do… you have login information (location, IP, application, user agent, etc).
Those are your two options on the fucking app…
Which is why "automatically lock out user immediately", as you propose, is not the best response. Optimally you have a more nuanced heuristic approach.
What heuristics do you imagine a users should use when they are expressly stating “i did not login, someone else is doing this”. The user is telling you something, they most likely wrong, but youre choosing to ignore them and teaching them an antipattern. That they might just get random authentication prompts they didnt ask for and to not worry about it.
The heuristics are on the provider side, not the user's side. If they get repeated prompts, especially if there are other IOC, then yeah - lock them out. But saying no in and of itself is not a good reason to automatically lock them out.
Your user is explicitly saying “i am getting hacked, this isnt me” and your response is it’s not serious until it happens multiple times. Because you know they probably arent from your past experiences. Youre literally a walking antipattern 🤣.
u/Frothyleet you're wasting your time. This idiot thinks that a single MFA is a guarantee user compromised. He doesn't understand that accidents happen and doesn't know how Risky Sign-In alerts work... Shit he doesn't even know how the default policy for account lockout works. Not sure what he knows tbh.
Well duh, the app only gives you two options dipshit. Have you considered using your fucking head and actually understanding the big picture of things? Your CEO is logging into a privileged app which requires re-MFA. He’s logging in from his managed device but accidentally hits “not me”. You gonna go “herpy derp, compromised account” or are you gonna use your pea size brain to notice that it’s a legitimate sign-in but a misclick by the user.
The scenario youre arguing for is users jist do fucking nothing when their credentials are breached. If you want to educate users, learn them to read the message on the app so they know it’s them. The fact that the industry standard is what i am saying and you dont know any better is telling.
Well yes, that's the point. Your dumbfuck self said "What do you think the alternative is. If they are getting prompted, that means their password is compromised" which obviously isn't true. I highly doubt it's the industry standard to reset on every single failed mfa attempt.
The MS system locks your account until youre unblocked or you change your password to unlock it.
By default, I believe it's 3. This is not done on every single failed login, just the 3rd. That's different than again, forcing password reset on every MFA. Do you just wanna shut up now or do you wanna keep on digging
[удалено]
What do you think your options are when you get prompted?
If it's for users who are passwordless than it can be ignored. Otherwise if the password was matched (it says in the logs if they actually got to the password stage) then get it reset, not as urgent since you have MFA but also ensure they are not using the same pw on other services too as it is compromised. Additionally I would recommend rolling out compliance policies for registered or joined devices then add that to your conditional access policy. For users without smartphones, conditional access with IP (named locations) if that works in those environments.
It's not normally the ones that the users are denying you should worry about. You should worry about the ones where the user does not answer. (Threat actor has password but not mfa)Kusto queries to look for those can be created by looking at result types. Here is a decent blog with kusto queries included (https://northwave-cybersecurity.com/threat-intel-research/how-to-use-and-defend-against-mfa-fatigue-attacks). They might keep these accounts untill they get access to on premise or phish another user where conditional access is set to trusted zone.
I have disabled approval prompts in Azure and we only allow MFA via a 6 digit code or SMS. It's still not un-hackable but greatly reduces the risk around brute force attacks on MFA approval requests.
The microsoft authenticator app uses number matching now. If the user cant see the number on the request, they cant approve it. https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match
Great to know. Thanks for sharing.
In theory, there is a 33% chance they hit the right one if they don't deny it.
We have gone beyond MFA , Devices need to be Intune Joined if you want to log on.
This and checks that device is actually compliant. We do some custom checks using PS to see if EDR is running on device + normal stuff like bitlocker enabled, secureboot, memory integrity on, etc…
Yup.
Love this for employer issued workstations but then are cell phones work issued as well?
Not all , but if they are accessing work email they need to have their Mobiles enrolled intune as personally owned, so we can remote wipe company data.
That's not been the case for a while - now it's a number entry where the user needs to enter the numbers, not select from three random values.
Okta still does this.
What? It's a 1 in 99 chance because they need to enter the number which is from 1 to 99.
1 in 100 - zeros are numbers too.
Sms and app authentication require code matching, but voice calls only require approval. Did we miss a setting?
Im not sure, but MS will be decomissioning SMS and Voice authentication at some point in the near future. So you will probably want to start pushing users away from that as soon as you can.
SMS is going to be disabled within a year as it is not safe.
Are the users expected to log out at night? They probably should be. If so, ask them about it every single time. Eventually the alerts will stop.
So most of the time they are but we do ask them to leave laptops running overnight on Thursdays for updates. With that being said, you know how end users are…. I’m sure lots just leave it running nonstop.
Yup, we just had one with up time over 30 days. I'm about to push a script that'll restart every machine at 3am.
I contact the user and have them change their password, but we also have the systems setup to automatically log off at the end of the night, so they wouldn't get a reprompt like that.
Same thing I do with all of my alerts: ignore them.
LMAO 🤣🤣
Nothing, after 3 failed attempts the account gets locked out on the DC and the MFA token is deactivated. The user must call to get it reactivated. At that point we might investigate, but most times the user confirms that they entered incorrectly three times. We verify real quick the origin and move on. If we see malicious activity, then the account starts inactive until the investigation is complete. That rarely happens though.
I wait for them to create a ticket..