Defending your Phishing Page Against EOP and Safe-Links

Intended Audience: redteamers

Microsoft Office 365 is becoming increasingly popular, and I'm now seeing it more often than not on red team and phishing engagements. One feature that stands out to me is that it is very good at investigating links, both when the email is first delivered and again when the link is clicked through Safe Links. The last thing you want is for your payload or page to end up in a Microsoft sandbox. But I've developed a few techniques over the last few engagements to get the upper hand, at least for now.

Step 1: Create two sets of content

To pull the wool over Microsoft's eyes, create two sets of content when preparing for an email phishing campaign. One set of content will be shown to the targeted user, another set of content will be shown to Microsoft and any other potential security systems and analysts.

For example, you might create a credential harvesting page for the targets, but everyone else would be taken to some legitimate looking content.

Step 2: Blacklist Microsoft's published IP address range

Next, make use of Microsoft's published IP address space. Most, but not all, of the probes come from this range.

https://www.microsoft.com/en-us/download/details.aspx?id=53602

Create some logic at the start of your backend code for your phishing page. Any incoming request which matches one of the CIDRs listed here, show the legitimate looking content. If they pass this control, take them to the phishing content.

Step 3: Blacklist IP addresses using odd or no user agents

What we've discussed so far seems to work at blocking Microsoft for about nine in ten emails. However, this won't work if you're sending more than a handful of emails. Next we can consider user agents. Microsoft use a range of user agents, some of which are uncommon. Sometimes there will be no user agent at all.

Do some testing, and determine what user agents coming through seem unlikely to be actually in use by your target. If these are detected, dynamically add them to your blacklist so they get shown the legitimate content.

Step 4: Blacklist requests with no or unknown target identifiers

Due to the prevalence of one-time links, Microsoft doesn't usually access anything that looks like a one-time link, at least not exactly. Otherwise Microsoft would end up automatically clicking verification emails. To allow it to still review content without invalidating one-time links, it'll often do one of the following:

• Access the URL, but modify anything that looks like hexadecimal or UUID to a different value.
• Access the URL without the identifier or a blank identifier.

Add a unique URL parameter to your email link. Dynamically blacklist any address that comes in with an incorrect or missing identifier. Though there is some risk to this approach, as a curious technical user could end up blacklisting the office IP address.

Step 5: Blacklist IP addresses using the HTTP HEAD method

Though generally Microsoft doesn't access URLs with identifiers, sometimes it'll perform a HEAD request.

[ip] - - [date] "HEAD /page?code=[idcode] HTTP/1.1" 200 [size] "-" "-"

Any requests which come through with an unexpected HTTP method, dynamically add to your blacklist.

Step 6: Find all Microsoft's cloud providers

Microsoft has an extensive number of servers not covered by the public IP address space. Set up a test Office 365 account, and send it emails with test links which don't link to malicious content, testing all of the above code. Occasionally you'll notice requests from IP addresses that are not already in your original IP blacklist; some of these ranges belong to Microsoft but just aren't published in the Public IP Address Space document, others belong to various cloud, VPS, and other hosting providers from around the world.

Microsoft are clearly combating spammers blacklisting their published IP address space by using third-parties to make it harder. I won't be publishing a full list of these organisations myself, but you can repeatedly send emails with a test URL and click the link to gather a list of them. Every time you get an IP address that either gets through your blacklist or is dynamically added for suspicious behaviour, research the owner and blacklist all netblocks you can find that belong to them.

For example, an IP address in the 5.135.59.0/24 range queried my phishing page after a test email was sent. As the phishing page isn't publicly linked and no user clicked the email address, this must have been an action performed by Microsoft or on their behalf.

Whois shows that this IP address belongs to OVH Hosting, which after a little Googling is a hosting provider offering services on ovhcloud.com.

user@host:/$ whois 5.135.59.X
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '5.135.59.0 - 5.135.59.255'

% Abuse contact for '5.135.59.0 - 5.135.59.255' is 'abuse@ovh.net'

inetnum:        5.135.59.0 - 5.135.59.255
netname:        PT-OVH
descr:          OVH Hosting LD

Summary

It'll take some preparation and maybe a few engagements to get right, but this should be enough to keep your phishing page out of Microsoft's sight most of the time.