🔑 Honey Service Account

Fake service accounts/principals in cloud directories.

→ Explore in ATT&CK matrix (2 mappings) Deployment detail

What it is

A decoy non-human identity — a service principal or machine account — placed where an attacker enumerating workload identities will find it. Service accounts are attractive targets because they often hold standing privileges and rarely have MFA. This one holds neither, and nothing in your estate authenticates as it, so any sign-in or key-creation call against it is unambiguous.

Implementation requirements

AWS: IAM user with no console login profile and no access keys issued — its presence in the account listing is the lure
Azure: Entra ID service principal registered with no credentials and no role assignments against real resources
GCP: service account created without keys, and with no IAM bindings on production projects
Disable credential generation where the provider allows it, so an attacker's CreateAccessKey attempt fails and is recorded
Monitoring: CloudTrail CreateAccessKey, GetUser and UpdateLoginProfile against the decoy principal; Entra ID service-principal sign-in logs; GCP audit logs for key creation
OPSEC: give it a plausible workload name and a creation date consistent with your real service accounts
Rollback: Disable, then delete the service account or principal and any keys it has. Remove it from detection rules.
Upkeep: Review it whenever directory naming conventions change. Monthly proof-of-life use from a test host.

Cost

Negligible. Service accounts and principals are free to create on all three providers. Cost is audit-log ingestion only.

Indicative only. Cloud pricing and licensing change — check the provider's official pricing pages for current rates before you budget.

Technologies

AWSAzureGCP

ATT&CK coverage 2

Technique	Tactic	Status	Confidence	Tier
T1087.004 Cloud Account	Discovery	theoretical	moderate	T1
↳ Detection point: the attack step itself touches the decoy
↳ Evidence (2 sources) Logging management events — AWS CloudTrail User Guide — Control-plane reads and changes (create, attach, modify, delete) are management events, logged by default. MITRE ATT&CK Enterprise v20.0 — ATT&CK v20 documents T1087.004 Cloud Account as an adversary behaviour. Listing users does not name the decoy; reading it does.
T1098 Account Manipulation	Persistence	confirmed	strong	T3
↳ Detection point: the attack step itself touches the decoy
↳ Evidence (3 sources) Microsoft Defender for Identity classic security alerts (honeytoken alerts 2014, 2427, 2428, 2429) — Alerts 2427 (attributes modified) and 2428 (group membership changed) fire on any change to a honeytoken user; Microsoft maps both to T1098. Logging management events — AWS CloudTrail User Guide — IAM AttachRolePolicy is a logged management event, so changes to a decoy IAM role are recorded (cloud decoys: moderate). MITRE Engage — adversary engagement matrix and ATT&CK mapping — MITRE Engage maps T1098 to its Lures activity.

Evidence

Decoy User Credential (D3-DUC) — MITRE D3FEND standard
MITRE Engage — adversary engagement matrix and ATT&CK mapping — MITRE 2022 standard
Microsoft Defender for Identity classic security alerts (honeytoken alerts 2014, 2427, 2428, 2429) — Microsoft industry
Detecting Kerberoasting Activity Part 2 – Creating a Kerberoast Service Account Honeypot — Metcalf, S., ADSecurity.org 2017 practitioner
MITRE ATT&CK Enterprise v20.0 — MITRE 2026 standard

Research basis: MITRE D3FEND D3-DUC (Decoy User Credential). Sourcing here is category-level only — D3FEND covers decoy credentials generally, and no study addresses decoy service accounts specifically. The mechanism follows directly from the credential case, but it has not been independently studied.