and hackers have developed ways to bypass multi-factor authentication (MFA) on cloud productivity services like Microsoft 365 (formerly Office 365).
A BEC attack recently analyzed by cloud incident response company Mitiga used an adversary-in-the-middle (AitM) phishing attack to bypass Microsoft Office 365 MFA and gain access to a business executive’s account and then managed to add a second authenticator device to the account for persistent access. According to the researchers, the campaign they analyzed is widespread and targets large transactions of up to several million dollars each.
Initial access for the BEC attack
The attack started with a well-crafted phishing email masquerading as a notification from DocuSign, a widely used cloud-based electronic document signing service. The email was crafted to the targeted business executive, suggesting that attackers have done reconnaissance work. The link in the phishing email led to an attacker-controlled website which then redirects to a Microsoft 365 single sign-on login page.
This fake login page uses an AitM technique, where the attackers run a reverse proxy to authentication requests back and forth between the victim and the real Microsoft 365 website. The victim has the same experience as they would have on the real Microsoft login page, complete with the legitimate MFA request that they must complete using their authenticator app. Once the authentication process is completed successfully, the Microsoft service creates a session token which gets flagged in its systems that it fulfilled MFA. The difference is that since the attackers acted as a proxy, they now have this session token too and can use it to access the account.
This reverse proxy technique is not new and has been used to bypass MFA for several years. In fact, easy-to-use open-source attack frameworks have been created for this purpose.
Secondary authenticator app provides persistence
According to the logs analyzed by Mitiga, the attackers used the active session to add a secondary authenticator app to the compromised account, giving them persistence even if that session token later expired. Because they already intercepted the user’s credentials, they now had their own method to generate MFA codes.
“Adding an additional MFA device to an Azure AD user does not require any additional verification, such as re-approving MFA for the session,” the researchers said in their report. “This means that the attacker can add an MFA device to the victim account even an entire week after the session was stolen without invoking any further user interaction, such as re-prompting for MFA approval.”
The researchers believe this is a design weakness in Microsoft’s authentication system, because in their opinion, security-sensitive actions such as modifying MFA options, including adding a new MFA device, should prompt an MFA rechallenge. In fact, this is not the only sensitive action where this doesn’t happen. According to the researchers, using the Privileged Identity Management (PIM) feature in Azure AD, which allows admins to temporarily elevate their privileges, does not require an MFA rechallenge, either.
“PIM is designed so that administrative users can work with non-administrative rights and only elevate their permissions to an administrator using this portal,” the researchers said. “Microsoft does not, however, allow the customer to require an MFA rechallenge for this activity despite its high risk. This means that even if you have PIM enabled, if the account is compromised, the attacker can become an administrator by going to the PIM portal themselves (although, at least in this case, the user will get a notification that someone activated that privilege).”
Another issue that Mitiga highlights is that customers don’t have the option to configure when an MFA rechallenge happens if they consider the default behavior insufficiently strict. The best they can do is set the expiration time for the session token to the lowest possible value to limit the time window the attacker has, but that’s not practical because they attacker needs seconds to perform such an action.
In this incident, attackers used the session token from an IP address in Dubai, a location that the victim has never been at or logged in from previously. Such a change in location should also prompt an MFA rechallenge.
“Microsoft Identity Protection has identified some of these as risky sign-ins,” the researchers said. “However, unless an organization can withstand some of the false positives generated by Identity Protection, the default behavior is to require an MFA rechallenge, which is not effective at this point because the attacker already has the Authenticator app set up.”
Reconnaissance and email thread hijacking
After they gained access to the executive’s Microsoft 365 account, the attackers started looking through his Outlook correspondence and SharePoint files. This allowed them to identify an email thread about an upcoming transaction between the victim’s company and another one. The discussion had multiple people copied in, including the company’s executives and lawyers from the law firm representing the organization, as well as executives from the third-party firm that was supposed to send the fund and its lawyers.
The attackers searched for files related to the transaction, including contracts and other financial records. They then registered fake domain names for the victim’s company and its law firm and crafted an email in the name of one of the lawyers, notifying the third-party company that the victim’s company has updated its wire instructions and account due to an ongoing audit freezing their regular account.
The reason why the fake domains, which were similar to the real ones, were needed was to create the appearance of keeping all previous parties in the email thread but using fake email addresses instead so they don’t actually get the new email. Only representatives of the third-party company that was supposed to initiate the transaction saw the rogue email.
Fortunately, one of the recipients became suspicious about the email so the transaction didn’t go through, but there are many cases where employees act on such carefully constructed emails and wire money to accounts controlled by attackers. According to the FBI’s Internet Crime Complaint Center (IC3), BEC attacks have led to over $43 billion in losses between June 2016 and December 2021.
“Given the accelerated growth of AitM attacks (even without the persistence allowed by an attacker adding a new, compromised, authentication method), it is clear that we can no longer rely on multi-factor authentication as our main line of defense against identity attacks,” the researchers said. “We strongly recommend setting up another layer of defense in the form of a third factor tied to a physical device or to the employee’s authorized laptop and phone. Microsoft 365 offers this as part of Conditional Access by adding a requirement to authenticate via an enrolled and compliant device only, which would completely prevent AitM attacks.”
Mitiga has also released a security advisory on the BEC campaign.
Copyright © 2022 IDG Communications, Inc.
