Feb 01 2018 03:37 PM
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.
Am I missing something? Is this actually a reality.
Andy
Feb 01 2018 06:18 PM
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.
Feb 01 2018 10:53 PM
SolutionFeb 02 2018 12:12 AM
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.
Feb 02 2018 07:21 AM
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.
Sep 02 2019 02:52 PM
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.
Dec 03 2019 11:05 AM
@Steven Seligman - Thanks for staying on top of this and replying. Yes, I saw this feature show up on the consumer side and I like it. It seems like a good compromise.
Feb 01 2018 10:53 PM
Solution