Bypassing Safe Links in Microsoft Defender for Office 365

Introduction

In this blog, we will demonstrate how attackers can bypass Safe Links in Microsoft Defender for Office 365 to successfully deliver a phishing email with a fake login page link that captures both the user credentials and Microsoft Authenticator token from the user; bypassing two-factor authentication.

We will first explore the normal Safe Links behavior in blocking malicious links and then showcase bypassing that protection.



What is Microsoft Defender for Office 365?

Microsoft Defender for Office 365 is a cloud-based protection service for Microsoft 365 suite. One of the protections it offers is Safe Links, which protects users from clicking on malicious links. Safe Links operates in real-time, which means it scans links for malicious content at the moment a user clicks on them.



More about Microsoft Defender for Office 365:

https://www.microsoft.com/en/security/business/siem-and-xdr/microsoft-defender-office-365







Lab Requirements

For the demonstration purpose, we have set up our testing lab which has the following:

Phishing email domain: Will be used by the attacker to send the phishing email.

Phishing login page: Will have a phishing page where it asks the user to enter their credentials. The link of this page will be in the body of the phishing email.

Victim email domain: The target organization where an employee will receive the phishing email from the attacker.

Microsoft 365 subscription: The main component for Microsoft 365 suite.

Microsoft Defender for Office 365 Plan 2: The cloud-based protection service for Microsoft 365 suite which has the Safe Links feature.

Evilginx: A man-in-the-middle attack framework used for phishing login credentials along with session cookies, which bypasses two-factor authentication protection.

Normal Safe Links Behavior



First, we create a phishing page to simulate the attack. Here, it's just a welcome page that prompts the user to login to Microsoft 365. This page can be a fake copy of the victim organization login page.

Once the user clicks on "Sign in with Microsoft", they will be redirected to the malicious page where the attacker can capture the credentials. Evilginx is running here with o365 phishlet to capture the Microsoft 365 credentials.

On the phishing page, where Evilginx is sitting, the user will be prompted to enter their email.

After entering the email, Evilginx will forward the request to the real Microsoft 365 to verify if the email is valid or not before prompting the user to enter their password.

Once a valid email is entered, the Evilginx phishing page will ask the user to enter their password.

Now the phishing page is ready and working as expected.



Now, let's simulate an attacker sending the phishing link to a victim in an organization that uses Microsoft 365 where it will have the Safe Links protection as part of the Microsoft Defender for Office 365.

We create our phishing email and send it to the victim.

The email reached the victim's inbox. However, it was deleted after a few minutes, and the Global Admin in Microsoft 365 received an alert about this activity (this was done by the Safe Links protection).

Defender for Office 365 also classified our phishing domain as malicious.

Bypassing Safe Links

Now, we will bypass this security feature in Microsoft Defender.



We did the same set up as in our previous scenario. And since our domain was categorized as malicious, we used a new domain for the set up that has not yet been seen by Microsoft Defender.



Now, since we control our phishing server, we will block Microsoft IPs, specifically the IPs for the Safe Link check. We used Apache to block these IPs as follows.

* Note: Those are Microsoft IPs as of the date of writing of this blog. Attackers can discover them during their information gathering phase and will be valid for a long time.

After blocking Microsoft IPs, that are used by Safe Links, from reaching and scanning our phishing page, we send our phishing email to the victim.

The victim received the email and opened it.

After the victim received the phishing email which contains the phishing link, the phishing web server received requests from Microsoft to scan our phishing link. But those requests were blocked by our Apache server blocking rules, so Microsoft Defender will not be able to scan the phishing page for malicious contents.

The link is not blocked by Microsoft Defender and the victim is able to access the phishing page.

The victim entered their email successfully.

Followed by their password.

After the victim enters their correct credentials, they are promoted to enter the Authenticator number from their device for two-factor authentication.

Now the victim successfully entered their email, password, and 2FA.



In the Evilginx server, we get the entered credentials by the user including the session token, which we can now use to login to the victim's Microsoft 365 account and access any service that uses Microsoft 365 for authentication.

At this point, the phishing email was not deleted by Microsoft Defender, nor was the link classified as malicious, and no alerts were generated to the Global Admin about this activity.





Conclusion

This blog demonstrated how attackers are able to block Microsoft IP addresses to bypass Safe Links protection and successfully execute a phishing attack compromising user credentials and bypassing two-factor authentication. It emphasizes how user awareness about cyber threats plays a major role in the security of organizations, and relying on technology alone for protection is not enough.



References

https://github.com/kgretzky/evilginx2

https://emtunc.org/blog/03/2017/bypassing-safe-links-exchange-online-advanced-threat-protection/