Cyber risk and advisory programs that identify security gaps and build strategies to address them.
MDR that provides improved detection, 24/7 threat hunting, end-to-end coverage and most of all, complete Response.
Our team delivers the fastest response time in the industry. Threat suppression within just 4 hours of being engaged.
Be protected by the best from Day 1.
24/7 Threat Investigation and Response.
Expert hunting, research and content.
Defend brute force attacks, active intrusions and unauthorized scans.
Protect assets from ransomware, trojans, rootkits and more.
Intelligence and visibility across AWS, O365, DevOps and more.
Configuration escalations, policy and posture management.
Detects malicious insider behavior leveraging Machine Learning models.
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.
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.
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.
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"]
[image src="/assets/Figure5.png" id="2307" width="900" height="374" class="center ss-htmleditorfield-file image" title="Figure5"]
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"]
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: