Adding cloned login page detection to your phishing defense arsenal

We’re excited to announce the release of our cloned login page detection feature, which will be available to all customers immediately. This feature adds another layer of defense to our already-cutting edge phishing prevention capabilities, enabling security teams to protect workforce identities and shut down phishing attacks that use website cloning tools. 

It’s more important than ever to stop phishing attacks 

Phishing is the oldest trick in the cybercrime playbook, but attackers continue to devise new ways to circumvent defenses and execute successful phishing campaigns. Old-school phishing prevention solutions have tried to solve the problem by protecting the email inbox, a common (but not the only) attack vector, and blocking lists of known-bad domains. But these methods are not as effective today as they were a decade ago. 

There are a few reasons for this. When anti-phishing products were first rolled out, detecting and responding to identity attacks – phishing, credential stuffing, etc. – used to be just one possible method of initial access in quite a lengthy Kill Chain that stretched from the compromise of the user device, pivoting to internal network resources, escalating privileges, moving laterally, and finally achieving their objectives. The more actions an attacker has to perform, the more opportunities for detection, and the higher the likelihood that they’ll be caught in the act before any real, lasting damage can be caused. 

But today, attackers have a lot of opportunities to cause significant damage for much less effort than before through identity attacks. For example, if the goal is to compromise an app like Snowflake and dump the data from it, the Kill Chain is way shorter than a traditional network-based attack. And the initial layer of anti-account takeover controls are much more important in this context – there’s no margin for error. 

Why are existing controls failing?

The fact that phishing has remained a problem for so long is evidence enough that the old ways don’t work (and honestly, they never have). 

The main limitation is that for defenders to know that a URL, IP, or domain name is bad, it needs to be reported first. When are things reported? Typically after being used in an attack – so unfortunately, someone always gets hurt, and defenders are always one step behind the attackers. 

To make it harder for defenders to pre-emptively find phishing sites, attackers use a range of methods to obfuscate their phishing sites and evade the prying eyes of security teams and threat intelligence organizations. One of the methods that attackers use to make their sites appear legitimate is to create cloned login pages, which can be easily achieved using commonly available hacking tools.

Many phishing kits allow the attacker to simply copy the HTML code from a legitimate website and duplicate it on the malicious site or dynamically proxy the real site, creating a virtually identical interface that may lure users into a false sense of security when inputting their credentials.

Building defense in depth against phishing attacks

At Push, our goal is to change the way the industry thinks about phishing. We're focused on building detections that are hard for attackers to bypass because the variables we detect are difficult for them to change.

Push already offers controls that detect and prevent phishing attacks at different stages of the attack chain. Our AitM phishing toolkit detection can identify the specific phishing kits attackers are using (like Evilginx) and our SSO password protection control prevents employees from entering their password into any page other than the official SSO login page – preventing the key user action of entering their valid credentials into a phishing site.

While there are many other types of anti-phishing solutions on the market, only a browser-based agent like Push can detect and intercept attacks at the point of impact. 

Cloned login page detection adds yet another layer of defense, by identifying the presence of a page that is trying to pass as a legitimate login page, blocking the user from entering their password and shutting down the attack.

Much like other Push features, users can simply enable cloned login detection on the Controls tab within our portal, as seen in the image below. With each of these features, Push enables users to solve for a piece of the phishing puzzle. 

The new feature detects fraudulent login pages designed to mimic a legitimate identity provider (IdP) login page, as well as other high-sensitivity pages. We do this by fingerprinting the page structure and resources of your legitimate login pages and monitoring for pages that are very similar. By analyzing the actual structure of the page, we can virtually eliminate false positives and deliver high fidelity alerts to your security team.

The Cloned login page detection feature can identify clones of the following legitimate IdP login and signup pages:

• Google Workspace

• Microsoft 365

• Okta

• JumpCloud

• Duo Security

• Ping Identity

• IBM Identity Provider

• SAP Identity Provider

• GitHub

• AWS

When Push detects a cloned login page, it triggers an event that you can view on the Events page within the platform. This data can be fed into a SIEM or other tool by emitting a webhook event.

Alongside our SSO password protection and phishing toolkit detection, cloned login page detection adds another layer to our defense in depth approach. Together, these features provide comprehensive protection against phishing attacks.

Try it yourself

Here at Push, our mission is to build straightforward controls to protect against specific attack techniques, and then tell you exactly what those are so you can check it out. We think it’s important that you can test that our product actually does what it says. 

Like all our other controls, cloned login page detection is really easy to use – and, more importantly, to test that it works in real life (without having to hire a pentest team). 

To test the feature once you’ve enabled it:

• Visit a high-risk app like your IdP, or try the GitHub login page – when you do, the browser agent creates a couple of signatures for that login page.

• Next, simulate cloning that login page as an attacker would during a real phishing attack. You could do this using an Attacker in the Middle (AitM) phishing kit that basically proxies a login page – perhaps something like Evilginx (which would also trigger other Push detections) – but this takes a bit of setup. An easier way is to clone an app non-maliciously using a free web proxy which causes the same login page to show up on a different domain as it would for phishing. Plain proxies worked for us – open it and browse to https://github.com/login.

• Open the Push events page and find the cloned login page detection event. It should look something like:

And there you have it! Peace of mind that Push actually does what it says on the tin. 

Sign up for free

You can try Push by creating a free account on pushsecurity.com. You can also book a demo. We’ll be happy to show you this feature, along with how we discover all the apps your employees are using, even the ones not behind SSO, and how we detect vulnerable identities and stop identity attacks with browser-based controls.