# CISA Says Plant Fake Credentials to Catch Hackers — Here's How to Deploy Cyber Decoys

> CISA's September 2026 guidance recommends honeytokens, canary accounts, and decoy systems to detect living-off-the-land attacks. Practical deployment roadmap, Sigma rules, and PowerShell scripts included.

Source: https://playciso.com/blog/cisa-cyber-decoys-fake-credentials-catch-hackers-2026 · Published: 2026-09-18 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://cybersecuritynews.com/cisa-fake-credentials-catch-hackers/

---

On September 16, 2026, CISA published **"Using Cyber Decoys to Strengthen Detection and Response"** — a 22-page guidance document that tells security teams to do something counterintuitive: **fill your network with fake credentials, bogus admin accounts, and decoy systems, then wait for someone to touch them.** Any interaction is proof of compromise. No behavioral baseline needed. No machine learning. No new tools to buy. The guidance targets critical infrastructure operators and resource-constrained teams — the organizations least likely to have a dedicated threat-hunting team and most likely to face nation-state adversaries using living-off-the-land (LOTL) techniques that look identical to normal administration. ## Why deception, and why now The modern attacker doesn't drop custom malware on disk. They steal a credential, log in through the VPN, run `net group "Domain Admins" /domain`, move laterally over RDP, and exfiltrate through an approved cloud service. Every tool they use is a tool your admins use. Every protocol they traverse is a protocol your monitoring already sees thousands of times per hour. Signature-based detection can't catch it — there's no signature. Behavioral analytics can flag it, but the false-positive rate is high enough that real alerts drown in noise. CISA's acting executive director of cybersecurity, Chris Butera, framed decoys as **"both a very low-cost but actually high-fidelity way to detect an adversary who's already gained access"** and described the approach as making critical infrastructure networks **"unfriendly places for adversaries."** The core insight is simple: if you place something in your network that no legitimate user would ever touch, then _any_ interaction with it is malicious by definition. The signal-to-noise ratio is not 10:1 or 100:1 — it is infinite. Zero expected false positives. ## The four building blocks CISA's framework defines four types of deception asset: TypeWhat it isExample **Honeytoken**Fake data item — credential, API key, document, database recordA fake `svc_backup` password stored in Credential Manager **Honeypot**Fake system or serviceA low-interaction listener on SMB/RDP/SSH ports in a production VLAN **Breadcrumb**Clue that guides attackers toward a decoyA saved RDP connection to a decoy host, a config file referencing fake database credentials **Tripwire**Any decoy rigged to fire an alert on interactionA canary AD account that triggers a SIEM alert on any authentication attempt These aren't exclusive categories — a single canary account is simultaneously a honeytoken (the credential), a tripwire (the alert), and the target of breadcrumbs (planted references pointing to it). ## What to deploy: concrete decoy types CISA maps decoys to the MITRE ATT&CK techniques they catch: DecoyATT&CK technique detected Canary user/service account with Kerberos SPNT1558.003 Kerberoasting, T1078 valid account abuse LSASS-embedded or script-stored fake passwordsT1003 credential dumping, T1552 unsecured credentials Decoy host/listener on SMB, RDP, SSH, WinRMT1021 lateral movement, T1046 network discovery Beaconing documents ("Project_Metrics.xlsx")T1567 exfiltration over web service Fake AD computer accounts, misleading GPOsT1087 account enumeration, T1482 domain trust discovery ## Deployment roadmap: phased, no procurement required CISA explicitly designed this for teams that don't have a deception budget. The entire deployment uses native Windows, Active Directory, and existing SIEM/EDR capabilities: ### Weeks 1–2: Canary service accounts Create fake service accounts with attractive Service Principal Names (SPNs) that Kerberoasting tools will target. Example SPN: `MSSQLSvc/fakesql.corp.local:1433`. Wire authentication events (Event IDs 4624, 4625, 4768, 4776) to your SIEM. Any logon attempt against these accounts is hostile. ### Weeks 2–4: Honeytokens in credential stores Plant fake credentials in Windows Credential Manager, unattend.xml files, PowerShell scripts, and configuration repositories — everywhere attackers look when they dump credentials. Pair with LSASS access monitoring. An attacker who runs Mimikatz will harvest these alongside real credentials and eventually try to use them. ### Month 2: Decoy file shares Create network shares with names like `Finance-Backups` and `PasswordExport` containing beaconing documents. Alert on any read access. No legitimate user will open a file on a share they were never told exists. ### Months 2–3: Low-interaction honeypots Deploy listeners on production VLANs answering on common lateral-movement ports (445, 3389, 5985, 22). Configure Syslog/CEF reporting to your SIEM. Any connection to an IP that hosts no real service is hostile reconnaissance or lateral movement. ### Ongoing governance Maintain a restricted-access decoy registry visible only to IR/SOC leads. Exclude decoys from vulnerability scanner sweeps (or you'll alert on your own scanners). Review and rotate quarterly. ## Detection rules: three Sigma rules you can deploy today The guidance community has already produced detection rules aligned with CISA's recommendations: ### 1. Canary account authentication Monitors Windows Event IDs 4624, 4625, 4768, and 4776 for any logon attempt against designated canary identities (e.g., `svc_backup`, `adm_jwalker`, `sql_reports`, `helpdesk_temp`). These accounts have no legitimate use, so any authentication event is high-fidelity evidence of credential theft. ### 2. Kerberoasting tripwire Triggers on Kerberos TGS requests where the service name matches a canary account. Filters out legitimate machine account requests (accounts ending with `$`). Rated critical severity with zero expected false positives. ### 3. Decoy network connections Detects any traffic to decoy IP ranges on ports 445 (SMB), 3389 (RDP), 5985 (WinRM), and 22 (SSH). A misconfigured legacy application is the only legitimate false-positive source — and finding that is useful too. ## PowerShell deployment: native tools, no vendor lock-in CISA's approach uses only built-in Windows and Active Directory capabilities: `# Create canary service account New-ADUser -Name "svc_backup" -Enabled $true -PasswordNeverExpires $true # Set attractive SPN that Kerberoasting tools will target Set-ADUser "svc_backup" -ServicePrincipalNames @{Add="MSSQLSvc/fakesql.corp.local:1433"} # Plant honeytoken in Credential Manager cmdkey /add:fakesql.corp.local /user:svc_backup /pass:FakeP@ssw0rd! # Enable audit subcategories for detection auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable auditpol /set /subcategory:"Logon" /success:enable /failure:enable # Validate: confirm zero legitimate logon history Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} | Where-Object { $_.Properties[5].Value -eq 'svc_backup' }` ## Critical security guardrail CISA emphasizes one hard requirement: **decoys must not provide real access.** A fake admin account must not have actual permissions. A decoy host must not bridge to production systems. A honeytoken credential must not unlock anything. The documentation listing decoy locations must be stored outside the production environment — if an attacker compromises the network and finds the decoy map, the entire strategy collapses. ## MITRE framework alignment CISA recommends using MITRE ATT&CK to identify which adversary techniques your environment is most exposed to, then aligning decoy placement with MITRE Engage's three goals: - Expose: Detect adversary presence (canary accounts, honeytokens, tripwires) - Affect: Impose cost and disrupt operations (decoy shares that waste attacker time, fake credentials that trigger lockouts) - Elicit: Safely observe attacker behavior to collect intelligence (honeypots that log tooling, timing, and infrastructure) ## How this connects to incident simulation Deploying decoys is a detection strategy. Knowing what to do when one fires is an incident response problem. If your team has never practiced the sequence — decoy alert → triage → containment → forensics → credential rotation — the decoy fires and the SOC stares at it. PlayCISO's [War Room simulations](/arcade) put security teams through branching incident scenarios where decisions compound: the ransomware simulation forces exactly the kind of lateral-movement containment decisions that a honeytoken alert would trigger in production. ## The bottom line for security leaders CISA is telling you something it rarely says this directly: **assume the attacker is already inside, and rig the environment so that moving through it sets off alarms.** The guidance is accessible to teams without deception budgets, without specialized tools, and without dedicated threat hunters. It works because it doesn't try to be smarter than the attacker — it makes the attacker's own success (finding and using credentials) the trigger for detection. The 22-page document is available at [cisa.gov](https://www.cisa.gov/resources-tools/resources/using-cyber-decoys-strengthen-detection-and-response). ## Frequently asked questions **What are cyber decoys and why is CISA recommending them?** Cyber decoys are fake credentials, accounts, files, and systems planted inside a network that have no legitimate business use. Any interaction with them is strong evidence of unauthorized access. CISA recommends them because modern attackers increasingly use stolen credentials and built-in administrative tools (living-off-the-land techniques) that look identical to normal activity, making traditional detection methods ineffective. Decoys provide high-fidelity alerts with near-zero false positives. **What is the difference between honeytokens, honeypots, breadcrumbs, and tripwires?** Honeytokens are fake data items like credentials, API keys, or documents that reveal unauthorized access when used. Honeypots are fake systems or services (e.g., a decoy SSH or RDP listener). Breadcrumbs are clues planted in places attackers look — saved connections, config files, browser bookmarks — that guide them toward decoys. Tripwires are any decoy rigged to trigger an alert upon interaction. All four work together in a layered deception strategy. **Do I need to buy specialized deception tools?** No. CISA explicitly states that organizations can deploy decoys using tools they already own — EDR platforms, identity and access management systems, Active Directory, and data loss prevention tooling. The guidance includes PowerShell scripts for creating canary accounts and planting honeytokens using native Windows and AD capabilities. Open-source solutions are also a good option for organizations with limited budgets. **How do cyber decoys detect living-off-the-land attacks?** LOTL attacks use legitimate credentials and built-in tools like PowerShell, net.exe, and RDP that blend with normal activity, making behavioral detection unreliable. Decoys bypass this problem entirely: a canary service account or fake credential has zero legitimate use. Any authentication attempt or file access against these decoys is malicious by definition — no behavioral baseline or machine learning required. **What is the recommended deployment timeline?** CISA recommends a phased approach: Weeks 1–2, deploy canary service accounts with attractive SPNs. Weeks 2–4, plant honeytokens in credential stores. Month 2, create decoy file shares with beaconing documents. Months 2–3, deploy low-interaction honeypots. Ongoing: maintain a restricted-access decoy registry and review quarterly.