Threat actors using HEX encoded links to bypass phishing defenses

Overview:

Recently eSentire Threat Intelligence observed an increase in credential phishing pages hosted on Microsoft Cloud Services. Leveraging services such as Azure Blob Storage or SharePoint for phishing is not new and has been reported previously. Recent observations from our customer base in July 2019 indicate that attackers continue to see success in leveraging these services and are expending effort to circumvent email filtering by HEX encoding links (likely a response to increased scrutiny on these services).

Earlier this week, eSentire posted a security advisory for our customers on this new technique, and this blog post will aim to provide a more in-depth technical exploration of the use of HEX encoding to bypass traditional anti-phishing defenses.

Technical Review:

Use of Microsoft Cloud Services

Hosting phishing pages on cloud services provides significant advantages with relatively low effort/costs. A basic WordPress site on Azure Blog Storage can be built relatively quickly and provides a valid TLS certificate and domain for credential harvesting.

Similarities to BaseStriker

This HEX encoding of links does bear similarities to the previously disclosed ‘BaseStriker’ method for bypassing advanced security controls like ATP or Safe Links by abusing the <base> URL tag.

In this new example, however, the attackers have defined the HEX encoded malicious link within the <base href> within the message body, and then combining the user specific information from the <a href> link also within the message body.

HEX Encoding

While observed use of the aforementioned cloud services has gone on for some time, the use of HEX encoding presents a relatively low-effort obfuscation method and is likely a response to increased scrutiny. Once a new method is seized upon by attackers, it's common for them to try and squeeze as much out of it as possible to try and extend its shelf-life. From an attacker's perspective, it's often easier to adapt than it is to start fresh (PowerShell execution techniques are an excellent example of this).

The phishing campaign observed by eSentire leads the user to believe that server errors are delaying message delivery and attempts to prompt the user to click on 'Review Message'.

[image src="/assets/Figure1.png" id="2303" width="701" height="435" class="center ss-htmleditorfield-file image" title="Figure1"]

Looking closer at the email, and what makes this event slightly different than previously observed campaigns that utilize Microsoft Cloud Services is the use of URL HEX encoding within the message body - presumably being used to circumvent URL content-based filtering, link filtering etc. An example from the message header is displayed below.

[image src="/assets/Figure2.png" id="2304" width="695" height="114" class="center ss-htmleditorfield-file image" title="Figure2"]

If a user were to follow the link within the 'Review Message' link contained within the email message (Figure 1) – they would be presented with a very convincing phishing page that impersonates a Microsoft Office 365 login page. The 'Review Message' link contained within the phishing email will also pass the phished email addresses, along with the phishing link (e.g. the target users email address will be pre-populated in the Office phishing site). An example of the function that provides the mechanism is highlighted below.

[image src="/assets/Figure3.png" id="2305" width="739" height="60" class="leftAlone ss-htmleditorfield-file image" title="Figure3"]

Again, if the link is followed, the following phishing site that is impersonating the legitimate Office 365 Login page is presented, along with the passed target user/email address – the below figure is the resulting landing page.

[image src="/assets/Figure4.png" id="2306" width="1027" height="350" class="center ss-htmleditorfield-file image" title="Figure4"]

When a targeted user falls victim to this phishing site, there is a JavaScript function contained within the phishing page that will relay the pre-populated email address, and the entered password to a target domain of the attacker's choice. In this example, the content of the 'sendmails()' script is displayed below.

[image src="/assets/Figure5.png" id="2307" width="900" height="374" class="center ss-htmleditorfield-file image" title="Figure5"]

Bypassing a Leading Email Protection Provider

After initial observation, eSentire notified our email protection provider about the HEX encoded link technique, and at the time of publication of this blog they are still developing a preventative measure. To further validate this finding with our email protection provider, a simple proof of concept was created to highlight the lack of scanning for HEX encoded URL’s within the <base href> field.

[image src="/assets/Figure6.png" id="2308" width="1460" height="547" class="center ss-htmleditorfield-file image" title="Figure6"]

The resulting test email was then successfully delivered without any link scanning.

[image src="/assets/Figure7.png" id="2309" width="849" height="531" class="center ss-htmleditorfield-file image" title="Figure7"]

Also, for comparison a screenshot highlighting that link scanning successfully detecting the previously mentioned BaseStriker method described here.

[image src="/assets/Figure8.png" id="2310" width="1125" height="614" class="center ss-htmleditorfield-file image" title="Figure8"]

Additional Observations

• During our analysis of the above campaign we identified roughly 162 unique domains that were targeted by this specific event.
• We also identified the use of both .blob.core.windows.net, and .azurewebsites.net for a hosting platform. From the reviewed SSL Certificate information, we can identify this campaign most likely started on or around:
  • Phishing site ({redacted}.blob.core.windows.net) - April 30, 2019
  • Phishing site ({redacted}.azurewebsites.net) - May 9, 2019

Recommendations

As with any login portal, users need to ensure they are on the correct page. This example utilizes a legitimate (*.blob.core.windows.net / *.azurewebsites.net) certificate, so detection can be a little tricky from an end-user perspective, but also lacks organization-specific branding. Here are some steps you can follow to protect yourself from these types of attacks:

• Employ a robust process for reporting/triage of suspicious emails within your organization.
• Employ multi-factor authentication
• Review eSentire’s security advisory on this new technique