Opening

Phishing attacks are a daily threat to all organizations and unfortunately, they are one of the hardest threats to protect against. No matter how many defensive layers an organization has put in place following best practice defense-in-depth design, it only takes one (1) user to click on that malicious link or open that weaponized attached document to circumvent all of these tactical defensive layers.

The goal of this blog post is to provide analysis insight gained from a recent phish email Incident Response engagement that I worked. Within this post, I will focus on a critical pivot point that can be missed if an investigator sticks to the surface layers of evidence when working through a phish email incident. I will walk through identifying the specific phishing tactic used, highlight an evolving trend in the use of cloud storage to host a phishing page, provide OPSEC examples when browsing phishing sites, and call out specific phishing indicators. To conclude, I will discuss how to take active measures to monitor phish activity and proactive steps to help prevent this sort of phishing attack from taking place.

Note: Specific, low-level analysis is deliberately excluded to respect the privacy of the client.

Starting With the Basics - Initial Phishing Email Analysis

The first thing that I acquired during the phishing email compromise was the original phish email that was sent to the affected users. The primary reason for this was to analyze the original email message itself along with the associated email headers for any critical Indicators of Compromise (IoCs) that could be extracted and used to pivot from.

I parsed the client's Exchange Message Tracking logs and identified that 78 internal users received the phishing email. It was identified that eight (8) internal users clicked on the malicious link and supplied their network login credentials (I will show how I verified this statistic later). This does not seem like a high ratio, but it only takes one (1) user to click and provide credentials for an organization to be fully compromised in the end.

A few things to call out immediately from the phish email itself that should have been recognized by the end-user:

• The odd From: email address [email protected]
• The hyperlink text of VIEW MAILS, instead of saying VIEW EMAILS

From the email message header, I extracted the sending source IP address of the email, which I later pivoted from to identify that it was tied to malicious Office 365 login activity for this client. This is poor threat actor OPSEC, in my book. Some basic OSINT of the source IP address identified that it was also affiliated with other malicious Internet activity since 2014, classified as a TOR exit node, and known to host malware associated with RemcosRAT, Netwire, Agent Tesla, and Nanocore.

I also noted the X-Sender-ID used, which clearly identified the that threat actors used a compromised external domain email address to ensure the phish came from a legitimate source to assist in bypassing any perimeter mail validation checks.

Due to time constraints, no further threat actor attribution was performed from the extracted IoCs. Keep reading though, the fun stuff is actually just over the horizon.

Failed Defensive Measures

Flawed user security awareness is the easy one to call out here, but since there was a SPAM filter in place, some red flags could have been triggered from a policy perspective:

• RCVD_NUMERIC_HELO
• FROM (which was different from the X-Sender-ID) domain was not registered and identified as having an SPF violation
• Loose real-time message link protection

More stringent real-time message link protection could have prevented the link from being resolved due to the real-time analysis of the URL and have it safely redirected to a message warning. But the critical factor here in defeating this defensive layer is the use of a legitimate storage location hosted in Google's Cloud Storage, Firebase (seen below in the link analysis).

Malicious Link Analysis - Time to Dig In

This is where it gets fun! After digging into the email header, it was time to dive into the embedded email link to try and obtain information on the threat actor's phishing infrastructure and identify any phishing campaign intelligence. Prior to doing any active testing, I do want to call out some basic OPSEC steps that should be in place prior to this part of the analysis. These basic steps will help in obfuscating your true-source IP address:

• Use of a host VPN client
• Enable TOR network-level routing for command line testing
• Use of TOR browser for active phish site browsing

I went ahead and extracted the embedded link from the phish email.

Encoded Link

Decoded Link

Based on the decoded link, it was easy to see that this was not a legitimate location where these so-called email messages would be hosted from. It looked like a fairly new tactic that was leveraging Firebase to host a fake Exchange Outlook Web App (OWA) login page (shown below).

Passive Link Testing

The first step in this analysis is simple passive link testing, which does not raise any OPSEC concerns. Usually, these phishing sites are only up for a short period of time, so it is important to attempt these checks as soon as possible. Of course, there are OSINT sites that can be used to view cached pages that have already been indexed and so forth, but it is so much more fun to deal with an operational phishing page.

My go-to passive URL verification site is https://urlscan.io. Once I ran the site check, I was able to validate my assumption that the malicious link was redirecting the users to a fake OWA login page.

Active Link Testing

The next step in this analysis involved active phish site testing where OPSEC is necessary. My setup consisted of the following (this may be overkill, but it is good to establish OPSEC processes):

• A VM that had network-level TOR routing enabled
• TOR browser installed on my VM
• Host machine VPN client was activated

From my experience, this is something that is usually not performed and is missed by most investigators: looking deeper than the surface findings of the phish page and thinking like an attacker. I browsed to the malicious phishing site login page and decided to look at the page source code. In doing so, I uncovered some surprising embedded malicious JavaScript code (at the bottom of the HTML source code), which I identified was basic key logging functionality that redirected the captured user input to another compromised external site.

The following JavaScript sections were a clear indication of the keylogging functionality and the sending of credentials to what appeared to be a compromised website that was used to store the harvested credentials. Shout out to my co-worker ScottWhite who assisted me in breaking down the full JavaScript code.

The JavaScript keydown event is triggered when a key is pressed, regardless of whether it produces a character value. The keydown event.KeyCode of 13 identified this particular key to be the Enter key.

To validate this, I used the following JavaScript event keycode checker site: https://keycode.info/

Some additional information to understand is this particular key code is relatively safe to use across various browser types, which would indicate higher success of the malicious script.

The following bit of code identified after the triggered keydown event is an HTTP POST event that would then send the input of the user: and pass: information to a compromised external website that is storing the harvested credentials.

Below is a copy of the JavaScript that was embedded in the phishing login webpage:

Misconfigurations Lead to Active Phish Campaign Monitoring

Since I had the URL that was being used to store the harvested credentials, I could not pass up the opportunity to try to gain further intelligence surrounding the threat actor’s phishing campaign activity. With the assistance of Incident Response Team Lead TylerHudak, we identified that the website had a directory indexing misconfiguration that allowed us to browse to the directory that contained the text file storing all of the compromised credentials.

Having access to this file allowed me to confirm exactly which users submitted their credentials to the fake OWA login page (with some users entering them multiple times). From this information, I was able to pivot over to the client’s Office 365 environment and validate that the phished users also had their Office 365 mailboxes compromised within minutes of providing their login credentials to the threat actors.

After reviewing the text file that contained the compromised credentials, I identified that there were five (5) other organizations with compromised credentials within this particular file, which indicated that a larger phishing campaign was underway.

Phish Campaign Real Time Monitoring

Again, I could not walk away knowing I had this access. This was another opportunity to keep my hooks into the threat actor's phishing infrastructure and maintain real-time monitoring of the associated activity with any future phishing campaign activities.

I put together a simple script (using all the OPSEC steps listed earlier, including modifying the User Agent used) that would monitor the Last-Modified file parameter, which would indicate when newly acquired compromised user credentials were uploaded. After monitoring the activity for a two-week period, I identified that the threat actors initiated multiple global phishing campaigns. During this monitoring period, I identified that organizations from the United States, Australia, New Zealand, Philippines, and South Africa were affected by these phishing campaigns.

Responsible Disclosure and Takedown Request Submitted

After concluding this monitoring, I took steps to assist in notifying some of the affected US-based organizations through protected communication channels within the industry. Responsible disclosure surrounding Incident Response findings that venture outside of the incident an investigator is working on can be tricky, so do your due diligence on the proper methods of this disclosure. I also submitted a takedown request to the hosting provider of the website, which was hosting the credential harvesting file, but I have not received any response at the time of this blog post.

Defensive Protective Measures

Some defensive layers to take into consideration to assist in preventing email phishing attacks and credential stealing from phishing attacks would be:

• Email scanning and filtering
• Email security gateways
• DNS authentication (DMARC, DKIM, and SPF)
• Anti-malware and anti-spam
• Multi-factor authentication (MFA)
• Phishing security awareness

No matter how robust the email defensive layers are, phishing emails will find their way into a user's mailbox. In the end, the user is the last measure in these defensive protection layers, and they are only as strong as the effectiveness of the phishing security awareness training provided by the organization.

Closing Thoughts

As we have seen, digging deeper can uncover some interesting follow-on threat actor monitoring possibilities and potential attribution capabilities from a standard phishing email incident. Walk into an incident with an open mind, endless curiosity, and the desire to uncover more. Share with the community and strive to do more to protect the impacted. I hope the content within this blog post is found to be useful and interesting.

@H3dTr1p