Honeypots & Deception

Honeypots are systems with no productive purpose whose sole job is to be attacked – which makes every interaction at least suspicious by definition. Low-interaction honeypots emulate individual services or protocols only superficially; they are resource-efficient, quick to deploy and low-risk, but provide limited insight and are easier for attackers to identify as decoys. High-interaction honeypots run real operating systems and applications and allow deep analysis of attacker tools and techniques – at the cost of significantly higher operational and hardening effort. In its foundational study, ENISA evaluated 30 honeypot solutions along exactly this taxonomy, covering both server-side and client-side variants.

Honeytokens transfer the decoy principle from systems to data and credentials: planted API keys, documents, database records, DNS names or email addresses that nobody uses in regular operations. If such an object is opened or a planted key is used, this constitutes an almost unambiguous indicator of compromise – even where traditional sensors are absent, for example in SaaS services or in cases of data exfiltration. Freely available services such as Canarytokens by Thinkst offer more than 30 token types, from AWS keys and Office documents to kubeconfig files, enabling adoption with minimal effort. NIST describes this approach (“tainting”), alongside redirecting attackers (“misdirection”), as an approach within the cyber resiliency technique of deception.

Traditional detection via SIEM, EDR or NDR has to filter attacks out of vast volumes of legitimate events – with the corresponding background noise and tuning effort. Deception inverts this logic: since legitimate users never touch decoys and honeytokens, virtually every alert is relevant. Deception platforms orchestrate decoys centrally, feed alerts into the SIEM or SOC, and deliver context-rich telemetry for incident response. Since 2022, MITRE Engage has also provided a dedicated framework that structures denial, deception and adversary engagement activities and aligns them with attacker behavior observed in the real world. For operators of critical facilities, deception can complement the attack detection systems required under Section 31 BSIG – but it cannot replace them.

Deception is effective where attackers move after initial access: in internal network segments, in Active Directory, on file and backup systems, in cloud environments and increasingly in OT networks as well. Proven practice includes deploying decoy systems in every relevant segment and placing honeytokens in repositories, configuration files and credential stores – along the paths that lateral movement and privilege escalation typically take. A honeypot publicly exposed on the internet, by contrast, mainly generates background noise from mass scanning and contributes little to detecting targeted attacks on your own network. Credibility is decisive: naming conventions, patch levels and metadata of the decoys must match the real environment, and deception infrastructure must be strictly separated from the production network.

Operating honeypots on your own infrastructure is permissible as a pure detection measure – the attacker accesses the operator's systems of their own accord, which does not constitute criminal “incitement”. This must be clearly distinguished from the “hack back”: active access to third-party systems is not permitted for companies in Germany and remains a criminal offense in the absence of a legal authorization (including under Sections 202a et seq. of the German Criminal Code, StGB); deception ends at your own network boundary. Under data protection law, the processing of the data generated in the process (such as IP addresses) can regularly be based on legitimate interest under Art. 6(1)(f) GDPR – Recital 49 explicitly mentions ensuring network and information security, insofar as the processing is strictly necessary and proportionate for that purpose. Care is required in the scenario where a compromised high-interaction honeypot is abused as a stepping stone for attacks on third parties: criminal law literature discusses aiding-and-abetting risks for operators in this context, which is why outbound traffic must be strictly restricted at the technical level.

Deception only detects attackers who actually interact with decoys – it replaces neither prevention nor comprehensive detection, but complements both with a highly precise additional signal source. Experienced attackers attempt to unmask honeypots through fingerprinting; emulation artifacts, implausible systems or missing traces of use destroy the illusion and devalue the measure. Operating deception therefore requires ongoing care: updating decoys, adapting to changes in the environment, defined playbooks for alerts and clear responsibilities within the SOC. The ENISA study already identified usability, documentation and staffing requirements as major hurdles to honeypot adoption – modern platforms and honeytoken services lower this threshold considerably, but do not eliminate the maintenance effort entirely.