In August 2020, Microsoft posted an article focused on email authentication utilizing their Azure Active Directory (AD) authentication and the use of Multi-Factor Authentication (MFA).
The issue is in order to support legacy email protocols such as SMTP, IMAP, MAPI and POP, MFA is not supported and thus, not utilized even in an organization with Azure AD MFA required.
This permits threat actors to log into those email accounts using single-factor authentication, bypassing any MFA security safeguards. According to the article, the authentication protocols identified as “legacy” in Azure include:
- Authenticated SMTP - Used by POP and IMAP clients to send email messages.
- Autodiscover - Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.
- Exchange ActiveSync (EAS) - Used to connect to mailboxes in Exchange Online.
- Exchange Online PowerShell - Used to connect to Exchange Online with remote PowerShell. If you block basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect. (For instructions, see Connect to Exchange Online PowerShell using multi-factor authentication.)
- Exchange Web Services (EWS) - A programming interface used by Outlook, Outlook for Mac, and third-party apps.
- IMAP4 - Used by IMAP email clients.
- MAPI over HTTP (MAPI/HTTP) - Used by Outlook 2010 and later.
- Offline Address Book (OAB) - A copy of address list collections downloaded and used by Outlook.
- Outlook Anywhere (RPC over HTTP) - Used by Outlook 2016 and earlier.
- Outlook Service - Used by the Mail and Calendar apps for Windows 10.
- POP3 - Used by POP email clients.
- Reporting Web Services - Used to retrieve report data in Exchange Online.
- Other clients - Other protocols identified as utilizing legacy authentication.
This issue came to light when an organization with MFA in place received a number of spearphishing emails from an internal email address. An investigation revealed a user from Russia logged in to the user’s email account via a legacy protocol using breached credentials. The threat actor then had unrestricted access to the employee’s email, as only single-factor authentication was required. The threat actor began sending spearphishing emails to organization employees.
Pre-Attack Phase
During the pre-attack phase, the organization noticed a number of failed authentication attempts using legacy protocols. This was to establish whether those protocols were supported, which would clear the way for a single-factor authentication entry into the victim’s account.
Attack Phase
Threat actors were able to log in and access email using single-factor authentication via breached credentials. They were able to send emails under the employee’s account; this could have resulted in significant brand damage and fraud focused on both employees and customers.
Determining if legacy authentication protocols are in use
- Navigate to the Azure portal > Azure Active Directory > Sign-ins.
- Add the Client App column if it is not shown by clicking on Columns > Client App.
- Add filters > Client App > select all of the legacy authentication protocols. Select outside the filtering dialog box to apply your selections and close the dialog box.
Applying this filter will permit you to review which users are utilizing legacy protocols to authenticate. You can view additional details about the authentication by clicking on the individual users in the interface and reviewing the authentication protocol available in the Client App field.
Mitigation
Mitigating the risk can take two forms, directly or indirectly blocking the use of legacy authentication protocols. The process for each technique and the user impact is covered on the Microsoft advisory page.