Deploys DNS, HTTP, and AWS API key canary tokens across network infrastructure to detect unauthorized access and lateral movement. Integrates with webhook alerting (Slack, Teams, email, generic HTTP) for real-time intrusion notifications. Provides automated token generation, placement strategies, and monitoring for enterprise network environments. Use when building deception-based network intrusion detection with Canarytokens.org and Thinkst Canary platforms.
Instrucciones de origen · Vista previa de solo lectura
name
implementing-canary-tokens-for-network-intrusion
description
Deploys DNS, HTTP, and AWS API key canary tokens across network infrastructure to detect unauthorized access and lateral movement. Integrates with webhook alerting (Slack, Teams, email, generic HTTP) for real-time intrusion notifications. Provides automated token generation, placement strategies, and monitoring for enterprise network environments. Use when building deception-based network intrusion detection with Canarytokens.org and Thinkst Canary platforms.
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.
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.
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"]
# Embed in internal HTML pages, documents, or bookmark files
Placement strategies for HTTP tokens:
Hidden <img> tags in internal wiki pages with sensitive titles
URL shortener redirects in shared bookmark collections
Links in internal documentation labeled "admin credentials" or "VPN configs"
.url or .webloc shortcut files in network shares
Browser bookmark exports in user profile backups
Step 3: Create AWS API Key Tokens
AWS key tokens are among the highest-fidelity canary tokens. They generate real-looking
AWS access keys that trigger an alert whenever anyone attempts to use them against any
AWS API endpoint.
# Place in ~/.aws/credentials on honeypot or jump servers[default]aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
region = us-east-1# Also plant in:# - .env files in code repositories# - Docker environment configurations# - Terraform state files (decoy)# - Jenkins/CI credential stores
Step 4: Configure Webhook Alert Integration
Set up real-time alerting to your SOC through multiple channels:
