Docs

Appearance

Canary Token Inventory ​

Classification: RESTRICTED — Security Operations Only
Owner: Rory Garshol (IT/Security)
Last verified: 2026-04-13
Next review: 2026-05-13

Purpose ​

This document is the authoritative inventory of all deployed canary tokens and canary files in the Cirius Group environment. Canary tokens are deception layer tripwires — any access to a canary resource triggers an immediate CRITICAL incident in SecOps with no suppression.

Rule: Never open, access, or use any resource listed here. Doing so will trigger a CRITICAL security incident. These resources exist only to detect unauthorized access.

Canary Tokens (canarytokens.org) ​

CT-001 — AWS Access Key Token (DECP-001) ​

FieldValue
Token typeaws-keys (IaC honeytoken — not canarytokens.org)
PurposeDecoy AWS credentials — detects credential harvesting / use
Decoy principalIAM user svc-backup-replication (Logging account) — explicit deny-all
Bait locationSSM SecureString /backup/replication/aws-credentials (Logging account)
DetectionCloudTrail → metric filter canary-aws-key-used → CloudWatch alarm → security_alerts SNS
Defined inaws-infra/logging/canary_aws_key.tf (PR #991)
Last verified2026-06-21 — Apply complete! 6 added (resources confirmed created)
StatusACTIVE — armed via Terraform

How it works: the decoy IAM user has an explicit deny-all policy, so its access key can do nothing. The key is planted as bait in an SSM SecureString a post-compromise attacker would enumerate. Because the key is never used legitimately, any appearance of its key id in CloudTrail trips the canary-aws-key-used alarm (CRITICAL) to the security_alerts SNS topic.

Maintenance: managed in Terraform — to rotate or change the bait, edit aws-infra/logging/canary_aws_key.tf and apply. No manual canarytokens.org step.

CT-002 — SharePoint Document Token (DECP-002) ​

FieldValue
Token typems-word or pdf
PurposeCanary document in SharePoint — detects unauthorized document access
LocationSharePoint Security site → Restricted Documents library
Webhook URLhttps://soc.bedrockcybersecurity.org/webhooks/canary?secret=<KV:canary-webhook-secret>
Alert emailsecurity@ciriusgroup.com
canarytokens.org tokenajxunu0hbv77rra0nrwo3hi1h
Last verified2026-06-27
StatusACTIVE — PHI-Patient-Records-Q4-2025.docx uploaded to SharePoint Security site → Restricted Documents

Notes: SharePoint document upload requires delegated Graph API permissions. Rory must manually upload the canary document. Recommend using a Word or PDF token from canarytokens.org and naming the file "PHI-Patient-Records-Q4-2025.docx" with a realistic-looking SharePoint path.

CT-003 — DNS Canary Token (DECP-003) ​

FieldValue
Token typedns
PurposeDNS-based tripwire — any DNS lookup triggers the alert
Canary domain1jc6alp4tev0qpj3429rc0ps7.canarytokens.com
Webhook URLhttps://soc.bedrockcybersecurity.org/webhooks/canary?secret=<KV:canary-webhook-secret>
Alert emailsecurity@ciriusgroup.com
canarytokens.org token1jc6alp4tev0qpj3429rc0ps7
Last verified2026-06-27
StatusACTIVE — embed hostname in config files and connection strings

How it works: canarytokens.org generates a unique subdomain (e.g., abc123.canarytokens.com). Embed this domain in configuration files, scripts, or database connection strings. Any DNS resolution of this domain (e.g., during credential testing) fires the alert immediately.

Deployment steps for Rory:

  1. Go to canarytokens.org → Generate → DNS
  2. Set webhook URL to the SecOps webhook URL with canary secret
  3. Note the generated canary domain (e.g., abc123.canarytokens.com)
  4. Embed this domain in: fake configuration files, DB connection strings (DECP-004)
  5. Update this inventory with the canary domain

CT-004 — URL Token per Infra Repo (DECP-004) ​

FieldValue
Token typeweb (URL)
PurposeFake DB connection strings in infra repos — detects repo cloning with credential testing
Locationsazure-infra, aws-infra, azure-dde-infra, ops-automation, bedrock-hub
Webhook URLhttps://soc.bedrockcybersecurity.org/webhooks/canary?secret=<KV:canary-webhook-secret>
Alert emailsecurity@ciriusgroup.com
canarytokens.org tokenjo6cn7v7b15v31va1bkgg9cls
Last verified2026-06-27
StatusACTIVE — embedded in bedrock-hub, bedrock-soc, bedrock-grc, bedrock-infra, bedrock-scanner

How it works: A URL-type canary token generates a unique URL that fires when fetched. Embed this URL as a fake webhook endpoint or API URL in non-sensitive config files in each infra repo. If an attacker clones the repo and attempts to test/validate any URLs found, the canary fires.

Deployment steps for Rory:

  1. Go to canarytokens.org → Generate → Web (URL)
  2. Create one token shared across repos (or one per repo for granularity)
  3. Add a comment block to a README or config file in each repo with the URL embedded as a "legacy webhook endpoint" or "monitoring URL"
  4. PR the change to each repo

Canary Files (Storage Canaries) ​

CF-001 — AWS S3 Canary File (DECP-009) ​

FieldValue
TypeHoneyfile (fake credentials)
Locations3://cirius-veeam-prod-bucket/security/PHI-patient-records-backup.txt
File namePHI-patient-records-backup.txt
ContentFake AWS keys, Azure connection string, PostgreSQL connection string
Monitored bycanary_agent.py (periodic existence check)
Alert if missingCRITICAL incident via SecOps
Deployed2026-04-13 — PENDING (CloudPCRole lacks PutObject; deploy from CI/CD)
Last verifiedPending

Deployment steps for Rory (run from GitHub Actions or a host with S3 write access):

bash
aws s3 cp PHI-patient-records-backup.txt s3://cirius-veeam-prod-bucket/security/PHI-patient-records-backup.txt

CF-002 — Azure PROD Canary File (DECP-009) ​

FieldValue
TypeHoneyfile (fake credentials)
Storage accountciriusarchiveprod (logging subscription)
Containercanary (private, no public access)
Blob namePHI-patient-records-backup.txt
Monitored bycanary_agent.py
Alert if missingCRITICAL incident via SecOps
DeployedPending — network deny rules block deployment from Cloud PC
Last verifiedPending

Deployment steps for Rory (run from a whitelisted IP — home or GitHub Actions):

bash
az storage container create --name canary --account-name ciriusarchiveprod --auth-mode login --public-access off
az storage blob upload --account-name ciriusarchiveprod --container-name canary --name PHI-patient-records-backup.txt --file PHI-patient-records-backup.txt --auth-mode login

Container App env var to set:

CANARY_AZURE_PROD_ACCOUNT=ciriusarchiveprod
CANARY_AZURE_PROD_CONTAINER=canary
CANARY_AZURE_PROD_BLOB=PHI-patient-records-backup.txt

CF-003 — Azure DDE Canary File (DECP-009) ​

FieldValue
TypeHoneyfile (fake credentials)
Storage accountciriusddearchiveprod (DDE subscription)
Containercanary (private)
Blob namePHI-patient-records-backup.txt
Monitored bycanary_agent.py
Alert if missingCRITICAL incident via SecOps
DeployedPending
Last verifiedPending

Deployment steps for Rory:

bash
AZURE_CONFIG_DIR=~/.azure-dde az storage container create --name canary --account-name ciriusddearchiveprod --auth-mode login --public-access off
AZURE_CONFIG_DIR=~/.azure-dde az storage blob upload --account-name ciriusddearchiveprod --container-name canary --name PHI-patient-records-backup.txt --file PHI-patient-records-backup.txt --auth-mode login

Container App env var to set:

CANARY_AZURE_DDE_ACCOUNT=ciriusddearchiveprod
CANARY_AZURE_DDE_CONTAINER=canary
CANARY_AZURE_DDE_BLOB=PHI-patient-records-backup.txt

Entra ID Decoy Accounts (DECP-008) ​

DA-001 — svc-legacy-reporting ​

FieldValue
UPNsvc-legacy-reporting@ciriusgroup.com
Display namesvc-legacy-reporting
TenantAzure PROD (d477c9f8)
Group membershipsNone
Resource accessNone
PurposeTriggers when an attacker enumerates Entra and attempts to use a service account
Monitored byidentity_agent.py (SignInLogs), canary_agent.py (existence check)
CreatedPending — requires User Administrator role (current SP lacks this role)
StatusPENDING — Rory needs to assign User Administrator role to create this account

Deployment steps for Rory:

  1. Assign yourself the "User Administrator" role in Entra PROD → Roles and administrators
  2. Then run:
bash
az ad user create --display-name "svc-legacy-reporting" --user-principal-name "svc-legacy-reporting@ciriusgroup.com" --password "<strong-random-password>" --force-change-password-next-sign-in false
  1. Verify: no group memberships, no license, no resource access
  2. Add a Conditional Access policy exclusion for monitoring (allow sign-in for detection purposes)
  3. Update this inventory with the account object ID

Container App env var to set:

CANARY_ENTRA_DECOY_UPN=svc-legacy-reporting@ciriusgroup.com

Required Key Vault Secrets ​

The following secrets must be stored in cirius-openai-kv-prod:

KV Secret NamePurpose
canary-webhook-secretShared secret validating inbound canarytokens.org webhooks — include in webhook URL as ?secret=<value>

The CANARY_WEBHOOK_SECRET env var must be set in both:

  • job-orchestrator-cirius Container App Job
  • ca-secops-prod Container App (for the /webhooks/canary endpoint)

Monitoring Architecture ​

canarytokens.org ──[webhook POST]──► soc.bedrockcybersecurity.org/webhooks/canary
                                              │
                                              ▼
                                     Validate X-Canary-Secret
                                              │
                                              ▼
                                    POST /api/incidents/ (CRITICAL)
                                     source_agents=["canary_agent"]
                                     severity=CRITICAL
                                     no suppression ever

canary_agent.py (4hr cycle) ──► check S3 file exists
                             ──► check Azure PROD blob exists
                             ──► check Azure DDE blob exists
                             ──► check Entra decoy account exists
                             └──► CRITICAL incident if any missing

Incident Response ​

Any CRITICAL incident with source_agents=["canary_agent"] means:

  1. Do not dismiss without full investigation — canary triggers have no false positive path
  2. Identify source IP from incident details
  3. Block source IP at Palo Alto perimeter immediately
  4. Check Entra sign-in logs for any activity from that IP
  5. Check CloudTrail for any AWS API calls with the fake credentials
  6. Assume full compromise until proven otherwise — activate IR runbook
  7. Do NOT reset canary credentials until forensics are complete (evidence preservation)
  8. After investigation, re-deploy the canary with new canarytokens.org tokens

This document is maintained by Kobe (infrastructure agent). Update after any canary deployment, rotation, or incident.

Internal use only — Cirius Group