New BOLO: Phishing Attacks that Customize O365 Pages with Your Branding

Phishing actors continue to deploy convincing Office 365 phishing attacks by hosting pages on trusted cloud services while automatically customizing these pages to the target organization’s branding. This appears to abuse a Microsoft feature meant to allow systems administrators the ability to customize the Office 365 login page for their users. By customizing the O365 branding on the fly, this technique reduces the effort required for conducting convincing phishing attacks at scale.

First observed in 2019 by eSentire in phishing attacks against our customers (and on public blogs/sites such as urlscan.io), the technique is not new. However, the continued use in attacks to this day caused us to revisit this issue in more detail. In order to ensure the security of eSentire customers, phishing sites related to these attacks are blocked after identification and watchlists are used to identify potential connection requests to malicious infrastructure.

Background on Login Page Customization

Microsoft allows organizations to customize their Office 365 login page for users to match company branding:

https://docs.microsoft.com/en-gb/microsoft-365/admin/setup/customize-sign-in-page?view=o365-worldwide

Figure 1 Customizing Options for 0365 Login Pages (Microsoft Docs)

Example of custom branding:

Figure 2 Customized Office 365 Login Page

The transformation appears when the user opens the login page and enters their email address. When this occurs, the content defined by the organization (background image, logo, text) is retrieved from Microsoft directly and the page is updated.

The Branding is All Public Knowledge, What’s the Big Deal?

It’s true that anyone can search the company name and find their logo or visit https://login.microsoftonline.com/ and view the logo/background/text manually. The concern here is that this information can be retrieved automatically with little effort, meaning attackers can cast a much wider net and target many different organizations with convincing phishing attacks.

How are Phishing Attacks Mimicking this Behavior?

Phishing attacks appear to have been abusing this feature to customize their phishing pages to the target for some time (see this blog post from August 2019). In recent weeks, we responded to a phishing attempt against a customer using a custom login page.

The attack worked as follows:

1. Victim receives email containing link to hxxp://t.info.samsungusa[.]com (open redirect meant to bypass email filters)
2. When clicked, this redirects to redacted[.]azurewebsites[.]net
3. This page acts as a filter, and validates the victim’s email address by submitting it to rohstofff[.]de
4. If successful, the victim is then redirected to an Office 365 phishing page at hxxps://firebasestorage[.]googleapis[.]com/redacted[.]html
5. Target specific branding is pulled from rohstofff[.]de.
6. If credentials are provided, they are submitted to rohstofff[.]de

The relationship between the different sites can be expressed as follows:

Examining the content hosted on hxxps://firebasestorage[.]googleapis[.]com/redacted[.]html, we see that it contacts an attacker-controlled website (rohstofff[.]de) to retrieve the same three sign-in customization options outlined by Microsoft (logo/background/text):

Each of these HTTP GET requests passes the victim’s email address (retrieved from the URI) to an attacker-controlled site and returns a links to secure.aadcdn.microsoftonline-p.com:

Each request above returns a custom branding component hosted by Microsoft. These components makeup the company logo, background and custom text for Microsoft’s login pages. These components are used to automatically customize the phishing page to make it more convincing.

How are they doing this?

Curious how this works, we examined the real Office 365 login page to see how the custom images and text are loaded. Sure enough, it makes the same requests to secure.aadcdn.microsoftonline-p.com:

Figure 7 Logo and Background Retrieval on Legitimate Office 365 Login Page

The question is, how are attacker-controlled sites like rohstofff[.]de retrieving this information? The branding links appear to use unique identifiers which are tied to the specific company. rohstofff[.]de is seemingly able to resolve an email address to the appropriate Microsoft links.

After some research, we came across this blog from Dr Syynimaa. In it he shows how you can use the GetCredentialType API to enumerate 0365 users. Of note, he states “the API needs at least the username posted in the request body in JSON format”.

Returning to the real Office 365 login page, it makes an HTTP POST request to https://login.microsoftonline.com/common/GetCredentialType when your email is entered. This returns various information about the account and the organization, including links to the custom branding:

Figure 9 Data Returned by GetCredentialType API (Some Values Omitted)

Figure 10 Demonstrating Links Returned by GetCredentialType API are for Branding Content

Proof of Concept:

curl https://login.microsoftonline.... -X POST -H "Content-Type: application/json" -d '{"Username":"[email protected]"}'

The above makes a POST request to GetCredentialType API using just the username. This works, but returns branding resources from aadcnd.msauthimages.net, not secure.aadcdn.microsoftonline-p.com:

Figure 11 GetCredentialType Results Returned by PoC

After some testing, it appears that including the cookie name “buid” is what causes this:

• · Request contains buid cookie and value: secure.aadcdn.microsoftonline-p.com
• · No buid cookie: aadcnd.msauthimages.net

The buid cookie contains what appears to be a unique value, but it’s not immediately clear how it is generated.

Regardless, the branding content returned from both domains is the same. Interestingly, Googling both domains finds other multiple sites proxying this branding content:

How Prevalent is This?

A recent trend in phishing is the use of cloud services such as firebasestorage.googleapis.com, blob.core.windows.net, azurewebsites.net (among others) for hosting phishing pages. Doing so immediately improves the authenticity of the phish, as it’s hosted on a familiar website using HTTPS. As we find these pages, we attempt to identify the supporting infrastructure by examining the HTML on the page. In nearly all cases of cloud host phishing, the heavy lifting is performed by a separate, attacker controlled website. This site hosts various PHP scripts which validate the target email, proxies branding requests and collects and stores credentials. It’s worth the additional time to identify these sites, as they don’t change as often as the credential capture form hosted on the cloud services above (these are flagged and taken down much more quickly).

As we identify the supporting sites, we block them across our customers and setup watchlists for connection attempts. We’ve identified similar attacks against customers as recent as the second week of March 2020. Using the website urlscan.io, these can be found as far back as June 2019. Note that this is limited to submitted pages, so the number could be higher. A list of these attacker controlled sites proxying branding content can be found at the end of this article.

Final Thoughts

This feature is meant to make it easier for systems administrators to give their login portal a custom look. Unfortunately, by abusing it attackers can do the same for their phishing pages. While we cannot say 100% that attackers are using the GetCredentialType API to retrieve company branding for the target, analysis of several phishing kits indicates they are retrieving branding (logos/background/text) from Microsoft directly. We were able to replicate this by submitting an email address to https://login.microsoftonline.com/common/GetCredentialType, which leads us to believe a similar method could used by phishing operators.

Recommendations

• Employ a Multi-Factor Authentication solution
• Educate users to recognize signs of suspicious login pages
  • Treat any login request originating from email links as suspicious.
  • Check the address bar for suspicious sites such as Google/Microsoft Cloud storage.
  • Be cautious if the page appears broken, or doesn't fully match your normal login page

Indicators

The below domains were observed in customer incidents or identified using urlscan.io. These sites were proxying Office 365 brand information and collecting credentials for cloud hosted phishing pages since June 2019.

Acknowledgement

• urlscan.io – This site is highly recommended for researchers and analysts and is quickly becoming one of our favourites.
• Rapid 7 – Previous blog post on this topic (https://blog.rapid7.com/2019/08/20/how-attackers-can-harvest-users-microsoft-365-credentials-with-new-phishing-campaign/ )
• Azure AD Seamless SSO allows enumerating tenant users by Dr Nestori Syynimaa - http://o365blog.com/post/desktopsso/

For more information on O365 phishing attacks, view our on-demand webinar Threat Intelligence Insights: Are Cybercriminals Using Microsoft Office 365 Against You?