Microsoft 365 EOP
By Elmer Hernandez, Cofense Phishing Defense Center (PDC)
The Cofense Phishing Defense Center (PDC) uncovered a phishing tactic that leverages the OAuth2 framework and OpenID Connect (OIDC) protocol to access user data. The phish is not a typical credential harvester, and even if it was, Multi-Factor Authentication (MFA) wouldn’t have helped. Instead, it attempts to trick users into granting permissions to a rogue application. 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.
Using the lure of a Q1 bonus, the email is crafted to appear to be a normal invite to a SharePoint hosted file. The prospect of receiving an increase to their salary is an effective lure that can lead users to fall prey.
Figure 1 – Email Body
After clicking on the link, users are taken to the legitimate Microsoft Office 365 login page at https://login.microsoftonline.com (Figure 2). However, if one inspects the URL in its entirety, which average users are unlikely to do, a more sinister purpose is revealed.
Figure 2 – O365 Login Page
Anatomy of a URL
First, a quick primer: applications that want to access Office 365 data on behalf of a user do so through Microsoft Graph authorizations. However, they must first obtain an access token from the Microsoft Identity Platform. This is where OAuth2 and OIDC come in. 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.
Figure 3 – Entire URL
The response_type parameter denotes the type of access being requested to the Microsoft Identity Platform /authorize endpoint. In this case, 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.
Next, the redirect uri parameter indicates the location to which authorization responses are sent. This includes tokens and authorization codes. As we can see, responses are sent to hxxps://officehnoc[.]com/office, a domain masquerading as a legitimate Office 365 entity, located at 88[.]80[.]148[.]31 in Sofia, Bulgaria and hosted by BelCloud.
Moving on, the scope parameter shows a list of permissions the user gives to the application (note “%20” represents a blank space). These allow the application to read (read) and/or modify (write) specific resources for the signed in user. If the “All” constraint is present, permissions apply for all such resources in a directory.
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.
If the attackers were successful, they could grab all the victims’ email and access cloud hosted documents containing sensitive or confidential information. Once the attacker has sensitive information, they can use it to extort victims for a Bitcoin ransom. 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.
Perhaps most concerning however is “offline_access” As access tokens have an expiration time, this permission allows the application to obtain refresh tokens, which can be exchanged for new access tokens. Therefore, users need only to authenticate and approve permissions once to potentially enable indefinite access to their data.
Finally, we find openid and profile which are technically scopes in themselves; openid indicates the application uses OIDC for user authentication, while profile provides basic 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.
After signing in, the user 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.
The OAuth2 phish is a relevant example of adversary adaptation. 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.
How Cofense Can Help
Visit Cofense’s Remote Work Phishing Infocenter to stay up to date as threats evolve. Our site is updated with screenshots of real phish that have evaded secure email gateway detection and other helpful resources so you can help keep your organization protected.