How Cyber Criminals Are Abusing Microsoft Domain to Deliver Phishing Mails

Attackers are constantly finding new ways to bypass security solutions to deliver malware or phish users. Earlier phishing campaigns used to be very simple and easy to detect. One has to clearly look at the URL of the fake page and no SSL certificates were being used at that time. But today’s phishing campaigns have become very sophisticated where cyber criminals are constantly evolving themselves and adopting new techniques to make their fake pages look more legitimate to the users.

Yesterday only we were reported of an incident where one of the users received an email from their own email address or from organization’s internal mail servers. The body of the message said that Office 365 has prevented the delivery of 7 new emails and in order to review them you have to login to the link provided by the attacker in the email.

Interestingly the embedded link looks legitimate that even the majority of security solutions identified that links as clean, at the time of writing this post.

hxxps://officedcz50l0sxil6um4o[.]z11[.]web[.]core[.]windows[.]net/index.php?c=[victim's_email_address]

If you clearly look at the URL above, you will notice a windows.net domain which is actually legitimate. How I am so sure? You can do a domain lookup in Whois. If the domain is really legitimate then how these attackers have managed to deliver phishing campaign through legitimate windows domain. Does that mean that Microsoft’s site got compromised or is there something else that we are not aware of?

Let’s get down to the business where I’ll be showing you how these attackers are actually fooling their victims by delivering phishing campaigns like the one which I have shown below.

On doing some research I found that attackers are actually abusing Microsoft domain to deliver their phishing campaigns. And this technique was so effective that not even a single security solution companies were able to detect it (during the analysis) due to the legitimacy of the domain.

Navigating to the link mentioned above presented us with a Microsoft login page where the recipient’s email address was encoded in the URL.

As this is an Office 365 login page and the site is secured using a Microsoft SSL certificate, many may be convinced that this is a legitimate sign-in form.

On further checking the source code of that page I noticed some strange JavaScript code which made me dig deeper into it.

Online decoders did great work in decoding the JavaScript code and after beautifying that encoded code, it presented us with the decoded code which now looked more understanding to us than it was earlier.

While going through the decoded code above, I noticed a variable where an array of few words were set and within the bottom of that array I noticed a strange URL with /validate.php as a parameter and was pretty much sure that the credentials would be sent to this script within that domain. But I wanted to be 100% sure whether this is actually the case or It was just mentioned there to make our analysis process more time consuming.

So, just to check the application flow of that page, I thought of sending the wrong credentials and immediately received an error “incorrect password, reset it now” which is quite obvious and nothing changed in the URL. Now, you might be thinking that this the legitimate page as it provided the error message due to the wrong supply of credentials which actually should be the case.

Since, I was not convinced and everything was happening at the background may be because of AJAX I decided to capture the request and decide. Soon after capturing that request I noticed the POST request and the credentials were actually being sent to the server operated by the attackers which in this case is the URL listed in the encoded JavaScript code. (which we mentioned above).

The URL which was found while capturing the request was created on Dec, 2018 and recently updated this month i.e. February, 2019.

How attackers pulled this off?

Attackers actually used Azure blob storage to host their phishing form and by this, they will be secured by a Microsoft SSL certificate.

Azure blob storage is actually a service from Microsoft to store unstructured data like images, videos or text. One of the advantages of using Azure blob storage is that it is accessible using both HTTP and HTTPs protocol and while accessing via HTTPs, will display a green padlock and a signed certificate from Microsoft.

All the attacker need is an active subscription to the Azure subscription and enable static website hosting on their storage account. Once, the feature of static website hosting is enabled, a container named $web is created.

Files in the $web container are:-

• served through anonymous access requests
• only available through object read operations
• case-sensitive
• available to the public web following this pattern:
  • https://<ACCOUNT_NAME>.<ZONE_NAME>.web.core.windows.net/<FILE_NAME>
• available through a Blob storage endpoint following this pattern:
  • https://<ACCOUNT_NAME>.blob.core.windows.net/$web/<FILE_NAME>
    

So, In the case of this phishing campaign “officedcz50l0sxil6um4o” is an account name, “z11” is a zone name and “[victim’s_email address]” is the filename.