Attackers on your network love finding stray credentials. They are an easy way to elevate privileges and are often one of the first things attackers look for during post-exploitation.

There’s no shortage of places where these credentials can be found and surprisingly, there’s very little downside to attackers trying them…

…unless there’s a way to drop decoy credentials. This isn’t a new idea, but it usually requires heavy tooling and configuration.

Our newest AD tokens allow you to create fake credentials that can be left in all the familiar places, but without a heavy software component. A single, light-weight script that runs on your Domain Controller lets you know when the fake credentials are used.

Lets walk through typical usage:

1. Head over to your console to create a new “Active Directory Login” token:

2. You’ll need to add:

• A Token reminder, which is a note to your future-self reminding you where you placed the fake credentials. It’s possible that this token will fire months from now, when you’ve forgotten where you deployed it. The token reminder could be something like: credentials left in unattend.xml files on the backup server.
• A few fake usernames which when used will trigger the token (we’ll suggest some randomized plausible candidates for you automatically).

3. You can download these credentials as an unattend.xml file and/or as a plain text file to leave lying around.

4. Then you can download the token itself. This script will create a task on your server that catches the planted credential (attempted) usage. Run this script on a Domain Controller to set up the task.

5. An attacker who finds these credentials somewhere on your network will try them, which adds entries to event logs. The task processes the event logs and when it sees a login attempt for one of the fake credentials, it will fire off an alert to your Console (and announce their presence).

This is an unusual token for us, because it runs a script on your Domain Controller. We’ve kept the script simple and legible so that you can make sure it’s not doing anything nefarious (and so that the script logic can be easily extended). Our work on this token is inspired by IppSec, who showed an initial concept for an AD token that you can catch in his YouTube video here.

If you’d like to take it for a spin, reach out to us here. We’d love to hear how it works out!

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:

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. 

References 

1. https://blog.duszynski.eu/hijacking-browser-tls-traffic-through-client-domain-hooking/
2. https://blog.duszynski.eu/phishing-ng-bypassing-2fa-with-modlishka/
3. https://github.com/drk1wi/Modlishka
4. https://github.com/muraenateam/muraena
5. https://github.com/kgretzky/evilginx2
6. How Much Is The Phish? Evolving Defences Against Evilginx Reverse Proxy Phishing by Kuba Gretzky
7. Kuba Gretzky – Phishing Through Modern 2FA Defences With Evilginx
8. https://github.com/CERT-Polska/anti-modlishka
9. https://cert.pl/en/posts/2019/01/recommendations-on-mitigation-of-man-in-the-middle-phishing-attacks-evilginx2-modlishka/
10. Phishing with Modlishka (bypass 2FA)
11. https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/
12. https://github.com/aalex954/evilginx2-TTPs
13. #HITB2019AMS D2T1 – Muraena: The Unexpected Phish – Michele Orru and Giuseppe Trotta
14. Muraena – Unexpected Phish
15. https://learn.microsoft.com/en-us/security/operations/token-theft-playbook
16. https://www.proofpoint.com/us/blog/threat-insight/mfa-psa-oh-my
17. https://catching-transparent-phish.github.io/catching_transparent_phish.pdf

Labs is the research arm of Thinkst but research has always been a key part of our company culture. All Thinksters are encouraged to work with Labs on longer term projects. These become that Thinkster’s “day job” for a while. (These are intended both for individual growth, and to stretch ourselves into new areas: They don’t have to be related to Canary or security).

I took a brief hiatus from the engineering team to explore a computer vision project: CourtVision.

CourtVision set out to explore how to process a video stream of a racquet and ball game (padel–popular in the southern hemisphere and growing in popularity world-wide!) from a stationary (but unaligned) camera and extract information about the game. Padel, like other racquet sports, is played on a regulation court with lines demarking in and out of bounds (though there are times when a ball is in play even outside of the court); CourtVision aimed to extract information such as player positions and ball trajectories from a video feed. Secondly, visualising these outputs to provide insights into game tactics and strategies.

While there are existing computer vision systems to track play in racquet games, namely the Hawk-Eye system, these require systems of multiple fixed, calibrated, and synchronised cameras. The CourtVision challenge was to offer similar outputs from a single viewpoint, that is not in a specific location in relation to the court

The problem formulation

The problem is thought of as unwinding the events that gave rise to the video.  To achieve this we draw on prior knowledge such as court layout and ball and player dynamics. At each moment during a game the light emanating from the scene is sampled (at 30 fps) and produces a sequence of images.

The problem now is to associate certain pixels in the image with objects in the scene we would like to know more about and then make estimates about the objects positions that best explain the sensor readings – image sequence. 

Starting from here a number of avenues were explored and below is a linearized path of how we went about solving this problem.  

The path is simple (looking back):

1.  Establish a mapping from world coordinates to image plane pixel locations.
2.  Detect objects of interest (players and ball) in each frame.
3.  Estimate the world coordinates of each object by leveraging the inverse mapping found in Part 1.

Establishing a mapping between world coordinates and image plane is a well understood problem and implementations exist in commonly used computer vision libraries. The unknown in our case is doing it given a single image. Taking inspiration from [3], where they used the net on a tennis court to form an additional plane, we took orthogonal planes from the court structure and jointly found the camera pose and intrinsic matrices. This is explained in Part 1of the blog below.

In Part 2 we expand on how we leveraged existing computer vision models to detect objects of interest in each frame. 

Previous works that attempted 3D tracking from a single camera relied on either: knowing the size of the object being tracked [1] and that its projected size is invariant to the viewing angle i.e spherical objects; or the object of interest followed purely ballistic trajectories [2]. Here, we modeled the ball trajectory as a ballistic trajectory but retained a multimodal distribution over the ball’s states in a particle filter allowing the tracker to quickly adapt to new trajectories (modes) without explicitly modeling the interaction with walls, floor and racket. Part 3 illustrates this approach.

We made the following assumptions: 

1. Camera is stationary (but does not need to be in a specific location)
2. Court dimensions are known.

Players’ feet remain on the ground. Part 3 illustrates limitations in our tracker and by making this assumption we could improve player tracking stability.

Part 1: Camera calibration and pose estimation

Extracting real-world measurements from a camera requires knowing both the extrinsics (position and pose) and the intrinsics (such as focal length and distortion coefficients) of the camera. Once these are known we can map any point in the world coordinate frame to a pixel location in the image. We can also project rays into the world coordinate system from a desired pixel location.

The trade off made for not having to collect data first hand is that little is known about the setup. In this case the camera intrinsics and extrinsics were unknown. The common approach to determine camera intrinsics is to capture a calibration sequence which is often a checkerboard pattern. Since we didn’t have such a luxury we exploited the structure in the scene and defined a set of planes for which the image plane and world coordinate correspondences could be identified. By doing this we effectively introduced a set of 8 planes (similar to a checkerboard) and performed camera calibrations from this. The mean reprojection error was approximately 9 pixels on 1080 x 1920 images. 

Part 2: Bootstrapping custom object detectors

There are a plethora of off-the-shelf models that can do object detection however, none have single class “padel ball” detectors. Fine-tuning such a model is fairly common and to achieve this a few annotated frames were needed. LabelStudio is a very versatile data labeling tool that makes it easy to “put a model in the loop”. By doing this we bootstrapped our ball detector by repeatedly annotating more images and each time using the latest model to automatically label the additional images that were manually verified and corrected.

Part 3: Bringing image detections to the real world

Making detections on an image plane tells us nothing about the player and balls position in the real world. To estimate the position of the ball and players we define a state for each player and the ball and then update this state based on the detections. To govern this process in a more principled manner we used a Bayesian filter and in particular a particle filter. 

A particle filter stores a distribution over the state of each object. This is stored as a vector and an associated weight indicating a probability mass. To illustrate this the top image in figure 4 shows the cloud of particles representing the state of the ball. During the filter’s update step we follow Bayes rule to update the weight of each particle based on how well they explain the observation (the image). As we can see the core of the particle cloud is around the ray emanating from the detected ball position in the image. All particles along that ray “explain” the observation equally well. The information held in that current state (prior) ensures the updated state does not naively squash all particles onto the ray. Bayesian filters like this are a great way to encode knowledge we have about the ball dynamics and current state and update this belief as we get more observations.

But we don’t want a fuzzy cloud around where the tracker “thinks” the ball is? We want to know the best estimate of the ball’s position. Once again we consult our probability distribution over our ball states. We can grab any statistic we want. The particle with the largest weight – argmax or the weighted mean over all states. Below is the weighted mean position of the ball. 

This approach shows promising results but we did see the tracker fail after a few missed detection and resulted in mode collapse. That is the distribution over ball state (cloud of particles as in figure 6) either dispersed or reduced to a point. Particle filters come in a number of flavors and we only implemented the simplest resampling methods so it might be a bug in this or just a naive choice somewhere. Ah, research, so many avenues to explore! 

To constrain the player tracking to a plane we called on assumption 3. from above and projected the ray to intersect with the ground plane. These results are shown below as a heatmap of player positions and velocity. Tracking under this constraint means a detected player (measurement) can be projected onto the ground plane (tracker state) with no information loss (3D to 2D) and our tracker remains performant.

Results

The ultimate goal of such a system is to provide insights into game play and strategies. To this end we show court occupation and player movement speeds. The position and velocity heatmaps of players during a rally. The bottom image has Team A in the foreground and Team B in the background. Here we can see where players were during the rally as well as how they moved. In this rally we can see Team A  (on the left) plays from deep while Team B (on the right) occupies the mid court far more. Translating this raw positional information into actionable insights remains as future work. 

Going from a set of hypotheses to evaluating them is a fun technical challenge and my time in Thinkst Labs was great. I still hope to bring this to a court sometime soon and test the final assumption: seeing game play metrics can improve tactics. 

Resources

A collection of tools this project found useful as well as outputs from this work.

• Great computer vision libraries:
  • Kornia
  • Pytorch
  • Ultralytics
• An amazing visualization tool ReRun
• Slick tool for writing type set documents Typst 
• Paper (pre-print) describing this work in detail
• Code associated with this project – CourtVision

References

[1] 3D Ball Localization From A Single Calibrated Image

[2] MonoTrack: Shuttle trajectory reconstruction from monocular badminton video

[3] Generic 3-D Modeling for Content Analysis of Court-Net Sports