Step 1: Phish Mitiga. Step 2: Get Your Phishing-as-a-Platform Dissected by Mitiga

Ofir Rozmann
Nov 27, 2020

A few weeks ago one of Mitiga’s employees received an email phishing for credentials. Instead of just laughing it off, our team decided to use their lunch breaks to analyze it. What we found indicates a sophisticated phishing platform that uses AWS and Oracle infrastructure to phish Office 365 email accounts.


Modus Operandi

This particular attack begins with the victim receiving a phishing email sent from a legitimate, but compromised, Office 365 email account. This email asks the targeted user to click a link for a voice mail message.

Once the link was clicked, the user is redirected through several proxies, including AWS load balancers, all the way to a compromised website belonging to a genuine organization. Our team identified over 40 websites belonging to SMBs that were compromised by the associated threat actors.

Ultimately, the victim ends-up on a fake and malicious Office 365 login page hosted on Oracle Cloud infrastructure. In some variations of these attacks, we also observed Office 365 login pages hosted on AWS S3 buckets.

Once the victim entered their credentials, they were exfiltrated to a compromised but legitimate website.

It should go without saying that these compromised Office 365 credentials may be used as entry vectors for deeper access into the victim organization’s network, or used to conduct a Business Email Compromise (BEC) attack.

Image for post

Image for post
Screenshot of phishing email. After clicking on “LISTEN TO VOICENOTE”, the user is redirected to an Office 365 login page

Image for post
Screenshot of a malicious Office 365 login page

It Gets Much More Interesting

Despite the campaign’s relatively trivial target (Office 365 credentials), it is actually quite sophisticated in several aspects:

First, the threat actors use a vast “network” of over 40 compromised websites as part of their infrastructure proxy chain.

Second, the threat actors use AWS load balancers as proxies, and Oracle Cloud resources for hosting the Office 365 login pages. In some cases we observed them hosted on AWS S3 buckets whose names imitate Zoom invitations. We believe the AWS and Oracle infrastructure is controlled and operated directly by the threat actors — who leveraged these freely available services for their malicious intentions.

Third, the threat actors sent the phishing emails from legitimate compromised email accounts.

Our team also found several interesting strings, comments, and function names that are possible clues hinting at the attacker’s origin. They were found while researching the HTML infrastructure deployed on the Office 365 login pages. We would like to stress that all of these may be false flags deployed by the threat actors to misguide security researchers. Nonetheless, we found:

  1. HTML pages had variables named “Tombol” (button) and “Tekan” (press).

2. Older HTML pages versions deployed as early as April 2020, had references to “Kolom” (Column), “Lagiya” (Again), “Kirim” (Send).

Evidence Points to a Turnkey Phishing ‘Solution’

There are several indications that lead us to believe that the threat actors received the phishing infrastructure from a 3rd party — as a Phishing-as-a-Platform solution, so-to-speak:

For the record, we found no evidence affiliating any of the findings above with a known cybercrime group.

Image for post

Image for post
Screenshots of HTML content of the compromised websites

Image for post
Screenshot of HTML content of the Office 365 login page with the indicative strings

Who Were the Targets?

During our investigation, we discovered several email addresses that received emails originating from the malicious infrastructure. These email addresses belong to small and medium sized businesses, as well as major financial institutions in the US and Australia. The attackers targeted mostly C-level executives in these organizations.

We have no indication that the phishing attempts targeting these email addresses were indeed successful, and that their credentials were in fact stolen. However, at least some email addresses were indeed compromised by the threat actor — the ones that were used to send the malicious emails.

Due to the relatively sophisticated nature of this phishing campaign, we recommend checking whether any credentials were stolen.

Our Recommendations

  1. Enforce Office 365 Multi-Factor Authentication.
  2. Enforce Office 365 password updates.
  3. Examine forwarding rules in your Email accounts.
  4. Search for hidden folders within Email inboxes, or check for emails in built-in folders were they should not be (e.g. RSS Feeds folder).
  5. Ensure changes to mailbox login & settings are logged and retained for 90 days.
  6. Enable alerts for suspicious activity, such as foreign logins, and analyze server logs for anomalous Email access.
  7. Consider simulating a similar attack scenario using a Red Team to test phishing awareness of the organization.

Copyright ©️ Mitiga, Ltd. All rights reserved | Terms of Use | Privacy Policy