Clever Phishing Attack Bypasses MFA to Nab Microsoft Office 365 Credentials

The attack discovered by Cofense can steal sensitive user data stored on the cloud as well as find other victims to target.

A new phishing campaign can bypass multi-factor authentication (MFA) on Office 365 to access victims’ data stored on the cloud and use it to extort a Bitcoin ransom or even find new victims to target, security researchers have found.

Researchers at Cofense Phishing Defense Center discovered the tactic, which leverages the OAuth2 framework and OpenID Connect (OIDC) protocol and uses a malicious SharePoint link to trick users into granting permissions to a rogue application, researcher Elmer Hernandez wrote in a blog post published Tuesday.

The attack is different than a typical credential harvester in that it attempts to trick users into granting permissions to the application, which can bypass MFA, he said. MFA is used as back-up security to a user’s password in case the password is compromised and is meant to protect an account in such a scenario.

“This is not the first time the tactic has been observed, but it’s a stark reminder that phishing isn’t going to be solved by multi-factor authentication,” Hernandez noted.

If attackers are successful, they can engage in a number of threat behaviors, researchers said. The most basic attack can steal all the victims’ email and access cloud hosted documents containing sensitive or confidential information. But attackers wouldn’t have to stop there, he said.

“Once the attacker has sensitive information, they can use it to extort victims for a Bitcoin ransom,” Hernandez wrote. “The same permissions can also be used to download the user’s contact list to be used against fresh victims. Using the address book and old emails would allow the attacker to create hyper-realistic Reply-Chain phishing emails.”

The email used in the attack appears like a typical invite to a SharePoint hosted file; in the example cited in the research, the file seemed to be offering information about a salary bonus, creating an effective lure, Hernandez noted.

After clicking on the link, users are taken to the legitimate Microsoft Office 365 login page at https://login.microsoftonline.com. However, a closer inspection of the full, long-form URL showed that there are clues to its nefarious intentions that someone without technical experience might not notice, but which are more obvious to security experts.

Applications that want to access Office 356 data on behalf of a user do so through Microsoft Graph authorizations, but must first obtain an access token from the Microsoft Identity Platform, Hernandez explained.

“This is where OAuth2 and OIDC come in,” he said. “The latter is used to authenticate the user who will be granting the access, and if authentication is successful, the former authorizes (delegates) access for the application. All of this is done without exposing any credentials to the application.”

The entire URL used in the attack includes key parameters that show how the attacker can trick a victim into giving a rogue application permissions to access his or her account.

A parameter called “response_type” denotes the type of access being requested to the Microsoft Identity Platform /authorize endpoint. In the case of the attack examined by Hernandez, both an ID token and an authorization code (id_token+code) are requested.

“The latter will be exchanged for an access token which will, in turn, be presented by the application to Microsoft Graph for data access,” he explained.

In the next phase, the “redirect uri” parameter indicates the location to which authorization responses are sent, including tokens and authorization codes. In the attack outlined in the post, responses are sent to hxxps://officehnoc[.]com/office, a domain masquerading as a legitimate Office 365 entity. The domain’s location is 88[.]80[.]148[.]31 in Sofia, Bulgaria, where it is hosted by BelCloud, Hernandez noted.

Then, the “scope” parameter shows a list of permissions the user gives to the application that allow the application to read and/or modify specific resources for the signed-in user. If this parameter shows an “all” constraint, these permissions apply for all such resources in a directory, Hernandez said. Attackers also can ask for specific permissions using this parameter, he noted.

“For example “contacts.read” enables the application to read only the user’s contacts, whereas “notes.read.all” allows it to read all OneNote notebooks the user has access to, and “Files.ReadWrite.All” to both read and modify (create, update and delete) all files accessible to the user, not only his or her own,” he wrote.

The last and “most concerning” parameter that Hernandez identified in the extended URL ┬áis “offline_access,” he explained, which allows the application to obtain refresh tokens that can be exchanged for new access tokens once they expire. This would allow an attacker to need only to authenticate and approve permissions once to potentially enable indefinite access to a victim’s data, he explained.

In the final step of the attack OpenID and profile parameters come into play, used to provide user authentication and profile information–such as the user’s name, profile picture, gender and locale among others. “This information, known as claims, is sent to the application in the ID token issued by the /authorize endpoint,” Hernandez wrote.

If a user falls for the malicious SharePoint link and signs in, he or she then will be asked to confirm one last time that he or she wants to grant the application the aforementioned permissions.

“If users fail to act, it will be up to domain administrators to spot and deal with any suspicious applications their users might have misguidedly approved,” Hernandez noted.

Hernandez said that the novel phishing campaign is evidence of attackers adapting and finding new ways to steal people’s credentials and use it for foul play, creating scenarios in which they can trick victims into working against themselves.

“Not only is there no need to compromise credentials, but touted security measures such as MFA are also bypassed; it is users themselves who unwittingly approve malicious access to their data,” he noted.

Concerned about the IoT security challenges businesses face as more connected devices run our enterprises, drive our manufacturing lines, track and deliver healthcare to patients, and more? On June 3 at 2 p.m. ET, join renowned security technologist Bruce Schneier, Armis CISO Curtis Simpson and Threatpost for a FREE webinar, Taming the Unmanaged and IoT Device Tsunami. Get exclusive insights on how to manage this new and growing attack surface. Please register here for this sponsored webinar.

Suggested articles

Discussion

  • Mike Sulja on

    Great article! If user consent for applications is disable in Azure AD (requiring admin approval), does that prevent this attack since the user can't approve the rogue application?
  • mrmacedonian on

    As Mike Silja mentioned, not allowing users to approve or add apps is the top mitigation of this vector. Google does this with Advanced Protection (Security Key MFA + disabling app integrations). I personally feel this article is lacking a reference to blocking users from allowing apps (simple KB link is sufficient), since it is being framed as a security vulnerability and has a pretty clear mitigation.
  • Anonymous on

    where is the MFA bypass part?

Leave A Comment

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.