Skip to content

Back to the catalog

dfir.chwriteup

Canarytokens: Catching Insider Threats (and Threat Actors?)

A DFIR consultant describes using Canarytokens.com to investigate two real incidents: an Excel-based canarytoken embedded via an external OOXML image reference to determine whether a company's customer data was being leaked by an insider or a compromised web server, and a "whoami" registry canarytoken that fired during an incident response engagement because Cobalt Strike's Elevate Kit ran the uac-schtasks technique (Invoke-EnvBypass from the Empire project), which internally calls whoami. The post walks through the OOXML/XLSX external-relationship mechanics that trigger the Excel canarytoken and notes canarytokens' value and limits as a supplement to, not a replacement for, EDR.

TL;DR DFIR case studies showing Canarytokens catching a data-leak insider/web-compromise scenario and a Cobalt Strike UAC-bypass privilege escalation via a triggered whoami honeytoken.
Document

What it is

A DFIR field account (dfir.ch) of using a Canarytokens Excel (.xlsx) file to answer a concrete question: was a company's customer list being leaked by an insider or by a compromised web server? The token document is generated free at canarytokens.org and handed to suspects or staged where the leak was suspected.

How it works

An .xlsx is an OOXML package — a ZIP of XML files. The token lives in one relationship entry, xl/drawings/_rels/drawing1.xml.rels, which declares an external "image" that is actually an HTML page on canarytokens.com:

<Relationship Id="rId1"
  Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image"
  Target="http://canarytokens.com/static/hkkmt4dgsx7<redacted>/index.html"
  TargetMode="External"/>

When anything fetches that URL, Canarytokens emails the defender, including the source IP. The post's key operational point: the file does not need to be opened in Excel. Merely parsing it — the author demonstrated this by uploading to a public online Excel parser — fetched the external reference and fired the alert within minutes. That IP is what proves whether, and from where, the data was accessed.

What to do

  • To deploy for leak-hunting: generate an Excel token, then either give distinct copies to individuals you suspect or stage it on the exposed server, and watch which source IP triggers first (day-before contact suggested a specific handoff window here).
  • To detect a canarytoken in an inbound/staged .xlsx before opening it, unzip and grep the rels files for an external target:
unzip suspect.xlsx

Then inspect xl/drawings/_rels/drawing1.xml.rels (and other *.rels) for TargetMode="External" pointing at an unexpected host such as canarytokens.com. The file command confirms the container type:

% file document.xlsx
document.xlsx: Microsoft OOXML

Caveats

  • The alert reports interaction (a fetch and source IP), not identity — it tells you an access happened and from where, not who was behind a NAT/proxy or an automated parser.
  • Because online viewers and preview/scanning pipelines fetch external references, a token can fire from benign automated parsing, not just a malicious open. Treat the IP as a lead, not proof of intent.
  • The page's second promised story (a Cobalt Strike elevate privilege-escalation caught via canarytokens) is cut off in the fetched text after ele — no usable detail is present, so nothing actionable can be drawn from it here.

Organisations named here

  • Image File Execution Options
  • Invoke-EnvBypass
  • uac-schtasks

Technologies named here

  • Microsoft Excel
  • Canarytokens
  • Windows
  • Cobalt Strike
  • Elevate Kit
  • EmpireProject
  • Windows Defender
  • Empire
  • PowerShell

Techniques named here

  • Excel/Office document external image beacon
  • UAC bypass via scheduled tasks
  • whoami /groups enumeration
  • Insider threat / data leak tracing via honeytoken

Threat actors named here

  • Elevate Kit threat actors