Forum Discussion
O365 MFA Mobile App Security Concern
We have implemented MFA in a broad section of test users. MFA was on the deployment plan, but it's getting fast tracked to mitigate an all out barrage of phishing attacks recently that specifically target non-MFA O365 users. I assume that the vector in known to everyone, but to summarize.
User receives phishing email. User acts on phishing email and provides their username/password to bad actor. Bad actor logs in to Office 365 via web portal using username/password of user. Bad actor trolls Outlook on the Web and finds relevant emails. Bad actor initiates new email from within O365 portal as user using language from user's email. Bad actor creates one or more Outlook rules via the web to handle bounces and replies. Bad actor maintains presence via Outlook on the Web, coming and going freely, until they are found by log scans or suspicious user or recipient of outbound emails.
MFA short circuits this process and is therefore good. One of the options for secondary verification via the mobile app is to receive auth request via the mobile app. This reduces complexity by allowing the user to just press Approve. The problem is that the same sort of user who would unknowingly be tricked into clicking and acting on a phishing scam is the same user who would blindly click on "Approve" if an auth request came in without an associated known logon attempt.
Why do I think this? Because when I talk to the rank and file user, most of them are never aware that they compromised their credential. As a matter of fact, most of them don't even remember entering their credential. It's entirely possible that they would receive an MFA Approve request and just press Approve because they figure that since the system is asking for something, that they must have done something to initiate it.
Additionally, although I have not heard of this happening, I could imaging a hacker scripting the process at the time of the initial compromise to pass the credentials to O365. That would kick off an Auth request and the user would think that they were responding to the initial request.
Having to enter a code, either via the app or from a text forces the user to interact with a part of the auth process. That one feels to me like it would be harder to spoof.
I keep thinking about this issue and hoping that I'm missing something and that it's not possible, but I've tested it up and down using multiple systems and, so far, it's totally possible.
Here's a simple test assuming that an account is configured to allow Auth requests via the mobile app.
- Go to anyone else's mobile device other than yours (assuming yours is the test account).
- Using the other mobile device's browser, log on to portal.office.com.
- Authenticate using your (test account's) user name and password. Imaging that you are entering from halfway around the world.
- The auth request will show up on your verification phone (test account device). Blindly press Authorize as an unsuspecting user might.
- You will be granted access via the alien device and, if the unwitting user was nice enough to click "Don't ask me for X days" then you may have just bought yourself some more hack time.
Am I missing something? Is this actually a reality.
Andy
- I agree that if a user is tricked into giving away their password, it is likely that the same user could also be duped into happily pressing a button on their phone, especially if the memo from IT says "you will soon receive a pop-up box on your phone, don't worry, that's just us, please authorize that." Sigh.
Here are some things that may help you:
1) In the MFA service settings page, uncheck the option for "Notification through mobile app" leaving only "text message to phone" or "Verification code from mobile app"
https://account.activedirectory.windowsazure.com/UserManagement/MfaSettings.aspx
2) Consider investing in an Azure AD Premium P1 license as this provides an additional conditional access feature where you can block users who are not domain joined, or are not enrolled in Intune... You can also implement IP Fencing rules to block countries that you don't do business with. For example, a lot of phishing is originating from IP addresses associated with Nigeria, so you could block all IP's from logging in from that country.
3) Simulate phishing attacks then follow up with user training
- Cian AllnerSilver Contributor
Interesting points you raise, though I haven't tested the specific steps you mention it sounds plausible though it relies on the account's password to be compromised beforehand, as you mentioned for the user to follow through and approve the MFA prompt.
User education is important, part of the rollout could tackle the scenario of looking out for unexpected MFA prompts. Also, there is the option of fraud alerts, though I have only seen that working via phone call. MFA is great but it's not a panacea, for example, it won't particularly help with Illicit Consent Grants, a threat highlighted recently.
Good practices would be also to make use of the Azure security reports (users flagged for risk and risky sign-ins), an upcoming feature of Secure Score will allow you to test users, simulating a phishing attack, and more besides.
- Joe StockerBronze ContributorI agree that if a user is tricked into giving away their password, it is likely that the same user could also be duped into happily pressing a button on their phone, especially if the memo from IT says "you will soon receive a pop-up box on your phone, don't worry, that's just us, please authorize that." Sigh.
Here are some things that may help you:
1) In the MFA service settings page, uncheck the option for "Notification through mobile app" leaving only "text message to phone" or "Verification code from mobile app"
https://account.activedirectory.windowsazure.com/UserManagement/MfaSettings.aspx
2) Consider investing in an Azure AD Premium P1 license as this provides an additional conditional access feature where you can block users who are not domain joined, or are not enrolled in Intune... You can also implement IP Fencing rules to block countries that you don't do business with. For example, a lot of phishing is originating from IP addresses associated with Nigeria, so you could block all IP's from logging in from that country.
3) Simulate phishing attacks then follow up with user training- ABaerstBrass Contributor
Yes, you are correct. These are all reasonable actions to implement.
We train, train, train. That's what is so concerning. We follow up after training with more reminders and examples. The very same users who swear that they would never click and act on a phishing attempt often get walloped and then have absolutely no recollection that they handed over their credentials. Their response usually includes, "well, it looked real...."
I was hoping that someone would leap forward on my post and point out an obvious flaw in my logic, but that doesn't seem to be the case. I can't see moving forward with the straight Approve method until I can come to peace with this issue. With a security hole this easily exploited, Notification Only seems like just pushing the issue one layer up and adding a process that provides a false sense of security.
I like MFA and think that it solves a big issue and is common place enough to be accepted and familiar to most users. I just have concerns about this one facet of this implementation of MFA.
Thanks for your recommendations.
- JayFMSTechCommIron Contributor
It seems like the consumer Microsoft Account has a partial solution to the oblivious user. When requiring identity verification, it prompts the user to Approve the Push Notification with Number xx. On the phone, it lists three choices: xx yy zz, and the user is supposed to push xx, instead of just "approve". If the hacker can't directly communicate with the hacked user, after he enters the compromised user ID and password, he can't tell the hacked user which approve option to press. However, the oblivious hacked user still has a 1 in 3 probability of accidentally pressing the correct auth code. Perhaps Microsoft should prompt the user with nine possible auth codes, greatly reducing the probability of a lucky guess when making a reply to an unrequested approval notification.
Well, there is no protection against oblivious users. But you definitely have a point here, and it's more and more relevant nowadays with the shift towards passwordless auth. Personally, I don't think that using MFA as primary auth is in any way more secure than password. Sure, it's convenient, no doubt about it. But without proper user education and additional controls, it's right there in the same boat as Password123.