Intended Audience: redteamers
Microsoft Office365 is becoming increasingly popular, and I'm now seeing it more often than not on redteam and phishing engagements. One feature that stands out to me is that it that 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 you 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.
What we want our targets to see
Don't worry Microsoft, it's just cat pictures, honest
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.
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, taken 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 wont work if your 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 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 doesnt 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 could 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. Setup 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 are not 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 wont 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 specious 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 https://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.
Comments