Skip to main content

Table of Contents

 

Introduction

An emerging trend in the threat landscape is the growing availability of phishing tools that act as man-in-the-middle proxies (also known as AiTM - Attacker in The Middlle), allowing attackers to intercept login credentials and session cookies, thereby bypassing two-factor authentication (2FA) protections. Originally designed for penetration testing, they have evolved into a popular method for cybercriminals to execute phishing attacks.

Common examples of phishing kits include Evilginx2.

The challenge with phishing kits acting as man-in-the-middle proxies resides on the fact they they are completely transparent to users and to security tools as well. There is no real difference between the phishing page and the real login page, and additionally there is no anomalous element in the page that would allow security crawlers to classify the page as phishing.

Moreover, phishing pages can be very short-lived, most of all if they are created with phishing kits, easily replicable and able to be quickly moved across different domains. For this reason relying only on threat intelligence is not an effective way to thwart this risk

The following document suggests several options to mitigate the risk of proxy phishing kits via the Netskope One Secure Web Gateway, with native security features of the platform, or in combination with native features of the cloud platform such as the Microsoft 365 Conditional Access.

The following documents propose three mitigation scenarios based on:

  • Conditional Access

  • Netskope One RBI

  • DLP

 

How a Reverse Proxy Phishing Kit Works

The following picture shows how a phishing kit works and is able to hijack the users' credentials.

 

Anatomy of a Phishing Kit acting as an AITM (Attacker-In-The-Middle)

 

Mitigation Strategy 1: Conditional Access on the Target Application

Conditional Access is a recommanded way to mitigate the risk of phishing kits (see for example this article by Microsoft). The principle behind this strategy is quite straightforward: the AITM acts a reverse proxy and as a consequence the source IP of the connection will be the IP of the reverse proxy, so any conditional access policy granting access to a specific range of IPs or specific locations will prevent the malicious connection to be successful. This might not prevent the attackers to steal the credentials, but they won’t be able to use them as long as they connect from a location that does not match the conditional access policy.

Netskope customers can simplify the configuration of conditional access policies since the NewEdge network assigns a specific range of IP addresses that can be configured in the target application. Of course this range is shared across all Netskope customers, however If needed the configuration can be narrowed further, leveraging the tenant restriction policies of the cloud service provider, or even better, Netskope customers can also purchase a Dedicated Egress IP (DEIP) specific for their organization.

The following example shows the Entra Conditional Access configuration limiting the access only to the IP addresses of the Milan Netskope POPs (yes, I am connecting from Italy!)

 

Entra Conditional Access

And this is the outcome once the connection flows to the destination (in this case a Microsoft 365 tenant) through the phishing page (please note the bogus domain login.microsoftlogino.]link).

 

Conditional Access Block

 

Mitigation Strategy 2: Remote Browser Isolation

 

Remote Browser Isolation (RBI) can mitigate the threat, configuring a read-only profile for specific categories. This strategy is particularly effective since ir prevents the attacker from stealing the user’s credentials and authentication cookies.

Netskope provides two different license for RBI:

  • The Targeted RBI license supports specific categories including:

    • Uncategorized

    • Newly registered domain

    • Newly observed domains

    • Parked domains

    • Security risk categories

  • The Extended RBI license supports:

    • More than additional 60 web categories, besides the ones available on the Targeted RBI license

    • unmanaged web apps

    • CCI rating

    • app tag, or destination country

    • 18 cloud apps including: Box, Dropbox, Google Drive, Google Gmail, Facebook, iCloud Drive, Line, LinkedIn, Microsoft Office 365 OneDrive for Business, Microsoft OneDrive, Outlook Live (OWA), Protonmail, Reddit, Telegram, Twitter, Yahoo Mail, WeTransfer, and WhatsApp. 

In this mitigation scenario it is possible to create a read-only RBI profile that prevents the submission of the users’ credentials in the phishing page. The following picture shows the example of such an RBI profile that needs to be put into a security policy whose action is isolate:

 

Example of the read-only RBI Policy

And the following Image shows the user experience when landing on the phishing page in isolation. Please note that the user cannot insert any credentials (and once again please not the bogus URL). Additionally a pop-up message and a colored frame (both of them customizable) warn the user that the page is being visited in isolation, and some activities are prevented by the isolation profile.

 

Bogus login page visited in isolation mode

Mitigation Strategy 3: DLP Profile

This mitigation strategy allows to create a simple DLP profile containing the email domain of the organization, which prevents the submissions in bogus forms (and potentially any forms belonging to applications that are not explicitly approved by the organization). The following image shows the example of such a policy where two specific domains (“netskope.com” and “netskopedemo.com) are prevented for being inserted into specific categories including login forms. In this case the action has been configured in “User Alert”, giving the user the possibility of choosing if logging in or aborting the session, in case with a justification (we call it coaching), but it is obviously possible to configure a block policy.

 

DLP policy to prevent the submission of corporate credentials

And this is what happens when the user tries to insert the credentials into the bogus login page. Please note that the block happens before the user access the phishing proxy, so it is impossible for the user to steal the credentials.

 

DLP Block during the submission of corporate credentials into a fake login form.

Conclusion

Netskope One offers multiple ways to mitigate the risk of phishing attacks. In this article we have explored several options to thwart phishing kits via security and DLP features embedded into the platform. These are part of the Netskope overall strategy that aims to enforce a layered security approach with multiple engines including static and dynamic detection algorithms.

Do not also forget that there are additional weapons in the Netskope arsenal to protect organizations from more “traditional” phishing attacks, such as the Netskope Threat Intelligence or the inline phishing classifier.

Be the first to reply!

Reply