Recognizing Deception

Recognizing Deception

Every other skill in this collection assumes the environment is telling you the truth. Deception technology exists specifically to break that assumption, and it is the failure mode an automated or semi-automated tester is least equipped to catch.

The distinction that matters: careful evidence-handling protects you against conclusions you invented. It does nothing against a false belief the environment deliberately planted. A honeypot presenting a convincingly vulnerable service produces real banners, real responses, and real artifacts. Every verification step you would normally run confirms it, because the evidence is genuine — it was manufactured to be.

Assume competent defenders have planted something. Your job is to notice before you touch it, because most deception fires on first use, and first use cannot be undone.

When to Use

• Anything is markedly easier than the rest of the environment
• Credentials turn up somewhere convenient — a share, a wiki, a config, a pastebin-shaped file
• A privileged account exists with a SPN, a weak password, and no logon history
• A service answers with a vulnerable banner but behaves oddly under real use
• You are about to use credentials whose provenance you cannot state
• A file, bucket, or database is named to attract attention (passwords.xlsx, backup-prod, domain_admins.txt)
• Before authenticating with anything recovered from an unexpected location

When NOT to Use

• Evading detection generally — that is engagement OPSEC, not deception recognition; a canary is not something you evade, it is something you avoid triggering
• Analysing an adversary's own decoys during an incident — use responding-to-incidents and producing-threat-intelligence
• Building a deception capability — this skill is about encountering deception, not deploying it
• A finding that is merely surprising — real environments contain real misconfigurations; see the base-rate discussion below before crying honeypot

The Economics Are Against You

Deception is cheap to deploy and expensive to trip:

A canary alert is one of the very few signals a SOC treats as automatically true. There is no benign explanation to hide behind, and the alert carries your source address and often your tooling's fingerprint. Tripping one typically ends the covert phase of an engagement immediately.

Signals, By Type

Honeytokens and canary tokens

The highest-frequency class, and the one that fires on use rather than on discovery. Common forms: AWS keys, Office documents with a callback, DNS tokens, URL tokens, cloned-website tokens, SQL Server rows, Windows directories, Kubeconfig files.

Signals:

• Credentials in a location with no operational reason to hold them — a world-readable share, a wiki page, a README, a desktop file
• An AWS key that is syntactically valid but appears in isolation, with no surrounding infrastructure, tooling config, or commit history
• Documents that are plausible but inert — a spreadsheet with no formulas, a .docx whose only interesting content is its filename
• Anything staged for discovery: correct name, convenient location, no supporting context

A canary AWS key alerts on the first API call, including sts get-caller-identity. There is no safe reconnaissance call. Treat key material of unknown provenance as live until you can explain how it got there.

Active Directory decoys

• Privileged account, SPN set, weak password, lastLogon empty or ancient — a Kerberoastable account nobody has ever authenticated as is bait
• Accounts whose whenCreated clusters with other suspicious accounts
• Description fields containing credentials — a classic real misconfiguration and a classic decoy, so provenance matters more than usual
• Shares with attractive names and no access history
• Objects that appear in enumeration but have no group membership, no manager, no ownership relationships — real accounts accrete relationships

Deceptive services

• Banner advertises a version with a famous CVE, but behaviour under real interaction is inconsistent with that version
• Service is reachable from a segment that should not reach it
• Response timing is uniform in a way real applications are not
• The host runs an implausible service combination, or a service with no business function on that host
• Exploitation "succeeds" but the resulting shell has no history, no other users, no realistic filesystem, and suspiciously clean logs

Cloud decoys

• S3 buckets, storage accounts, or secrets named to attract enumeration
• IAM users with permissive-looking policies and no CloudTrail history
• Resources tagged inconsistently with the rest of the account

Base Rates Cut Both Ways

Real environments are genuinely bad. Credentials really do sit in shares, service accounts really are Kerberoastable, and buckets really are public. If you label every finding a honeypot you will report nothing and miss the actual compromise path.

The discriminator is supporting context, not attractiveness:

• A real misconfiguration has a history — commit history, access logs, logon history, related infrastructure, other users, adjacent mess.
• A decoy is isolated. It exists to be found and nothing else uses it.

So the question is never "is this too good to be true?" It is: what else in this environment depends on this thing existing? If the answer is nothing, slow down.