Crooks target top execs on Office 365 with MFA-bypass scheme A business email compromise scheme targeting CEOs and CFOs using Microsoft Office 365 combines phishing with a man-in-the-middle attack to defeat multi-factor authentication. These attacks take advantage of a Microsoft 365 design oversight that allows miscreants to compromise accounts with MFA enabled and achieve persistence …
Ironically, I got the notification that I needed to change my Plex password because of their leak. Even Plex required me to enter my 2FA code to change my password, however, so the notion that you would not need to enter a current 2FA code to change your authentication mode is mind-boggling.
I guess they thought it would cover the "lost or stolen" use case... but you can't distinguish between authenticator apps in the 2FA management screen either, so if one device goes walkabout how are you supposed to remove it?
You have to delete them all and set them up again on your remaining devices.
Double facepalm for Microsoft.
Not defending MS and their system does have some serious issues to look into but:
Both the primary method of managing your account on 365 and Azure AD do list the device name (internal model on android and name you gave it on IOS) against the authenticator.
If you want to get into the security methods to change your authenticator you do need to authenticate again...
This is on a standard tenancy with no special configuration - just checked.
it would be useful for MS to give more info about the authenticator like location last used but that would get into issues with privacy. They should ask you for a unique name when you set it up.
Maybe there's a admin screen with more info, but on mysignins.microsoft.com/security-info which is what I see, when I have three alternative authenticator apps registered (i.e. non-MS authenticator apps), I just see three lines with "Authenticator app" and no way to distinguish between them or get any more info.
Yes, it would be easy to fix by allowing the user type in a string when registering a new non-MS authenticator app which appears in the list, but it's probably right at the bottom of MS' to do list as it makes life easier for you to use non-MS software.
Okta shows me where an MFA request originated right on the approval screen. I take it MS Authenticator can't do that? In this case it would show the request coming from Singapore, so I would hope a user might be a little bit suspicious (though probably not - most are so tired of auth prompts they just kneejerk approve everything that comes along).
Apple's MFA checks locations. However, the geolocation system has... problems. On several occasions I've attempted to log in, got the MFA screen and have been told that the attempted login in in Atlanta, Georgia, or Dallas, Texas. No, I'm neither in Georgia or Texas. However, I do use AT&T for cell connections, and I was away from base, and AT&T has major operations in Atlanta and Dallas. As I knew damn well that it was me, having just clicked the link myself, I went ahead. If I had seen Hong Kong or Moscow I probably would not have.
In any case, if I don't like where the geotag says the query is coming from, restarting the device usually gets me a new IP which is usually somewhat more accurate. It's annoying, but paranoid, to have to restart, but there it is.
Why MS can't put up a location screen is, well, one of the questions I asked a certain organization who insists on using MS Authenticator. If they ever reply, not that I'm holding my breath while waiting, I'll get back to this question. I suggest that others not hold their breath either. An attempt to contact MS on this required considerable jumping through hoops (have you tried to talk to an actual human at MS recently?) and total incomprehension. The 'tech support' guy literally could not understand why I might want to know location infor for a MFA query.
Others may attempt to contact those who force MS Auth, and MS itself. Good luck. You'll need it.
They did not "discover" anything..... Been dealing with this since jan 2022 with multiple MS reports.... took them until June to admit they could duplicate it.
There is another interesting caveat to all this...... where even resetting the users PW will not return the account to normal & remove this setup. (even account shows no other authentication systems)
Had some MASSIVE arguments with both MS engineer staff and our so called support provider.
MS was at one stage INSISTING we give control to our service provider to come in as super admin above our organization so that they could insert other users to
manage our instance.
When that failed the blocked our ability to place support requests, other than via the service provider , and THEN they refused to act upon their service requests unless they were filed from OUR MS instance, basically they wanted any excuse to NOT deal with what we found.
Then when we pointed out that it was possible to log into other instances that were NOT allocated to our Admin PW or even domain name!!!, they almost shit the bed shouting its not possible.... actually yes it is.
needs certain conditions to exploit it, but doable.
Esp. when we refused to tell them how.. in view of them treating our business with such disrespect, why should we...
so for over 8 months not only do they have this shitfest.....but also a way to exploit admin login into other instances.
Their whole front end for security is a JOKE.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
