🗄️ Honey Database
Decoy RDS/DynamoDB/CosmosDB with fake PII data.
What it is
A small database, or a decoy table inside a real one, holding generated records that look like personal data. Databases are a prime target for theft and extortion. Logins and queries are recorded by the database engine's own audit logging, which has to be switched on; the cloud control-plane log does not record SQL activity.
Implementation requirements
- Deploy a small managed instance (RDS, Azure SQL, Cloud SQL) or a decoy table inside an existing database, filled with generated records that look like personal data. Never copy production data
- Monitoring happens in the database engine, not CloudTrail: CloudTrail records control-plane calls (
ModifyDBInstance,CreateDBSnapshot) but not SQL logins or queries. Enable engine logging, such as PostgreSQLlog_connectionsplus pgAudit object auditing on the decoy tables, or a SQL Server audit with a database audit specification, and ship the log to your collector - DynamoDB: CloudTrail data events (
GetItem,Query,Scan) for the decoy table. Cosmos DB: theDataPlaneRequestsdiagnostic category - Safety: credentials unique to the decoy, and no network path from it to production. Mark the synthetic records internally, so a later public leak can be recognised as decoy data and not reported as a breach
- OPSEC: instance class, engine version and naming like real databases; a table name that matches your schema conventions
- Rollback: Take a final snapshot for evidence, then delete the instance or decoy table. Remove its audit configuration and credentials.
- Upkeep: Patch the engine with the fleet. Monthly proof-of-life login and query.
Technologies
ATT&CK coverage 8
| Technique | Tactic | Status | Confidence | Tier |
|---|---|---|---|---|
| T1119 Automated Collection |
Collection | confirmed | strong | T3 |
| ↳ Detection point: the decoy fires at a later step of the attack | ||||
↳ Evidence (3 sources)
| ||||
| T1213 Data from Information Repositories |
Collection | confirmed | strong | T2 |
| ↳ Detection point: the decoy fires at a later step of the attack | ||||
↳ Evidence (5 sources)
| ||||
| T1213.006 Databases |
Collection | confirmed | strong | T3 |
| ↳ Detection point: the attack step itself touches the decoy | ||||
↳ Evidence (3 sources)
| ||||
| T1526 Cloud Service Discovery |
Discovery | theoretical | moderate | T1 |
| ↳ Detection point: the attack step itself touches the decoy | ||||
↳ Evidence (3 sources)
Moderate: discovering that a service exists does not necessarily touch a decoy resource in it. | ||||
| T1485 Data Destruction |
Impact | theoretical | moderate | T4 |
| ↳ Detection point: the attack step itself touches the decoy | ||||
↳ Evidence (4 sources)
Deleting a decoy snapshot or database is a management event; deleting objects in a decoy bucket needs data events enabled. | ||||
| T1486 Data Encrypted for Impact |
Impact | confirmed | strong | T4 |
| ↳ Detection point: the attack step itself touches the decoy | ||||
↳ Evidence (3 sources)
| ||||
| T1565 Data Manipulation |
Impact | theoretical | moderate | T2 |
| ↳ Detection point: the attack step itself touches the decoy | ||||
↳ Evidence (2 sources)
Direct when the attacker alters the decoy's own records; database-level audit not yet sourced. | ||||
| T1657 Financial Theft |
Impact | theoretical | weak | T4 |
↳ Evidence (1 source)
Financial theft is an outcome; access to decoy billing data is collection. | ||||
Evidence
- Decoy Object (D3-DO) — MITRE D3FEND standard
- Decoy Environment (D3-DE) — MITRE D3FEND standard
- MITRE Engage — adversary engagement matrix and ATT&CK mapping — MITRE 2022 standard
- MITRE ATT&CK Enterprise v20.0 — MITRE 2026 standard
- Tracebit for AWS — canary resources and credentials — Tracebit industry
- Canarytokens token guides (MS Word, Windows Directory, Network Folder, Kubeconfig, AWS Infrastructure, DNS, Azure Login Certificate, MySQL Dump) — Thinkst Applied Research industry