Implementing Canary Tokens for Network Intrusion Detection

When to Use

• When deploying deception-based tripwires across network infrastructure to detect intrusions
• When building early warning systems that alert on unauthorized access to sensitive resources
• When planting fake AWS credentials, DNS beacons, or HTTP tokens to catch attackers during lateral movement
• When integrating canary token alerts with SOC workflows via Slack, Microsoft Teams, or SIEM webhooks
• When complementing traditional IDS/IPS with zero-false-positive deception technology

Prerequisites

• Python 3.8+ with requests library installed
• Network access to canarytokens.org API (or self-hosted Canarytokens instance)
• Webhook endpoint for alert delivery (Slack, Teams, email, or generic HTTP)
• For Thinkst Canary enterprise: valid console domain and API auth token
• Administrative access to target systems where tokens will be planted
• Appropriate authorization for all deployment activities

Core Concepts

What Are Canary Tokens?

Canary tokens are digital tripwires -- resources that should never be accessed during normal operations. When an attacker interacts with a canary token, it immediately triggers an alert with near-zero false positives. Unlike signature-based detection, canary tokens detect attackers by their behavior (accessing bait resources) rather than matching known patterns.

Token Types for Network Intrusion Detection

Alert Flow Architecture

[Attacker Action] --> [Token Triggered] --> [Canarytokens Server]
                                                    |
                                            [Webhook POST]
                                                    |
                          +-------------------------+-------------------------+
                          |                         |                         |
                    [Slack Alert]           [Email Alert]             [SIEM Ingestion]
                          |                         |                         |
                    [SOC Analyst]           [On-Call Page]           [Correlation Rule]

Instructions

Step 1: Generate DNS Canary Tokens

DNS tokens are the most versatile -- they trigger on any DNS resolution, even from air-gapped networks with only DNS egress. The token is an FQDN that, when resolved, alerts the token owner.

import requests

# Create DNS canary token via Canarytokens.org
response = requests.post("https://canarytokens.org/generate", data={
    "type": "dns",
    "email": "soc@company.com",
    "memo": "Production database server - /etc/app/db.conf",
    "webhook_url": "https://hooks.slack.com/services/T.../B.../xxx"
}, timeout=15)

token_data = response.json()
dns_hostname = token_data["hostname"]
# Example: abc123def456.canarytokens.com

Plant DNS tokens in locations attackers commonly inspect:

• /etc/hosts entries pointing to the canary FQDN
• Application configuration files (database_host, backup_server)
• SSH config files (~/.ssh/config) with canary hostnames
• Internal DNS zone files as decoy A records
• CI/CD pipeline environment variables

Step 2: Deploy HTTP Canary Tokens

HTTP tokens generate a unique URL that triggers on any HTTP request. They reveal the source IP, User-Agent, and other HTTP headers of the requester.

# Create HTTP token
response = requests.post("https://canarytokens.org/generate", data={
    "type": "http",
    "email": "soc@company.com",
    "memo": "Internal wiki - IT admin passwords page",
    "webhook_url": "https://hooks.slack.com/services/T.../B.../xxx"
}, timeout=15)

http_url = response.json()["url"]

…