A honeypot is a deliberately vulnerable system or resource designed to attract attackers and capture intelligence about their tactics. To attackers, it looks like a real production system worth attacking; to defenders, every interaction is high-confidence detection of malicious activity (because no legitimate user has any reason to access it). Honeypots come in many forms — fake servers, fake databases, fake credentials, fake documents — and serve multiple purposes: early warning of attacks in progress, threat intelligence collection, distraction of attackers from real targets, and research into adversary techniques.

Six categories: (1) **Low-interaction honeypots** — emulate services partially (Cowrie SSH, Dionaea malware capture); cheap, low risk, but attackers may detect emulation, (2) **High-interaction honeypots** — full operating system, attacker can fully compromise; deepest intelligence but higher risk and operational cost, (3) **Honeynets** — entire networks of honeypots simulating production environment, (4) **Honeytokens** — fake credentials, fake API keys, fake documents seeded into systems; alert when accessed, (5) **Honeyfiles** — fake sensitive documents (e.g., 'Q4_Financials.xlsx') that beacon when opened, (6) **Honey accounts** — fake AD accounts with high privilege; alert on any login attempt. Modern deception platforms (Illusive, TrapX, Acalvio, Smokescreen) automate deployment at enterprise scale.

Open-source: (1) **T-Pot** — community honeypot platform from T-Systems; bundles 20+ honeypots in Docker, (2) **Cowrie** — SSH/Telnet honeypot, captures attacker commands, (3) **Dionaea** — malware capture honeypot, (4) **Honeyd** — virtual honeypot creator, (5) **Canary (Thinkst)** — commercial-grade simplicity (set-and-forget), (6) **OpenCanary** — open-source Canary alternative. Enterprise deception platforms: (1) **Acalvio ShadowPlex** — distributed deception across IT/OT/cloud, (2) **Illusive Networks** (acquired by Proofpoint) — Active Defense + identity protection, (3) **TrapX DeceptionGrid**, (4) **Attivo Networks ThreatDefend** (acquired by SentinelOne) — integrated with Singularity. Selection criteria: scale, integration with SIEM/SOAR, IT/OT coverage, telemetry quality.

Yes — but the modern pattern is **deception technology** rather than standalone honeypots. Modern enterprises deploy honeytokens at scale: fake credentials in password managers, decoy AWS keys in code repositories, lure files in network shares, decoy AD accounts. Every interaction is high-confidence breach detection. Why it works: attackers performing reconnaissance and lateral movement inevitably encounter decoys; the false positive rate is essentially zero. Detection at the point of *post-breach lateral movement* complements EDR/XDR perimeter detection. ITDR (Identity Threat Detection and Response) products bundle honeytokens with broader identity attack detection. Major analysts (Gartner, Forrester) recommend deception as a top-quartile detection control.

Three related but distinct concepts: **Honeypots** — original term, individual fake systems for research and capture; mostly external-facing or DMZ. **Deception technology** — modern enterprise term, scaled honeypots + honeytokens distributed across the production environment to detect post-breach lateral movement; integrated with SOC. **ITDR (Identity Threat Detection and Response)** — newer category specifically for identity-based attacks; combines honey accounts/credentials with behavioural identity analytics (Microsoft Defender for Identity, CrowdStrike Falcon Identity Protection, Silverfort, Semperis). Modern programmes use all three: classic honeypots for external reconnaissance, deception for internal lateral movement, ITDR for identity-targeted attacks.

Six considerations: (1) **Entrapment defence (rare in cyber context)** — most jurisdictions don't recognise entrapment as a defence for unauthorised access; honeypot deployment is generally legal, (2) **Privacy** — capturing attacker traffic may inadvertently capture innocent third parties (e.g., Tor exit relay traffic); banner with consent recommended, (3) **Cross-border data** — if honeypot captures traffic from EU residents, GDPR implications apply, (4) **Active defence prohibitions** — most jurisdictions prohibit hack-back; honeypots are *passive* and legal, but offensive actions from honeypot are not, (5) **Banner / Terms of Service** — display authorised-use-only warnings to strengthen legal position, (6) **Evidence preservation** — if honeypot captures actionable evidence, follow forensic chain of custody for potential prosecution. Consult legal counsel before deploying in production.

Eight best practices: (1) **Network isolation** — deploy in segmented network with strict egress filtering; honeypot must not become a pivot to real production, (2) **Firewall rules** — block all outbound from honeypot except logging traffic to SIEM, (3) **Resource limits** — cap CPU/memory/bandwidth to prevent abuse for DDoS amplification, (4) **Patching** — even honeypots need patching for the underlying platform; the honeypot service is intentionally vulnerable, but the host OS shouldn't be exploitable for unintended access, (5) **No real data** — never deploy honeypots with real customer data, (6) **Monitoring** — every honeypot interaction should generate SIEM alerts, (7) **Realistic content** — empty honeypots are detectable; populate with fake-but-believable data, (8) **Periodic refresh** — rotate decoys to prevent attackers learning to recognise them. Test thoroughly in staging before production.