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