HoneyGPT: Breaking the Trilemma in Terminal Honeypots with

Large Language Model

Ziyang Wang Jianzhou You Haining Wang
Institute of Information Engineering, Sangfor Technologies Inc. Virginia Tech Arlington
Chinese Academy of Sciences;School Shenzhen, China Virginia, USA
of Cyber Security, University of youjianzhou@gmail.com hnw@vt.edu
Chinese Academy of Sciences
Beijing, China
wangziyang2022@iie.ac.cn
arXiv:2406.01882v1 [cs.CR] 4 Jun 2024

Tianwei Yuan Shichao Lv Yang Wang

Institute of Information Engineering,
Chinese Academy of Sciences;School
of Cyber Security, University of
Chinese Academy of Sciences
Beijing, China
yuantianwei@iie.ac.cn
Institute of Information Engineering, Shenzhen Institute of Advanced
Chinese Academy of Sciences;School Technology,Chinese Academy of
of Cyber Security, University of Sciences
Chinese Academy of Sciences Shenzhen, China
Beijing, China yang.wang1@siat.ac.cn
lvshichao@iie.ac.cn

Limin Sun
Institute of Information Engineering,
Chinese Academy of Sciences;School
of Cyber Security, University of
Chinese Academy of Sciences
Beijing, China
sunlimin@iie.ac.cn
ABSTRACT in enticing attackers into more profound interactive engagements
Honeypots, as a strategic cyber-deception mechanism designed and capturing a wider array of novel attack vectors in comparison
to emulate authentic interactions and bait unauthorized entities, to existing honeypot technologies.
continue to struggle with balancing flexibility, interaction depth,
and deceptive capability despite their evolution over decades. Often 1 INTRODUCTION
they also lack the capability of proactively adapting to an attacker’s Honeypots have been widely used as effective cybersecurity tools
evolving tactics, which restricts the depth of engagement and sub- for detecting, enticing, and understanding malicious activities on
sequent information gathering. Under this context, the emergent the Internet [2, 10, 12, 14, 25, 26, 29, 32, 33, 42]. These traps are
capabilities of large language models, in tandem with pioneering designed to lure attackers, allowing security teams to gather their
prompt-based engineering techniques, offer a transformative shift information and monitor their behaviors for threat analysis, as well
in the design and deployment of honeypot technologies. In this as
paper, we introduce HoneyGPT, a pioneering honeypot architecture deflect ongoing attacks.
based on ChatGPT, heralding a new era of intelligent honeypot Terminal honeypots are a specialized type of honeypots for em-
solutions characterized by their cost-effectiveness, high adaptabil- ulating real terminal systems. They are typically employed to at-
ity, and enhanced interactivity, coupled with a predisposition for tract hackers or malicious software targeting terminal systems.
proactive attacker engagement. Furthermore, we present a struc- Terminal honeypots range from low-interaction variants that sim-
tured prompt engineering framework that augments long-term ulate a minimal set of protocols or service information [17], to
interaction memory and robust security analytics. This framework, medium-interaction honeypots that replicate a broader array of
integrating thought of chain tactics attuned to honeypot contexts, system functionalities at a higher deployment and maintenance
enhances interactivity and deception, deepens security analytics, cost, and high-interaction honeypots that leverage sophisticated
and ensures sustained engagement. virtualization technologies, such as VMWare to create convincing
The evaluation of HoneyGPT includes two parts: a baseline com- environments of terminal systems or even deploy actual systems
parison based on a collected dataset and a field evaluation in real for maximum authenticity.
scenarios for four weeks. The baseline comparison demonstrates However, existing terminal honeypots face a trilemma prob-
HoneyGPT’s remarkable ability to strike a balance among flexibility, lem related to flexibility, interaction level, and deceptive capability,
interaction depth, and deceptive capability. The field evaluation fur- stemming from the limitations of programmatic approaches and
ther validates HoneyGPT’s efficacy, showing its marked superiority the fixed nature of system environments. In the trilemma, existing

terminal honeypot designs struggle to achieve optimal performance
across all three dimensions simultaneously, forcing defenders to
compromise and select imperfect solutions.
It is very challenging to address the trilemma in practice. The
primary methods for running honeypots are based on either pro-
grammatic simulations or real operating systems. On one hand, the
programmatic simulation approach is limited by development costs,
making it difficult to balance scalability and interaction depth. On
the other hand, honeypots based on real operating systems suffer
from rigidity, due to their inherent configurations that are short of
flexibility. Moreover, both deployment methods lack intelligence
during interactions, unable to provide responses that align with
attackers’ intentions to entice further engagement. This signifi-
cantly limits the honeypot’s deception capabilities. However, there
has been a growing demand for honeypots that are more dynamic,
intelligent, and cost-effective.
The development of Large Language Models (LLMs) [5, 6, 11,
35, 39] appears to offer a potential solution to these problems. By
providing attack commands as queries to the large language model,
it can generate responses tailored to the attackers’ interests based
on the provided prompt. This approach breaks the Trilemma of
traditional honeypots, as a single LLM can simultaneously simulate
multiple high-interaction honeypots with different configurations.
Furthermore, by designing prompts to guide the LLM, it is possible
to better fulfill attackers’ objectives and entice them into deeper
levels of interaction.
However, designing honeypots based on LLMs still faces three
major challenges. A prominent issue is the absence of a standard-
ized approach to honeypot prompt design. To address this problem,
this paper establishes a universal specification for honeypot prompt
keywords. Another challenge arises from the native thinking con-
straints of LLMs, which cannot handle complex attack combinations.
To address this challenge, we employ a Chain of Thought (CoT)
strategy that allows the language model to answer the command’s
impact on the operating system during each interaction. When
posing the next question, we integrate the consolidated changes in
the operating system and the user command to enhance the large
language model’s understanding of the task. The third challenge
lies in that the performance of LLMs in prolonged sessions is ham-
pered by their context length limitations and inherent forgetting
mechanisms. To manage this issue, we employ the CoT approach
to assess the significance of each attacker command and its impact
on the terminal system. This assessment allows us to strategically
prune the session history, ensuring that only the most essential con-
textual information is retained within the confines of the context
length, thereby optimizing the honeypot’s effectiveness in extended
interactions. The major contributions of this paper are summarized
as follows.
1. We propose HoneyGPT, an intelligent terminal honeypot that
addresses the dimensions of flexibility, interaction level, and decep-
tive capability, enabling extended interactions while overcoming
the Trilemma.
2. We propose a Chain of Thought strategy for terminal honey-
pot task scenarios, which enhances the task-solving capabilities
of native LLMs and overcomes the inherent context length limita-
tions. The introduction of CoT is essential to advancing honeypot
technology and improving network security defense capabilities.
Trovato and Tobin, et al.
3. We conduct a baseline evaluation of HoneyGPT in comparison
with traditional honeypots, utilizing open-source attack data cap-
tured by Cowrie. The results indicate that HoneyGPT outperforms
conventional honeypots with respect to its composite capabilities
in flexibility, level of interaction, and deception efficacy.
4. We deploy HoneyGPT and Cowire, which is a programmatic
honeypot, on the Internet for four weeks and observe that Hon-
eyGPT captures more attack behaviors and longer interactions than
Cowrie.
The rest of this paper is structured as follows. Section 2 provides
background on LLMs, prompt engineering, and terminal honey-
pots. Section 3 describes the trilemma of flexibility, interaction,
and deception in existing terminal honeypots. Section 4 presents
our HoneyGPT solution, detailing its framework, concept, strategy,
prompt management, and configuration. Section 5 validates the ef-
ficacy of HoneyGPT, providing baseline comparisons on deception,
interaction, and flexibility, as well as field evaluations to measure
its effectiveness in engaging attackers and capturing novel attack
vectors. Section 6 outlines the limitations and potential future work,
and finally, Section 7 concludes the paper.
2 BACKGROUND
In this section, we provide the background of Large Language
Models, prompt engineering, and terminal honeypots.
2.1 Large Language Models
Large Language Models (LLMs) are a subset of pre-trained language
models (PLMs), characterized by their voluminous parameter sets,
reaching or even exceeding hundreds of billions, as defined by Ka-
plan et al [11]. Since OpenAI introduced ChatGPT [19], LLMs have
been widely used across a spectrum of disciplines [4, 6], particularly
in the field of cybersecurity [8, 9, 16, 21, 22, 31]. Compared to pre-
vious models, LLMs offer two main advantages in interdisciplinary
applications:
Firstly, LLMs display astonishing emergent abilities as identified
by Wei et al [35], which are competencies absent in smaller-scale
models but manifest in larger configurations. Such models experi-
ence a quantum leap in performance relative to their diminutive
counterparts. Prominent among these emergent abilities are:
• In-context learning: LLMs can, upon receiving natural
language instructions or several task demonstrations, gen-
erate accurate outputs for test cases by continuing the input
text sequence, circumventing the need for further training
or gradient adjustments [4].
• Instruction following: LLMs possess the ability to com-
prehend and execute natural language instructions with
minimal or even zero examples, adapting to new tasks [30].
By fine-tuning tasks articulated through instructional prompts,
LLMs have demonstrated proficiency in accurately handling
tasks they have never seen before [20].
• Step-by-step reasoning: Distinct from conventional PLMs,
LLMs are capable of deconstructing complex tasks into a
sequence of discrete subtasks by employing prompt-based
strategies such as chain-of-thought. It is conjectured that
this capacity may be derived from their training on code [6,
36].
HoneyGPT: Breaking the Trilemma in Terminal Honeypots with Large Language Model
Secondly, LLMs transform the traditional employment of AI
algorithm development and utilization, significantly diminishing
the technical threshold for cross-disciplinary actors to harness such
algorithms. In contrast to previous models, users engage with LLMs
via a prompt interface (e.g., the GPT-3-turbo API), by formulating
natural language prompts or directives to modulate the model’s
behavior to yield anticipated results. This empowers individuals
who lack a deep understanding of model training paradigms but
are conversant with prompt engineering to employ LLMs for task
facilitation.
2.2 Prompt Engineering
Prompt engineering is the process of crafting prompts to better
guide large language models to understand and resolve tasks. Here
we briefly introduce prompt engineering from its core facets: com-
ponents, design principles, and strategic approaches.
Components. The standard components of LLM prompts typi-
cally include:
• Task Description: Instructions that the LLM is expected
to adhere to, expressed in natural language.
• Input Data: The requisite data for a task, presented in
natural language.
• Contextual Information: The contextual or background
information that can aid in the execution of a task.
• Prompt Style: The formulation of the prompt, which is
tailored to optimize the model’s responses, such as through
role-playing or incremental reasoning.
Design Principles. The development of effective LLM prompts is
predicated on:
• Clarity: Ensure instructions are explicit and communica-
tion is clear through symbolic delimiters, structured out-
puts, conditional logic, and "Few-shot" examples.
• Deliberation: Allow LLMs time for thought, structur-
ing prompts for sequential processing and reasoning with
"chain of thought" techniques. Allow LLMs time to reason
by structuring prompts for sequential information process-
ing using "chain of thought" techniques.
Prompting Strategies. The "Chain of Thought" (CoT) [5, 13, 15,
36, 38, 39, 41] paradigm has been shown to significantly enhance
LLM performance on tasks that require complex reasoning by in-
corporating intermediary reasoning steps within the prompts. The
zero-shot CoT, as introduced in foundational research, employs
prompts such as "Let’s think step by step" to shepherd LLMs to a
logical conclusion, thus highlighting the significance of scale in
emergent capabilities.
2.3 Terminal Honeypots
Honeypots are security tools designed as decoys to attract and
monitor unauthorized or malicious attackers. Based on their im-
plementation approaches, terminal honeypots can be categorized
into three primary types: emulated honeypots, which are based on
programmed simulations; real system honeypots, which utilize real
systems; and hybrid honeypots, which combine the features of the
first two types.
Emulated Honeypots. Emulated honeypots are software constructs
that simulate network services and devices to attract cyber ad-
versaries. They are developed using conventional programming
methodologies, as exemplified by Honeyd [17], Dionaea [23], and
Cowrie [18]. These honeypots utilize rule-based matching and log-
ical controls to mimic desired targets. Despite their effectiveness,
they are constrained by the limitations of development and opera-
tional costs, preventing a full emulation of an operating system’s
intricate behaviors. The interactivity spectrum of these honeypots
spans from minimal to moderate: Honeyd and Dionaea deliver
low-interaction platforms rich in configuration possibilities, while
Cowrie steps up to offer a medium-interaction milieu. However,
this comes at the cost of diminished adaptability and increased
operational costs. Such frameworks have laid the groundwork for
a range of specialized offshoots [1, 14].
Real-system Honeypots. Real-system honeypots, by contrast, uti-
lize genuine, unmodified system environments, offering a more
authentic simulation of user interactions, file system activities, and
operational behaviors [2, 32, 34]. They provide a high level of in-
teraction, creating a convincing facade of a real system, which
significantly increases the probability of capturing complex attack
strategies that simpler honeypot architectures may miss. However,
the inherent rigidity of their physical environments [1] requires
individualized configuration for each new system variant, which
incurs substantial deployment and maintenance costs.
This authenticity offers potential attackers a highly interactive
environment, fostering a convincing deception that aids in uncov-
ering intricate attack vectors that might elude detection by more
rudimentary honeypots. However, a challenge arises from the secu-
rity protocols native to real operating systems, such as stringent
permission controls, which are not inherently conducive to fulfill-
ing malicious requests. These protocols can inadvertently deter
threat actors from engaging in more profound levels of system
exploitation, thus potentially curtailing the honeypot’s effective-
ness as a lure. Additionally, the deployment and maintenance of
real-system honeypots are encumbered by the need for individ-
ual configurations for each system variant, leading to significant
resource expenditures.
Hybrid Honeypots. In an effort to combine the strengths of both
emulated and real system honeypots, a scalable hybrid honeypot
framework has been proposed [37, 40]. This framework employs
programmed methods for simulating low-level interactions, such as
network protocols, while delegating high-level interactions, such
as file executions, to a real file system. Although the hybrid model
ostensibly enhances flexibility and interaction depth, it is not de-
void of limitations. The framework may experience discordance be-
tween the simulated protocols and the actual file system responses,
leading to a detectable discrepancy that astute attackers could po-
tentially exploit. Furthermore, the rigidity in configuring a physical
environment restricts adaptability and diminishes the diversity of
supported environmental configurations, which could impair its
capacity to effectively deceive sophisticated attackers.

3 TRILEMMA OF EXISTING TERMINAL
HONEYPOTS
The trilemma in honeypot design reflects the intricate balancing
act required to optimize the three key attributes of effective hon-
eypot systems: interaction depth, flexibility, and deception ability.
Honeypots from their inception have grappled with this trilemma,
consistently facing trade-offs that impede their overall efficacy.
3.1 Limited Flexibility
The narrow concept of flexibility within honeypot design is in-
dicative of the system’s adaptability in authentically replicating
a variety of systems and services. Such adaptability is pivotal for
honeypots, as it underpins their ability to create authentic and per-
suasive simulations of various operational environments. Yet, the
quest for such flexibility is one of the most formidable challenges
in honeypot development, with the central issue being the support
for a wide range of operating system versions and nuanced system
configurations.
Contemporary honeypots often struggle to provide sufficient
flexibility, particularly regarding the support of diverse operating
system versions and security configurations. The pursuit of in-
creased flexibility can compromise the depth of interaction and the
honeypot’s deception ability.
Code-based emulated honeypots exemplify this issue, as they
require extensive resources for the creation and maintenance of sim-
ulations that encompass numerous operating system versions and
environmental configurations. Such complexity leads to substantial
development and operational costs, and no code-based honeypot
has yet managed to seamlessly transition across varied terminal en-
vironments while maintaining high interaction fidelity. Real-system
honeypots offer detailed interactions but lack the adaptability of
their emulated counterparts, making them difficult to reconfig-
ure in response to evolving threats. They also impose significant
management overhead, due to the requirement of maintaining real
operating system environments.
Moreover, traditional honeypot offerings remain constrained to
single-dimensional deception techniques. As to leveraging the data
they capture, there is a conspicuous lack of flexibility in integrating
security analysis, necessitating distinct systems dedicated to data
processing and analysis.
The core challenge, therefore, is to architect honeypots that
strike an optimal balance between delivering authentic, complex
interactions and possessing the agility to counter novel attacks.
Achieving this equilibrium should not exacerbate costs or inflate
management burdens, crafting a solution that is as economical as
it is effective.
3.2 Limited interaction
Due to limitations in implementation methods and development
costs, code-based terminal honeypots are restricted to simple rule
matching and lack the capability to execute complex commands as a
real operating system. This limitation significantly reduces the level
of interaction these honeypots can manage, making them inade-
quate in responding to complex commands issued by attackers. For
instance, Cowrie, a commonly used middle-interactive honeypot,
is unable to handle complex commands that involve concatenation
Trovato and Tobin, et al.
with pipe symbols (|). The inability to process complex operations
can lead to honeypot instability or crashes, thereby failing to fur-
ther engage attackers. Enhancing the interaction of honeypots is
crucial for increasing their reliability and effectiveness.
3.3 Limited Deception
A key factor contributing to limited deception is the lack of dynamic
and adaptive behavior in existing honeypot systems. Code-based
terminal honeypots typically rely on static configurations and pre-
defined matching mechanisms, while honeypots based on real oper-
ating systems often perform limited and monotonous simulations
of the operating environment due to cost constraints. Experienced
attackers can easily identify these singular and rigid environment
configurations. The lack of variability reduces the effectiveness
of deception because attackers can quickly recognize and bypass
the simulated environment of the honeypot. Additionally, code-
based terminal honeypots lack authentic user interactions and the
realism of contextual information, further limiting their ability to
convincingly simulate real systems. When attackers perform com-
plex operations such as file execution or process communication,
code-based honeypots struggle to replicate authentic user interac-
tions or provide the depth of a real system.
In addition, in terms of enticing attackers for deeper-level at-
tacks, current honeypots often fall short. Whether it is a code-based
honeypot like Cowrie or a honeypot based on real systems, the lim-
ited configurations and restricted permissions provided to attackers
often fail to meet the intentions of attackers. Catering actions such
as modifying user passwords, terminating competing processes, or
viewing graphics card information, which could effectively boost an
attacker’s motivation, are often overlooked by existing honeypots.
Especially in a real system environment, the operating system’s
characteristics, such as permission control mechanisms and limited
configurations (such as hardware devices and account password
configurations), have limitations in fulfilling the attacker’s attack
intentions.
4 HONEYGPT
To address the trilemma of existing honeypots, we introduce Hon-
eyGPT, an advanced honeypot framework based on ChatGPT. This
framework transforms the conventional "request-response" mes-
sage interaction (based on terminal protocols) into a "question-
answer" text interaction (based on ChatGPT API).
As shown in Figure 1, the framework consists of three main
components: the Terminal Protocol Proxy, the Prompt Manager,
and ChatGPT. The Terminal Protocol Proxy is responsible for fun-
damental protocol tasks, such as establishing connections, finger-
print emulation, message encapsulation, and parsing. We utilize
the protocol layer of the Cowrie honeypot to develop the Terminal
Protocol Proxy, which supports protocols such as SSH and Telnet.
The Prompt Manager is tasked with constructing prompts based on
commands sent by attackers and interacting with ChatGPT. Chat-
GPT generates responses based on the provided prompts. After
receiving a response from ChatGPT, the Prompt Manager extracts
the terminal output and forwards it to the Terminal Protocol Proxy,
which then encapsulates it into messages and returns them to at-
tackers. Since the Terminal Protocol Proxy repurposes the work
HoneyGPT: Breaking the Trilemma in Terminal Honeypots with Large Language Model
Figure 1: HoneyGPT Framework
of the Cowrie honeypot and is not a primary innovation, we will
predominantly elaborate on the design of the Prompt Manager in
the following section.
4.1 Concept and Strategy
We first articulate the fundamental concepts and methodological
strategies that are integral to the design of the Prompt Manager.
4.1.1 Concept of HoneyGPT. We define the interaction history as
a sequence of N question-answer pairs:
{(𝑄 1, 𝐴1 ), (𝑄 2, 𝐴2 ), . . . , (𝑄 𝑁 , 𝐴𝑁 )} (1)
To obtain the response 𝐴𝑖 from the 𝑖-th interaction, we con-
structed complex prompts. The operational logic of HoneyGPT
during the 𝑖-th interaction is showcased in Figure 2. The 𝑖-th Hon-
eyGPT interaction is formally defined by Equation 2.
(𝐴𝑖 , 𝐶𝑖 , 𝐹𝑖 ) = 𝐶ℎ𝑎𝑡𝐺𝑃𝑇 (𝑃, 𝑆, 𝐻𝑖 , 𝑆𝑅𝑖 , 𝑄𝑖 ) (2)
The components 𝑃, 𝑆, 𝐻𝑖 , 𝑆𝑅𝑖 , and 𝑄𝑖 together constitute the
prompt for the 𝑖-th interaction. Here 𝑃 and 𝑆 represent the static
configuration of the prompt, remaining unchanged throughout the
interactions. 𝑄𝑖 is the command sent by the attacker during the
𝑖-th interaction. 𝐻𝑖 and 𝑆𝑅𝑖 are dynamic aspects of the prompt,
updated after each interaction by the Prompt Manager M. The
Prompt Manager synthesizes these variables into the new prompt
for subsequent dialogue sessions, as defined by:
𝑀 (𝑃, 𝑆, 𝑄𝑖 , 𝑆𝑅𝑖 , 𝐶𝑖 , 𝐹𝑖 , 𝐴𝑖 , 𝑤) = (𝑃, 𝑆, 𝐻𝑖+1, 𝑆𝑅𝑖+1, 𝑄𝑖+1 ) (3)
The following are definitions for each variable:
Honeypot Principle 𝑃 defines the strategies and guidelines
used to create a honeypot.
Honeypot Setting 𝑆 refers to the initial configuration set within
the prompt for the Honeypot.
History of Interaction 𝐻𝑖 {(𝑄 1, 𝐴1 ), (𝑄 2, 𝐴2 ), . . . , (𝑄𝑖 −1, 𝐴𝑖 −1 )}
provides ChatGPT with the essential context required to support
its capacity for extended interaction memory. To ensure that the
length of 𝐻𝑖 remains within the context length limits of ChatGPT,
the Prompt Manager 𝑀 implements a pruning algorithm to regulate
the size of the historical context. This algorithm judiciously trims
components of 𝐻𝑖 that have less significance, striking a balance
between retaining pertinent context and maintaining the model’s
operational efficiency within its architectural constraints.
System State Register 𝑆𝑅𝑖 refers to a collection of system states
communicated to ChatGPT at the 𝑖-th interaction: {(𝐶 1 ), (𝐶 2 ), . . . ,
(𝐶𝑖 −1 )}, where each state 𝐶𝑖 corresponds to the system’s changes
after each prior interaction, paralleling the order of 𝐻𝑖 . 𝑆𝑅𝑖 is the
manifestation of a ’chain-of-thought’ strategy, which HoneyGPT
leverages to enhance its capacity for generating the subsequent
response 𝐴𝑖 .
Attacker Query 𝑄𝑖 in the context of HoneyGPT, refers to the
command issued by the attacker to the honeypot terminal system
during the 𝑖-th interaction.
Honeypot Answer 𝐴𝑖 in the context of HoneyGPT, denotes the
command execution echo returned by the honeypot terminal to the
attacker during the 𝑖-th interaction.
System State Evaluation 𝐸𝑖 is an assessment provided by Chat-
GPT regarding the system’s state post-interaction, consisting of
two parts: Impact Factor 𝐹𝑖 , which values the impact of 𝑄𝑖 on the
system, and 𝐶𝑖 , which denotes the changes to the terminal system
environment after 𝑄𝑖 execution.
Weaken Factor 𝑤 is the constant used in the pruning algo-
rithm, which accounts for the timing of interactions, preferentially
trimming older and less relevant exchanges to maintain a recent,
pertinent dialogue history.
4.1.2 Strategy. The design of HoneyGPT incorporates a Chain of
Thought (CoT) strategy to address the intrinsic limitations of Chat-
GPT in processing complex, extended dialogues and to circumvent
the constraints of the prompt context length. The essence of CoT
lies in compelling the LLM to decompose a multifaceted problem
into a sequence of sub-problems, tackling them incrementally to
enhance the LLM’s ability to comprehend and address intricate
issues.
Complex Extended Dialogue Tasks: In realistic adversarial
scenarios, attackers often execute a series of malicious activities
through multiple commands. As shown in Figure 3, attackers issue
the "write-elevate-execute" attack sequence. While native Chat-
GPT can effectively handle individual commands, it struggles with
complex, interdependent, extended dialogue tasks that require mem-
orization and coherence. By contrast, HoneyGPT can significantly
increase the capability to handle such complex command sequences
by incorporating the CoT strategy.
Within HoneyGPT, we simplify the complexity of extended dia-
logues into two steps: first, assessing the impact of previous com-
mands on the operating system, and then determining the system’s
response to new adversarial commands based on the evaluated
impact. To ensure the continuity and automation of the attack inter-
action process, the task of assessing the impact of attack commands
on the operating system has been delegated to ChatGPT. Thus,
during each interaction, the prompt must provide ChatGPT with
details of the changes that have occurred within the system up
to that point( 𝑆𝑅𝑖 ), as well as the present attack command( 𝑄𝑖 ).
ChatGPT is then tasked with analyzing the expected output from
the terminal ( 𝐴𝑖 ) and determining the result of System State Eval-
uation ( 𝐶𝑖 , 𝐹𝑖 ). Following the conclusion of an interaction, the
 Trovato and Tobin, et al.

Figure 2: HoneyGPT Architecture

Figure 3: Comparison of the Effects of Integrating CoT

Prompt Manager integrates 𝐶𝑖 into 𝑆𝑅𝑖 , respectively, setting the
stage for the subsequent interaction.
Prompt Pruning Strategy: After each interaction, the Prompt
Manager appends content to prompt, respectively, which results in
an increasingly lengthy prompt for subsequent interactions. How-
ever, due to limitations imposed by computational resources, stor-
age capacities, and model characteristics, LLMs have a restricted
context length for prompts. Should the prompt’s token count ex-
ceed this threshold, ChatGPT will be unable to function. To address
this issue, we introduce a strategy known as Prompt Pruning: if the
prompt’s context length surpasses the limit, we eliminate the least
impactful entries from the dynamic portion, 𝐻𝑖 , with respect to the
current operating system. Although 𝑆𝑅𝑖 also grows dynamically,
its length is significantly shorter than the context length limit, and
therefore, it does not require pruning. Since 𝐻𝑖 represents the col-
lection of historical honeypot interactions, it suffices to consider
both the temporal sequence and the magnitude of impact to identify
and remove the least pertinent interaction records for the current
exchange. The impact magnitude is determined by ChatGPT dur-
ing each interaction, for which we have provided a set of grading
criteria that ChatGPT uses to generate 𝐹𝑖 , as listed in Table 1.
HoneyGPT: Breaking the Trilemma in Terminal Honeypots with Large Language Model
Table 1: Rules of the Assignment of Values to 𝐹𝑖
Value Condition
0 Read file, display system information
1 file created, install tool
2 modify files/dir, change working directory, change shell
3 Start/stop service, download file, Elevate privilige
4 Impact services, delete files, password changed
4.2 Prompt Manager 𝑀
The operations of the Prompt Manager are categorized into three
main processes: prompt construction, prompt pruning, and content
updating.
4.2.1 Prompt Construction . The construction process takes place
before each interaction session. When the attacker issues a com-
mand to HoneyGPT, the Prompt Manager formulates three critical
questions for ChatGPT to answer, based on the Honeypot Princi-
ple, Honeypot Setting, Attacker Query, System State Register, and
History of Interaction:
(1) What is the terminal’s response (𝐴𝑖 ) ?
(2) How does the system state change (𝐶𝑖 ) ?
(3) Assign a numerical value to the command’s aggressiveness
(𝐹𝑖 ).
Question 2 underpins the CoT strategy, while Question 3 is in-
tended for prompt length pruning and will be discussed later. Upon
obtaining responses Ai, Ci, and Fi, HoneyGPT relays Ai back to
the attacker, while Ci and Fi are utilized by the Prompt Manager to
update the Hi and SRi in prompt for the subsequent interaction.
4.2.2 Prompt Pruning. Pruning is activated when the length of
the prompt exceeds the operational limits of commercial LLMs.
The primary objective is to trim interactions of less importance
from the History of Interaction (𝐻𝑖 ). Since the entries regarding
system state changes are typically concise, 𝑆𝑅𝑖 are exempt from this
curtailment. The success of pruning depends on accurately singling
out the least significant interactions from 𝐻𝑖 . We have graded the
impact of adversarial commands on the current system by using
a scale from 0 to 4. The criteria for assigning values to the Impact
Factor (𝐹𝑖 ) are detailed in Table 1. LLMs will generate responses by
referencing the table, ensuring that the pruning process is executed
in a systematic and uniform manner.
In addition, the design contemplates the temporal dimension
of command relevance, positing that earlier exchanges bear less
pertinence to the present interaction. The Weaken Factor 𝑤 is
introduced to quantify this temporal effect. With each interaction’s
conclusion, the Impact Factor 𝐹𝑖 for each entry in 𝐻𝑖 is attenuated
by multiplication with 𝑤, effectuating a time-based diminution of
𝐹𝑖 . During the pruning process, entries with the lowest 𝐹𝑖 values are
prioritized for removal to manage and preserve the prompt token
limit efficiently.
Regarding the determination of the Weaken Factor 𝑤, both the
length of the dialogue and the relevance of the content are con-
sidered. Observations from cybersecurity practices indicate that
a sequence of attacks with strong correlation typically progresses
through a "write-elevate-execute" triad. Therefore, it is advisable to
ensure that a newly executed command has a higher significance
than a high-privilege command that occurred three steps prior,
signified by 𝐹𝑖+3 · 𝑤 3 < 𝐹𝑖 . Additionally, the value of 𝑤 should not
be too diminutive in order to adequately reflect the effect of time
on the relevance of past commands. The process of temporal decay
is implemented during Content Updating, where 𝐹𝑖 of each element
is multiplied by the Weaken Factor (𝑤).
4.2.3 Content Updating . The updating process is conducted at
the end of each interaction session, aiming to renew the dynamic
cache contents, specifically the System State Register 𝑆𝑅𝑖 and the
History of Interaction 𝐻𝑖 . This does not include static elements
such as constants S, P, and the adversary’s instructions 𝐴𝑖 . Upon
the completion of the 𝑖-th interaction, the Prompt Manager incor-
porates the query-response pair (𝑄𝑖 , 𝐴𝑖 ) into 𝐻𝑖 , and the context
𝐶𝑖 into 𝑆𝑅𝑖 . The 𝑆𝑅𝑖 supports the CoT strategy, while 𝐻𝑖 serves
as contextual information for enriching ChatGPT’s understanding
of the interaction history. Additionally, the updating includes the
application of a temporal decay to the Impact Factor 𝐹𝑖 to support
the pruning mechanism.
4.3 Configuration of HoneyGPT
Here we introduce the static components involved in configuring
HoneyGPT, namely the System Principles (𝑃) and Honeypot Set-
tings (𝑆), which remain unchanged once a honeypot is initialized.
System Principles provide behavioral guidelines for simulating sys-
tem activities, covering aspects such as the role of HoneyGPT, time
sensitivity, input/output formats, and few-shot learning. These prin-
ciples enable HoneyGPT to effectively attract and analyze potential
attack behaviors by maintaining a credible system illusion. The
Honeypot Settings involve specific configurations like hardware
specifications and software environments, which are essential for
simulating realistic targets that are attractive to attackers. These
settings are designed to enhance the honeypot’s attractiveness and
precision in capturing malicious exploitation such as cryptocur-
rency mining. Once set, both components provide a stable platform
for HoneyGPT to operate effectively within its designed parameters.
A detailed description of these two sets is given in Appendix A.
5 EVALUATION
Our evaluation of HoneyGPT includes two parts: the baseline evalu-
ation and the field evaluation. The baseline evaluation compares the
capabilities in deception, interaction level, and flexibility between
HoneyGPT and traditional honeypots. Specifically, to evaluate the
honeypots’ capability in deception and interaction level under con-
sistent attack scenarios, the baseline evaluation utilizes the attack
dataset collected by Cowrie. The field evaluation involves deploying
HoneyGPT and Cowrie simultaneously on the Internet for a period
of four weeks to assess whether HoneyGPT can influence attackers’
attack strategies and capture a wider range of attack types and
interaction lengths.
5.1 Baseline Comparison Set
The comparison in the baseline evaluation is from three aspects:
deception, interaction level, and flexibility. The comparisons of
deception and interaction level are performed in a quantitative
manner, by utilizing the same attack dataset to ensure the same
 Trovato and Tobin, et al.

Table 2: Baseline Comparison Set

Capability Subjects Method Research

Type Type
Deception HoneyGPT (GPT-3.5 Replay attack Quantitative
turbo), HoneyGPT dataset Research
(GPT-4), Cowrie, Real
System
Interaction HoneyGPT (GPT-3.5 Replay attack Quantitative
turbo), HoneyGPT dataset Research
(GPT-4), Cowrie
Flexibility HoneyGPT, Cowrie, Verification Qualitative
Honeyd, Real System Individually Research

Table 3: Attack Data Source Figure 4: Distribution of Deception Categories Across Differ-
ent Honeypots

Source Capture Time Span Number Effective Attack

Method of Attacks Sessions
Cowrie 2021/04/06- 5099153 2479
[3]
captured 2021/06/11
Cowrie 2022/06/09- 1261689 7374
[24]
captured 2022/10/29
attack scenarios, while the flexibility comparison is performed in a
qualitative manner, through individual experimental verification
for each indicator.
Table 2 shows the experimental setup for the baseline compari-
son. The comparison of deception is conducted among HoneyGPT
based on GPT-3.5 turbo interface, HoneyGPT based on GPT-4 turbo
interface, Cowrie, and a real system. The interaction level com-
parison is limited to the comparisons among HoneyGPT based on
GPT-3.5 turbo interface, HoneyGPT based on GPT-4 turbo interface,
and Cowrie, because the real system exhibits the best interaction
level and there is no need to compare. The flexibility comparison is
conducted among Honeyd, a low-interaction honeypot, along with
HoneyGPT, Cowrie, and the real system.
To assess the differences in deception and interaction level be-
tween HoneyGPT and traditional honeypots under the same attack
scenarios, we use the same attack dataset to replay traffic, simu-
lating identical attack scenarios. This dataset compiles attack data
previously captured by Cowrie, a mainstream, code-based, medium-
interaction open-source honeypot system [3, 24]. As shown in Table
3, these datasets include a substantial volume of attack commands
and valid attack sessions. A sequence of actions performed by an
attacker post-successful login is considered as a valid attack ses-
sion. We perform data cleaning and aggregation on these datasets,
resulting in 160 attack sessions and 1,489 attack commands, which
are used for baseline comparison.
5.2 Baseline Comparison of Deception
Here we assess the deception capabilities of Cowrie, HoneyGPT
based on the GPT-3.5 Turbo API, HoneyGPT based on the GPT-4
API, and a real operating system based on virtual machines.
5.2.1 Evaluation Metrics. We assess the deception of honeypots
from two aspects:
(1) Whether the execution of commands succeeds or not. Attack
behaviors typically exhibit temporal dependencies and con-
trol logic, where the execution of commands relies on the
desired effects of previous attack commands, such as suc-
cessful execution or system information that is of interest
to attackers. Thus, a higher execution success rate indicates
the honeypot’s capability to induce attackers into deeper
interactions and capture more valuable information.
(2) Whether the outputs of honeypot comply with the OS logic or
not. Whether the honeypot’s outputs align with the logic
of the operating system directly affects the effectiveness of
its deception. Deviations from the expected behaviors of
an operating system, such as inconsistent shell prompts or
command execution results, may raise suspicion by attack-
ers and expose the honeypot. A higher level of OS logic
compliance indicates a stronger deceptive capability of the
honeypot.
Based on these two aspects, we then define four distinct categories
to classify and compare the deceptive performance of the honeypot
system’s responses.
• SALC (Successful Attack with Logic Compliance):
Successful attacks that conform to the logic of the operating
system.
• SALNLC (Successful Attack without Logic Compliance):
Successful attacks that do not adhere to the logic of the op-
erating system.
• FALC (Failed Attack with Logic Compliance): Failed
attacks that conform to the logic of the operating system.
• FALNLC (Failed Attack without Logic Compliance):
Failed attacks that do not adhere to the logic of the operating
system.
With these defined categories, we can now introduce four key
evaluation metrics to assess the honeypot system’s deceptive capa-
bilities:
HoneyGPT: Breaking the Trilemma in Terminal Honeypots with Large Language Model
Figure 5: Performance Comparison
• Accuracy: It measures the system’s ability to generate out-
puts consistent with the logic of a real operating system. It is
calculated by dividing the number of successful attacks that
conform to the operating system’s logic (SALC) by the total
number of successful attacks (SALC + SALNLC). Improv-
ing accuracy enables more precise simulation of operating
system behaviors, lowers attacker suspicion, and enhances
information gathering and threat awareness capabilities.
• Temptation: It evaluates the effectiveness of the system
in attracting attackers’ engagement. It is calculated by di-
viding the number of successful attacks that conform to
the operating system’s logic (SALC) by the total number
of attacks with operating system logic (SALC + FALC). A
higher level of temptation indicates a more successful lure
for attackers and greater information collection.
• Attack Success Rate: It measures the overall success
rate of executing deceptive commands. It is calculated by
dividing the total number of successful attacks by the total
number of attempted attacks. A higher success rate im-
plies more successful interactions and better information
collection.
• OS Logic compliance: It evaluates the system’s capabil-
ity to generate outputs consistent with the logic of a real
operating system. It is calculated by dividing the number
of attacks that conform to the operating system’s logic
(SALC + FALC) by the total number of attempted attacks.
Improving OS logic compliance allows for the creation of
more accurate simulations of operating system behaviors,
lowering attackers’ suspicions.
5.2.2 Performance Comparison. Figures 4 and 5 illustrate the per-
formance comparison among Cowrie, a real operating system, and
HoneyGPT based on GPT-3.5 and GPT-4.
In terms of attack success rate and temptation, HoneyGPT based
on GPT-3.5 and GPT-4 outperforms both Cowrie and the real operat-
ing system. The inherent characteristics of LLMs enable HoneyGPT
to better cater to attackers’ intentions, enticing them to further
engage in attacks, which is a significant advantage of HoneyGPT.
Furthermore, increasing the model parameter size leads to improve-
ments in both metrics. Regarding OS logic compliance and accuracy,
Table 4: Evaluation of Interaction Level
Metrics Cowrie HoneyGPT HoneyGPT
(GPT-3.5-turbo) (GPT-4)
Full Session Re- 81.88% 93.75% 99.38%
sponse Rate
Command Re- 96.98% 99.13% 99.93%
sponse Rate
Mean Session 57.28% 71.73% 99.93%
Length Percentage
Mean Interaction 83.24% 94.45% 99.91%
Degree Percentage
HoneyGPT based on GPT-3.5 and GPT-4 also demonstrates superior
performance than Cowrie and approaches the level of the real op-
erating system. Additionally, increasing the model parameter size
leads to enhancements in both metrics. Note that with the increase
in model parameter size, there is a notable improvement in the pro-
portion of successful execution of deceptive commands that comply
with the operating system logic (SALC). This indicates that as the
model evolves, the precision of HoneyGPT in catering to attackers’
intentions also increases. In summary, the performance compar-
ison highlights the advantages of HoneyGPT based on GPT-3.5
and GPT-4 over Cowrie and the real operating system. HoneyGPT
demonstrates superior performance in terms of accuracy, tempta-
tion, attack success rate, and compliance with operating system
logic. Moreover, increasing the model parameter size can further
improve the performance in these metrics.
5.3 Baseline Comparison of Interaction
Unlike the deception assessment, we consider a honeypot providing
interactions as long as it can respond without crashing, even if the
honeypot’s feedback suggests that the service does not exist or there
is insufficient permission. We assess the interaction level of Cowrie,
HoneyGPT based on the GPT-3.5 Turbo API, and HoneyGPT based
on the GPT-4 API. The baseline comparison of interaction level
can be divided into two parts. First, we compare and analyze the
degree of interaction support that HoneyGPT and Cowrie provide in
response to diverse attack requests. Second, based on the ATT&CK
matrix, we derive the response rates of HoneyGPT to different
attack techniques under varied interface supports and analyze the
reasons for non-responses to each attack technique.
5.3.1 Performance Comparison. To assess the interaction level of
a honeypot, we introduce four key metrics:
• Complete Session Response Rate: The ratio of sessions
that are completely and successfully responded to requests
throughout their duration.
• Command Response Rate: The percentage of individual
commands within sessions that receive responses.
• Mean Session Length Percentage: Defined as the ratio of
the average executed session length to the overall average
session length.

Figure 6: Analyse of GPT-3.5 Turbo Non-Responses
• Mean Interaction Degree Percentage: Defined as the
average of the proportions of successful responses within
individual sessions.
Table 4 presents a detailed comparison of the interaction levels
for each honeypot. The results clearly demonstrate the superior
performance of HoneyGPT, especially the version based on the GPT-
4 API, achieving nearly perfect interaction performance across all
categories. This indicates the superiority of HoneyGPT’s capability
to maintain interactive sessions and support command interactions.
5.3.2 Unresponsiveness Analysis and Error Origins. We assess the
interactive performance of HoneyGPT based on the GPT-3.5 Turbo
API and that of HoneyGPT based on the GPT-4 API in responding
to various attack vectors, analyzing the types and frequencies of
errors they encounter with each type of attack.
Our analysis employs the "Techniques" component of the ATT&CK
framework developed by MITRE to classify the test data [28]. Within
the ATT&CK framework, the "Techniques" section comprehen-
sively outlines the specific methods adversaries employ to achieve
their tactical objectives. By examining the response rate and error
causes for each technique, we gain deeper insights into the perfor-
mance capabilities and potential limitations of HoneyGPT under
different API supports.
The test results, as detailed in Appendix B, indicate that Hon-
eyGPT demonstrates excellent support in responding to each attack
technique, achieving response rates above 99%. Notably, the perfor-
mance of GPT-4 surpasses that of GPT-3.5 Turbo. This analysis not
only highlights the robustness of HoneyGPT’s design in simulat-
ing realistic and responsive interaction, but also underscores the
improvements in handling complex security scenarios facilitated
by advancements from GPT-3.5 to GPT-4.
Additionally, Figures 6 and 7 provide an analysis of the causes
and frequencies of non-responses encountered by each version of
HoneyGPT against various ATT&CK techniques. A notable obser-
vation is substantial reductions in commonly encountered error
types with GPT-4, such as "response wrong format", "wrong com-
mand", and "prompt length exceeds limit", in comparison to GPT-3.5
Turbo.
Trovato and Tobin, et al.
Figure 7: Analyse of GPT-4 Non-Responses
Response wrong format indicates issues with the parsing of
responses due to discrepancies between the returned format and
the expected format.
Wrong command occurs when the command is deemed incor-
rect or inexecutable within the specified system environment.
Prompt length exceeds limit arises when the length of an
attack command or response surpasses the LLM’s context length
limit, making it impossible to work.
These issues are not easily rectifiable solely through prompt
engineering in circumstances where the model’s performance is
subpar. By contrast, with the advent of GPT-4, these error types
become virtually nonexistent, with only a minuscule number of
"security policy" errors remaining. It highlights the improvement
in error management with the introduction of GPT-4, reflecting
significant advancements in better interaction than GPT-3.5 Turbo.
Security policy occurs when the ChatGPT refrains from exe-
cuting a command based on its internal security protocols, and it
primarily involves operations such as malicious file downloads or
deletions. This type of error is unavoidable in the design of hon-
eypots based on commercial LLMs. Fortunately, at this moment,
the frequency of such an error is very low, and their impact on
honeypot performance is negligible.
5.4 Baseline Comparison of Flexibility
The evaluation of honeypot flexibility focuses on three key aspects:
scalability across different systems, adaptability in different system
configurations, and integration of additional security analysis fea-
tures. The comparative evaluation is among HoneyGPT, Cowrie,
Honeyd, and real-system honeypot. Cowrie operates as a medium-
interaction honeypot that provides interactive terminal emulation,
and Honeyd serves as a low-interaction honeypot designed for
general purposes. Real-system honeypots, on the other hand, are
actual operating systems running on virtual machines.
5.4.1 Flexibility in Simulating Different Systems. The diversity of
operating systems requires traditional honeypots to adapt to vari-
ous system versions and instruction sets. This adaptation frequently
demands independent development efforts for each simulated sys-
tem. However, the advanced generative capabilities of LLMs offer a
HoneyGPT: Breaking the Trilemma in Terminal Honeypots with Large Language Model
Table 5: Flexibility in Simulating Different Systems
Honeypot Expansion Cost Simulation Level Scalability
Cowrie High Medium Medium
Honeyd Low Low High
Real System High High Low
HoneyGPT Low High High
groundbreaking solution to overcome these challenges. We evalu-
ate the emulation capabilities of these honeypots across different
operating systems, including Ubuntu and CentOS. Table 5 lists
the expansion costs, simulation levels, and scalability of each hon-
eypot type. Cowrie, as a medium-interaction honeypot, requires
extensive modifications to adapt to different system versions, in-
cluding updates to system information and the file systems, as well
as reconfigurations of the instruction set, and thus the expansion
costs are considerably high. Honeyd, as a low-interaction honeypot,
requires only minimal adjustments in configuration information
to accommodate system version changes, offering high scalability.
Real-system honeypots, while achieving high simulation fidelity,
require the configuration of new physical environments, which
significantly increases the associated costs and reduces overall flex-
ibility. HoneyGPT requires only minimal adjustments to system
settings in prompt to simulate different systems. The LLMs can
automatically generate file system, instruction set, system user, and
other details based on the system settings in prompt. Our approach
offers high scalability and a superior level of simulation.
5.4.2 Flexibility in Simulating Different System Configurations . To
assess the flexibility of configuration modifications, we conduct
a comparative analysis of Cowrie, Honeyd, real-system Honey-
pot, and HoneyGPT. We categorize configuration changes into
five types: network configuration, file system, user configuration,
hardware setting, and service status. If configuration updates can
be easily achieved by simple command-line or configuration file
modifications, we consider it as supporting flexible modification
for that configuration. Table 6 shows that HoneyGPT is the only
product allowing flexible modifications across all configuration as-
pects. Honeyd, Cowrie, and real-system honeypots exhibit limited
configuration flexibility.
Traditional honeypots often struggle with modification of sys-
tem configurations, leading to fixed deployments that can be easily
identified by attackers. This rigidity undermines their effectiveness
as deception tools. However, the advent of LLMs introduces a novel
paradigm. HoneyGPT enables direct modifications to system config-
urations via prompt adjustments, offering unprecedented flexibility
and adaptability, thereby enhancing deception capabilities.
5.4.3 Flexibility of Integration with Security Analysis Capability. In
the context of practical operations, honeypots primarily act as col-
lectors of attack data, representing just one facet of comprehensive
security measures. Beyond this basic role, the analysis of collected
attack data is crucial. Traditional honeypot designs, such as Cowrie,
Honeyd, require specialized development efforts, thereby incurring
significant overheads to integrate these functionalities.
However, the HoneyGPT’s design circumvents this challenge
by leveraging the capabilities of ChatGPT to seamlessly integrate
additional functionalities through simple prompts. For example,
we can employ ChatGPT to analyze attackers’ behavioral logs,
enabling functionalities like security policy alerts. As designed in
the prompt manager of HoneyGPT, each interaction with LLMs
not only inquires about the outcome of the current command but
also asks about the potential impact of the attack command on the
operating system.
This innovative approach represents a paradigm shift where a
honeypot, by leveraging LLMs, seamlessly integrates security anal-
ysis capabilities. The utility of the honeypot is greatly enhanced
while reducing the cost and complexity associated with the integra-
tion of these auxiliary features. Therefore, HoneyGPT presents a
cost-effective, scalable, and efficient approach for future honeypots.
5.5 Field Evaluation
The field evaluation focuses on assessing HoneyGPT’s entrapment
efficacy in the real world. We have simultaneously deployed Hon-
eyGPT based on GPT-4 and Cowrie inside the same network for
four weeks. HoneyGPT is implemented using the best practice de-
ployment strategies, while Cowrie is configured with its default
settings. We detail the evaluation procedure and our main findings
below.
5.5.1 HoneyGPT Deployment. Our baseline comparisons demon-
strate that HoneyGPT significantly enhances deception, interactiv-
ity, and flexibility. However, the economic burden associated with
the query costs of commercial LLMs presents practical challenges
for deployment. Furthermore, these models also impose restrictions
on the quantity and frequency of requests from a single user within
a given timeframe, potentially limiting their capacity to handle tasks
with high concurrent requests. To optimize the cost-effectiveness
of HoneyGPT under the constraints of high query costs and strin-
gent request limitations, we adopt a hybrid deployment strategy.
This strategy integrates HoneyGPT with the traditional emulated
honeypot approach, leveraging the strengths of both to enhance
performance while reducing costs.
In the strategic deployment of HoneyGPT, prudent management
of command processing is crucial for optimizing efficacy and cost-
efficiency. Those commands that are challenging for LLMs to pro-
cess, as well as those governed by fixed, simple rules, are delegated
to emulated honeypots. In other words, the commands that LLMs
typically handle inefficiently, such as binary file reading, and those
dependent on time mechanisms (e.g., sleep and uptime), as well as
commands following simple rules, such as whoami, are rerouted to
emulated honeypots.
Furthermore, resolved interactions from HoneyGPT—comprising
terminal prompts and command combinations—are stored in a
database. If an attacker’s request corresponds to a stored HoneyGPT
query, the recorded response from the database is immediately
returned. For new, context-sensitive queries, processing is handled
by HoneyGPT to ensure responses are coherent and contextually
accurate. Due to the repetitiveness of attacker requests in actual
intrusion scenarios, this strategy significantly reduces the query
load and congestion on commercial LLMs.
Moreover, to enhance the appeal of the honeypot to specific
adversaries, such as those involved in cryptocurrency mining, the
simulated environment within HoneyGPT is configured to mimic a
 Trovato and Tobin, et al.

Table 6: Evaluation of Configuration Flexibility for Different Configuration

Honeypot Type Network Configuration File System User Configuration Hardware Settings Service Status
Cowrie ✓ ✓ ✓ × ×
HoneyD ✓ × × × ✓
Real-system honeypot ✓ × ✓ × ×
HoneyGPT ✓ ✓ ✓ ✓ ✓

high-performance computing server. Prompts are carefully crafted

to align with attackers’ intentions, allowing for the successful ex-
ecution of attack commands. This is intended to modify attacker
behaviors and elicit more prolonged and informative interactions,
thereby providing deeper insight into their strategies and poten-
tially uncovering more complex attack techniques.
5.5.2 Comparative Analysis of Attacker Engagement. By comparing
the interaction data of HoneyGPT and Cowrie, we observe that for
Figure 9: Command Support Level
the same attack source under the three cases, HoneyGPT achieves
a deeper interaction with the attacker than Cowrie.
• Fulfillment of Attacker's Intent. As illustrated in
Figure 8, attackers issue the ps and grep command combi-
nation to identify processes related to the "miner" keyword,
aiming to detect mining malware. Cowrie cannot reveal
the processes with the "miner" keyword, leading to a pre-
mature termination of the attack. Conversely, HoneyGPT
effectively mimics the expected system responses, thus ful-
filling the attacker’s intent and encouraging sustained en- Figure 10: Content Rigidity
gagement.
This comparative analysis highlights HoneyGPT’s superior capabil-
ities in providing dynamic, contextually relevant content that can
significantly sway attacker behaviors, support a broader array of
command interactions, and effectively disguise its honeypot iden-
tity, thereby extending engagement and potentially exposing more
advanced attack strategies.
Figure 8: Fulfillment of Attacker’s Intent 5.5.3 New Attacks Vector Discovered by HoneyGPT. The deploy-
ment of HoneyGPT has unveiled new attack vectors that signifi-
• Command Support Level. As illustrated in Figure 9, when cantly differ from those captured by the traditional Cowrie honey-
attackers try to use complex command structures with mul- pot. As detailed in Appendix C, HoneyGPT identifies 11 types of
tiple command combinations, the limited interaction ca- attack actions categorized into six different ATT&CK techniques,
pabilities of the Cowrie honeypot often fail to support all highlighting the evolving landscape of cyber threats and the critical
the sub-commands within these complex commands. As role of advanced, adaptive honeypot technologies like HoneyGPT
a result, attackers typically cease their attacks after un- in identifying and analyzing emerging attack vectors.
successful attempts using similar commands. By contrast,
HoneyGPT’s generative capabilities are sufficient to handle 6 LIMITATIONS AND FUTURE WORK
such complex commands, which can entice attackers to
engage in deeper levels of attacks. While the integration of LLMs has enhanced the entrapment ca-
• Content Rigidity. As illustrated in Figure 10, when at- pabilities of honeypot systems, there remain several limitations
tackers engage in reconnaissance of the target system, Cowrie manifested in the following aspects:
typically provides rigid, easily identifiable honeypot re- • Context Length Restriction. LLMs are inherently lim-
sponses. Recognizing these as features of a honeypot, at- ited by the Context length of prompt. When attackers input
tackers often terminate their interaction prematurely. By and execute lengthy command scripts directly at the ter-
contrast, HoneyGPT dynamically generates responses tai- minal, LLMs may fail to respond appropriately. Attempts
lored to the honeypot setting outlined in the prompt, effec- to limit response lengths within the prompts have proven
tively camouflaging its honeypot nature and maintaining suboptimal. This issue may necessitate the development of
attacker engagement. proprietary LLMs tailored for extensive token interactions.
HoneyGPT: Breaking the Trilemma in Terminal Honeypots with Large Language Model
• Request Rate Limit. Although the use of rule-based
matching has reduced the amount of unnecessary com-
mercial LLM requests, commercial models’ limitations on
request rates remain a significant obstacle to the deploy-
ment of honeypot systems. Professional honeypot models,
fine-tuned from open-source LLMs, could potentially ad-
dress this issue.
• Ineffectiveness against Fixed Attack Sequences.
During field testing, we discovered that some attackers em-
ploy predetermined attack sequences to target honeypots,
regardless of the honeypot’s ability to respond to requests
or the quality of the response content. For such attackers,
HoneyGPT is unable to prolong the interaction length by
catering to their intent.
• Prompt-based Attacks on ChatGPT. While no prompt-
based attacks against ChatGPT have been discovered thus
far, this remains a potential vulnerability that needs to be
monitored and addressed [7, 27].
• Overfitting Issue. LLMs may exhibit overfitting to incor-
rect commands, returning seemingly normal results despite
command errors. This issue highlights the need for further
refinement in the model’s error recognition capabilities.
Moving forward, the development of LLMs for honeypot ap-
plications should focus on mitigating these limitations. Research
efforts may include creating more sophisticated and context-aware
models that can handle longer token sequences and have a deeper
understanding of complex systems. Furthermore, enhancing models
with temporal awareness and addressing request rate limits will
be crucial for advancing honeypot technology. It will also be para-
mount to continually monitor for new types of attacks and adapt
the LLMs accordingly to maintain robust security measures. Finally,
addressing the overfitting problem may involve implementing more
nuanced training strategies that emphasize the correct handling of
anomalous or incorrect command inputs.
7 CONCLUSION
The triad of challenges in traditional honeypots—flexibility, interac-
tion depth, and deceptive capacity—has historically curtailed their
allure and efficacy in engaging attackers. To address this trilemma,
this paper presents HoneyGPT, a bespoke innovation in adaptive
honeypot solutions specifically engineered to circumvent the in-
herent limitations of traditional honeypots. Our comparison evalu-
ations indicate that HoneyGPT transcends traditional honeypots in
terms of flexibility, interaction, and deception, and it also exceeds
the entrapment capabilities of real systems, emphasizing its supe-
riority in meeting attackers’ intents to deepen engagements. Our
field evaluations further validate that HoneyGPT adeptly conducts
extended interactions and captures a broader spectrum of attack
vectors while facing diverse adversaries in the real world. Overall,
HoneyGPT positions itself as an effective and intelligent counter-
measure against ongoing security threats, and it also paves the path
for future honeypot research.
REFERENCES
[1] Vetterl Alexander and Clayton Richard. 2018. Bitter Harvest: Systematically
Fingerprinting Low- and Medium-interaction Honeypots at Internet Scale. In
12th USENIX Workshop on Offensive Technologies. USENIX Association.
[2] K. G. Anagnostakis, S. Sidiroglou, P. Akritidis, K. Xinidis, E. Markatos, and A. D.
Keromytis. 2005. Detecting Targeted Attacks Using Shadow Honeypots. In 14th
USENIX Security Symposium. USENIX Association.
[3] Melike Başer, Ebu Yusuf Güven, and Muhammed Ali Aydın. 2021. Ssh and
telnet protocols attack analysis using honeypot technique: Analysis of ssh and
telnet honeypot. In 2021 6th International Conference on Computer Science and
Engineering. IEEE Computer Society.
[4] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan,
Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda
Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan,
Rewon Child, Aditya Ramesh, Daniel Ziegler, Jeffrey Wu, Clemens Winter, Chris
Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack
Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever, and
Dario Amodei. 2020. Language models are few-shot learners. In Advances in
Neural Information Processing Systems. Curran Associates, Inc.
[5] Guhao Feng, Bohang Zhang, Yuntian Gu, Haotian Ye, Di He, and Liwei Wang.
2024. Towards revealing the mystery behind chain of thought: a theoretical per-
spective. In Advances in Neural Information Processing Systems. Curran Associates,
Inc.
[6] Yao Fu, Hao Peng, and Tushar Khot. 2022. How does gpt obtain its ability?
tracing emergent abilities of language models to their sources. Yao Fu’s Notion
(2022).
[7] Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten
Holz, and Mario Fritz. 2023. Not what you’ve signed up for: Compromising real-
world llm-integrated applications with indirect prompt injection. In Proceedings
of the 16th ACM Workshop on Artificial Intelligence and Security. Association for
Computing Machinery.
[8] J He and M Vechev. 2023. Large Language Models for Code: Security Hardening
and Adversarial Testing. In Proceedings of the 2023 ACM SIGSAC Conference on
Computer and Communications Security. Association for Computing Machinery.
[9] Peiwei Hu, Ruigang Liang, and Kai Chen. 2024. DeGPT: Optimizing Decompiler
Output with LLM. In Proceedings of the 31st Annual Network and Distributed
System Security Symposium. Association for Computing Machinery.
[10] Linan Huang and Quanyan Zhu. 2021. Duplicity games for deception design
with an application to insider threat mitigation. IEEE Transactions on Information
Forensics and Security (2021).
[11] Jared Kaplan, Sam McCandlish, Tom Henighan, Tom B Brown, Benjamin Chess,
Rewon Child, Scott Gray, Alec Radford, Jeffrey Wu, and Dario Amodei. 2020.
Scaling laws for neural language models. arXiv preprint arXiv:2001.08361 (2020).
[12] Jinwoo Kim, Eduard Marin, Mauro Conti, and Seungwon Shin. 2022. EqualNet:
A Secure and Practical Defense for Long-term Network Topology Obfuscation.
In Proceedings of the 29st Annual Network and Distributed System Security Sym-
posium. Association for Computing Machinery.
[13] Zhan Ling, Yunhao Fang, Xuanlin Li, Zhiao Huang, Mingu Lee, Roland Memisevic,
and Hao Su. 2024. Deductive verification of chain-of-thought reasoning. In
Advances in Neural Information Processing Systems. Curran Associates, Inc.
[14] Efrén López-Morales, Carlos Rubio-Medrano, Adam Doupé, Yan Shoshitaishvili,
Ruoyu Wang, Tiffany Bao, and Gail-Joon Ahn. 2020. HoneyPLC: A Next-
Generation Honeypot for Industrial Control Systems. In Proceedings of the 2020
ACM SIGSAC Conference on Computer and Communications Security. Association
for Computing Machinery.
[15] Pan Lu, Swaroop Mishra, Tanglin Xia, Liang Qiu, Kai-Wei Chang, Song-Chun
Zhu, Oyvind Tafjord, Peter Clark, and Ashwin Kalyan. 2022. Learn to explain:
Multimodal reasoning via thought chains for science question answering. In
Advances in Neural Information Processing Systems. Curran Associates, Inc.
[16] Ruijie Meng, Martin Mirchev, Marcel Böhme, and Abhik Roychoudhury. 2024.
Large language model guided protocol fuzzing. In Proceedings of the 31st Annual
Network and Distributed System Security Symposium. Association for Computing
Machinery.
[17] Provos Niels. 2004. A Virtual Honeypot Framework.. In 13th USENIX Security
Symposium. USENIX Association.
[18] M OOSTERHOF. [n. d.]. Cowrie. [Online]. https://github.com/micheloosterhof/
cowrie.
[19] openai. [n. d.]. chatgpt. [Online]. https://openai.com/blog/chatgpt/.
[20] Long Ouyang, Jeffrey Wu, Xu Jiang, Diogo Almeida, Carroll Wainwright, Pamela
Mishkin, Chong Zhang, Sandhini Agarwal, Katarina Slama, Alex Ray, John Schul-
man, Jacob Hilton, Fraser Kelton, Luke Miller, Maddie Simens, Amanda Askell,
Peter Welinder, Paul F Christiano, Jan Leike, and Ryan Lowe. 2022. Training
language models to follow instructions with human feedback. In Advances in
Neural Information Processing Systems. Curran Associates, Inc.
[21] Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and
Ramesh Karri. 2022. Asleep at the keyboard? assessing the security of github
copilot’s code contributions. In 2022 IEEE Symposium on Security and Privacy.
IEEE Computer Society.
[22] Hammond Pearce, Benjamin Tan, Baleegh Ahmad, Ramesh Karri, and Brendan
Dolan-Gavitt. 2023. Examining zero-shot vulnerability repair with large language
models. In 2023 IEEE Symposium on Security and Privacy. IEEE Computer Society.
[23] PhiBo phibos. [n. d.]. Dionaea. [Online]. https://github.com/DinoTools/dionaea.

[24] VS Devi Priya and S Sibi Chakkaravarthy. 2023. Containerized cloud-based
honeypot deception for tracking attackers. Scientific Reports (2023).
[25] Julian L Rrushi. 2018. Dnic architectural developments for 0-knowledge detection
of opc malware. IEEE Transactions on Dependable and Secure Computing (2018).
[26] Takayuki Sasaki, Akira Fujita, Carlos H Ganán, Michel van Eeten, Katsunari
Yoshioka, and Tsutomu Matsumoto. 2022. Exposed infrastructures: Discovery,
attacks and remediation of insecure ics remote management devices. In 2022
IEEE Symposium on Security and Privacy. IEEE Computer Society.
[27] Wai Man Si, Michael Backes, Yang Zhang, and Ahmed Salem. 2023. { Two-
in-One } : A Model Hijacking Attack Against Text Generation Models. In 32nd
USENIX Security Symposium. USENIX Association.
[28] Blake E Strom, Andy Applebaum, Doug P Miller, Kathryn C Nickels, Adam G
Pennington, and Cody B Thomas. 2018. Mitre att&ck: Design and philosophy.
In Technical report. The MITRE Corporation.
[29] Sadegh Torabi, Elias Bou-Harb, Chadi Assi, ElMouatez Billah Karbab, Amine
Boukhtouta, and Mourad Debbabi. 2020. Inferring and investigating IoT-
generated scanning campaigns targeting a large network telescope. IEEE Trans-
actions on Dependable and Secure Computing (2020).
[30] Sanh Victor, Webson Albert, Raffel Colin, Bach Stephen, Sutawika Lintang,
Alyafeai Zaid, Chaffin Antoine, Stiegler Arnaud, Raja Arun, Dey Manan, et al.
2022. Multitask prompted training enables zero-shot task generalization. In
International Conference on Learning Representations. OpenReview.net.
[31] Nishant Vishwamitra, Keyan Guo, Farhan Tajwar Romit, Isabelle Ondracek, Long
Cheng, Ziming Zhao, and Hongxin Hu. 2024. Moderating New Waves of Online
Hate with Chain-of-Thought Reasoning in Large Language Models. In 2024 IEEE
Symposium on Security and Privacy. IEEE Computer Society.
[32] Omar Abdel Wahab, Jamal Bentahar, Hadi Otrok, and Azzam Mourad. 2019.
Resource-aware detection and defense system against multi-type attacks in the
cloud: Repeated bayesian stackelberg game. IEEE Transactions on Dependable
and Secure Computing (2019).
[33] Yuntao Wang, Zhou Su, Abderrahim Benslimane, Qichao Xu, Minghui Dai, and
Ruidong Li. 2023. Collaborative honeypot defense in uav networks: A learning-
based game approach. IEEE Transactions on Information Forensics and Security
(2023).
[34] Zhiwei Wang, Yihui Yan, Yueli Yan, Huangxun Chen, and Zhice Yang. 2022.
{ CamShield } : Securing Smart Cameras through Physical Replication and Isola-
tion. In 31st USENIX Security Symposium. USENIX Association.
[35] Jason Wei, Yi Tay, Rishi Bommasani, Colin Raffel, Barret Zoph, Sebastian
Borgeaud, Dani Yogatama, Maarten Bosma, Denny Zhou, Donald Metzler, Ed H.
Chi, Tatsunori Hashimoto, Oriol Vinyals, Percy Liang, Jeff Dean, and William
Fedus. 2022. Emergent abilities of large language models. arXiv preprint
arXiv:2206.07682 (2022).
[36] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, brian ichter, Fei
Xia, Ed Chi, Quoc V Le, and Denny Zhou. 2022. Chain-of-Thought Prompting
Elicits Reasoning in Large Language Models. In Advances in Neural Information
Processing Systems. Curran Associates, Inc.
[37] Yiwen Xu, Yu Jiang, Lu Yu, and Juan Li. 2021. Brief industry paper: Catching iot
malware in the wild using honeyiot. In 2021 IEEE 27th Real-Time and Embedded
Technology and Applications Symposium. IEEE Computer Society.
[38] Kaiyu Yang, Jia Deng, and Danqi Chen. 2022. Generating Natural Language
Proofs with Verifier-Guided Search. In Advances in Neural Information Processing
Systems. Curran Associates, Inc.
[39] Mengjiao (Sherry) Yang, Dale Schuurmans, Pieter Abbeel, and Ofir Nachum.
2022. Chain of Thought Imitation with Procedure Cloning. In Advances in Neural
Information Processing Systems. Curran Associates, Inc.
[40] Jianzhou You, Shichao Lv, Yue Sun, Hui Wen, and Limin Sun. 2021. Honeyvp: A
cost-effective hybrid honeypot architecture for industrial control systems. In ICC
2021-IEEE International Conference on Communications. IEEE Computer Society.
[41] Eric Zelikman, Yuhuai Wu, Jesse Mu, and Noah D Goodman. 2022. Star: Self-
taught reasoner bootstrapping reasoning with reasoning. In Advances in Neural
Information Processing Systems. Curran Associates, Inc.
[42] Zhenxin Zhan, Maochao Xu, and Shouhuai Xu. 2013. Characterizing honeypot-
captured cyber attacks: Statistical framework and case study. IEEE Transactions
on Information Forensics and Security (2013).
Trovato and Tobin, et al.
A CONFIGURATION OF HONEYGPT
A.1 System Principles 𝑃
HoneyGPT, serving as a terminal honeypot system, is specifically
designed to attract and monitor attack activities. To achieve this
objective, we have implemented the system’s principles within
the prompts, providing operational guidelines for ChatGPT. These
prompts play different crucial roles in the functionality of the sys-
tem, including:
Role of HoneyGPT. HoneyGPT strategically simulates an authen-
tic terminal environment, tailored to align closely with attackers’
intents, thereby encouraging deeper and more sustained engage-
ment. The system expertly balances authenticity with the objective
of enticing attackers into prolonged interactions, thereby enhancing
the honeypot’s effectiveness.
Time Sensitivity. In scenarios where attacks are time-sensitive,
attackers may issue commands related to current time inquiries,
such as uptime and top. Since ChatGPT inherently lacks the capa-
bility to query real-time networked time data, it is necessary for
us to provide time-related information such as the current time
and boot time in the prompts to ChatGPT. This approach ensures
that the honeypot’s responses are temporally accurate, thus more
convincingly mimicking a real system environment.
Input/Output Format. The structure of both input and output
prompts critically defines each interaction with the LLM in Hon-
eyGPT. The input format is crucial for the LLM’s accurate under-
standing of the honeypot system’s state and the commands issued
by attackers. Conversely, the output format affects HoneyGPT’s
operational effectiveness. To ensure HoneyGPT’s robustness, we
instruct the LLM to use the JSON format for outputs. This standard-
ization ensures consistent and correct parsing of responses during
each interaction with the model.
Few-Shot Learning. HoneyGPT utilizes a few-shot learning strat-
egy to enhance ChatGPT’s comprehension of task requirements
and improve the quality of its outputs, compensating for gaps in
several command knowledge. Our experience indicates that by inte-
grating only 4-5 representative examples, HoneyGPT’s generative
capabilities can be significantly enhanced.
A.2 Honeypot Setting 𝑆
Honeypot settings describe the terminal system information simu-
lated by HoneyGPT, which is crucial for attracting and capturing
potential attackers. Our experience indicates that honeypots with
high-end configurations are more attractive to malicious entities,
such as cryptocurrency-mining malware. Furthermore, the more
details of honeypot configurations, the higher precision of the re-
sponses. The ability to customize honeypot settings via natural
language significantly enhances flexibility and reduces the com-
plexity of deployment. Honeypot settings are divided into two main
categories: hardware and software.
Hardware. It is essential to define the hardware specifications
that will be emulated by HoneyGPT. It includes defining CPU types
and counts, GPU presence, and storage capacities, those attributes
that attackers frequently scrutinize. The specifications selected
HoneyGPT: Breaking the Trilemma in Terminal Honeypots with Large Language Model

must mirror those of the systems intended to be simulated by Hon- tailored within HoneyGPT to create customized responses for each
eyGPT to maintain the authenticity of the honeypot environment. engagement scenario.
Additionally, configuring systems with high-end GPUs and CPUs
can attract specific types of threat actors, such as crypto-mining B SUCCESSFUL RESPONSE RATE OF
malware, prompting deeper interactions. HONEYGPT BASED ON GPT-3.5-TURBO AND
Software. The software environment of a honeypot, including the GPT-4
operating system, open ports, user configurations, and application Figure 11 shows the successful response rate of HoneyGPT based
services, must be strategically crafted to reflect the behaviors of on GPT-3.5-turbo and GPT-4, with support rates for each attack
potential targets. For instance, if the objective is to mimic a web technique exceeding 99%.
server, HoneyGPT should be configured with the appropriate web
server software, along with associated services and open ports. C NEW ATTACKS VECTOR DISCOVERED BY
Additionally, attackers are often drawn to details such as system HONEYGPT
processes, resource utilization, scheduled tasks, user configurations, As shown in Table 7, HoneyGPT identifies 11 types of attack actions,
and filesystem information. These elements can be specifically which are classified into 6 categories of ATT&CK techniques.
 Trovato and Tobin, et al.

Figure 11: Successful Response Rate with GPT-3.5 Turbo and GPT-4 in HoneyGPT

Table 7: New Attacks Vector Discovered by HoneyGPT

Technology action
System Service Discovery (T1007) By employing pipeline operators (|) to integrate the nvidia-smi command with grep and other
filtering commands like head, awk, and wc, these commands facilitate the selective extraction
and presentation of precise GPU information in accordance with predetermined criteria.
System Service Discovery (T1007) By employing pipeline operators (|) to merge the lspci command with various filtering com-
mands including grep, cut, egrep, and wc. The objective is to extract and display specific
information related to VGA or 3D graphics from the PCI devices present within the system.
System Service Discovery (T1007) The lscpu command is integrated with egrep and cut to selectively extract the CPU model
name.
System Service Discovery (T1007) The grep command is utilized to search the /proc/cpuinfo file to calculate the total number of
processors or CPU cores in the system.
System Network Configuration Discov- The command arp -a is used to display the system’s ARP table, containing mappings between
ery (T1016) IP addresses and MAC addresses.
System Network Configuration Discov- An HTTP GET request is sent using curl to "curl ipinfo.io/org" in order to retrieve organizational
ery (T1016) information associated with the system’s IP address that initiated the request.
System Network Configuration Discov- The nano command is used to view the /etc/resolv.conf file, to access the configuration of the
ery (T1016) DNS resolver.
System Information Discovery (T1082) The uptime command is employed to obtain the system’s uptime.
Indicator Removal on Host (T1070) Several actions are taken to ensure anonymity and to avoid leaving traces of system activity: 1.
Unsetting environmental variables to disable the saving of command history. 2. The command
history -c is used to clear the existing history. 3. The rm -rf command combined with the path
to log files is used to delete log files, thereby eliminating traces of system activity.
Virtualization/Sandbox Evasion( T1497) The sleep command is used to nsuring program synchronization, preventing detection of
anomalous behavior, and it can also be used to detect if the target system is a honeypot, in
which case, if execution fails, further attacks are not pursued.
Obfuscated Files or Information (T1027) Scripts written in shell or Perl are obfuscated by base64 encryption prior to execution to avoid
detection and identification.