Not Token for Granted

New phishing campaign against financial services steals OAuth tokens to bypass MFA in O365 accounts

DarkLab recently discovered a suspicious email which we identified as part of an active phishing campaign primarily targeting banks and investment companies worldwide, including a number of targets in Hong Kong. The campaign initially seemed aimed at stealing victims’ credentials, a common tactic among threat actors. However, a closer look showed that threat actors leveraged OAuth2 framework to gain permissions to the victim’s O365 account by exploiting a rogue Azure application. This would have allowed them to bypass multifactor authentication controls and directly access the victim’s account with a stolen OAuth token, rendering this a particularly effective social engineering tactic.

Overall, this campaign shows how financially motivated threat actors are evolving their tactics, techniques, and procedures to exploit companies’ increasing reliance on cloud infrastructure.

Phishing email analysis

The email is sent from a domain of a separate entity, likely compromised by the threat actor before initiating the attack against our client. The email metadata also suggests deliberate spoofing of the SMTP FROM header.

The email contains a fake e-signature verification request, along with a link to “Review and sign”.

The link is crafted to present the user with a request screen (see figure above) to grant permissions to a rogue Azure application. Depending on threat actors’ intent, permissions request can be modified to allow access to cloud-hosted documents and applications, including the email account.

Here is an example of the phishing link:

hxxps:// &redirect_uri=https%3A%2F%2Fkp3jccawgk[.]online&resource= https%3A%2F%2Fkp3jccawgk[.]online&state=xxxxxxxxxxxx #efe1b61bcf8df6b76595xxxxxxxxxxxx

The url above represents an access requested to the Microsoft Identity platform with a request for an authorization code, denoted by the response_type flied. The client_id field denotes the unique ID of an Azure application owned by the threat actor, with a redirect_uri field pointing to a domain – kp3jccawgk[.]online – staged by the threat actor to capture the redirected HTTP request once the victim grants the access permission.

To create such an attack infrastructure the threat actor only needs to register a rogue application under an Azure tenant, and to host a website to capture the URL requests and  authorization codes. The redirected site also contains JavaScript snippets that detect the accessing IP address and details of the victim organisation, very likely for victims’ profiling and filtering out potential accesses from security vendors.

Eventually, the victim is redirected to a blank page, now defunct.

Threat actors would then leverage the rogue application and request a valid access token with the authorization code. They could then access the victim’s O365 account with the permissions granted during the phishing process, and perform a variety of actions from accessing account information to sending emails on behalf of the victim.

This attack aims at stealing access tokens in form of OAuth. This allows direct access to a victim’s account and bypasses the need to steal valid user credentials, including multi-factor authentication.

Attack infrastructure and insights into the campaign

By pivoting on the redirect domain, we were able to identify multiple threat actors’ domains suggesting that they are very likely targeting banks, asset managers, equity firms, and in a lesser degree also law firms and consultancies around the world, including Hong Kong. According to domain registration data, the campaign started at the end of February and it is currently active. Based on the nature of its targeting the campaign appears to be financially-motivated.

Detection and remediation

To detect malicious behavior linked to a user falling victim to a similar phishing email, the most effective way is to monitor Azure audit logs for “Consent to Application” events. These represent users’ approval to grant permissions to third-party applications. Microsoft Cloud App Security is also a good location to detect new OAuth applications with high privileges in the tenant.

Sample Microsoft Azure log showing a Consent to Application event for a malicious Azure application

In the event where an internal user falls victim and consent is given to rogue application, IT teams can manually remediate the applied access under the “Enterprise Application” section of Microsoft Azure portal, and ensure that the user credentials are reset and protected by MFA. As a preventive measure, IT teams are also recommended to leverage the Azure AD Admin Consent to force administrator involvement to gatekeep user data against such kind of attack tactic.

Indicators of compromise

  • 188.166.68[.]51
  • kp3jccawgk[.]online
  • 17l78xgnzj[.]online
  • 4zl8t4sqon[.]online
  • 9ybzef6d2h[.]online
  • cprapid[.]com
  • cts1g02r2c[.]online
  • kp3jccawgk[.]online
  • l7p5g1kwh4[.]online
  • num7ewnkn1[.]online
  • rh6757nysb[.]online
  • wbxputufpj[.]online
  • wzoschqdd0[.]online

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Leave a Reply