Cloned Website Token and Reverse Proxies

Our Cloned Website Token has been available for a long time now, both on our public Canarytokens.org site as well as for our Canary customers. It’s helped users all over the world detect attacks early in the process. We wanted to take a moment and go over some of the details of this token: how it works, how to create and use one, and critically, how it fares against the new “Adversary-in-the-Middle” (AitM)-generation of phishing attacks..

The cloned website token is super simple: You get an alert any time your webpage is hosted or proxied through an unexpected location.

It’s free, it’s easy, and finding out your site has been cloned as soon as it happens gives defenders precious hours (or days) to get ahead of serious attacks.

Here is how you create it:

1) Visit canarytokens.org

2) Select cloned site token

3) Add this JS to your site

4) You can choose to obfuscate it if you want

Now.. if an attacker clones or proxies your site…

The JS runs.. If it is not on the right domain

You get an alert.

So, in essence. If the URL for a site that a user has visited, is not the same as the expected URL, you get an alert.

Many of our customers also obfuscate the JavaScript, to avoid attackers that replace strings in a cloned site or proxied site. For example, if you just leave the plain text domain string example.com, attackers can simply match and replace that inside of your page. By adding obfuscation, you can make it more difficult to find and replace your token. Below is an example of a recent addition to our customer console, that allows teams to simply click to obfuscate the JavaScript.

We’ve also recently added obfuscation to our canarytokens.org site as well!

That is the basics. Takes you just a few seconds to create and obfuscate the JS Snippet and insert it. Go ahead and create one and put it on a site today, don’t worry, I’ll wait! If you want to learn more, keep on reading.

History of the Cloned Website Token – How did we get here?

This token has more than proved its worth from huge tech companies discovering their red teamers weeks before the official engagement has begun to large media houses actively fighting nation-state attackers.

Recently though, attackers have been upping their games with a move to making use of reverse proxies instead.

This allows duped users to interact with the original site, making the attacks more believable. Attackers can steal both usernames and passwords, as well as web based session tokens while providing a seamless experience to the users being phished.

What is a reverse proxy phishing attack?

The reverse proxy has been rediscovered with new enthusiasm and tools. In essence this is very similar to running a tool like Fiddler or Burp, where you can control and inspect and modify all the requests and responses. The attacker runs a reverse proxy and sits in the middle of the user and the legitimate server, hence Adversary-in-the-Middle. The attackers will send phishing emails or links, and hope you click on the site, and login–then they have captured your credentials.

There are a number of tools on the market that allow you to perform these attacks. Some examples are Modlishka, Muraena and EvilGinx (see references below) . These tools grant an attacker or researcher or defender complete control over the HTTP[S] interactions.

The researcher Kuba Gretzky and others have also done a number of talks and published extensive tools and documentation on this topic.

A common pattern is to register a domain name that is similar to the target that you hope to phish.

So suppose you have a nice website canaryexample.com. An attacker may register 3xample.com and then proxy victims to canaryexample.com through the fake site.

“The phishing page has two different Transport Layer Security (TLS) sessions—one with the target and another with the actual website the target wants to access. These sessions mean that the phishing page practically functions as an AiTM (Adversary in The Middle) agent, intercepting the whole authentication process and extracting valuable data from the HTTP requests such as passwords and, more importantly, session cookies. Once the attacker obtains the session cookie, they can inject it into their browser to skip the authentication process, even if the target’s MFA is enabled.” – Microsoft Threat Intelligence

What’s the difference with “basic” phishing attacks?

With basic phishing attacks, attackers attempt to recreate, or clone as faithfully as possible, a lookalike page (from Outlook, LinkedIn, Google, etc). They will then attempt to lure the victims into entering their credentials, which are then logged and stolen by the hacker.

A reverse proxy attack takes it one step further. Instead of showing a lookalike page, it simply relays traffic between the real website and the phished user.

After clicking on a malicious link, phished victims are sent to the real website, unaware that the malicious proxy is capturing the data being transmitted between the victim and the site. There are no TLS warnings, since the domain the user lands on initially is controlled and issued a valid certificate to the attacker.

This is an excellent diagram showing inspection and manipulation of HTTP body in the pages that are served:

source: https://conference.hitb.org/hitbsecconf2019ams/materials/D2T1%20-%20Muraena%20-%20The%20Unexpected%20Phish%20-%20Michele%20Orru%20&%20Giuseppe%20Trotta.pdf

How does the Cloned Website Token perform in the face of this new/old technique?

tl;dr: Even in the face of these emerging attacks, the cloned website token performs as expected!

This token is based on a very simple check: Expected vs Actual location of the website.

By distilling this token down to the essence of the check, it allows us to endure across a wide range of geriatric as well as emerging attacks. While the attacker’s techniques may change, this simple token still endures.

Let’s imagine our login site is canaryexample.com, however, the URL I clicked is associated with 3xample.com.

We can see the difference between the expected URL and the actual URL.
This is picked up by our Canarytoken and alerts us even before a user has even attempted to login to the fake / proxied site.

We think this is very exciting for teams defending their web apps.

You can do this for free, you can do it today.

It’s a durable detection that works well in the face of emerging attacks.

A few more final thoughts

In our customer consoles we have an “ignore option” which is not available on canarytokens.org. The ignore list simply helps teams that have expected proxies or alternative hosting environments, or CDN, etc.. Even if you are using the open-source canarytokens.org, it’s important to think through possible expected domains that might trigger that don’t require an all-hands-on-deck response.

Proper Mitigation

While this may help you detect that your site has been cloned or is under an active proxy attempt, it is only a part of a holistic response to phishing campaigns. It is recommended to use FIDO2 as an MFA scheme as those authentication sessions are tied to the expected domain, so both simple cloning and AitM attacks will fail to get a session. Microsoft offers other guidance as well:

Closing thoughts

By adding a simple few lines of JavaScript, we can detect if a site we want to protect is being cloned or proxied. This gives defenders a quick insight that they may not otherwise have. Give it a try, it’s super easy, let us know how it goes. We are thankful for the authors of the reverse proxy tools for publishing their work and tooling to better help defenders with detection. It is important to realize, that without obfuscation, there is a chance your Cloned Website Token won’t alert, if the attacker is replacing strings–we’ve added obfuscation to help defenders.

Thanks for reading.

Cloned Website Token and Reverse Proxies