Canarytokens: Catching Insider Threats (and Threat Actors?)

Insider Threat?

We were contacted by a company that regularly sends emails to customers promoting new services and discounts. An Excel is uploaded to a web server, where a job processes the file to create an email per customer, taking the email addresses from the uploaded Excel file.

For a significant period of time, the company has been struggling with a serious issue - its competitors are reaching out to the same customers they intend to contact in the upcoming mailing, often a day or two earlier. This is not an isolated incident. Every customer listed in the Excel sheet for the forthcoming mailing has been contacted earlier by competitors (in plural), posing a significant threat to our customer base.

The customer asked us for advice on finding out whether they face an insider threat selling their data to the competitors or whether the external web server had been hacked (and the newest Excel file is leaking from a web vulnerability or another badly secured access on the webserver).

Let me introduce you Canarytokens

Canarytokens are decoys that mimic a digital resource on endpoints, servers, or networks to serve as early warning indicators of a security breach or unauthorized access. They are named after canaries used in coal mines to detect toxic gases, where the canary’s death served as a warning sign for the miners to evacuate.

In cybersecurity, canarytokens work similarly by generating alerts when they are triggered. They are designed to look like enticing targets for attackers, such as documents, URLs, email addresses, or other digital assets. When an attacker interacts with or accesses a canarytoken, it triggers an alert, providing defenders with valuable information about potential threats.

Canarytokens come in various forms, including:

• File tokens: Files that, when opened, trigger an alert.
• URL tokens: Unique URLs that, when visited, trigger an alert.
• DNS tokens: Unique DNS records that, when looked up, trigger an alert.
• Email tokens: Email addresses that, when sent a message to, trigger an alert.
• Web bug tokens: Small images or code snippets embedded in web pages or emails that trigger an alert when loaded.
• Sensitive Command Token: This token creates a registry key and sends an alert to you in near real-time that the command of interest has been executed.

One can easily generate a new canarytoken here. Figure 1 depicts a subset of the possible token types for a new canarytoken (or configuration).

For further insights into canarytokens, watch the BlueHat talk Building a Canarytoken to Monitor Windows Process Execution.

Excel Canarytoken

Returning to our insider threat or compromised web server case, we planned to generate an Excel canarytoken document, which we will pass on to our client. The client could hand it over to various people in the organization they suspect of wrongdoing or simply upload it to the web server as a preparation for the upcoming emailing to the customers.

Creating a new document is trivial, and we can now download our canarytoken document (with the filename hkkmt4dgsx7dm150bffdjhx3s.xlsx).

The next step, as a test, is to upload our canarytoken Excel file to an online Excel parsing platform. Keep in mind that we uploaded the document to this parser platform for the sake of demonstration. It does not really matter in this case if we open the document on our computer or upload it to such an online parser - we must simulate the opening of the document, check whether the alerting mechanisms (the “canarytoken”) is triggered, and see what the outcome will look like.

And yes, uploading our document to the Excel parsing platform indeed parsed our canarytoken file. A few minutes later, we received a message in our mailbox that someone had opened the document (Figure 5).

How does that work? XLSX files are the default format for Excel files created in versions of Excel starting from Excel 2007. They are based on the Open XML standard and are essentially a collection of XML files compressed into a ZIP archive:

% file hkkmt4dgsx7dm150bffdjhx3s.xlsx 
hkkmt4dgsx7dm150bffdjhx3s.xlsx: Microsoft OOXML

And we can unzip our document:

% unzip hkkmt4dgsx7dm150bffdjhx3s.xlsx 
Archive:  hkkmt4dgsx7dm150bffdjhx3s.xlsx
  inflating: [Content_Types].xml     
  inflating: _rels/.rels             
  inflating: docProps/app.xml        
  inflating: docProps/core.xml       
  inflating: xl/workbook.xml         
  inflating: xl/worksheets/sheet1.xml  
  inflating: xl/worksheets/_rels/sheet1.xml.rels  
  inflating: xl/drawings/drawing1.xml  
  inflating: xl/drawings/_rels/drawing1.xml.rels  
  inflating: xl/styles.xml           
  inflating: xl/theme/theme1.xml     
  inflating: xl/_rels/workbook.xml.rels

Looking inside the file _./xl/drawings/rels/drawing1.xml.rels:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" 
Target="http://canarytokens.com/static/hkkmt4dgsx7<redacted>/index.html" 
TargetMode="External"/></Relationships>

We see a reference to an external image, which is an HTML webpage. It’s not strictly necessary to open the Excel file, the loading of this website alone triggers the canarytoken, which brings another email to our inbox. Equipped with such a document, the customer will find out from which IP address the document is opened—proofing whether the data is indeed stolen or leaked (or not).

Another story - Elevate Kit from CobaltStrike

The power of canarytokens can also be told in another story: In an investigation last year, we found out that the threat actors executed the elevate command from CobaltStrike to raise the privileges on the beachhead (or at least tried to raise the privileges). The following command (with the corresponding output) was recorded inside the Cobalt Strike logs:

elevate uac-schtasks
Tasked Beacon to run windows/beacon_https/reverse_https
(<redacted>) in a high integrity context

The elevate command is part of the ElevateKit from CobaltStrike: The Elevate Kit demonstrates how to use third-party privilege escalation attacks with Cobalt Strike’s Beacon payload. The parameter uac-schtaks, passed to the elevate command, runs the Invoke-EnvBypass function from the EmpireProject.

Loading this module on my test machine with activated Defender flags the code immediately as malicious (disable the local antivirus for testing this specific UAC bypass). When I later opened my mailbox, I was surprised to find that a canary token had been triggered.

But why?

I completely forgot about the whoami Canarytoken I installed on that machine

The canarytoken was triggered because Invoke-EnvBypass (see above) runs the whoami command:

if(($(whoami /groups) -like "*S-1-5-32-544*").length -eq 0) {
    "[!] Current user not a local administrator!"
        Throw ("Current user not a local administrator!")
    }
    if (($(whoami /groups) -like "*S-1-16-8192*").length -eq 0) {
    "[!] Not in a medium integrity process!"
        Throw ("Not in a medium integrity process!")
    }

Yes, I know the whoami discussions from Twitter.. As the above case from a recent incident response case shows, attackers might use the standard tools and commands without considering the implications or dependencies of the commands, which we, as defenders, can use to our advantage.

Oddvar Moe published a blog post in 2018 about Image File Execution Options, the technique used by this canarytoken. If you are interested in the details of the implementation, check out the blog post here.

Conclusion

Canarytokens can be helpful, especially for specific use cases such as the first case with the Excel sheet. In a company network, it would have to be carefully considered where and in which case it makes sense to place a canarytoken. In any case, it’s another tool in the box.

As pointed out by Casey in his BlueHat talk Building a Canarytoken to Monitor Windows Process Execution:

Not a replacement for an EDR: Canarytokens are not a direct replacement for Endpoint Detection and Response (EDR) solutions. While both enhance an organization’s security posture, they serve different purposes and address various aspects of cybersecurity.

Commands aren’t as rare as you might think: Canarytokens may generate false positives, triggering alerts for benign activities or legitimate users. This can lead to alert fatigue and undermine the credibility of the system, causing administrators to overlook genuine security incidents.

The following are some of my thoughts on the subject.

Dependency on External Services: Many Honeytoken services rely on third-party providers or cloud platforms to host and manage the tokens. This dependency introduces risks related to service availability, data privacy, and compliance with regulatory requirements.

Early Warning System: Canarytokens provides an early warning system for potential security breaches. Administrators can quickly detect unauthorized access or suspicious activities by deploying these tokens across different parts of a network or system.

Simple Deployment: Canarytokens are relatively easy to deploy and require minimal configuration. They can be quickly set up and distributed across various endpoints, making them a convenient addition to an organization’s security toolkit.

Cost-effective: Many honeytoken services offer free or low-cost options for basic functionality, making them accessible to organizations with limited budgets. They provide a cost-effective way to enhance security posture without significant financial investment.

Bottom line

Canarytokens do not replace existing detection mechanisms but serve more as a supplement. An organization’s holistic security strategy also includes aspects such as patch and vulnerability management, multi-factor authentication, active directory hardening, and the least privilege principle.

Thanks to Gian-Luca (https://www.linkedin.com/in/gian-luca-buol/) for proofreading this post.