A Review of Honeypots: Fingerprinting Techniques, Detection, and Evasion Mechanisms

Abstract

Honeypot fingerprinting poses a significant threat in cybersecurity, as attackers who are able to identify honeypot systems can successfully evade them, thereby greatly reducing their overall effectiveness as defensive and intelligence-gathering tools. Over the years, numerous studies have proposed a variety of analytical techniques and countermeasures to minimize honeypot fingerprinting and improve honeypot stealth. This paper presents a comprehensive examination of the methods and strategies that attackers employ to detect and fingerprint honeypot systems, including behavioural, network-based, and system-level indicators. In addition, this paper analyzes common vulnerabilities inherent in both low-interaction and high-interaction honeypots that facilitate successful fingerprinting. Existing anti-detection and obfuscation techniques are evaluated for their effectiveness and limitations. Specifically, this paper offers a structured analysis of honeypot fingerprinting techniques, examines attackers’ probing strategies, evaluates the most vulnerable protocol artifacts, and outlines mitigation strategies to reduce the likelihood of honeypot detection. Finally, this paper discusses how emerging technologies and increasingly complex computing environments, such as cloud infrastructure and virtualization, impact honeypot deployment, and it highlights open challenges and promising future research directions in the field of honeypot anti-fingerprinting.

1. Introduction

Honeypot systems are used in network and computer security. They are designed to deceive attackers by masquerading as a real critical system. This helps defenders observe malicious activity and study attackers’ tools and strategies. These systems are usually equipped with monitors and event loggers to record the attacker’s behaviour [1]. As described in the Hacking the Hacker: Learn from the Experts Who Take Down Hackers [2], the main functionality of honeypots is to act as a deceptive asset, using their ability to reveal an attacker’s intent and strategies instead of just focusing on providing direct protection to the real system.

However, over the past years, research in honeypot fingerprinting has increased, revealing methods attackers can use to identify and evade honeypots. The main importance of honeypots is that they remain unidentifiable from the main system. If a honeypot can be easily identified as such, its value is significantly reduced [3], but this does not appear to be the case in many instances. In general, fingerprinting is benign for many systems, but it poses a serious threat to honeypot systems, as maintaining secrecy is essential for entrapment [4].

To illustrate this challenge, consider an organisation deploying low-, medium-, or high-interaction honeypots. All are used to detect malicious activities. These honeypots differ in their level of complexity and inherent weaknesses. Low-interaction can expose static banners or protocol negotiations. Medium-interaction can reveal timing behaviour or state transitions. High-interaction honeypots provide greater security by more closely mimicking a real system, but they entail greater operational complexity. Attackers can employ various probing techniques to reveal the system’s identity, and differentiating among susceptibility artifacts is critical for evaluating the effectiveness of honeypot deployments. Figure 1 presents an example of an attack scenario involving a low-interaction honeypot.

In this article, we analyse existing research on honeypot fingerprinting strategies. Specifically, we examine how fingerprinting techniques differ across low, low-medium, and medium-interaction honeypot deployments. We identify different probing techniques, analyse protocol-level artifacts that are most prone to detection, and show methods proposed to prevent honeypot fingerprinting. By doing so, this work aims to clarify current limitations in honeypot stealth and highlight research gaps in honeypot fingerprinting studies.

1.1. Key Contributions

This literature survey brings the following contributions:

1. Comprehensive analysis of honeypot fingerprinting techniques. We systematically analyse and categorise existing fingerprinting techniques for identifying low- to medium-interaction honeypots, highlighting the primary threat posed to honeypots and the vulnerabilities these techniques aim to exploit.

2. Identification of predominant probing strategies. We systematically analyse different probing strategies used against honeypots to reveal attackers’ workflows and detect honeypot systems.

3. State-of-the-art anti-fingerprinting strategies. We analyse several novel strategies from the literature for fingerprinting prevention, distinguishing those with measurable effectiveness from those based solely on claims.

4. Identification of research gaps. Based on our research, we also identified significant gaps in the existing literature and directions for future work.

1.2. Structure

This survey includes a Related Works section that reviews many studies and surveys on honeypot fingerprinting. The methodology then describes the methods used to identify, select, and filter the papers for this study. Then, each research question is expanded using the extracted data from the papers. This is followed by the discussion of the results from the data extraction and analysis in the research question sections, and then the conclusion of this survey.

2. Background

This section provides background on honeypot interaction levels, probing and fingerprinting techniques, susceptibility artifacts, attacker models, and mitigation approaches to frame the necessary understanding for this paper’s contribution.

2.1. Honeypot Interaction Levels

Honeypots are commonly classified into three levels of interactivity. These levels are low, medium, and high-interaction and are based on the degrees of freedom an intruder can have within the system [5].

Low-interaction honeypots are limited in the services and interaction that they can provide. They replicate simple services and, as a result, are primarily used to analyse spammers or to implement active countermeasures against worms [6]. They usually do not interact with the attacker beyond emulating specific services, such as login portals, and are easy to deploy and maintain. A simple example of such is Honeyd [5].

Medium-interaction honeypots are more sophisticated than low-interaction but still do not implement an actual operating system, unlike high-interaction honeypots [7]. They enable a broader range of attack types to be logged and studied. Examples of medium-interaction honeypots include nwcollect, nepenthes, and honeytrap [5].

High-interaction honeypots are the most advanced form of honeypots because they run an operating system. As the used directories, binaries, and interactions can be logged and analysed, the most comprehensive data and information about the attacker can be collected. An example of a high-interaction honeypot includes Honeynet [5].

2.2. Probing Techniques

Probing is a method of scanning systems or services to identify vulnerabilities or potential avenues for asset compromise. It is the primary stage of the attacker’s attempt to exploit a vulnerable system [8]. Intruders employ a variety of probing techniques to achieve this, including fuzzing-based, active, and longitudinal or behavioural probing, each aimed at revealing system characteristics, implementation details, or indicators of deception.

2.3. Fingerprinting Techniques

In cybersecurity, digital fingerprinting refers to the process of identifying and profiling a device, system, or user based on a collection of unique characteristics and behaviours emitted during their interaction with a network or digital environment [9].

Fingerprinting attacks may be done either actively or passively on the target. In an active fingerprinting attack, a group of fabricated packets is sent to the target system, and the received response is analysed to obtain a fingerprint. In a passive fingerprinting attack, only the target machine’s traffic is intercepted and analysed to obtain a fingerprint [10].

There are several fingerprinting techniques in which an attacker attempts to identify a honeypot as an actual system. These include Banner and metadata, Timing and Latency, Handshake and Negotiation, and many other techniques in which the attacker exploits an inconsistency or vulnerability to identify specific honeypots.

2.4. Artifacts

The term artifact refers to the identifiable behaviours of a honeypot system. Attackers can exploit known behaviours of different artifacts to establish honeypot fingerprints. These behaviours can arise due to configuration choices or underlying infrastructure. An example of an artifact includes a static banner. This involves checking the banner advertised by the end system with static banners offered by honeypot implementations. Honeypot implementations typically provide a limited set of banners, or even static banners, that, in some cases, do not match the actual banners advertised by the services running on the underlying OS. As these banners are hard-coded, they can be matched against a list of known honeypot banners [3].

3. Literature Review

This section details the research questions, related prior scientific work, methodology, selection criteria, and quality assessment.

3.1. Research Questions

The specific research questions proposed are:

• How do fingerprinting techniques and susceptibility artifacts (Configurations, etc.) differ across low, medium, and low-medium interaction honeypot deployments?
• What are the predominant probing techniques used to identify low, medium, and low-medium interaction honeypots in current literature?
• Which specific protocol artifacts (e.g., TLS stacks, static responses) are most vulnerable to detection in low, medium, and low-medium interaction honeypots?
• What strategic and operational methods are most suited to prevent low, medium, and low-medium interaction honeypot deployments from being identified?

3.2. Related Work

Numerous studies have investigated the threats posed by honeypot fingerprinting and the subsequent evolution of mitigation strategies.

Table 1. Other related work on honeypots (✔ means there are at least traces of the topic in the given article, ✗ means there are no traces of the given topic in the given article).

Year	Paper	Fingerprinting Technique	Probing	Susceptible Artifacts									Anti-Detection Method
				Static Banners	Limited Negotiation	Malformed Packets	State Machine	Timing Anomalies	Error Messages	Default Config	Behavioural Consistency	Physical State
2016	[7]	✔	✗	✗	✗	✔	✗	✔	✗	✔	✗	✗	✗
2015	[11]	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗	✔
2021	[12]	✗	✔	✗	✗	✗	✗	✔	✗	✗	✔	✗	✔
2025	[13]	✔	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗
2019	[14]	✔	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗	✔
2021	[15]	✔	✔	✗	✗	✔	✗	✔	✗	✔	✔	✗	✔
2024	[16]	✔	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗	✔
2023	[17]	✔	✔	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗
2018	[18]	✔	✔	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗
2021	[19]	✔	✗	✗	✗	✔	✗	✗	✗	✗	✗	✗	✗
2016	[20]	✔	✗	✗	✗	✔	✗	✗	✗	✗	✗	✗	✗
2019	[21]	✔	✗	✗	✗	✔	✗	✗	✗	✗	✗	✗	✔
2019	[22]	✔	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗	✗
2019	[23]	✔	✔	✗	✗	✔	✔	✗	✗	✗	✔	✗	✗
2022	[24]	✔	✔	✗	✗	✗	✗	✗	✗	✗	✗	✗	✔
2025	THIS SURVEY	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔

compares our novel study with prior studies. Many papers provide minimal details on the questions surrounding honeypot fingerprinting, including its techniques, probing, artifacts, and mitigation methods.

Nawrocki et al. [7] and Nagpal et al. [11] established a taxonomy of interaction levels and general security risks; they provide only limited analysis of specific attack artifacts and the technical vulnerabilities that enable their discovery.

Recent literature has shifted focus towards specialised environments, particularly the Internet of Things (IoT). For instance, Franco et al. [12] and Kavitha et al. [13] examine the unique design features of IoT honeypots, and Franco et al. [12] do not identify anti-detection techniques in the IoT domain. Despite their other contributions, both note that the IoT space is susceptible to evasion but do not provide technical solutions or mitigation plans.

Zobal et al. [14] talk about the current state of honeypots and deception strategies. The article surveys honeypot problems and strategies in the cyberworld. They explore the problem associated with identification, but the article lacks technical exploration of the susceptible honeypot artifacts.

Fan et al. [23] focus on a proposed honeypot architecture called HoneyDoc, designed to coordinate them for high-quality attack capture. They discuss the conventional honeypot architecture and highlights its shortcomings in terms of stealth. This, however, is a single honeypot deployment and not a general research trend.

Kocaogullar et al. [24] present an experiment that evaluates and compares the effectiveness of high-interaction and low-interaction honeypots in terms of the amount and type of information collected from attacks targeting them. This again focuses on honeypot creation over analysing the fingerprinting process. This survey distinguishes itself by providing a thorough list of susceptible artifacts, probing methods, and mitigation techniques that define the current landscape of deception and anti-deception.

3.3. Methodology

This section describes the methodology used to identify, select, and filter the relevant literature used in this paper. Our methodology is inspired by the papers [25,26], which show how to select literature based on research questions and iteratively snowball through it to obtain the maximum amount of useful data. An overview of each step of the paper selection is shown in Figure 2.

Search Strategy

To develop an effective methodology, we followed the PICO method [25] and used DTU Findit, Google Scholar, IEEE Xplore, ACM Digital Library, and Scopus as our varied sources to minimise publication bias. For the PICO method, we established the PICO mapping in

Table 2. PICO classification and derived search terms.

PICO Component	Search Terms
Population	“honeypot”, “honeypots”
Intervention	“low-interaction”, “medium-interaction”
Comparison	“protocol”, “artifact”, “signature”, “trace”
Outcome	“fingerprinting”, “fingerprint”, “detection”, “detecting”, “evasion”, “anti-detection”, “counter-measures”

. Here, we formulated the Population, Intervention, Comparison, and Outcome criteria:

• Population: The papers ”application area” is honeypots.
• Intervention: The paper’s scope and focus narrow down to low and medium-interaction honeypots
• Comparison: The factors and variables being analysed in the paper include protocols used, honeypot artifacts, signatures, and network traces.
• Outcome: The outcome of the paper focuses on two different results, fingerprinting honeypots, and evasion/counter-measures to prevent being detected.

The search terms in Table 2 led to query

Table 3. Mapping of the systematic search query to PICO components.

PICO Component	Query Section	Rationale
Population	(“honeypot” OR “honeypots”) AND intitle:(“honeypot”)	The core subject of honeypots is present and central to the paper’s focus.
Intervention	(“low-interaction” OR “medium-interaction”)	Limits the scope specifically to the interaction levels defined in the Research Questions.
Comparison	(“protocol” OR “artifact” OR “signature” OR “trace”)	Ensures the paper discusses the technical evidence required to answer questions about vulnerability and techniques for fingerprinting.
Outcome	(“fingerprinting” OR “fingerprint” OR “detection” OR “detecting”) AND intitle:(“fingerprint” OR “detection” OR “fingerprinting”) AND (“evasion” OR “anti-detection” OR “counter-measures”)	Captures both the identification of the problem (detection) and the proposed solutions (evasion/prevention).

. The query sections in Table 3 are the combination of search terms from Table 2. The exact query sections defined in Table 3 are joined together with the term AND to form the final search term.

From this query, we found 123 papers from Google Scholar, 41 on ACM Digital Library, 34 on DTUFindit, 10 on IEEE Xplore, and 9 on Scopus. This gave a total of 180 unique papers.

3.4. Selection Criteria

This section shows the selection process for the literature used in this paper.

3.4.1. Initial Exclusion

The exclusion process began by removing papers that met any of the following criteria to keep the dataset manageable and focused on high-quality, peer-reviewed work.

• Studies not presented in English
• Studies that were not available through institutional resources were searched for using academic search engines and open-access sources. We excluded only the studies that did not meet our classification criteria.
• Studies that are duplicates of other studies
• Books and grey literature
• Studies presenting non-peer-reviewed material

Grey literature was defined as magazines, web articles, theses, technical reports, and preprints. However, select high-quality papers from established academic institutions are included to ensure that the most current technological developments in honeypot detection and anti-detection are represented. From these specifications, the initial set of papers was narrowed to 109.

3.4.2. Title/Abstract Exclusion

The next stage of exclusion involved reviewing the title and abstract. With the PICO in mind, we selected papers relevant to our research questions and included them if their titles suggested honeypots, detection, fingerprinting, probing, identification, emulation, deception, or interaction levels. We further excluded papers whose titles clearly indicated unrelated security domains, malware-only studies, IDS or monitoring without honeypots, or non-security topics.

The abstract was included if it explicitly discussed honeypot detectability or fingerprinting, mentioned attacker probing or scanning techniques, described protocol behaviour, artifacts, or configurations, or addressed mitigation or evasion of detection. The abstract was excluded if it mentioned honeypots only incidentally, used honeypots solely to collect attack data, or did not relate to any research question. If there was still ambiguity, the paper was temporarily included and sent for further in-depth screening. From this, the number of papers was narrowed down to 84.

3.4.3. Introduction/Conclusion Exclusion

Following the abstract screening, papers were further analysed for their introduction and conclusion sections. This removed ambiguous abstract reviews from the paper list that were not relevant. This section also served as a boundary between related work papers and papers for data extraction.

• The Introduction clearly articulates a problem statement related to honeypot detectability, fingerprinting, or evasion techniques, directly matching at least one Research Question.
• The Conclusion confirms that the paper delivers a specific contribution (e.g., a new fingerprinting method, a set of identified artifacts, or an evasion strategy) rather than purely theoretical discussions or general surveys without technical depth.

Papers that discussed honeypots in a different context, without technical contributions on identification, interaction, or countermeasures, were excluded here. This cut the number of papers down to 50.

3.4.4. Full Paper Exclusion

The final step involved a complete reading of the remaining papers. This step ensured that the selected papers provided sufficient technical detail to address the research questions. In this stage, papers were excluded if they met any of the following criteria.

• Insufficient Technical Detail: The paper discusses fingerprinting or evasion abstractly but fails to identify specific “traces,” “protocols,” or “artifacts” (Comparison) required for data extraction.
• Scope Mismatch (Intervention): The study focuses exclusively on high-interaction honeypots or physical hardware traps, which fall outside the “low-interaction” or “medium-interaction” scope defined in our Intervention criteria.
• Lack of Empirical Evidence: The paper proposes a solution or theory but provides no experimental validation, traces, or implementation details that would allow for the analysis of susceptibility artifacts.

After this filtering process, a final set of 35 papers was selected. This reading yielded an initial set of high-quality papers to review and use as tools for snowballing and quality assessment.

3.4.5. Backwards and Forward Snowballing

By snowballing both backwards and forwards from the 35 papers from the full-text review, 200 papers were found. After the full-text review, following the same procedure as for the initial papers, 29 remained in the new set. Only one round of backward and forward snowballing was necessary, as no new papers were found to consider; the later papers had already been found or were irrelevant. A total of 64 papers were used in the study for data analysis.

3.5. Quality Assessment and Data Extraction

Given the technical nature of our research questions (which require specific artifacts and traces), we conducted a quality assessment to verify that the selected papers went beyond theoretical discussion and provided empirical, reproducible evidence. We developed a quality checklist comprising two categories: General Quality Criteria, which assess the overall scientific credibility of the paper, and Research Question-Specific Criteria, which ensure that the paper contains the necessary data to answer our specific research questions.

3.5.1. General Quality Criteria

To assess the overall validity and credibility of the included studies, we applied the following general assessment questions to every paper:

• Aims and Context: Were the aims of the study clearly stated and relevant to the domain of honeypot security?
• Methodology: Was the research method clearly defined, credible, and appropriate?
• Data Collection: Was the data collection carried out well (e.g., scientific sampling vs. arbitrary selection)?
• Confounding Variables: Were confounding variables (e.g., background noise, network latency) adequately controlled for in the analysis?
• Peer Review: Was the study peer-reviewed?

3.5.2. Technical and Research Question Specific Criteria

In addition to the general quality criteria, specific technical criteria were defined based on this paper’s research questions. A paper was required to satisfy these criteria to be considered a high-quality contributor for that specific research question. The

Table 4. Technical quality assessment questions mapped to research questions.

Target RQ	Quality Assessment Question
RQ1	Q1: Was the configuration of the low- and medium-interaction honeypots clearly described?
	Q2: Were the environmental conditions consistent for the deployments mentioned?
RQ2	Q1: Was the identification of probing techniques based on analysing actual network traffic or log data (vs. theoretical models)?
	QA2: Is the sample size and data collection period clearly stated?
RQ3	Q1: Are the specific protocol artifacts (e.g., TCP timestamps, banner strings, error codes) explicitly listed and technically defined?
RQ4	Q1: Did the study provide measurable evidence (quantitative or qualitative) of the effectiveness of the proposed mitigation method?

presents technical quality assessment questions mapped to research questions.

3.5.3. Assessment Procedure

For each paper, the answers to these questions were recorded alongside the “Explanation” and “Location” (page/section) to ensure traceability. This process allowed us to distinguish between papers that merely mentioned a concept and those that provided the measurable “traces” and “artifacts” required for our data extraction. The papers were grouped into 3 categories according to how their findings addressed each quality assessment question. These sections were ”yes”, “partial”, and “no”. The “yes” papers were accepted if they answered the specific question sufficiently to yield meaningful conclusions. The “partial” papers briefly answered the questions or listed the answers only implicitly, which could be inferred. The “no” papers did not provide any meaningful conclusions for that quality assessment question. Only the papers that sufficiently answered the quality assessment questions were considered in the discussion of the research questions.

4. Framework for Low and Medium Honeypots

To answer the first research question, a table was compiled that aggregated data across the different honeypot deployments identified in this study. This table includes the fingerprinting techniques used on each deployment, the susceptibility artifacts, and the probing techniques. The different techniques and artifacts reported in all papers are described here. We categorize fingerprinting techniques with codes from T1 to T7 (see Figure 3), susceptibility artifacts with codes A1 to A8 (see Figure 4), and probing techniques with codes P1 to P7 (see Figure 5).

Using these codes, a detailed

Table 5. Fingerprinting techniques, susceptibility artifacts, and probing techniques in low, medium, and low-to-medium-interaction honeypots (research question 1).

Study	Honeypot Type	Interaction Level	Fingerprinting Technique (T1–T7)	Susceptible Artifact (A1–A8)	Probing Technique (P1–P7)
[20,27,28,29,30,31,32,33,34,35,36,37,38,39,40]	ICS/SCADA/OT Honeypots	Low(10), Low-Medium(5)	T5(12), T7(8), T1(6), T6(5), T4(4), T3(3), T2(1)	A7(8), A8(8), A1(6), A3(4), A4(3), A5(3), A6(3), A2(2)	P2(10), P1(8), P6(6), P5(3), P3(4), P7(4), P4(2)
[41,42,43,44,45,46,47,48]	IoT & Smart Devices	Low(4), Medium(5)	T1(6), T3(5), T2(4), T5(4), T4(3), T7(3), T6(2)	A7(7), A1(5), A4(4), A2(3), A5(3), A8(3), A6(1)	P2(6), P1(5), P6(4), P7(3), P5(2), P3(1), P4(1)
[49,50,51,52,53,54,55,56]	Shell & Admin (SSH/Telnet)	Low(3), Medium(6), Low-Medium(1)	T7(7), T2(6), T3(6), T5(6), T4(2), T1(1), T6(1)	A6(7), A8(6), A7(6), A4(5), A3(4), A2(3), A5(2), A1(1)	P2(8), P7(5), P1(4), P3(4), P5(4), P4(2), P6(1)
[3,24,57]	Web & Apps	Low(2), Medium(1), Low-Medium(1)	T1(2), T2(2), T3(2), T5(2), T7(2)	A7(3), A3(2), A4(2), A8(2), A1(1), A2(1), A6(1)	P2(3), P3(2), P5(2), P1(1), P7(1)
[10,58,59,60,61,62,63,64,65]	AI & Dynamic	Low(5), Medium(4)	T3(5), T5(5), T1(3), T7(4), T4(2)	A4(5), A8(5), A6(2), A1(4), A3(2), A5(2), A7(1)	P2(7), P1(2), P6(2), P7(2), P5(3), P3(2)
[4,66,67,68,69,70,71,72,73,74,75]	Network & Virtualisation	Low(11), Medium(1), Low-Medium(1)	T5(10), T4(8), T7(6), T2(5), T3(3), T1(2), T6(1)	A5(8), A8(6), A4(5), A7(5), A2(4), A3(4), A6(7), A1(2)	P4(8), P2(7), P5(6), P1(4), P3(3), P6(4), P7(3)
[23,64,76,77,78,79]	Hybrid Architechture	Low(3), Medium(3)	T5(3), T2(2), T4(3), T7(2),T1(1)	A7(3), A8(3), A3(2), A5(2), A1(1), A2(1)	P1(2), P7(2), P5(1), P6(1)
[80,81,82,83]	Specialised/Niche	Low(2), Medium(2)	T3(3), T5(3), T7(3)	A4(4), A7(2), A5(1), A8(2)	P2(4), P5(3), P7(1)

was created.

4.1. ICS/SCADA/OT Honeypots

In the OT space, Table 5 shows that many fingerprinting techniques rely heavily on targeted banner-grabbing (T1) and implementation-specific checks (T5). The most common artifacts are default configurations (A7).

The study by [40] states, for example, that although it is a hybrid implementation, it still proves that implementation-specific fingerprinting techniques are prevalent, as attackers are fingerprinting by resource exhaustion, where using a low-interaction honeypot as a proxy can hide the limitations of the implementations of the higher-interaction deployments in the backend.

The authors of [39] note that using the default banners for Conpot and not creating custom CIP identity attributes such as Vendor ID, Device Type, etc., can serve as a banner and help identify honeypots, especially since Conpot uses default static artifacts. Ref. [36] further reinforces the idea that low-interaction ICS system deployments struggle to enable realistic, dynamic, complex systems by contrasting the static nature of Conpot with the dynamic HosTaGe honeypot. Ref. [20] also demonstrates that OS leakage can occur through hidden ports left open (e.g., port 514 for Syslog in Linux).

Similarly, the authors in [38] describe how the implementation of honeypots and network topology can affect traffic; as shown in the data, Corporate Networks received 91% more S7Comm traffic than Cloud. On the other hand, they also showed that Cloud-based honeypots exhibited an advantage, with a 45% increase in HTTP traffic compared to Corporate, demonstrating that setting and placement are critical. Reference [37] follows the same idea in terms of topology, but for smart grids. The complexity in the deployment can help mask the suspiciousness of the honeypot’s vulnerability.

4.2. IoT and Honeypots

This section is focused mainly on command handling (T3) and banners (T1). Artifacts are often device-specific (A7, A1).

Reference [48] states that in IoT deception, botnets are a major problem and can attack a system by overwhelming it and observing its response. Therefore, they propose integrating a hybrid approach into IoT honeypots to mitigate the fingerprinting via limited negotiation. Following the theme of botnets, the authors of [46] note that botnets scan the Telnet banner and login prompt before deciding which malware to download onto IoT devices. They report how many different attackers attempt to run various binaries on different architectures to verify that they are truly using that system and architecture. Here, static banners, default configurations, and limited negotiation are again major issues.

Moreover, papers such as [44] rely on static emulation of CPE devices, which is a clear problem in the IoT space. Ref. [45] proposes scanning real-life IoT devices and taking their replies to replace honeypots. This copying of the banner and its metadata demonstrates that banner fingerprinting is easily mitigated.

4.3. Shell and Admin

This is the most intensely fingerprinted group for handshakes and state machines. The authors of [49] discuss how SSH and Telnet honeypots are detected using handshake and protocol-negotiation techniques. They observe this from deviations in the SSH version string, such as in SSH2$\_MSG$_KEXINIT packets and Telnet negotiation requests. The authors in [52] report that the Cowrie honeypot is fingerprinted due to its default administrative behaviour. In Reference [56], Cowrie is described as an interactive shell-based honeypot, and the authors argue that inconsistent state changes enable attackers to determine whether a system is real or fake.

4.4. Web and Apps

From Table 5, it is clear that the sample size is smaller than most, but the techniques and artifacts are evenly distributed across banner, handshake, and state issues. Reference [24] clearly shows how, in some web-based deployments, attackers exploit specific URL endpoints by checking whether they return the correct JSON structure. If the honeypots do not return the correct structure, they are classified as honeypots. Similarly, banner metadata was analysed using Shodan to demonstrate that the static banners are well-known. In this paper, Delilah was also not identified and was presumed to be so by the authors due to the more pronounced artifacts it exhibited.

4.5. AI and Dynamic Honeypots

AI has become a major and impactful tool for honeypot fingerprinting and evasion, but, in line with this paper’s findings, AI dynamic honeypots rely heavily on Command/State (T3) analysis. Interestingly, these sophisticated honeypots are most affected by Incomplete State Machines (A4) and behavioural Inconsistencies (A8), as the AI generates unusual responses.

For example, in Reference [63], they try to combat the incomplete state machine problem of a limited training set by using LLMs (GPT 3.5) instead of training on data. Here, the simulation was compared with Cowrie, which does not support edge-case requests, whereas the LLM can hallucinate a response. Therefore, the LLM will need more robust probing than simply checking whether it matches the Cowrie response to determine that it is a honeypot. Due to the LLM hallucinating, behavioural consistency is, of course, an issue for this type of implementation. Similarly, both papers [60,62] are honeypots that use training sets to learn a response. In reference [62], the authors compare against IoTCandyJar and FirmPot, and it is an adaptive learning honeypot that suffers from issues with HTTP logic in remembering its previous states. To address consistency, [61] proposed using Seq2Seq to maintain semantic and state consistency and found that it achieved an accuracy of 89.7%.

Ref. [59] flips the script to identify fingerprinting attacks using AI. This paper showed how this leads to successful attack recognition and then passes the attacker to a more focused, higher-interaction honeypot that can take over the attack and gain valuable information.

In another light, Ref. [64] uses AI to fingerprint honeypots using machine learning classification models by feeding data into a Random Forest model that comes from all the various interactions and probing from banners, hardware (MAC address), TCP/IP stack behaviours, TTL value, etc. This data is used by the model to estimate the likelihood of the device being a honeypot. This further shows that machine learning can be used to develop rigorous detection techniques that leverage many modern fingerprinting methods.

To address Telnet banner and state machine checks in the IoT space, Ref. [58] proposes IoTCandyJar, which operates at the application layer and uses learning algorithms to move beyond static scripts. They validated this by showing that the system can capture exploit code that attackers would otherwise withhold if they detected a fake device, further indicating that static honeypots are among the biggest problems for modern-day low-interaction honeypots.

4.6. Network and Virtualisation

From Table 5, this section is the clear leader in Timing and Latency (T4) issues. Virtualisation artifacts (A5) are also the dominant vulnerability in this context.

To continue along the static banners, Ref. [68] explores Nmap and Xprobe fingerprints by testing for predictable TCP ISNs, TCP port tests, and ICMP response packets, highlighting the areas most needing improvement.

Ref. [69] is an example of timing and latency issues in which an attacker can use ICMP latency to measure packet round-trip times and distinguish real networks from simulations. This paper specifically tests on Honeyd and shows that simulating routing and topology on a single device creates a timing artifact. It suggests that Honeyd should include a timing delay to simulate real-world traffic.

4.7. Hybrid Architecture

Overall, from our findings, hybrid architectures have been found to be susceptible to artifacts arising from the seam between the front-end and back-end. Papers such as [78] note that the number of connections that different levels of interaction can have varies, with lower levels typically having more. Ref. [78] also shows that sending packets from the low-interaction to the high-interaction regime for further inspection can introduce timing-fingerprinting issues that the system must account for. This shows that service availability is a key factor in creating an efficient hybrid honeypot setup to minimise detectability.

Ref. [79] is, however, different from the rest, as it was the only paper to propose making a real system look more like a honeypot by adopting the common fingerprinting technique of T1 and T4 by the system to encourage wrongful identification through multi-stage fingerprinting. This further highlighted that fingerprinting can be flipped to keep attackers away by mitigating behavioural probing in networks.

4.8. Specialised/Niche

This m = categoty mostly includes T3 and T7, often looking for deep system inconsistencies (A4).

In [83], the fingerprinting technique of host inspection was presented by checking processes that were running or specific file paths to reveal the honeypot’s implementation. In this paper, they also compare how attackers can exploit kernel discrepancies between what the user sees and what is in memory to detect the presence of a honeypot. It is here that honeypots are suggested to use specific system calls to hide the honeypot’s own processes from the attacker. It proposes that hiding these discrepancies can help prevent incomplete state machines in honeypots.

Ref. [82] focuses on file system implementation and highlights that file counts, directory depths, etc., are common ways for attackers to identify low-interaction honeypots, as they are not overly complex. The paper also notes that file system metadata should be aligned with the server’s time to ensure consistency and prevent timing anomalies. Files and signatures, such as sebek.exe, are also hidden from the attacker to prevent fingerprinting.

Interestingly, [81] focuses on botnets and how they can trust devices to be part of their networks. The paper presents the fact that if the botnet does not send out any malicious packets to its secret node, then it cannot trust it, but mitigating this goes against ethical responsibility, so it is not explored further.

To add onto the static nature of the ICS-honeypots, like Conpot and ICSPot, ref. [80] presents a honeypot identification tool that exposes the weaknesses in these deployments. It does this by generating automated network request messages and analysing the traffic (responses) to extract memory features from the honeypots. This tool also probes the control logic blocks to verify the PLC’s internal state and determine whether the memory block exists. This memory testing is shown to be a failure mode these low-interaction honeypots share due to their simplicity and lack of full emulation.

4.9. Summary

To summarise and address the first research question, the literature suggests that fingerprinting techniques and susceptibility artifacts scale in complexity alongside the honeypot’s interaction level. Low-interaction deployments (e.g., ICS/OT) are primarily identified through surface-level artifacts such as static banners (A1) and default configurations (A7), using basic active probing (P1). In contrast, medium-interaction systems (e.g., SSH/Telnet shells) shift the vulnerability to protocol and behavioural artifacts, where attackers exploit incomplete state machines (A4) and implementation-specific handshake deviations (T2) through malformed or fuzzing-based probing (P3). Low-medium (Hybrid) and AI-driven honing systems introduce unique behavioural consistency artifacts (A8); while they mitigate static detection, they often fail to maintain long-term state or timing realism (A5) across the “seam” between front-end proxies and back-end execution, which is increasingly detected via longitudinal and differential probing.

5. Probing Techniques

From

Table 6. Table describing the predominant probing techniques used to identify low-, medium- and low-medium-interaction honeypots in current literature.

Probing Technique	P-Code	Description	Strength	Count	Papers
Active multi-stage probing	P2	The attacker performs multiple probing technique in many phases, such as before and after exploitation to compare the difference in the system	High	46	[3,4,10,24,27,28,29,30,31,32,33,34,36,39,41,42,43,45,46,47,49,50,51,52,53,54,55,56,57,58,60,61,62,63,64,65,66,67,71,73,74,80,81,82,83,84]
Active single-stage probing	P1	The attacker performs a one-time probing technique to collect immediate responses such as banners, open ports, or protocol metadata.	Medium	28	[20,24,29,33,35,36,37,38,39,40,43,44,45,47,48,49,52,54,55,59,64,71,72,74,75,77,78,84]
Differential probing	P5	The attacker compares responses from the same target system under different conditions.	Medium	26	[10,24,28,29,33,38,41,44,49,50,53,54,57,63,64,65,66,67,69,73,74,79,80,82,83,84]
Longitudinal/behavioural probing	P7	The attacker observes the target machine over a long period to analyse behavioural consistency and compare the historical state with the current state.	Low	21	[3,27,28,30,32,41,43,47,52,53,54,55,56,58,65,67,70,71,77,79,81]
Cross-protocol/multi-service probing	P6	The attacker probes multiple protocols or services on the same host to compare their responses.	Low	19	[20,29,30,32,33,37,40,43,45,47,48,49,59,64,68,74,75,78]
Malformed/fuzzing-based probing	P3	The attacker sends malformed, or protocol-violating packets. This is intended to trigger abnormal parsing or error-handling behaviour.	Low	15	[3,4,10,31,34,35,46,49,50,51,53,57,65,68,71]
Timing-based probing	P4	The attacker measures response delays or processing latency by making repeated and controlled requests.	Low	13	[4,28,29,41,51,56,64,66,67,68,69,70,72]

, we extracted information to answer our research question 2. Here, we present the most predominant probing techniques discussed across the literature.

5.1. Active Multi-Stage Probing-P2

This is the top-most predominant probing technique we observed. References [3,31,50,64,66] have shown sequential probing steps to detect low-to-medium interactive level honeypots. For example, the authors in [3] introduced a pipeline comprising seven probe-based fingerprinting techniques. In Reference [50], the authors establish four connections per target host using unique packet sets. They present this technique as a stage-wise approach to improve its reliability in the presence of unknown implementations. Reference [64] split its probing technique into three feature groups: application, network, and system-layer. In references [31,66], the authors used multi-stage probing techniques and different types of connections, including regular service requests, probe requests, and attack service requests.

Several other studies [28,41] also defined their detection frameworks with several stages/heuristics. They then correlate the results across the different probes and classify the system as a honeypot if all probes are positive. This also reduces the risk of false positives. Reference [67] also splits probing into pre- and post-exploitation stages. Similarly, the authors in [4] apply different OS fingerprinting probes to the same target. In reference [29], the authors also used multiple probing tools.

Further studies [34,51] confirm the dominance of active multi-stage probing. For example, in reference [42], probing occurs across multiple interaction phases. In reference [30], they show two stages, in which the second connection stage depends on the outcome of the first stage.

Other research shows filtering and classification. In reference [32], the authors only analyse those hosts that successfully complete an application-layer handshake. They then combine multiple signatures and assign confidence levels to each. As for [51], they used a detection model to detect honeypots after they narrowed down the suspected honeypots and normal hosts using the random Forest algorithm. References [10,27,53,56,65,73] also show sequences of probes based on previous responses. For example, in Reference [53], the authors demonstrate this using multi-stage probing. First, they scan SSH services to identify honeypots, then they log in to execute commands to extract additional fingerprinting information.

5.2. Active Single-Stage Probing-P1

This is the second most frequently discussed probing technique in the current literature for detecting low-to-medium-interaction honeypots.

Reference [49] demonstrates that even sending just a single carefully crafted packet can easily fingerprint the honeypot. In their conclusion, they state that even a single or two packets are sufficient, and that the attacker leaves only minimal forensic traces. In reference [29], they showed the same principle using Nmap scans. A single scan can reveal the differences between the real PLCs and honeypot deployments. In another study [43], non-recurring port scans are also observed, as the attacker performs only a single-stage probe.

In Ref. [71], the authors also demonstrated using a single request packet. This also makes the approach suitable for detection with high-speed scanners such as ZMap. In [33], the IPv4 Internet was scanned using ZMap. Then, a set of requests is sent to industrial protocols such as Modbus and S7comm. Afterwards, TTL values can be used to reveal the real system. In another study [77], the authors showed that a single SSH connection can collect a HASSH fingerprint. One SSH login attempt (username and password) can also be considered a single probe and then can be used for further analysis [52].

Another technique attackers use is to send a single RTSP request to an invalid URL. They do this to check how the service responds [47]. In Ref. [72], scanners send requests for one service feature at a time and also send ICMP ping requests to measure response time.

In Ref. [74], Nmap is used to detect which network services are running, and the system is then fingerprinted from the initial response. The authors in [54] show that attackers can use a single Linux command to determine whether a system is real or a Cowrie honeypot. Regarding command-based attacks, ref. [55] reported that attackers connect to the system using only commands such as echo and then disconnect. Once they detect the honeypot, they terminate the session; therefore, the sessions in this case are quite short. The authors in [35] show how scanners send a single Modbus request to acquire the firmware information. They also presented scan samples suspected of being generated by the Shodan tool. Attackers also perform random scans to connect to many IP addresses. In Ref. [75], the authors presented in their results how they observed that the computer with the IP address of 192.168.196.225 attempted to connect to a honeyd instance with IP 192.168.196.123 on ports 135, 139, and 445.

5.3. Differential Probing-P5

This probing technique was identified as the third most predominant in our research. Many studies presented with comparative probing to compare honeypots with responses from an alternative deployment. In Ref. [50], they proposed an approach called differential fuzzing to compare protocol responses using similarity metrics. The differences can reveal the honeypot. In Ref. [29], the authors run their tools on both the obfuscated PLC and the non-obfuscated PLC IP addresses. The authors of Ref. [57] select probes that consistently trigger differential responses and then analyze similarity in content, which helps them to distinguish honeypots from real systems.

5.4. Malformed/Fuzzing-Based Probing-P3

This probing technique was identified and studied across 15 papers in our report. Ref. [71] states that malformed protocols can expose honeypots’ implementation weaknesses. The authors demonstrate that invalid SSH negotiations can trigger unique error messages that can indicate that the system is a honeypot. In another study [4], attackers examine the TCP rules in the response by sending abnormal TCP packets, like FIN or FIN/SYN packets. In Ref. [10], they mention that in NULL scanning, honeypots do not respond correctly, which makes them easier to detect.

5.5. Timing-Based Probing-P4

Timing-based probing is the lowest on our list of probing techniques in Table 6, mentioned in only 13 papers. We assume this is because it relies on many external factors, such as network latency, routing paths, and background overload, making it not the most reliable way to detect honeypots. As presented in References [29,72], a controlled experimental setup is required to perform time measurements. Noise is a major factor in the real world that can influence these measurements. In another study [56], timing responses are observed to determine whether a user is a bot or a human. Therefore, artificial delays are introduced as a defensive adaptation to make the system look more realistic.

5.6. Cross-Protocol/Multi-Service Probing-P6

Many studies have discussed cross-protocol/multi-service probing as a common technique for detecting honeypots. In Ref. [74], the authors describe the collection of Layer 4 and Layer 7 information from each network service. This is an example of how attackers compare protocol behaviour, and application versions, etc. In another study [75], they also show different numbers of RPC, MS-SQL, and DNS probes. Another study [47] defines a multistage attack as a sequence of attacks targeting the same IP address. They also present this information in an image showing how the same IP targets multiple protocols.

5.7. Longitudinal/Behavioural Probing-P7

This is a type of probing attack in which honeypots are monitored over a long period to detect behavioural differences. In [55], for data collection, the authors deployed a honeypot on the university network and observed attackers’ behaviour from 2018 to 2021. This way, they were able to study attacker recurring behaviour and session correlation. In another study [52], the authors presented data capturing millions of attacks over weeks to evaluate them later. A similar study [77] discussed the same way of collection data using Cowrie.

5.8. Summary

To summarise and address research question 2, the literature identifies active multi-stage probing as the most predominant and effective technique for identifying honeypots, regardless of interaction level. This method employs sequential phases of pre- and post-exploitation behaviours to correlate responses and more effectively identify honeypots. Single-stage probing remains frequent due to its simplicity and effectiveness for high-speed scanning. While fuzzing and time-based probing provide valuable insights, they are underutilised due to the high noise and complexity involved in their execution.

6. Protocol Artifacts

This section discusses the specific protocol artifacts that are most vulnerable to detection in low-, medium-, and low-medium-interaction honeypots.

6.1. Static Banners

This artifact has been reported across many studies, making it the most vulnerable protocol artifact to detect in low- or medium-interaction-level honeypots. Study [3] states: ”Honeypot implementations offer a limited set of banners or even static banners”. They further emphasise that this limited set of banners is easy for attackers to detect, making it the most vulnerable artifact. These static banners are typically included in the honeypot’s default configuration. The authors of [33] discuss banner-grabbing for fingerprinting honeypots. They explicitly called static banners ”universal identification metrics”. In Ref. [42], the authors note that default static values for SSL/TLS certificates and HTTP responses can make honeypot instances easier to detect. They demonstrate this with an experiment, showing that attackers can easily detect the honeypot using only the banner metadata or a string. A total of 21 studies in our research discussed the limitations of static banners, as presented in

Table 7. The predominant protocol artifacts that are most vulnerable to detection in low-, medium-, and low-medium-interaction honeypots.

Protocol Artifact	A-Code	Description	Strength	Count	Papers
Static banners	A1	Fixed service strings, version numbers or metadata that do not change across sessions.	High	22	[3,20,29,30,32,33,36,39,42,43,44,45,46,51,58,59,61,64,71,74,79,84]
Error messages	A6	Non-standard or too generic error responses	Medium	17	[3,28,31,34,41,49,50,51,52,53,54,55,58,68,71,73,74]
Malformed packet handling	A3	Abnormal handling of invalid or malformed protocol packets.	Medium	16	[3,4,10,23,31,34,35,49,50,51,53,57,65,68,71,76]
Limited negotiation	A2	Incomplete or simplified protocol negotiation	Low	14	[3,38,40,41,46,48,49,50,52,64,68,71,74,78]

.

6.2. Limited Negotiation

The limited protocol negotiation was mentioned in 13 studies. We will present a few of the examples from the studies and show how they discuss this as one of the most vulnerable protocol artifacts. In Ref. [71], the authors note that Telnet sends negotiation option data that reveals the service before the actual banner is sent. In a separate study [41], the authors discuss how attackers exploit SSH version negotiation behaviour and authentication to detect honeypot services. Having default OpenSSH versions or default passwords can be a sign that the system is not a real OS. Therefore, it is important to handle negotiations appropriately. Ref. [74] also discusses how incomplete HTTP method negotiation, such as the absence of ‘POST’, ‘PATCH’, ‘DELETE’, etc., can be a sign of a honeypot.

6.3. Malformed Packet Handling

A total of 16 studies from this paper, and active fingerprinting tools such as Nmap and Xprobe, show how to exploit malformed packet artifacts by sending non-standard packets (e.g., illegal TCP flags or invalid checksums) to trigger OS-specific error responses. Ref. [68] (Honeyd) mitigates this by implementing a personality engine that simulates the TCP/IP stack in user space and intercepts and modifies outgoing packets to mimic the specific quirks of a target OS (e.g., Windows XP) rather than those of the host machine. This allows the honeypot to pass fingerprinting tests by generating valid TCP Initial Sequence Numbers (ISNs) and precise ICMP error messages for closed ports. However, this solution is limited to TCP, UDP, and ICMP. Packets from other protocols are simply discarded, which can itself serve as an identifiable artifact if the emulated OS would normally respond.

6.4. Error Messages

This is one of the most vulnerable protocol artifacts we studied across different papers. In Ref. [28], the authors study ICS honeypot detections. For example, honeypots such as GasPot return nonstandard error codes in response to function requests. It returns 9999FF1B for sensor status commands, whereas real systems do not exhibit the same behaviour and implement more appropriate error handling to remain protocol-compliant. Missing or incomplete protocol implementations can be a sign of a honeypot. Another example is the difference between industrial CPS honeypots and industrial CPS devices and how they implement error handling [34]. Through experiments, they showed that when malformed probing techniques are used, abnormal error code 03 packets reveal the presence of the honeypot. Furthermore, Ref. [73] examines HTTP status codes produced by honeypot emulators. A real server would return a proper server-side failure error, whereas a honeypot may return overly generic error codes. This inconsistency also exposes the honeypot.

6.5. Summary

To summarise and address research question 3, the literature identifies static banners as the most prevalent and vulnerable artifact at these interaction levels. It is consistently labelled an identification metric. Error messages and malformed packet handling also play into the static limitations of these honeypots, being a considerable portion of identifiable artifacts as well. Overall, the static nature of the simpler deployments is their downfall.

7. Mitigation Plans

This section examines which strategic and operational methods are most effective for preventing low-, medium-, and low-medium-interaction honeypot deployments from being identified. Some limitations are also noted alongside the validated methods.

Table 8. Mitigation methods are designed to prevent honeypots from being identified. The validated methods are summarised in the table for each susceptible artifact, whereas other methods are proposed only in the reviewed studies.

Susceptible Artifact	A-Code	Validated	Mitigation Method
Static banners	A1	[29,42,58,74]	Banner normalization [3,30,32,33,38,51,58,71,74], Controlled banner exposure [29], GAN-based dynamic response generation [42]
Limited negotiation	A2	[40,45,74]	Real protocol implementation [49], Full protocol negotiation emulation [3,45,50], Protocol negotiation completion and tuning [74], hybrid implementations [40,48,78]
Malformed packet handling	A3	[23,31,65,74,76]	Strict protocol parsing and validation [3,49,51,53], Fuzzing-based robustness testing and detection [31,50,65], TCP sequence and acknowledgment synchronization [23,76]
Incomplete state machine	A4	[24,28,54,55,56,66]	Real backend execution and command proxying [54,55], Service probe redirection [66], Full state-machine and command emulation [3,24,28,41,51,74], Fuzzing-based fingerprint detection [10], Adaptive command-response emulation [56]
Timing anomalies	A5	[23,28,29,56,65,66,67,76]	Traffic redirection and path masking [23,29,66,67], Response timing randomization and normalization [28,51,56], Realistic transport and protocol timing emulation [76], Adaptive fingerprint detection [10,65]
Error responses	A6	[28,31,54,55,74]	Error message normalization and alignment [3,28,49,50,53,54,71,74], Error suppression and response substitution [41,51,55], Fuzzing-based error fingerprint detection [31]
Default configuration	A7	[28,29,42,55,74,77]	Configuration randomization and diversification [28,30,50,53,55,74], Configuration hardening and default sanitization [3,32,41,51,71], Unique keys and certificates per deployment [49], behavioural and traffic realism alignment [29,33,42], Traffic routing by fingerprint [77]
Behavioural consistency	A8	[23,27,28,29,31,54,55,65,66,67,76,77]	Maintenance and exposure management [27,32,49,53], State preservation and context unification [41,67,77], Behavioural variability and decoy diversity [3,23,28,30,31,33,70,71], Traffic shaping and interaction balancing [29,66,76], Adaptive and learning-based behavioural control [10,54,55,65], Traffic redirection [75]

represents the mitigation methods.

7.1. Configuration and Surface Randomisation

This subsection examines research on making honeypots harder to detect by modifying visible system settings and increasing the variety of exposed features.

7.1.1. Banner Normalization

Most studies addressing static banner artifacts (A1) propose Banner normalization as a mitigation method. These studies [3,30,32,33,51,74] argue that default service banners enable honeypot identification through banner grabbing and response comparison. For example, ref. [74] suggests that modifying the default File Transfer Protocol (FTP) banner can reduce the effectiveness of honeypot fingerprinting. Many studies extend the banner randomisation to include HTTP headers and application-layer response content [33,38,58,71] to ensure consistency across services. Overall, banner normalisation is presented as an operational mitigation for banner-based honeypot identification. However, these proposals have some limitations; for example, as noted in Ref. [58], the training data is incomplete and noisy.

7.1.2. Controlled Banner Exposure

The authors of [29] propose a new strategic obfuscation technique that exposes default honeypot banners in front of a real Programmable Logic Controller (PLC). This makes the PLC appear to be a honeypot. All communication, except for industrial control port traffic, is sent to the honeypot; however, from the attackers’ perspective, they believe they are interacting with the honeypot. Consequently, attackers often stop probing at this point. The authors had experts evaluate the system, who observed the exposed banners and ceased interaction, thereby demonstrating that this method prevents attackers from further investigation. They did mention that highly sophisticated attackers might still be able to bypass with advanced analysis. Therefore, this paper classifies this mitigation as controlled banner exposure. This can also be referred to as a reverse deception model, in which the authors presented themselves to make the real system appear as a honeypot. An example of this is also seen in [79].

7.1.3. Configuration Randomization and Diversification

Modifying static, predictable system defaults to more deployment-specific values is presented as an operational countermeasure in the current literature [28,50,53]. In [30], while no countermeasure is implemented, the authors identify default Siemens S7 configuration values to be reused across honeypots as a susceptible artifact. Only a few studies [55,74] have empirically demonstrated effectiveness, such as replacing default identifiers with realistic values to lower the honeypot detection probability. Some limitations were also mentioned. The authors of [74] mentioned their mitigation is limited to OSI layers 3, 4, and 7. The authors of [53] clearly quoted that “We find that honeypot operators seldom change default configuration options.”

7.1.4. Behavioural Variability and Decoy Diversity

Across the reviewed studies, this mitigation method is addressed at different levels of validation. In [31], behavioural consistency is only observed in repeated probes to detect Modbus fuzzy testing, but the paper does not provide specific countermeasures. In contrast, Ref. [70] suggests a strategic deployment concept, proposing heterogeneous decoy systems, for example, running a few virtual machines alongside a low-interaction honeypot. This generates false positive responses and increases behavioural variability, thereby reducing fingerprinting. Still, this approach can be vulnerable to fingerprinting and may lead to excessive resource use or make scaling more difficult, especially in virtualised environments. The most comprehensive study of this mitigation method is presented in [23]. The authors propose dynamically reconfiguring the decoy’s fingerprints and the honeynet topology. Their experiments showed that this reduces detectability, as attackers perceive more stable, repetitive behaviours.

7.2. Traffic Redirection and Network-Level Masking

This subsection reviews mitigation approaches that reduce detectability by manipulating network-level interactions.

7.2.1. Real Backend Execution and Command Proxying

Real backend execution and command proxying forwards attacker commands to a real OpenSSH/Linux backend. Using a real system on the backend prevents the honeypot from being exposed, since the attacker receives a complete command response. Experiments from different studies [54,55] have proved its effectiveness through testing.

7.2.2. Service Probe Redirection

Another study [66] provided a similar operational strategy by sending probes to a real system, thus preventing the exposure of the honeypot’s partial protocol implementation.

7.2.3. Traffic Redirection and Path Masking

Traffic redirection and path masking involves masking routing paths and processing differences that reveal honeypots when forwarding attacker traffic to real backend systems [23,29,66,67]. Techniques such as TTL masquerading and Layer-2 redirection ensure that probes experience realistic delays. In [67], the authors implemented the HoneyPortal system as a strategic mitigation against NC3-based timing detection. HoneyPortal presents the front-end and back-end as a single system. Their experimental evaluation showed that timing measurements remain consistent before and after exploitation. However, this approach introduces additional latency and requires a complex deployment that involves traffic-redirection infrastructure.

7.2.4. Unique Keys and Certificates per Deployment

In [49], the authors suggest having unique keys and certificates per deployment. This is an implicit mitigation. The paper highlights that many honeypots share default configurations, such as reused SSH host keys or co-located deployments. Thus, enforcing keys/certificates and isolated deployment can help mitigate detection. However, their mitigation suggestion is limited as it does not address deeper protocol-level inconsistencies that enable fingerprinting.

7.2.5. Traffic Shaping and Interaction Balancing

Research in [76] proposes an operational mitigation method based on long-term behavioural consistency. The authors introduced an SDN-based controller and demonstrated how distributing packet processing evenly over time reduces behavioural fingerprints. This masks the honeypot’s artificial behaviour, namely its repetitive packet I/O patterns.

7.3. Timing and Response Normalization

This subsection examines methods to improve stealth by making timing behaviour more normal and adjusting protocol responses to better match real-world systems.

7.3.1. TCP Sequence and Acknowledgement Synchronisation

Two studies [23,76] proposed operationally validated mitigation methods. Both studies used a hybrid honeypot system in which traffic is redirected from a low- or medium-interaction front-end to a high-interaction backend. The TCP mechanism has two sequence numbers (Seq) generated by the source and destination endpoints. When forwarding a TCP connection, both sequence numbers must be synchronised. In [76], the authors proposed an SDN-controlled forwarding mechanism that was shown to be highly stealthy while preserving protocol consistency. Similarly, ref. [23] validated this by synchronising Sequence (Seq) and Acknowledgment (Ack) values. However, the authors in [23] noted that this approach introduces additional latency overhead and requires a complex SDN-based deployment with customised components.

7.3.2. Error Message Normalization and Alignment

This mitigation method is consistent across many studies [3,28,49,50,53,54,71,74]. One method, introduced but not validated in [71], is to patch the honeypot source code so that it matches real SSH implementations, eliminating inconsistent error-message signatures. Another paper [74] suggested replacing unrealistic error messages, for example, changing a static PHP warning to a generic “Permission Denied” response. In [53], the authors point out a key weakness: Python-based SSH honeypots handle protocol errors differently from real systems. They argue that this difference renders the architecture flawed due to built-in implementation gaps. In [54], the authors implement error message normalisation within a medium-interaction honeypot architecture. They noted that Cowrie often returns a zero exit status, which indicates abnormal behaviour. The author implements controlled, normalised error responses via a proxy-based design, enabling the proxy to send standard, realistic error messages (e.g., “command not found”). The effectiveness of this mitigation is supported by long-term deployment results. They also identified weaknesses in the Asgard system. For example, blocking behaviour made it harder to detect complex attacks, and the proxy struggled to handle complex commands.

7.3.3. Error Suppression and Response Substitution

Another mitigation technique found in many papers [41,51,55] targets error-based fingerprinting. Explicit protocol error responses can be used to exploit SSH honeypots [51]. Another study [55] proposed a mitigation system implementing proxy-based response substitution. This maintained realistic interactions and reduced detectability in real deployments. Still, the system had some limitations. For example, its proxy-based design may fail to capture complex or hidden commands.

7.3.4. Traffic Routing by Fingerprint

In [77], the authors presented a hybrid honeypot that manages attacker traffic among low-, medium-, and high-interaction honeypots. The traffic direction depends on the attacker characteristics, such as botnet-originated patterns. Traffic is dynamically routed, sending selected connections to high-interaction honeypots. This adaptive traffic management approach at the network level mitigates honeypot detection. However, this approach can complicate deployment because it relies on multiple components. Additionally, the evaluation may be biased because the experimental setup remains evident.

7.4. Protocol and State-Machine Completeness

7.4.1. Full Protocol Negotiation Emulation

Some studies did not implement mitigation methods but provided similar suggestions for reducing fingerprinting detection. In [50], the authors suggested a strategic mitigation for implementers. They advised employing differential fuzzing and their fingerprinting methods to narrow the gap between the real protocol implementation and the honeypot. This can be considered a full protocol-negotiation emulation; during the protocol handshake and negotiation phase, the attacker cannot distinguish between the honeypot and the real system. However, this mitigation lacks experimental validation and may be constrained by the inherent challenges of accurately replicating complex protocols and TLS behaviours. Strategic countermeasures in [3] also suggest increasing the depth of protocol emulation. Hakim et al. [45] validated a technique with an emulated device that mimicked real IoT devices and how it deceives vendor applications and external systems. It has some limitations, including the fact that an attacker can exploit the response time to detect a real honeypot. Session time and data capture performance were left as future work.

7.4.2. Protocol Negotiation Completion and Tuning

In [74], the authors demonstrated a strategic protocol negotiation completion and tuning method by recreating HTTP protocol behaviour similar to that of a real Apache server, thereby reducing detectability through inconsistencies in protocol negotiation.

7.4.3. Strict Protocol Parsing and Validation

Implementing strict protocol parsing and validation, as stated in some findings [3,51,53], can reduce the detectability of honeypots. This is motivated by the fact that if a honeypot accepts malformed protocol inputs such as incorrect SSH version tags, protocol errors, or corrupted responses, it contributes to honeypot detectability.

7.4.4. Fuzzing-Based Robustness Testing and Detection

This mitigation is proposed by several studies. It provides a mechanism to identify malformed and anomalous probing behaviour typical of fuzzing attacks [31,50,65]. In [31], Modbus fuzz-testing behaviour is identified through operational methods such as fuzzing-based testing. In [65], the authors applied a strategic method called Dynamic Fuzzy Rule Interpolation (D-FRI), which can detect fingerprinting attacks caused by fuzzing-style malformed and abnormal packets. Based on their experimental testing, they concluded that the overall detection sensitivity of D-FRI-Honeypot using D-FRI is 85.6%, with a prediction accuracy of 79.88%. They also identified several limitations, including that they may not know how it will perform on untested tools or when handling unknown attacks. They also focused solely on the core protocols TCP, UDP, and ICMP, without considering protocols such as HTTP, FTP, SMTP, or SNMP.

7.4.5. Full State-Machine and Command Emulation

Many studies [3,28,41,51,74] discuss this mitigation, where the services are implemented with complete protocol logic and realistic state transitions rather than default or partial settings. For example, in [28], the authors implemented an ATG honeypot by reading through the manual for Veeder-Root ATG devices. Their honeypot provided full protocol support, with 113 commands, whereas GasPot supported only 5. This strategic method can reduce the honeypot’s fingerprint to some extent. However, they claimed not to be fully resilient to fingerprinting.

7.4.6. Adaptive Command-Response Emulation

Another study [56] proposed a strategic methodology to address incomplete state-machine behaviour. They experimented with dynamically varying command responses using reinforcement learning. In this study, the honeypot learns interaction policies and selects actions such as allowing, blocking, delaying, substituting, or modifying command responses. This keeps the attacker engaged and reduces session termination, creating the illusion of an actual system. They validated the effectiveness of this approach during their live attacker–honeypot interaction session. However, the evaluation was conducted over a short period.

7.4.7. Realistic Transport and Protocol Timing Emulation

Realistic transport and protocol timing emulation methods address the resolution of deterministic and unrealistic network responses in medium-interaction honeypots [76]. For example, as mentioned earlier in Traffic Redirection and Network-Level Masking, an SDN-controlled environment is used to preserve external timing characteristics when traffic is redirected [76], thereby reducing the honeypot detection. However, this approach introduces latency due to TCP replay and Snort-based inspection.

7.4.8. Configuration Hardening and Default Sanitisation

Several studies have presented that honeypots deployed with default configurations, credentials, or predictable response fields can expose the honeypot system. Prior work [51] showed how explicitly hard-coded implementations or specific protocol error messages can be used by the attackers to identify SSH honeypots. In [71], the author pointed out that low-interaction honeypots are easily detectable, primarily because they are usually deployed without any customisation to their configuration.

7.5. Adaptive and Learning-Based Mitigation

This subsection examines mitigation methods that use adaptive, learning-based techniques to generate responses and detect fingerprinting attempts as attacker behaviour changes.

7.5.1. GAN-Based Dynamic Response Generation

Ref. [42] proposed RGPot, a novel honeypot based on a generative response model, presenting the strategic technique Generative Adversarial Network (GAN)-based dynamic response generation. Instead of using static values (e.g., in SSL/TLS), RGPot dynamically generates responses to simulate real IoT devices. This approach was experimentally validated by the authors. Compared with other honeypots, such as Cowrie, Conpot, Hfish, etc., which were detected using fingerprinting techniques, RGPot remained unrecognisable with the same detection methods. They noted limitations, including that the validation was conducted in a simulated environment, so the results may not generalise to real-world attackers.

7.5.2. Fuzzing-Based Fingerprint Detection

Another learning-based mitigation method is proposed in [10]. In their proposed D-FRI-based fuzzy inference system, the honeypot observes abnormal probing patterns in real time and dynamically adapts its rules. They provided a quantitative evaluation of their strategy using extensive Nmap-based attack simulations, proving that 84% of active fingerprinting attacks were detected at high severity.

7.5.3. Adaptive Fingerprint Detection

Adaptive fingerprint detection, an operational method introduced in [65], detects timing-based fingerprinting by observing ICMP packet size regularity and repeated abnormal request patterns rather than modifying protocol timing. The honeypot identifies consistent behaviours typical of fingerprinting tools and was experimentally evaluated against tools such as Nmap and Xprobe2, demonstrating effective detection in practice and providing logical steps and fingerprinting techniques for honeypots to improve on.

7.5.4. Behavioural and Traffic Realism Alignment

Several studies have shown that background traffic and network-layer characteristics can be reliable indicators for detecting honeypots. To mitigate the inconsistency of traffic patterns with those of real systems, behavioural and traffic realism alignment is introduced in some studies [29,42]. Some work implicitly demonstrates this by citing OT honeypots, where Linux-default TTL values can create distinguishable fingerprints. The author of [33] motivates aligning honeypot traffic behaviour and network-layer characteristics with those of real OT systems.

7.5.5. Adaptive and Learning-Based Behavioural Control

Behavioural control is proposed against honeypot detectability. References [54,55] introduce reinforcement learning to dynamically adjust responses to attacker commands, such as allowing, blocking, or substituting actions. For example, in [54], Cowrie Asgard continuously updates its behaviour based on observed attacker actions. In [55], the authors experimentally validated that this technique achieves over 96% precision in self-protection.

7.5.6. Hybrid Implementation

Ref. [48] proposed a mitigation approach that combines physical and virtual components, leveraging machine learning to mitigate deception. But, the authors also stated that more advanced ML techniques are needed.

7.6. State Preservation and Context Awareness

This subsection reviews mitigation strategies that focus on maintaining a consistent system state and long-term behavioural realism.

7.6.1. Maintenance and Exposure Management

Many studies have shown that outdated software can produce fingerprintable behaviours over time. References [49,53] mentioned that poorly maintained honeypots can be detected by attackers using previously disclosed techniques; regular maintenance and timely patching are necessary to reduce long-term fingerprintability. Similarly, ref. [32] noted that having many open ports over time can be a clear sign of a honeypot. The most complete study that proposed a solution to mitigate behavioural consistency over time is ref. [27]. The authors evaluated controlled exposure management by maintaining the attacker’s operational visibility. Instead of immediately blocking detected malicious activity, they allowed the bot to continue interacting with the network. They concluded that this caused the bot to waste time. However, adaptive attackers may still bypass it, and deploying it with SDN is complex.

7.6.2. State Preservation and Context Unification

Ref. [41] demonstrated that medium-interaction SSH honeypots are unable to preserve attacker-induced states. They implicitly proposed preserving system state and unifying session context to match realistic long-term behaviour. However, even with these well-configured changes, they may still be insufficient. Ref. [77] also suggested an operational strategy to preserve attacker-specific decisions and unify vulnerability data into a persistent decision state. This helps avoid repeated exposure of honeypots using fingerprintable artifacts. They validated this using a Cowrie-based hybrid honeypot proxy, which showed improved capture of repeated connections from the same botnet sources. The authors of another study [67] validated their approach through state preservation and context unification, demonstrating its effectiveness in preventing NC3-based behavioural fingerprinting.

7.7. Summary

To summarise and address research question 4, the literature proposes a transition from static emulation to dynamic, context-aware deception strategies. Low-interaction honeypots require focusing on banner normalisation and random configurations to eliminate universal identifiers. Medium-interaction honeypots should focus on their incomplete state machines by forwarding attacker commands to a real operating system. Reinforcement learning should also be utilised to generate non-deterministic responses, thereby significantly reducing the predictable behavioural signatures observed in traditional emulators.

8. Lessons Learned and Discussion

In this systematic literature survey, it is evident that the fingerprinting of honeypots varies with the interaction level and architectural design of the honeypot. Across all the deployments, attackers rely on banner analysis, protocol negotiation, state-machine validation, timing measurements, and implementation-specific artifacts to help distinguish honeypots from real systems. Low- and low-medium-interaction honeypots are most vulnerable to artifacts, primarily due to static variables that do not reflect real-world behaviour. ICS/SCADA honeypots are particularly vulnerable to default configurations. IOT honeypots similarly exhibit static banners, limited negotiation, and poor command handling. Shell and administrative honeypots are among the most fingerprinted for handshakes and state machine attacks. Web and application honeypots demonstrate that attackers increasingly exploit application-layer logic, such as endpoint validation and response-structure analysis.

The analysis of this literature shows that honeypot fingerprinting is primarily achieved through the presented probing techniques, with attackers seeking to extract as much information from a honeypot as possible. Across all probing strategies, active multi-stage probing dominates in both frequency and effectiveness. This technique allows attackers to iteratively refine their assessment of a target by sending responses across multiple phases at different protocol layers. The second most prevalent technique is active single-stage probing, in which a single carefully crafted packet is used to expose static banners or protocol inconsistencies.

Regarding the mitigation of honeypot fingerprinting, there is a wide range of operational, architectural, and learning-based techniques, each targeting specific vulnerabilities. Configuration and surface-level mitigations are among the most widely adopted. To mitigate low-effort attacks, techniques such as banner normalisation, configuration randomisation, and error message alignment are employed.

Regarding underexplored areas in the literature, there is little discussion of human-in-the-loop attackers, whereas more attention is paid to scanners, botnets, and scripted probing. Moreover, honeypot ageing is not systematically discussed, including how honeypots evolve over time and how attackers can exploit historical artifacts.

9. Conclusions and Future Work

This systematic literature review surveys existing research on honeypot fingerprinting and anti-detection techniques, with a focus on low and medium-interaction honeypot deployment. This review analysed fingerprinting methods, probing techniques, and susceptible artifacts, and proposed mitigation strategies, as reported in the literature.

By consolidating the findings, this survey provides better insight into how the interaction-level of honeypots and the artifacts of honeypots affect detectability, and it analyses which methods reduce attacker identification.

Overall, this survey provides an organised review of the subject matter and serves as a reference point for future studies to analyse honeypots properly, as well as for people seeking to design, evaluate, or improve honeypot systems. For future research directions, there should be more consideration in the aforementioned high-interaction fingerprinting techniques. Investigation into longitudinal studies of honeypot deployment are needed to understand how fingerprinting changes over time and should also investigate adversarial resilience of adaptive and AI-driven honeypots, including probing strategies designed to exploit learning mechanisms, as well as the ethical, legal, and operational constraints that balance effectiveness with responsible deployment. These findings aim to help researchers and enthusiasts understand the current state of the field and guide future investigations.