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.
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:
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.
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:
Thanks for reading.
- How Much Is The Phish? Evolving Defences Against Evilginx Reverse Proxy Phishing by Kuba Gretzky
- Kuba Gretzky – Phishing Through Modern 2FA Defences With Evilginx
- Phishing with Modlishka (bypass 2FA)
- #HITB2019AMS D2T1 – Muraena: The Unexpected Phish – Michele Orru and Giuseppe Trotta
- Muraena – Unexpected Phish