Bypass Office 365 strong authentication (MFA) in 3 lines (and fix it 😉 )

Strong authentication is an authentication performed with an identifier (login, email...) and, at least, two different factors among :

• What I know (my password, a sentence...) ;
• What I am (biometrics such as fingerprint, retina, foul breath...)
• What I can do (signature, coded gesture https://twitter.com/mynameisv_/status/1258372512628555779 ...) ;
• What I own (a phone receiving a code by SMS, a smartphone receiving a notification, a small token generating one-time codes or OTP derived from time and a secret, or the same thing but in application on a smartphone...);
• The place where I am (geolocation) ;
• ... Strong authentication is often called "Multi Factor Authentication / MFA" and sometimes also called "Two-Factor Authentication / 2FA", a subclass of MFA limited to the use of 2 factors. But by abuse of language, the MFA is generally about strong authentication with 2 factors.

For more details, I refer you to the Wikipedia god: https://fr.wikipedia.org/wiki/Authentification_forte

Once authenticated on a system (website, API, application...), you usually get a session identifier (cookie, token, JWT, PHPSESSIONID...) valid for a given time, sent back at each action, to avoid re-authentication.

Yes, there are many "..." 😉.

Therefore, we should not confuse :

• Authentication and Identification, authentication is an identification with a proof in the form of an authenticator (such as a password) ;
• Simple authentication (a login and a password) and strong authentication ;
• Strong "crap" authentication with two passwords and true strong authentication.

Office 365 is your email (and many others things) managed by Microsoft in SaaS and that you pay every month without any possible amortization.

The solution is adapted to a large number of companies (except for very competitive or secret sectors), works really well, simplifies the management of your email (and part of the information system such as SharePoint), and allows you to have a higher level of security than when the email was managed internally.

The problem is that cybercriminals massively attack companies using Office 365 because it gives an almost unique entry point to use the same attack tools with simple techniques:

• Password spraying, which consists in trying to authenticate on many accounts but with very few passwords such as "CompanyName2020!", allowing not to block accounts with too many failed attempts;
• Password Reuse, which consists in recovering public leaks containing users and their passwords and trying these passwords, having previously found the companies of these users, their professional email... ;
• Phishing, which consists in sending emails containing a link to a fake Office 365 authentication form in order to steal the user's login and password.

Many organizations get Office 365 accounts compromised due to weak, predictable or reused passwords. This usually results in dozens of account compromises every week, costing security people a lot of time and energy.

The easiest way to block these attacks is to implement strong authentication. Even if the attacker finds your password, they'll be blocked by requiring the second authentication factor.

To benefit from MFA on Office 365, at this time, you just need a Microsoft 365 license (plan) (or Azure AD Premium P1 or P2). You have many documentations at Microsoft on the different ways to activate the MFA, the main one being here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

Note that as a bonus, some companies use an internal identifier (I5178Y1, X171819, apricot for Alexandre BRICOT...) but not the full email. If the company uses an Office 365 authentication based on an identity repository kept internally (ADFS), the strong authentication is then done in several steps on the Office 365 website:

• Entering the email on the portal ;
• Redirection to the ADFS;
• Entering the login and password;
• Redirection to Office 365;
• Enter the second authentication factor. In this case, if the internal credentials are not trivial, then the company almost has some sort of additional security 😉.

MFA is great but unfortunately it is possible to bypass it and it is a feature!

However, you still need a valid login and password (but if you knew how many people put "CompanyName2019!" or 2020, as their password...).

Generally, you use one of these two access methods:

• Your browser, supporting strong authentication by nature (which is true and false, because it is not the browser that supports MFA but the fact of accepting redirects but let's move on, let's keep it simple) ;
• Your heavy client like Outlook, Teams, Word, App Mail on iOS... supporting MDA and working with the Outlook Anywhere protocol (RCP over HTTP with or without SSL/TLS encryption but it's better with 😉 ) or with the Messaging Application Programming Interface / MAPI protocol (SOAP based protocol and containing Microsoft's filthy XML "over HTTP" with all the doc here: https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxprotlp/30c90a39-9adf-472b-8b5b-03c282304a83?redirectedfrom=MSDN)){:target="_blank"} Microsoft being the specialist of backward compatibility, naturally, Office 365 supports a very large number of ways to access the mail (I simplify to avoid making long lists of what can be accessed: mail, contacts, calendar and sometimes files, sharepoint, azure features ...), many of which do not support this famous MFA, which allows to bypass it.

You will find in this article several of these workarounds, using MailSniper: https://www.blackhillsinfosec.com/bypassing-two-factor-authentication-on-owa-portals/

Here is the list of the different protocols and workarounds:

• Exchange Control Panel (ECP), this is actually the "options" section of Outlook Web Access / OWA, the Outlook web client;
• ActiveSync, the mobile access, used from the native iPhone / Android email applications;
• Exchange Web Services (EWS), generally used for accessing mailbox content or accessing calendar availability information, but mostly by Outlook for Mac;
• POP and IMAP, the old protocols from the 80's ;
• PowerShell;
• REST API, another method of accessing mailboxes, which has (had?) to be replaced by EWS;
• Autodiscover, a way to discover the configuration options of a mailbox. Here, we will focus on EWS, released in 2007, based on SOAP and supporting only "basic auth", an old web authentication protocol that sends the login and password in clear text (almost). For more details with diagrams, you can read this article: https://blog.behrouze.com/basic-auth/

Note that EWS was supposed to be deprecated on October 13, 2020 (https://techcommunity.microsoft.com/t5/exchange-team-blog/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/ba-p/608055) but because of COVID, its end is postponed to mid-2021 (see last comment of the article). This in order to favor modern protocols like OAuth 2.0 (I'll do an article soon about OAuth, SAML, OpenID Connect...).

Here is my account with a client with a code sent by SMS as MFA:

And here is how to bypass the MFA in 3 lines (and again, I'm being generous with the count), using the MailSniper tool (https://github.com/dafthack/MailSniper) which by default will look for mails containing "password", "creds"... :

powershell -exec bypass

Import-Module .mailSniper.ps1

Invoke-SelfSearch -Mailbox vladimir.kolla@****.com -ExchHostname outlook.office365.com -remote

In 1 line for fun :

powershell -exec bypass -c "Import-Module .\MailSniper.ps1; Invoke-SelfSearch -Mailbox vladimir.kolla@****.com -ExchHostname outlook.office365.com -remote;"

This opens a window to ask (again) for the email and especially the password, but no second factor:

Then the magic happens, I'm connected to my mail bypassing the MFA and the tool looks for the keywords in my mails (I had sent me mails with the word "password" to get a result) :

You can also do it manually in PowerShell, here is an example (dirty) listing the titles of the first 200 mails of each mailbox:

No, but my detection experts will detect your underworld rebus technique!

Having logs is good, watching them is better.

However, since we operate in the world of witchcraft, if you use Microsoft's CloudAppSec log analysis tool, you won't see these accesses.

That's beautiful!

From what I understand, this category of access is filtered upstream and does not show up in Microsoft's security tools so as not to pollute the console. So either you do what you need to do and get drowned in useless logs or... uh... Joker!

So as it is, if someone uses this technique and steals all the emails of a user, it will be almost invisible.

To see these accesses, you have to go to the Azure administration portal (https://portal.azure.com) > then to :

Azure Active Directory

Sign-Ins (yes, the thing on the left, at the very bottom, almost hidden, as if they were ashamed😉)

Create a "Client App" filter with the "Add Filter" button.

Set this filter to select "Exchange Web Services" (because in my case I used EWS but otherwise you would have to select all the workarounds listed above)

And there, finally, under your amazed eyes, you can see the users legitimately using a protocol that will soon be deprecated or ... Tajik cybercriminals from the south of North Korea of the CIA (note that I added a filter displaying only the successes) :

Countermeasures

First of all, as said above, Microsoft is progressively depreciating all these old ways of access with a high risk of breaking stuff but that's your problem, not theirs : << Welcome to the jungleCloud !!! >>

In the meantime, you'll have to create a conditional access policy, applied to all users and blocking those old accesses. On the other hand, remember to activate it because recently, despite an accompaniment from Microsoft, a "none" was put instead of an "All cloud apps" which allowed to continue to bypass the MFA 😉:

Note also that the activation of the strategy may take 24 hours to be applied (see comments): https://techcommunity.microsoft.com/t5/exchange-team-blog/modern-auth-and-unattended-scripts-in-exchange-online-powershell/ba-p/1497387