Docs

Appearance

Runbook: Canary Token Alert Response ​

Classification: RESTRICTED — Security Operations Only
Severity: CRITICAL — every canary fire is an immediate P1
Owner: Rory Garshol (IT/Security)

THE RULE ​

A canary token alert is confirmed unauthorized access. Not suspicious. Not a false positive. Confirmed.

Canaries have no legitimate trigger path. Nothing in the environment should ever access these resources. If the alert fired, something unauthorized touched it. Treat it as a breach immediately.

What the Alert Looks Like ​

Canary fires come in two forms simultaneously:

Email (from canarytokens.org → security@ciriusgroup.com):

Subject: Canary token triggered: [token type] — [token nickname]
Body:
  Token type:    aws-keys / dns / web / ms-word / pdf
  Token name:    [whatever you named it at canarytokens.org]
  Triggered at:  2026-05-25T14:32:10Z (UTC)
  Source IP:     203.0.113.47
  User agent:    aws-cli/2.x (for AWS key tokens) / Mozilla/5.0 (for URL/doc)
  Additional:    [token-type-specific fields — see per-type section below]

SecOps incident (auto-created by webhook):

Severity:      CRITICAL
Source:        canary_agent
Incident type: Deception Layer Trigger
Title:         [token nickname] canary triggered — [source IP]

The SecOps incident is created within seconds of the trigger. Check secops.bedrockcybersecurity.org if you need additional detail.

First 5 Minutes — Do These In Order ​

1. Do not close or dismiss the alert.

2. Identify which canary fired. Cross-reference the token type and name against the inventory at security/canary-token-inventory.md. The token name in the alert email matches what was entered at canarytokens.org during setup.

If token is...It means...
CT-001 (AWS Key)Attacker found the S3 canary file and tested the fake AWS credentials
CT-002 (SharePoint Doc)Attacker opened the canary Word/PDF document in SharePoint
CT-003 (DNS)Something resolved the canary domain — credential testing or DNS enumeration
CT-004 (URL)Attacker cloned an infra repo and fetched a URL found in the code

3. Call Arctic Wolf immediately. Do not wait for your own investigation to complete.

  • Arctic Wolf portal: open a P1 case
  • They have act-first authorization and may already be investigating
  • Give them: token type, trigger time, source IP, affected location

4. Open a SecOps incident if one was not auto-created (webhook may have failed).

  • Title: Canary token triggered — [CT-XXX] — [source IP]
  • Severity: CRITICAL
  • Do not suppress it

5. Preserve the alert. Forward the canary alert email to yourself and save it. Screenshot the SecOps incident. Do not let the email auto-archive before you've pulled the metadata.

Evidence to Capture Immediately ​

Capture these before doing anything else. Remediation destroys forensic value.

  • [ ] Full canary alert email (raw, including headers)
  • [ ] Source IP address and timestamp (exact, UTC)
  • [ ] User agent string from the alert
  • [ ] SecOps incident ID and auto-generated timeline
  • [ ] Any associated logs from that timestamp ±30 minutes (Palo Alto, Entra SignInLogs, CloudTrail)
  • [ ] Screenshot of the canary token page at canarytokens.org (token history tab shows all prior and current triggers)

Do NOT rotate the canary credentials yet. The fake credentials are not real — they cannot be used to access anything. Keeping them in place lets you observe if the attacker retries. Rotate only after forensics are complete.

Per-Token Response ​

Document Canary (CT-002 — SharePoint Word/PDF) ​

What happened: Someone opened the canary document. The canarytokens.org beacon inside the file phoned home when rendered.

What it means: An attacker has access to the SharePoint Security site Restricted Documents library. This is a PHI-adjacent location.

Immediate actions:

  1. Identify who has access to the SharePoint Security site → Restricted Documents library. Pull the SharePoint site members list from the SharePoint admin center.
  2. Check SharePoint audit logs for the file access event:
    • Microsoft Purview Compliance portal → Audit → Search
    • Operation: FileAccessed, Item: the canary document filename
    • Capture the account UPN that accessed it
  3. Check Entra SignInLogs for that account in the 2 hours before and after the trigger time.
  4. If the accessing account is a real Cirius account: treat it as compromised. Disable the account in Entra immediately (do not just reset the password).
  5. If the source IP is external: block it at Palo Alto perimeter now.
  6. Check for any other file access from that account or IP in the same window — lateral document access is common once an attacker is in SharePoint.
  7. Trigger HIPAA breach assessment (see section below) — this location is PHI-adjacent.

URL Canary (CT-004 — Infra Repo URL) ​

What happened: Something fetched the canary URL embedded in an infra repo. The URL has no legitimate use — it exists only to detect attacker behavior after repo cloning.

What it means: An attacker cloned one of the infra repos (azure-infra, aws-infra, azure-dde-infra, ops-automation, bedrock-hub) and tested URLs found in the code.

Immediate actions:

  1. The canarytokens.org alert includes the source IP. Look up this IP immediately (reverse DNS, geolocation, ASN). An attacker testing infra repos may be doing so from a cloud provider IP or VPN.
  2. Check GitHub audit logs for repo clone events from that IP or any unknown accounts:
    • GitHub org → Settings → Audit log → filter: git.clone
    • Look for clones in the 24 hours before the trigger
  3. Identify which repo the URL token was embedded in (if using per-repo tokens). If using a shared token, check all five repos for recent unusual access.
  4. Check if any GitHub accounts were added to the org recently or if any deploy keys were modified.
  5. Review if any secrets in those repos (even canary-safe ones) should be considered exposed — rotate any real credentials in the affected repos as a precaution.
  6. Block the source IP at Palo Alto if it appears in any other logs.
  7. Check Entra SignInLogs and Twingate access logs for activity from that IP.

AWS Key Canary (CT-001 — Fake AWS Credentials in S3) ​

What happened: The fake AWS credentials stored in s3://cirius-veeam-prod-bucket/security/PHI-patient-records-backup.txt were used to make an AWS API call. canarytokens.org detected the STS call.

What it means: An attacker found the S3 canary file and tested the credentials. This means they have read access to cirius-veeam-prod-bucket. That bucket contains Veeam backup data.

Immediate actions:

  1. The canarytokens.org alert for AWS key tokens includes the AWS API action attempted and the source IP. Capture both.
  2. Check CloudTrail immediately for the fake access key ID. Even though the credentials are canary credentials (they will return auth errors), CloudTrail may show the attempted call:
    CloudTrail → Event history → Filter by: Access key ID = [canary key ID from inventory]
  3. Check who accessed cirius-veeam-prod-bucket in the past 24 hours:
    • CloudTrail → S3 data events for cirius-veeam-prod-bucket
    • Look for GetObject on the security/ prefix
    • Identify the IAM principal that accessed the canary file
  4. Determine how the attacker got read access to that S3 bucket. Check:
    • Bucket policy for any public or overly permissive grants
    • IAM roles and users with S3 access (especially s3:GetObject on this bucket)
    • CloudTrail for any unusual IAM activity or credential exfiltration events
  5. If you identify a real AWS credential or role that the attacker used to reach the bucket: disable it immediately via AWS IAM console. Do not wait.
  6. Block the source IP at Palo Alto if it appears in other logs.
  7. Check all other S3 buckets in the prod account for unusual access from that same principal or IP in the same window.
  8. Trigger HIPAA breach assessment — the bucket is named and positioned as PHI storage. Even though the file is a canary, the attacker believed they were accessing PHI.

DNS Canary (CT-003 — DNS Domain) ​

What happened: Something resolved the canary domain (e.g., abc123.canarytokens.com). The canary domain is embedded in fake config files or DB connection strings. DNS resolution means something tried to use those fake configs.

What it means: An attacker found a fake configuration file and attempted to connect to the fake endpoint. This may indicate they have access to config files in repos, cloud storage, or deployed infrastructure.

Immediate actions:

  1. Check Cloudflare DNS Security logs for the canary domain:
    • Cloudflare dashboard → Zero Trust → DNS Logs
    • Filter by the canary domain name
    • Identify the source IP(s) that made the query
  2. Check Palo Alto DNS Security logs for the same domain:
    • Panorama → Monitor → Logs → URL/DNS
    • Filter by the canary FQDN
  3. Identify where the canary domain is embedded (per the inventory — CT-003 deployment notes). That location is where the attacker found the config.
  4. Check firewall logs for outbound connection attempts from your network to the canary domain. If an internal host resolved it, identify which host.
  5. If the resolution came from an internal host: treat that host as compromised. Isolate it from the network immediately.
  6. If the resolution came from an external IP: the attacker has a copy of the config file and is testing it from outside. Trace how they obtained the file.
  7. Review what other credentials or config data was co-located with the canary domain in the affected file.

HIPAA Breach Assessment ​

Trigger this process if the canary that fired was in any of these locations:

  • CT-001 (AWS Key): The S3 bucket is named and positioned as PHI storage — trigger assessment
  • CT-002 (SharePoint Doc): SharePoint Security site, Restricted Documents — trigger assessment
  • CF-001/CF-002/CF-003 (Honeyfiles): All named PHI-patient-records-backup.txt — trigger assessment
  • CT-003/CT-004: Assess case by case — lower likelihood of PHI exposure but evaluate what was adjacent to the canary

Assessment steps:

  1. Notify Adriana. She manages BAA/vendor/risk documentation and the breach notification process. Contact her by phone for P1 events.
  2. Document: what data was accessible to the attacker, what they accessed (or could have accessed), how long the access window was.
  3. The canary files themselves contain fake data — no real PHI is in the canary files. However, if the attacker had read access to the canary location, assess whether real PHI was accessible in the same bucket/folder/site.
  4. HIPAA breach notification clock starts at discovery. Document the exact time you confirmed the breach.
  5. Arctic Wolf can assist with breach scoping — they have full visibility into Azure and AWS.

Escalation ​

Always call Arctic Wolf for any canary fire. No exceptions. No "investigate first."

Canary fires are the highest-confidence alert in the environment. By the time you have read this far, Arctic Wolf should already be on the case. If they are not:

  • Arctic Wolf portal → open P1 case → describe: canary token type, trigger time, source IP, affected location
  • They have act-first authorization — they will contain before confirming with you if they identify active attacker movement

Secondary escalations:

  • Kevin (T1 DR Admin) — notify immediately for any canary fire. He needs to know even if the incident is contained.
  • Greg (T1 DR Admin) — same as Kevin.
  • If the incident involves data that customers could be affected by: escalate to Paul (customer relationship owner).

False Positive Edge Cases ​

Canary tokens are specifically engineered for zero false positives. There are almost none. The documented exceptions:

Security team testing (only valid FP): If you or Arctic Wolf ran a deliberate canary test (e.g., verifying the webhook works after a deployment), you may see a trigger from a known IP. To confirm this is a FP:

  • The source IP must match a known Cirius or Arctic Wolf IP
  • You must have a specific memory of running the test within the last hour
  • The activity must be logged in the SecOps change management system

If all three conditions are met, close the incident with note FP — security team test, CM ticket [ID].

Everything else is a real trigger. If you are unsure, treat it as real.

Post-Incident: Canary Reset and Documentation ​

Do not reset the canary until Arctic Wolf confirms the investigation is complete and you have documented everything.

Resetting the canary:

For canarytokens.org tokens (CT-001, CT-002, CT-003, CT-004):

  1. Go to canarytokens.org and disable the triggered token (do not delete — keep history)
  2. Generate a new token of the same type with the same webhook URL
  3. Replace the old token credentials/domain/URL in the deployment location with the new one
  4. Verify the new token is active by checking canarytokens.org token status

For honeyfiles (CF-001, CF-002, CF-003):

  1. The honeyfile content (fake credentials) should be refreshed with new fake values — the old values are now known to the attacker
  2. If using CT-001 embedded in CF-001, regenerate the CT-001 token first, then update the file
  3. Redeploy the file to its S3/Azure location

Update the inventory:

  • Update security/canary-token-inventory.md:
    • New token ID
    • New last-verified date
    • Incident reference (SecOps incident ID)

Document the incident in SecOps:

  • Resolve the incident with a full timeline
  • Record: how attacker reached the canary, what was exposed, what was contained, what was rotated
  • Tag: deception-layer, canary, and the relevant MITRE technique (T1078, T1003, etc.)
  • Link the HIPAA assessment outcome if one was triggered

Verify canary health after reset:

  • Trigger a manual run of canary_agent.py or wait for the next 4-hour cycle
  • Confirm the agent reports all canaries healthy
  • Confirm the SecOps incident list shows no new canary alerts

Quick Reference ​

TokenLocationPHI-adjacentAuto-created SecOps incident
CT-001 — AWS KeyS3 cirius-veeam-prod-bucket/security/YesYes
CT-002 — SharePoint DocSharePoint Security → Restricted DocumentsYesYes
CT-003 — DNSEmbedded in config files (DNS query)Case-by-caseYes
CT-004 — URLInfra repos (URL fetch)NoYes
CF-001 — S3 Honeyfile (missing)S3 cirius-veeam-prod-bucket/security/YesYes
CF-002 — Azure PROD Honeyfile (missing)ciriusarchiveprod/canary/YesYes
CF-003 — Azure DDE Honeyfile (missing)ciriusddearchiveprod/canary/YesYes
DA-001 — Entra Decoy Loginsvc-legacy-reporting@ciriusgroup.comNoYes

Key links:

  • SecOps platform: secops.bedrockcybersecurity.org
  • Canary token inventory: security/canary-token-inventory.md
  • Deception layer design: security/deception-layer.md
  • Arctic Wolf portal: (bookmark in browser)
  • canarytokens.org: manage tokens, view trigger history

Maintained by Rory Garshol. Update after any canary incident or token rotation.

Internal use only — Cirius Group