I recently received an interesting phishing email that I shared with the rest of our company as part of our Internal Security Awareness program.  You might guess that as CTO of a security company I often receive phishing emails (and you’d be right), but this one caught my eye.  This phishing email was interesting for a few reasons:

1. It made it past Microsoft’s ATP (Advanced Threat Protection) anti-phishing service in Office 365.
2. It had a valid SPF record (no DKIM or DMARC).
3. The phishing link had a clever URL encode redirect.

So, let’s take a look at the email:

There were several factors that tipped me off that things were amiss: 

• I have never seen a similar voicemail email.
• We don’t do business with any company named Alarmtech (looking at the email address).
• We definitely DON’T do any business with any company named Alarmtech that has a Polish TLD (the “.pl” of “alarmtech.pl” domain in the email address).
• The “local Wireless User” phone number was also odd.

So, I decided to take a look at the message’s full headers.

I was quite surprised to see that the email had a valid SPF record, and while it was unfortunate to see that a DKIM was not setup it is fairly common for less sophisticated admins to omit this type of email authentication.  This also explains part of why Office365 gave a phishing email a pass instead of convicting the email.

And, a quick check with MXToolbox confirmed that the SPF record was indeed valid.

Ok, at this point I was even more curious.  So, I copied the link for the “Play Record” button and utilized www.o365atp.com to de-obfuscate the link.  Bingo!  We’ve got something interesting!

Now, we have the de-obfuscated link (Office365 ATP uses a technology called Safe Links as an extra layer of protection).

__SNIP__

https://www.google.com.mx/url?q=ht%74p%73%3A%2F%2F6%34%65%35%33r%77%37.%62l%6fb.co%72%65.%77in%64%6f%77s.n%65%74%2F5%65%353%72%77%376%2F%69%6edex.%68t%6d%6c%26%236%33%3B%70z%6fne%26%23%36%31%3BY%575%6b%63mV%33Lmhh%62Wl%73d%479uQHB%79%61W1%31%63%33Nlcn%5a%70%592VzL%6dN%76%62Q%26%2361%3B%26%23%361&sa=D&sntz=1&usg=AFQjCNEZAsy-4nufrSB7lCmGPtn98lLW9Q

__SNIP__

If you notice, the URL begins with http://www.google.com.mx/url?q= this is a clever way to have Google (in this case it’s the Mexico link for Google as it has a TLD – top level domain – of “.mx”) to redirect to the actual malicious website address, which is:

__SNIP__

ht%74p%73%3A%2F%2F6%34%65%35%33r%77%37.%62l%6fb.co%72%65.%77in%64%6f%77s.n%65%74%2F5%65%353%72%77%376%2F%69%6edex.%68t%6d%6c%26%236%33%3B%70z%6fne%26%23%36%31%3BY%575%6b%63mV%33Lmhh%62Wl%73d%479uQHB%79%61W1%31%63%33Nlcn%5a%70%592VzL%6dN%76%62Q%26%2361%3B%26%23%361&sa=D&sntz=1&usg=AFQjCNEZAsy-4nufrSB7lCmGPtn98lLW9Q

__SNIP__

Yes, that is a valid FQDN and URL.  And, this is the other part of the reason why I believe that this phishing email made it past Office365’s ATP service.  It’s using a method called URL encoding.  URL encoding allows you to do things such as create spaces in a filename.  For example, the following two bullet point links would point to the exact same URL (Note:  I used a random domain name):

The “%20” is the URL encoded value for a space “ “.  There are some genuine uses for URL encoding, and it is especially helpful when creating scripts or working with APIs.  For example, when dealing with APIs in our SOC (Security Operations Center) this is often how we have to get around restrictions such as using an “@” in a username.  Instead of user@cybriant.com it’d be: user%40cybriant.com

So, let’s de-obfuscate the link using https://urldecoder.org:

__SNIP__

https://64e53rw7.blob.core.windows.net/5e53rw76/index.html?pzone=YW5kcmV3LmhhbWlsdG9uQHByaW11c3NlcnZpY2VzLmNvbQ=&#61&sa=D&sntz=1&usg=AFQjCNEZAsy-4nufrSB7lCmGPtn98lLW9Q

__SNIP__

There we have the REAL link.  Next, we’ll explode this link in Joe Sandbox to see it’s behavior.  Click on the following link to see the full Joe Sandbox analysis, and see what our SOC would discover if they were performing this for a customer.  I’ll give you a hint, it turns out it’s malicious:

https://www.joesandbox.com/index.php/analysis/166555/0/executive

Note:

When I first exploded the URL decoded link Joe Sandbox didn’t find anything interesting.  And so, the second time I utilized the link that was a google.com.mx referrer link.  When using the referring link Joe Sandbox determined that the final destination URL was indeed malicious.  In short, the bad actor built a check into their website to ensure that the full link was being used (confirmed by seeing Google.com.mx referring the user to the phishing website).  Pretty spiffy thinking on their part!