This page provides an overview of the Canary Tokens deployed during this internship. Canary Tokens are lightweight, easy-to-deploy deception artifacts used to detect unauthorized access or malicious behavior.
Each token acts as a trap: when triggered (e.g., opened, scanned, or used), it silently notifies defenders with contextual alert information. These tokens are particularly effective in detecting insider threats, lateral movement, and stolen data usage.
Below is a breakdown of each deployed token, including its purpose, detection method, possible false positives, and mitigation strategies.
This token generates a QR code that links to a unique Canary URL. It is commonly used to detect phishing attempts or physical access intrusions.
It detects if someone scans the QR code and opens the associated link — an action that can indicate suspicious activity.
When the QR code is scanned, the embedded URL is opened. This triggers an alert from Canary. The behavior differs based on whether the token is configured as a "slow redirect" or a "fast redirect".
The alert includes:
If this token is triggered, investigate the physical or digital location where the QR code was placed. Identify the source IP and User-Agent from the alert, and determine if the scan came from an unauthorized source. If confirmed, restrict access to the area or system, and check for further signs of compromise.
How to create a QR Code Canarytoken
This token simulates a realistic-looking credit card number that is not actually valid or usable.
To detect if someone attempts to validate or use the card number, which typically indicates data theft or unauthorized access.
If the token is entered into any credit card validation system or payment form, it will trigger an alert through the Canary platform.
If the token is used, immediately investigate where the token was stored or exposed. Analyze the context of the attempted use (e.g., which application submitted it) and identify the source. If this was unauthorized (not used during any test), disable access to systems that may have been breached and search for any other potential data leaks.
How to create a Credit Card Canarytoken
This token is embedded in a Word document that silently connects to a Canary URL when opened.
To detect document exfiltration or unauthorized opening of sensitive files.
When the document is opened, it sends a hidden web request to a unique URL. This action triggers an alert.
Upon triggering, check where the document was stored or sent. Investigate the alert details to determine who opened it and from where. If this was unauthorized, disable access to any system where the document was stored, and review recent activity from the user or host that triggered it.
How to create Word, Excel, and Macro-enabled Tokens
A fake Google Docs link that looks legitimate but is designed to detect unauthorized access.
To monitor if someone opens a decoy Google Docs file, usually placed in shared environments or email bait.
Clicking the link leads to a fake Google Docs interface that silently notifies Canary when accessed.
If triggered, review where the token was shared and who had access to it. Correlate the alert with known distribution methods to determine whether the access was legitimate or suspicious. Consider labeling the token clearly (e.g., “demo”) and limit its use to controlled environments to reduce false positives.
How to use a Google Docs Canarytoken
A unique subdomain that triggers a DNS request when it is resolved, even passively.
To detect unauthorized use of files, credentials, or configurations containing embedded hostnames.
If the subdomain is resolved by any system (e.g., when someone opens a file that references it), the Canary backend receives the request and alerts you.
If triggered, examine DNS logs to identify which system attempted the resolution. Correlate with file or config usage if the token was embedded. Investigate the host that resolved the token to determine whether data exfiltration or unauthorized access has occurred. Block or isolate the system if suspicious activity is confirmed.
How to create a DNS Canarytoken
A Canarytoken embedded within a transparent image (e.g., PNG or GIF) designed to detect unauthorized viewing or access.
This token is commonly used to track when an image is loaded, such as in emails, documents, or web pages — often signaling unauthorized or unintended exposure.
When the image is rendered (e.g., by an email client, browser, or preview tool), it triggers a hidden web request to a unique Canary URL. This action logs the event and notifies the defender.
Investigate which system or individual loaded the image. Review the source of the image load (e.g., email, website, or document). If the IP or User-Agent seems suspicious, correlate with other threat indicators. Remove or replace the image if it was exposed unintentionally, and initiate containment if compromise is suspected.
How to create a Web Bug Canarytoken
This token deploys a decoy Progressive Web App (PWA) that mimics a real mobile application, such as a banking or email app. Once installed and opened on a mobile device, the app silently triggers an alert to notify you of unauthorized access.
To detect if someone gains access to a mobile device and opens a sensitive-looking app. It’s ideal for identifying physical compromise or insider threats on mobile endpoints.
The fake app is delivered as a PWA. It can be installed on the target device in two ways:
When the decoy app is opened, it sends a hidden request to a unique Canary URL, which triggers an alert.
If the app is triggered, investigate who accessed the device and whether it was expected. Check distribution history and who had access to the installation link. If unauthorized access is suspected, treat the device as potentially compromised — initiate mobile incident response protocols, revoke session tokens, and monitor for further malicious activity.
How to create a Fake App Canarytoken (PWA)
A URL token that redirects almost instantly to another page (e.g., Google.com) but silently triggers an alert before doing so.
To detect when someone clicks on a disguised or planted URL, typically embedded in emails, documents, or chat platforms.
Once the tokenized URL is accessed, the system logs the request and then quickly redirects the visitor to a harmless page, leaving no obvious trace.
If this token is triggered, determine where the link was placed and how it might have been exposed. Identify who clicked the link and from which system. If external, assume possible leak or compromise and initiate incident response steps — investigate user activity, revoke shared links, and secure the original communication channel.
How to create a Fast Redirect Canarytoken
This token is a decoy certificate file (.pfx or .pem) that mimics an Azure Active Directory login certificate. It is designed to detect unauthorized access or export attempts by attackers.
To alert security teams if someone tries to use or extract a certificate that appears to be used for Azure authentication or SSO purposes.
When the certificate is used or parsed by a tool or system, it triggers a request to a Canary URL, silently alerting defenders.
If this token is triggered, investigate the host or user that accessed the certificate. Revoke any valid certificates stored nearby and check logs for signs of impersonation or unauthorized SSO activity. Strengthen certificate export policies and restrict access where possible.
How to create an Azure Login Certificate Canarytoken
This token looks like a legitimate AWS API key pair but is designed for monitoring and detection.
To detect credential theft or unauthorized attempts to access AWS environments.
If someone tries to use this fake key in an AWS API request, it triggers an alert from Canary.
Immediately invalidate the AWS keys used in the alert. Review CloudTrail or other AWS logs for any API calls made with the token. Assess the extent of access gained and begin forensic analysis on affected systems. Rotate all related secrets and credentials on the affected host.
How to create an AWS API Key Canarytoken
This token looks like a legitimate WireGuard VPN configuration file (typically a .conf
file) but is embedded with a Canary beacon to detect unauthorized access.
To identify when an attacker tries to use or inspect what appears to be a valid VPN configuration — a common target during lateral movement or exfiltration.
When the .conf
file is used in a WireGuard client, the embedded configuration causes a silent request to be made to the Canary server, triggering an alert.
If triggered, identify which device or user attempted to use the configuration. Revoke any nearby real VPN keys and inspect VPN logs for unauthorized access. Rotate credentials and monitor for further activity from the source IP.
How to create a WireGuard VPN Canarytoken
The Azure Entra ID Login Token is designed to detect Adversary-in-the-Middle (AiTM) attacks against your organization's Microsoft 365 login portal. These attacks typically involve cloning the login page to intercept session cookies, especially MFA tokens, allowing an attacker to hijack a valid session without needing to reauthenticate.
This token inserts a stealth CSS file into the Azure login page using Microsoft Entra’s company branding features. When someone clones the login page, their server will attempt to load this CSS, which triggers a Canary alert.
To detect phishing kits and AiTM proxies (e.g., Evilginx) that replicate your login portal to intercept session tokens. This helps identify active credential theft campaigns before the attacker gains internal access.
Example: A phishing site at
https://login.app.be
cloneslogin.microsoftonline.com
and loads the Canary CSS file, resulting in a trigger.
To detect session reuse in cases where the Canary fails, custom LEQL detection rules were created in Rapid7:
LEQL rule example:
Threshold: On every match between 2 and 10
Timeframe: 30 minutes
Group matched data by: source_json.properties.sessionId
Detect on unique values of: source_json.properties.deviceDetail.deviceId
from(
event_type = "ingress_auth"
)
where(
result = "SUCCESS"
AND
source_json.category = "NonInteractiveUserSignInLogs"
AND
source_json.properties.appDisplayName = "OfficeHome"
)
These rules look for suspicious reuse of the same session ID across:
If the token is triggered or an AiTM session is detected:
To prevent AiTM attacks:
This token simulates a SAML-based identity provider (IdP) application used in environments like Azure, 1Password, or Google Workspace. It is designed to detect attempts to authenticate through a spoofed or unauthorized SAML app — often part of AiTM attacks or credential abuse.
To detect identity-based threats that bypass device controls and target login infrastructure directly, such as stolen SAML assertions or misused federated credentials.
Once integrated into an identity platform, the SAML IdP App token passively monitors login attempts. When a login attempt occurs through the decoy SAML app — especially from cloned or malicious clients — the token triggers and sends a rich alert with contextual metadata.
This provides more telemetry than most other token types, including:
Example alert metadata:
Chrome/134.0.0.0
)If the token is triggered: