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.