A lot of work and effort has been put into deceptive technology, I don't really see it discussed much outside of honeypots (esp with the AI emulated environments etc.) and jars being flooded with the joy of the web. (This of course, being the nature of it, if everyone knows it is there, it is no longer deception ), but despite this, from an educational perspective, I've found aggregating a long list of information into actionable insights valuable to others, so here we are :)
To ensure this isn't click-bait for a holy grail solution for Credential and/or Session Token theft detection, I am highlighting the fact that attackers in some instances clone login pages (to your login portals especially) to make phishing and other social engineering attacks appear more legitimate.
A Canary what?
"Canarytokens are like motion sensors for your networks, computers and clouds. You can put them in folders, on network devices and on your phones. Place them where nobody should be poking around and get a clear alarm if they are accessed. They are designed to look juicy to attackers to increase the likelihood that they are opened (and they are completely free)."
- https://docs.canarytokens.org/guide/
Site Cloning
This is quite an interesting one as we are in a world of session theft in general being so rife, the ability to detect when a login page (for example) has been cloned for nefarious purposes is some really valuable information! Of course, we have alternative means of doing this such as Favicon hashes, but in the spirit is ' more is better', let's run through this deployment.
How it works
In a quick TLDR, Canary Token provides you with either a snippet of JS (JavaScript) or CSS to place into your application, (in this case, your authentication page) and will alert upon the content being observed in a non-defined URL.
The attack
The following will describe the attack at a high level prior to going into a short demo.
The setup
Utilising tools such as SeToolKit (Social-Engineer Toolkit) cloning a website is very straightforward, and as our authentication portals are typically public facing (and by nature... not being auth-walled) they are a smart target for attackers to go after.
Pictures/icons: Flaticon https://www.flaticon.com/
 |
| Initial setup |
In the above scenario, assume some application front-end has now been cloned by the threat actor, and they want to weaponise this to gain access into the environment.
Exploitation
Ultimately, if the attack was effective, the threat actor now has unauthorised access - and it should be stated, MFA protects the login process, not the session. Depending on the session lifetime, this could result in more than enough persistence to act on objectives.
What's available?
This capability comes in many forms from Entra to ASPs but in this instance, I will demonstrate it on a simple login page spun up on a Ubuntu server, more so as I don't have a P1/P2 licensed environment available for this demo.
- I hope from this, you will gain incentive and insight into the capabilities of utilising such technology especially on your auth portals.
How to implement it
So now we have a pretty good high-level overview of the attack, let's first implement our application and canary token. I'm going to use Apache Tomcat just for the ease of use.
 |
| The web application |
Now by getting the Canary Token (JS) we are given a JS snippet and some tips.
 |
| Token Creation |
For this demo, I'll perform this all in a private space, hence use IP addresses (for both legit and cloned site) just to speed up the process, but you will need to put in the appropriate hostname.
First, we need to place the provided JS into our webpage.
 |
| Addition to web app |
The attack & Triggers:
So we have our lovely authentication portal public facing ready for our users, but a threat actor observes it and wants in too.
Before going into this, ensure your Kali (or flavour of your choice) can reach the web page.
Cloning
First, jumping onto a Kali Linux box we can utilise setoolkit and configure as follows
In the above video, we see setoolkit access the defined page, and spin it up immediately.
Weaponise
Now the attacker has the appropriate 'infrastructure' per say set up to facilitate this, they can begin their phishing or social engineering campaign, however thanks to our canary token we have some detection capability in place.
However, in order for this to trigger, the page must be viewed to invoke the JavaScript, meaning one of the two scenarios must happen:
- The attacker verifies the outcome of the page (extremely likely, and you will get an IP associated with it!
- A user clicks the link and triggers the alarm
Additionally, depending on the objectives of the attacker, a variety of different paths could be taken here, simply harvesting the credentials or going ahead with MITM attacks for MFA & Session access reasons.
Detection
Upon a user (being legitimate or the adversary) accessing, the javascript will verify the hostname and if a non-match occurs, it will tweet away via the Canary Portal or in the form of a predefined email.
 |
| Web Portal notification |
What's extremely awesome about this is the volume of IOCs it provides as seen above, and the email - which arrived instantly.
 |
| Mail notification |
Summary
I highly recommend exploring https://canarytokens.org/nest/ further to see how you could implement deceptive technology into your detection stack. As seen above, this could have significant positive outcomes if implemented.
Comments
Post a Comment