Security+ 801 Countdown, T-15: Deception Moves to 4.1 and Adds the Canary Account

Deception technology is the deliberate placement of decoys that no legitimate user, process, or scheduled job has any reason to touch, so that the first interaction with one is evidence of an intruder or a misbehaving tool rather than an anomaly to be argued over. A decoy host, a decoy document, a planted credential, and an unused directory account share one property: their expected traffic is zero, so detection reduces to an identity match instead of a threshold. The control is detective rather than preventive. It does not stop an attacker; it reports that one is present, from which host, and under which account, early enough for the rest of the operations stack to act.

SY0-801 files deception and disruption technology under objective 4.1, Given a scenario, apply mitigating controls, techniques, and solutions to secure the environment, where the bullet sits between Sandboxing and Monitoring/alerting and is expanded to five sub-bullets, Honeypot, Honeynet, Honeyfile, Honeytoken, and Canary account (CompTIA 2025). Because 4.1 is a scenario objective, the exam expects you to choose and place the right decoy for a described threat and to read the alert it produces, not merely to recognize that a honeypot is bait.

The canary account is the fifth decoy and the one this post builds in full: an enabled directory identity that nothing legitimate ever uses, so any password guess, ticket request, or lookup against it is suspect by construction. The build doubles as a honey SPN for catching Kerberoasting and comes with its Event 4769 detection rule. The sections after it place the other four decoys, cover the isolation that keeps a decoy from becoming a foothold, and note the legal questions a honeypot raises.

Five decoys and one principle

The objectives document does not define the five items or the word “disruption,” so the definitions here come from primary sources, and the canary row is interpretation. What unites the five is a single design rule: a decoy has no legitimate use, so any use is the signal.

Item	What it is	The alarm
Honeypot	A decoy host or service	Any connection to it
Honeynet	A network of decoys	Any traffic into it
Honeyfile	A decoy document	Someone opens it
Honeytoken	A planted credential, key, record, or URL	Someone uses it elsewhere
Canary account	An enabled directory identity nobody uses	Any authentication, ticket request, or lookup

A honeypot, in the language of RFC 4949, is a system or system resource “designed to be attractive to potential crackers and intruders” (Shirey 2007). A honeynet is a network of such decoys; MITRE D3FEND splits honeynets into Standalone (D3-SHN), Connected (D3-CHN), and Integrated (D3-IHN). The two smaller decoys are objects rather than systems: D3FEND files Decoy File (D3-DF) and Decoy User Credential (D3-DUC) under Decoy Object, with the synonym “Lure” (MITRE n.d.-a). The distinction between them is where the alarm fires. A honeyfile alerts when it is opened in place; a honeytoken alerts when the planted item is used somewhere else, which is why a leaked access key works as a honeytoken and a payroll spreadsheet works as a honeyfile.

The canary account is a whole directory identity: created, enabled, monitored, and never used. Vendor naming blurs this line. Microsoft Defender for Identity calls the same concept a “honeytoken account,” applied as a Honeytoken entity tag under Settings > Identities, and says any sign-in from one triggers an alert (Microsoft 2026c). A workable split for the exam: a canary account is a whole directory identity; a honeytoken is any planted data item whose use is the alarm.

Building a canary account that doubles as a honey SPN

The most valuable canary account catches an attack that leaves no other domain-side signal. Kerberoasting (ATT&CK T1558.003) is that attack, and it needs only a domain foothold. In Kerberos, a service principal name (SPN) ties a service to the directory account that runs it, and any authenticated user holding a ticket-granting ticket (TGT) can request a service ticket for any SPN. The key distribution center (KDC) encrypts that ticket with a key derived from the password of the account that owns the SPN, so the attacker takes the ticket offline and cracks it without ever touching the service (MITRE 2025). The only domain-side trace is Event 4769 on a domain controller, whose subcategory Microsoft rates “Very High” in volume (Microsoft 2021), which rules out reading it by hand.

A honey SPN inverts the problem. A sweep that requests every SPN in the domain also requests the decoy’s SPN, which no client uses, so any 4769 naming the decoy as the service is an attacker or an authorized assessment. Audit the domain controllers first (by GPO in production), then create the decoy:

auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable

$pw = Read-Host -AsSecureString -Prompt 'Paste a 64-character random password'
New-ADUser -Name 'svc-sqlrpt' -SamAccountName 'svc-sqlrpt' `
  -Path 'OU=Service Accounts,DC=corp,DC=example,DC=com' `
  -Description 'SQL Reporting (legacy) do not disable' `
  -AccountPassword $pw -Enabled $true -PasswordNeverExpires $true `
  -ServicePrincipalNames 'MSSQLSvc/sqlrpt01.corp.example.com:1433'
Set-ADUser svc-sqlrpt -Replace @{'msDS-SupportedEncryptionTypes'=0x24}  # optional RC4 lure

The random password makes offline cracking infeasible, and the account holds no rights; the description is the bait. D3-DUC says decoys need upkeep to stay believable: give sqlrpt01 a DNS record and match your naming convention. A hit looks like this:

Event ID: 4769   Computer: DC01.corp.example.com
A Kerberos service ticket was requested.
Account Information:
  Account Name:            mlopez@CORP.EXAMPLE.COM
Service Information:
  Service Name:            svc-sqlrpt
Network Information:
  Client Address:          ::ffff:192.0.2.45
Additional Information:
  Ticket Options:          0x40810000
  Ticket Encryption Type:  0x17
  Failure Code:            0x0

Reading the hit

In ITN 260 I flag one trap here. Service Name (XML ServiceName) is the decoy, shown as its sAMAccountName, not the MSSQLSvc string. Account Name (XML TargetUserName) is the requester, i.e., the attacker’s foothold, so the pivot is to mlopez and 192.0.2.45, not to the decoy. Ticket Options 0x40810000 decodes as Forwardable, Renewable, Canonicalize. Encryption type 0x17 is RC4-HMAC (etype 23 decimal), present because of the 0x24 lure; a default decoy shows 0x12 (AES256).

The detection rule is a single identity match:

title: Kerberos Service Ticket Requested for Honey SPN Account
id: bdb9465a-4146-4744-a3f9-822e937d22df
description: Any TGS request for decoy svc-sqlrpt; no legitimate client uses its SPN
tags:
    - attack.credential-access
    - attack.t1558.003
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        ServiceName: 'svc-sqlrpt'
    condition: selection
falsepositives:
    - Authorized penetration tests or AD audits that request every SPN
level: high

The rule matches one identity, not volume or encryption type. SigmaHQ’s RC4 hunting rule, by contrast, keys on 0x17 and still lists legacy service accounts as false positives (SigmaHQ n.d.). Without a SIEM, Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4769; ServiceName='svc-sqlrpt'} runs the same check. Route hits as high severity to a named responder; alert pipelines are T-8’s, and gMSA and the other Kerberoasting defenses are T-12’s.

Why RC4 is a booster, not the trigger

Under Microsoft’s CVE-2026-20833 hardening, accounts without an explicit msDS-SupportedEncryptionTypes default to AES-SHA1 only (DefaultDomainSupportedEncTypes 0x18) from April 14, 2026, and from July 2026 enforcement is programmatic with no rollback (Microsoft 2026a). A client offering only RC4 for such an account is refused and logged as KDCSVC event 203 in the System log, with Account Name, Service Name, and Client Address. Watch 203s naming the decoy; do not count on a 4769 Failure, since some failure codes log only with KdcExtraLogLevel flags set. Microsoft honors explicit administrator settings, which is why the 0x24 lure works. Hex trap: 0x18 is RC4-HMAC-EXP in the 4769 encryption-type table but AES128 plus AES256 as a msDS-SupportedEncryptionTypes bitmask.

Canary signals beyond Kerberoasting

The honey SPN is one trigger. The same account, because nothing legitimate ever authenticates as it, is also a tripwire for password spraying, credential use, and enumeration, and each case shows up in a different domain controller event with the canary in a predictable field.

DC event	Canary appears as	Meaning
4771, Status 0x18	TargetUserName	Wrong Kerberos password; spraying reached it
4776, Status 0xC000006A	TargetUserName	The same over NTLM
4768, success	TargetUserName	Valid credentials; treat as compromise
4769	TargetUserName	The canary is reaching services
4769	ServiceName	Kerberoasting (honey SPN)

Every row keys on one identity, so none needs a threshold; the 4625 spraying patterns that do need thresholds are at T-28. Tagged in Defender for Identity, the same account raises alerts such as 2014 “Honeytoken authentication activity” and 2429 “Honeytoken was queried via LDAP,” which catches enumeration (Microsoft 2026b).

Honeyfiles and cloud honeytokens

A honeyfile is the simplest decoy to plant, and the usual mistake is planting it without the auditing that makes it fire. It needs the Audit File System subcategory enabled plus a system access control list (SACL) audit entry on the file itself, because Event 4663 is generated only when the SACL has a matching access control entry (ACE). Alert on 4663 where ObjectName is the decoy, e.g., D:\Shares\Finance\FY27_Payroll_Bank_Changes.xlsx, and AccessMask is 0x1 (ReadData). SubjectUserName and ProcessName show who opened it and with what; ProcessName also lets you exclude antivirus, backup, and indexing, the processes that touch files nobody reads.

A cloud honeytoken follows the same pattern with an access key in place of a file. Create an IAM user with no permissions, plant its access key where harvesters look (~/.aws/credentials on a jump host, a CI variable, a repo config), and alert on any CloudTrail event whose userIdentity.accessKeyId matches (Amazon Web Services n.d.-a). The AKIA prefix marks a long-term key, as in AWS’s documented example AKIAIOSFODNN7EXAMPLE. A common first move, aws sts get-caller-identity, needs no permissions even under an explicit deny, so it succeeds and is logged (Amazon Web Services n.d.-b), which is exactly what a zero-permission decoy wants. Expect the alert within minutes; Thinkst documents a 2 to 30 minute delay (Thinkst n.d.). Your secrets scanner may flag the planted key, so document an exception (T-29).

Placement, isolation, and the law

Each decoy has a natural home, chosen by the attacker behavior it is meant to catch.

Decoy	Where to put it	What it catches
Canary account	AD, named like a legacy service	Spraying, enumeration, Kerberoasting
Honeyfile	Finance or HR share	Collection, ransomware staging
Honeytoken	Repos, CI variables, vaults	Credential harvesting
Honeypot	Internal server VLAN	Scanning, lateral movement
Honeynet	Isolated decoy subnet	Attacker tooling, for study

Internal decoys give high-fidelity alerts because nobody should touch them, once documented exclusions exist for pentests, scanners, and backup jobs; internet-facing honeypots mostly yield threat intelligence and noise.

The serious risk is the pivot point. NIST SP 800-53 control SC-26 (Decoys) says decoys “require some supporting isolation measures” so deflected malicious code does not infect production (Joint Task Force 2020), and MITRE Engage’s Isolation activity (EAC0020) keeps an engagement within “desired limits” (MITRE n.d.-b). A high-interaction honeypot, one that exposes real services rather than emulated ones, needs its own segment, strict egress filtering, no trust relationships, and no real credentials, or it becomes a foothold and a launch point against third parties.

Legal notes, not legal advice: SC-26 says consulting the Office of the General Counsel before deployment may be needed. A honeypot that records the content of an intruder’s communications raises Wiretap Act questions under 18 U.S.C. 2511, whose relevant exceptions are party or prior consent in (2)(d), a provider protecting its “rights or property” in (2)(a)(i), and the computer-trespasser exception in (2)(i), which covers only persons acting under color of law with the owner’s authorization (Legal Information Institute n.d.). RFC 4949’s “entrapment” (planting apparent flaws) is a glossary term, not the courtroom defense.

What you need to know for SY0-801

• Deception is detective (SC-26: “detecting, deflecting, and analyzing”). Stem says detect, early warning, confirm an intruder, or study the attacker: think deception. Stem says prevent or stop: think lockout, rate limiting, MFA, application control, or segmentation.
• Honeypot, honeynet, honeyfile, and honeytoken are 701-era vocabulary; canary account is the SY0-801 addition, an enabled directory identity that is never used and always watched.
• “Disruption” is undefined; one interpretation is slowing an intruder, e.g., throttling or a kill switch (MITRE Engage EAC0016 Network Manipulation).
• Honeypot versus sandbox: a sandbox (SC-44 detonation chamber) judges suspicious code and is not meant to host adversaries long term; a honeypot is bait.
• Honeyfile versus honeytoken: opened versus used elsewhere. A decoy CSV of fake passwords is both.
• Canary versus stale account: a stale account is forgotten and unmonitored (a 2.4 attack surface); a canary is deliberate, enabled, and watched.
• Canary versus break-glass account: break-glass is used in an emergency; a canary is never used.
• Reading a honey SPN hit in Event 4769: Service Name is the decoy, Account Name is the requester, and the investigation pivots to the requester and its Client Address.

Check yourself

These are my own practice questions.

1. A domain’s controllers log tens of thousands of Event 4769s per hour, and the SOC wants early warning of Kerberoasting with almost no false positives. Which of the following is the BEST approach?

• A. Alert on every 4769 with Ticket Encryption Type 0x17.
• B. Give an unused account a plausible SPN and alert on any 4769 naming it as the service.
• C. Set the account lockout threshold to five attempts.
• D. Deploy a honeypot web server in the DMZ.

Answer: B. A honey SPN turns detection into an identity match. RC4 matching is noisy and misses AES roasting after Microsoft’s 2026 changes, lockout never fires because Kerberoasting causes no failed logons, and a DMZ honeypot sees internet noise.

2. A honey SPN rule fires: Account Name mlopez@CORP.EXAMPLE.COM, Service Name svc-sqlrpt, Client Address ::ffff:192.0.2.45. What should the analyst do FIRST?

• A. Disable svc-sqlrpt because it is compromised.
• B. Investigate mlopez and the host at 192.0.2.45 as a likely foothold.
• C. Reset the password of every service account.
• D. Remove the SPN to stop further requests.

Answer: B. Account Name is the requester; Service Name is the decoy, whose random password resists cracking. Disabling the decoy or removing its SPN only destroys the tripwire.

3. Developers have twice committed cloud access keys to public repositories. The CISO wants to know whether keys harvested from those repositories are ever used, and from which IP address. Which of the following BEST meets this requirement?

• A. Secrets scanning on every commit.
• B. A zero-permission access key planted in a repository and monitored in CloudTrail.
• C. A honeyfile on the build server.
• D. Sandboxing the CI pipeline.

Answer: B. That is a honeytoken: its use elsewhere is the alarm, and CloudTrail records the caller’s sourceIPAddress. Secrets scanning fits a stem about preventing leaks; a honeyfile alerts only when opened.

This is T-15 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-14: Wireless Configuration Exits as NAC, Posture Checks, and WIPS Take Over. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

Amazon Web Services. n.d.-a. “Logging IAM and AWS STS API Calls with AWS CloudTrail.” AWS Identity and Access Management User Guide. Accessed October 12, 2026. See also “IAM Identifiers.”

Amazon Web Services. n.d.-b. “GetCallerIdentity.” AWS Security Token Service API Reference. Accessed October 12, 2026.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

Joint Task Force. 2020. Security and Privacy Controls for Information Systems and Organizations. NIST Special Publication 800-53, Revision 5. Gaithersburg, MD: National Institute of Standards and Technology.

Legal Information Institute. n.d. “18 U.S. Code § 2511.” Cornell Law School. Accessed October 12, 2026. See also § 2510.

Microsoft. 2021. “4769(S, F) A Kerberos Service Ticket Was Requested.” Microsoft Learn. Accessed October 12, 2026. See also the pages for Audit Kerberos Service Ticket Operations, 4663, and 4771.

Microsoft. 2026a. “How to Manage Kerberos KDC Usage of RC4 for Service Account Ticket Issuance Changes Related to CVE-2026-20833.” Microsoft Support. Last updated April 14, 2026.

Microsoft. 2026b. “Microsoft Defender for Identity Classic Security Alerts.” Microsoft Learn. Accessed October 12, 2026.

Microsoft. 2026c. “Entity Tags in Microsoft Defender for Identity.” Microsoft Learn. Accessed October 12, 2026.

Microsoft. n.d. “New-ADUser.” Microsoft Learn. Accessed October 12, 2026. See also auditpol set and Get-WinEvent.

MITRE. 2025. “Steal or Forge Kerberos Tickets: Kerberoasting.” MITRE ATT&CK, Sub-technique T1558.003, version 1.3.

MITRE. n.d.-a. “Decoy User Credential (D3-DUC).” MITRE D3FEND. Accessed October 12, 2026. See also the Decoy File and Decoy Environment entries.

MITRE. n.d.-b. “Engage Activity Details.” MITRE Engage data, GitHub. Accessed October 12, 2026.

Shirey, Robert. 2007. Internet Security Glossary, Version 2. RFC 4949. Internet Engineering Task Force.

SigmaHQ. n.d. Detection Rule 496a0e47-0a33-4dca-b009-9e6ca3591f39. SigmaHQ rules repository, GitHub. Accessed October 12, 2026.

Thinkst. n.d. “AWS API Keys Canarytoken.” Canarytokens documentation. Accessed October 12, 2026.