Ghost Without Shell: Measuring Non-Interactive SSH Attacks on Honeypots Veronica Valeros
Muris Sladić
Sebastian Garcia
Czech Technical University in Prague Prague, Czechia [email protected]
Czech Technical University in Prague Prague, Czechia [email protected]
Czech Technical University in Prague Prague, Czechia [email protected]
arXiv:2606.28006v1 [cs.CR] 26 Jun 2026
Abstract Cyber deception research has focused on improving honeypot deception capabilities to increase attacker engagement and extend their interactions to collect more and better intelligence. For SSH honeypots, this relies on the assumption that attackers log in, open a shell, and type. We tested whether this still held by deploying eleven SSH honeypots that served both interactive and non-interactive session requests for fifteen days. We collected 177,622 authenticated sessions and validated our results against an independent Cowrie dataset over the same time window. We found that 99.23% of sessions were non-interactive. Interactive sessions account for only 0.10%. The same pattern held in the comparative third-party dataset used for evaluation. This finding is important because a honeypot that focuses on interactive shells or evaluates success based on session length and the number of commands can miss most authenticated attacks and draw the wrong conclusions about what attackers do after login.
Keywords honeypots, SSH, cyber deception, network measurement, LLMbased honeypots
1
Introduction
Much of the SSH deception measurement and literature implicitly assumes that after authentication, attackers open an interactive shell to type commands [13]. This view is common in SSH, and also Telnet honeypot work [1, 20], with only a few studies considering non-interactive sessions [11]. This assumption also motivates the design of recent LLM-based SSH honeypots, which focus on simulating a convincing shell dialogue [6, 15, 18], as well as motivate the metrics used to evaluate deception, which often treat engagement time and interaction volume as proxies for success [8]. However, this assumption has not been consistently checked, since SSH also supports non-interactive mode and file-transfer mode. In non-interactive mode, a client can authenticate, issue a single command via an exec request, read the output, and disconnect without the server ever allocating a shell. In file-transfer mode, the attacker uses scp or the sftp protocol to try to transfer files. Most SSH honeypot research reports “post-authentication commands" but does not distinguish whether they arrived through an interactive shell or a non-interactive exec request [7, 10, 13, 25]. When these modes are mixed, measurements can overstate interactive behavior and understate automated non-interactive campaigns, and deception designs can optimize for dialogue that most attackers never request.
Our research studies and quantifies this phenomenon of noninteractive sessions by deploying advanced LLM-based SSH honeypots on the Internet for 15 days and analyzing which attacks use interactive and non-interactive sessions and for what. Our methodology first involves developing a variant of the AdvancedShelLM LLM-based SSH honeypot [2], making it capable of distinguishing these two session types. Second, we analyze the attacks collected during the period, extracting session commands and answers. Finally, we validate our findings against an independent Honeypotas-a-Service (HaaS) Cowrie honeypot network operated by CZ.NIC over the same window [5]. Results show that 99.23% of authenticated sessions are noninteractive exec requests, typically completing in under a second. Interactive shell sessions only account for 0.10%, and file-transfer accounts for 0.67%. This overturns the common assumption that authenticated SSH honeypot traffic is mostly interactive, and it means that shell-only honeypots and engagement-based evaluations observe a small and biased slice of post-login behavior. A noninteractive session has, by definition, only one command, which must accomplish its purpose immediately, giving the honeypot exactly one chance to respond. Results also show that some non-interactive commands seem to be verification probes, meaning that they test whether a target is real or a honeypot before the attacker invests further. We observe 2,178 simulated-shell probes from 9 source IPs and 4 classic honeypot fingerprinting sessions from 1 IP, while prompt-injection strings and explicit AI/LLM mentions are absent. For LLM-based SSH honeypots in particular, success depends less on how long an attacker stays connected and more on whether the honeypot survives verification. This paper makes three contributions: • A measurement of which SSH mode attackers use after login, showing that most send a single non-interactive exec command rather than opening a shell, confirmed on an independent Cowrie dataset. • An analysis of the nature and characteristics of these verification probes. • An argument that SSH deception research should measure whether each answer is correct and whether the honeypot passes these checks, not only how long an attacker stays.
2
Background and Related Work
Measuring SSH attacks. The largest recent measurement of SSH attacks is by Munteanu et al., who analyzed 546 million sessions collected over three years by 221 Cowrie honeypots [13, 14]. They classify sessions by what commands do, separating commands that alter the honeypot state from those that do not. Like most studies in
this line, they do not report how commands arrive, that is, whether the attacker opened an interactive shell or sent a single exec request. That mode split is the axis this paper measures.
freshly allocated for this study. The collection window spans fifteen days, from May 27th, 2026, to June 10th, 2026.
3.3
LLM-based honeypots. Since shelLM demonstrated that an LLM can simulate a believable Linux shell [18], the idea has grown into a research line of its own. Examples include interactive SSH honeypots [6, 15, 23], the VelLMes multi-protocol deception framework [19], web honeypots [9], industrial protocol emulation [22], and earlier GPT-based shell simulation [16]. A recent SoK maps the area [4], and evaluation work has begun to standardize how response quality is measured [24]. Across this line, the design and the evaluation center on the interactive shell dialogue. VelLMes states this explicitly: its Internet deployment rejected non-interactive command execution by design [19]. Our results show that this design choice discards about 99% of the traffic sent by attackers.
For each authenticated session, AdvancedShelLM logs a single JSONL record with the following features: sensor id, session id, start date time, end date time, duration, session type (Section 3.4), termination reason (e.g.: exit, disconnect, error), attack source IP address, source port, username, password, sequence of credential attempts; ordered list of attacker commands, honeypot responses. Raw packets are not captured, and no information about attackers is collected beyond what is sent to the honeypot.
3.4
Session Types
AdvancedShelLM identifies each authenticated session as one of the three types described above (interactive, non-interactive, or file-transfer) based on its internal knowledge of the protocol. Even though AdvancedShelLM uses a real SSH server, it is possible to identify the types because AdvancedShelLM was modified to implement a session proxy that captures the necessary information.
Detection in both directions. Honeypot fingerprinting is a mature topic, and frameworks exist to detect deployed honeypots at scale [21]. The arrival of LLMs opened a second front. Reworr and Volkov instrumented an SSH honeypot with prompt injections to catch LLM-driven attackers, finding eight candidates in over eight million attempts [17], and later work proposes challenge-based traps and proactive defenses against LLM agents [3, 12]. All of this work points the detector at the attacker. The opposite direction, attackers probing whether the host itself is a simulation, has not been measured. That is the behavior we document in Section 4.3.
Non-interactive sessions. The attacker issues a single non-interactive exec request, e.g., ssh user@server ’ls -a’. The honeypot returns the output, and the SSH channel closes without a terminal ever being allocated. At the protocol level, the session consists of exactly one command–response exchange. Interactive sessions. The attacker requests a shell channel, usually after a pty-req, and exchanges zero or more commands through the allocated terminal. This is the traditional mode of SSH use.
3 Methodology and Setup 3.1 Honeypot System We collected SSH attack traffic by modifying AdvancedShelLM, a high-interaction SSH honeypot that uses a large language model (LLM) to generate realistic command output and shell behavior [2]. All our honeypots used the same fixed system prompt. The primary backend model was gpt-oss-120b, a locally deployed model that served 88.5% of sessions. The OpenAI models gpt-5-nano and gpt4.1-nano were used as a fallback provider during outages. The changes to the backend model do not affect our measurements, which concern the traffic attackers send to the honeypot rather than the responses it returns. AdvancedShelLM accepts any username and password combination as valid. This is standard practice in SSH honeypot work and maximizes the engagement of attackers. AdvancedShelLM implements both SSH exec requests, in which the client submits a single command without allocating a terminal, and shell channels, in which the client exchanges commands through an allocated terminal. It does not support data transfer commands such as scp or SFTP.
3.2
Data Collected
File-transfer sessions. The attacker attempts a file transfer via scp, rsync, sftp, or the standard sftp-server paths. Our modification to AdvancedShelLM does not implement these functionalities and refuses these attempts. These sessions are recorded with termination reason refused.
3.5
Haas: The External Validation Dataset
To check that our observations generalize beyond our own deployment, we compare them against an independent dataset collected with 4,737 Cowrie [14] SSH honeypots operated by “CZ.NIC" over the same time window [5]. We called this dataset HaaS. An agreement between the two datasets would increase confidence that our main results are not artifacts of our instrumentation or deployment choices. The HaaS dataset does not record the SSH session type, so we use expert heuristics to map its sessions to our three session types by only using the described commands in the logs. These are the heuristics applied, in priority order:
Deployment
(1) File-transfer sessions: These are those sessions whose first command token is one of the transfer programs: scp, rsync, sftp, or sftp-server). (2) Zero-command: the client logs in and sends no command. We discard these commandless sessions for this research. We do not know the reason for these zero-command sessions. (3) Single-command: exactly one command in the session with a median duration of approximately 0.18 seconds, which
We deployed eleven AdvancedShelLM instances on different virtual servers from a single cloud provider in Frankfurt, Germany. All instances shared the same hardware profile (2 GB RAM, 50 GB disk, Ubuntu 24.04 LTS x64), ran the same software configuration, and listened on the standard SSH port (TCP/22). Each instance was assigned a distinct public IPv4 address from the provider’s pool. These addresses are reused across tenants over time and are not 2
Sessions 176,256 179 1,187 177,622
Share 99.23% 0.10% 0.67% 100%
100 99
dataset mean 99.23%
98 97
97.60%
is too fast for a human to type. We consider this session non-interactive. (4) Multi-command: two or more commands in the session. We consider this session interactive.
fra -0 fra 0 -0 fra 1 -0 fra 2 -0 fra 3 -0 fra 4 -0 fra 5 -0 fra 6 -0 fra 7 -0 fra 8 -0 fra 9 -10
Mode Non-interactive exec Interactive shell File-transfer attempts (refused) Total
Non-interactive (%)
Table 1: Session-mode breakdown across all honeypots and the full 15-day window.
Heuristic bias. This mapping is approximate: (i) one-command sessions can still be interactive (shell opened, one probe, disconnect), inflating “non-interactive”; (ii) multiple exec requests can appear as multiple commands without an allocated shell, inflating “interactive”; (iii) the first-token rule misses wrapped transfers and subsystem-level SFTP, so file-transfer is a lower bound.
Figure 1: Fraction of authenticated sessions that are noninteractive per sensor. Every sensor sits at or above 97.60%, with the dashed line marking the dataset mean. Fra-00 through Fra-10 are the names of the cloud computers with the honeypots.
4
Table 2: Top ten non-interactive commands by session count. The top ten cover 41.59% of non-interactive traffic.
Sensor
Results
We group the results into specific findings from our data collection. Each subsection includes the validation results from the external dataset to facilitate the comparison to the reader.
4.1
Command
Most Sessions Are Non-Interactive Commands
Across the 11 sensors and the fifteen-day window we recorded 177,622 authenticated attack sessions from 1,997 unique source IP addresses, using 1,427 distinct usernames. Each session falls into exactly one of the three modes defined in Section 3.4: non-interactive sessions account for 176,256 (99.23%), interactive sessions for 179 (0.10%), and file-transfer sessions for 1,187 (0.67%). Table 1 summarizes the aggregate breakdown of session modes across our entire deployment window. This pattern is consistent across sensors and is not driven by a single high-volume host. Figure 1 reports, for each of the 11 sensors, the fraction of authenticated sessions that are non-interactive. The values range from 97.60% to 99.70%. We cross-checked this result against the CZ.NIC HaaS Cowrie dataset described in Section 3.5. In the matching window it contained 255,728 logged-in sessions from 6,579 unique source IPs. Among sessions that contained at least one command, 92.67% contained exactly one command. This matched our observations and indicated that non-interactive activity was not specific to our deployment.
4.2
Sessions
%
uname -s -v -n -r -m uname -a uname -m | awk ’{printf $1}’ echo ” whoami nproc lspci | egrep VGA && lspci | grep 3D uname -m export HOME=/dev/null . . . uptime
13,262 11,817 9,602 6,492 6,260 6,053 5,821 5,804 4,570 3,619
7.52 6.70 5.45 3.68 3.55 3.43 3.30 3.29 2.59 2.05
Top ten commands All other commands (9,374 distinct) No command recorded
73,300 102,927 29
41.59 58.40 0.02
Total (9,384 distinct)
176,256
100.00
they collect system and environment information without changing state. They query basic host properties (uname, nproc, lspci), identity (whoami), and uptime (uptime). We cross-checked command content in the external dataset, and the reconnaissance commands that are most common in our noninteractive traffic also appear in HaaS. Commands such as uname -a, whoami, pwd, uptime, and cat /proc/cpuinfo | grep ’model name’ | head -1 were common in both datasets, suggesting that the same automated campaigns reached both deployments.
Reconnaissance as Non-Interactive Commands
The distribution of non-interactive commands is highly concentrated: the ten most frequent commands account for 41.59% of all non-interactive sessions (Table 2). Across the full dataset we observed 9,384 distinct non-interactive command strings, but the most common commands are largely used for reconnaissance, because
4.3
Verifying if the Target is a Honeypot
Some non-interactive commands are not reconnaissance. Instead, they test whether a target behaves like a real host before the attacker invests further effort. We observe two kinds of such verification 3
probes: checks for a simulated shell, and checks for known honeypots. Each is described below.
drop in interactive sessions in October 2019 (from 22.8% to 9.0%), computed over sessions with at least one command, as in Section 3.5. In both cases, the change comes with a spike in total traffic, suggesting that a few large automated campaigns can move the monthly numbers, even though non-interactive sessions remain the majority overall. The biggest implication of this measurement is methodological: many SSH honeypot studies implicitly treat “post-authentication commands” as interactive shell activity. If most authenticated traffic is non-interactive, analyses that focus on interactive or multicommand sessions examine only a small subset of attacker behavior. Likewise, a honeypot that does not implement non-interactive requests produces a dataset that reflects what the honeypot allows, not what attackers attempt. To make results comparable, SSH honeypot studies should report which SSH modes are supported (shell, exec, subsystems such as SFTP) and the share of authenticated sessions observed in each mode. In deception design, non-interactive activities reduce the opportunity for narrative or dialogue-based techniques and shift the problem toward correctness under automation. It also challenges common evaluation metrics such as engagement time and interaction volume, because non-interactive sessions end quickly and a single TCP “session” may not correspond to a single actor’s activity. Recovering the intelligence value of one traditional interactive session, therefore, requires grouping many non-interactive sessions into meta-sessions per actor or campaign. Section 4.3 shows that some non-interactive commands are for verification: they check whether a target executes commands correctly, maintains state, and behaves like a real shell. This is a particular challenge for LLM-based shells, which can produce output that looks plausible but is not consistent with real execution. For these commands, engagement-based metrics are not informative. A more direct evaluation is (i) whether responses match a real system for common commands, (ii) whether state changes persist when re-checked, and (iii) how often the honeypot passes probe patterns observed in the wild. Across both datasets, we did not observe prompt-injection strings or explicit mentions of AI or model names. The verification activity we did observe was operational: attackers tested outputs and state rather than trying to steer a model through language. This does not rule out LLM-driven attackers, but it suggests that, in these datasets, the main pressure on LLM-based deception comes from executionchecking probes rather than conversational manipulation.
4.3.1 Checks for a simulated shell. The first kind tests whether the remote side executes commands and returns the correct output, rather than generating plausible text. This matters for LLM-based honeypots, which can answer in a way that looks reasonable but is not consistent with actual execution. We observed 2,178 simulated-shell check sessions in total. The largest campaign used a base64 decoding command. This campaign had 2,166 sessions from 4 IPs and it used commands like echo ’dGVzdA==’ | base64 -d, which should return the string test on a real system. Other commands included exact arithmetic (e.g., echo $((7*6))), binary dumps (e.g., cat /bin/echo), and state/timing checks such as writing a file and reading it back or sleep 0.1 && echo done. We found the same class of execution-check probes in the HaaS dataset, including campaigns that issued arithmetic and systemidentification sequences (e.g., echo $((7*6)); uname -m; cat /proc/uptime; head -1 /proc/version). One command in this family, cat /bin/echo, was far more common against Cowrie (1,064 sessions from 200 IPs) than against our dataset (2 sessions from 2 IPs). 4.3.2 Checks for a known honeypot. We observed 4 classic honeypotfingerprinting sessions from 1 source IPs. These probes look for tells of Cowrie and similar systems, such as listing processes for cowrie or kippo, testing whether /etc/passwd is writable, and checking for known fake users. We also checked the HaaS dataset for these fingerprinting commands. Using the same string-based detectors, we did not find corroborating classic fingerprinting sessions in HaaS. These results are discussed in Section 5. 4.3.3 What we did not find. We screened all 177,622 sessions for prompt-injection strings, explicit mentions of AI, LLMs, or named models, and fixed-string hash probes. None appeared. We repeated the same screen on the HaaS dataset and found no prompt-injection strings, no explicit mentions of AI/LLMs or model names, and no fixed-string hash probes.
5
Discussion
Our results suggest that post-authentication SSH attack activity is better described as a stream of atomic automated checks and short reconnaissance commands than as interactive operator sessions. In our deployment, 99.23% of authenticated sessions consisted of a single non-interactive exec request, while only 0.10% opened an interactive shell. The CZ.NIC HaaS dataset from 4,737 honeypots shows the same pattern in the matching window. To see when this shift occurred, we examined the HaaS archive over multiple years. Across 433,132,596 sessions from 2017 to 2026, non-interactive sessions have been common since at least 2018. This suggests many attackers now use SSH in a more automated way: log in, run one quick command, and move on as part of a larger scan or exploit run. The changes happen from month to month. The biggest changes are a +17.3 percentage-point jump in non-interactive sessions in October 2024 (from 80.1% to 97.4%) and a −13.8 percentage-point
6
Limitations
Our measurement reflects what honeypots on commodity cloud address space can see: indiscriminate, Internet-wide automated activity against hosts that accept any credentials. Attackers targeting a specific production system may still behave interactively, and our results do not cover them. The honeypot also shapes its own data: it refuses file transfers, and a campaign that probes a host before engaging further may stop after a failed check, which would inflate the non-interactive share by the very mechanism we document. 4
7
Future Work
[12] Xingyun Liu. 2026. Puzzle Pot: Challenge Based Honeypot Framework for Detecting and Defending Against Autonomous LLM Agents. International Journal of Software Engineering and Knowledge Engineering (March 2026), 1–27. doi:10.1142/S0218194026410032 [13] Cristian Munteanu, Yogesh Bhargav Suriyanarayanan, Georgios Smaragdakis, Anja Feldmann, and Tobias Fiebig. 2025. Attacks Come to Those Who Wait: LongTerm Observations in an SSH Honeynet. In Proceedings of the 2025 ACM Internet Measurement Conference (IMC ’25). Association for Computing Machinery, New York, NY, USA, 628–644. doi:10.1145/3730567.3764475 [14] Michel Oosterhof. 2026. Cowrie SSH/Telnet Honeypot. https://github.com/ cowrie/cowrie [15] Hakan T. Otal and M. Abdullah Canbaz. 2024. LLM Honeypot: Leveraging Large Language Models as Advanced Interactive Honeypot Systems. In 2024 IEEE Conference on Communications and Network Security (CNS). IEEE, Taiwan, 1–6. ISSN: 2994-5895. doi:10.1109/CNS62487.2024.10735607 [16] Jarrod Ragsdale and Rajendra V. Boppana. 2023. On Designing Low-Risk Honeypots Using Generative Pre-Trained Transformer Models With Curated Inputs. IEEE Access 11 (2023), 117528–117545. doi:10.1109/ACCESS.2023.3326104 [17] Reworr and Dmitrii Volkov. 2025. LLM Agent Honeypot: Monitoring AI Hacking Agents in the Wild. arXiv:2410.13919 [cs.CR]. doi:10.48550/arXiv.2410.13919 [18] Muris Sladić, Veronica Valeros, Carlos Catania, and Sebastian Garcia. 2024. LLM in the Shell: Generative Honeypots. In 2024 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, Austria, 430–435. ISSN: 2768-0657. doi:10.1109/EuroSPW61312.2024.00054 [19] Muris Sladić, Veronica Valeros, Carlos Catania, and Sebastian Garcia. 2025. VelLMes: A High-Interaction AI-Based Deception Framework. In 2025 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, Italy, 671–679. ISSN: 2768-0657. doi:10.1109/EuroSPW67616.2025.00082 [20] Shreyas Srinivasa, Jens Myrup Pedersen, and Emmanouil Vasilomanolakis. 2022. Interaction matters: a comprehensive analysis and a dataset of hybrid IoT/OT honeypots. In Proceedings of the 38th Annual Computer Security Applications Conference (ACSAC ’22). Association for Computing Machinery, New York, NY, USA, 742–755. doi:10.1145/3564625.3564645 [21] Shreyas Srinivasa, Jens Myrup Pedersen, and Emmanouil Vasilomanolakis. 2023. Gotta Catch ’em All: A Multistage Framework for Honeypot Fingerprinting. Digital Threats: Research and Practice 4, 3 (Sept. 2023), 1–28. doi:10.1145/3584976 [22] Christoforos Vasilatos, Dunia J. Mahboobeh, Hithem Lamri, Manaar Alam, and Michail Maniatakos. 2025. LLMPot: Dynamically Configured LLM-based Honeypot for Industrial Protocol and Physical Process Emulation. In 2025 IEEE 10th European Symposium on Security and Privacy (EuroS&P). IEEE, Italy, 963–979. doi:10.1109/EuroSP63326.2025.00059 [23] Ziyang Wang, Jianzhou You, Haining Wang, Tianwei Yuan, Shichao Lv, Yang Wang, and Limin Sun. 2024. HoneyGPT: Breaking the Trilemma in Terminal Honeypots with Large Language Model. arXiv:2406.01882 [cs]. doi:10.48550/ arXiv.2406.01882 [24] Simon B. Weber, Marc Feger, and Michael Pilgermann. 2024. Don’t Stop Believin’: A Unified Evaluation Approach for LLM Honeypots. IEEE Access 12 (2024), 144579–144587. doi:10.1109/ACCESS.2024.3472460 [25] Matej Zuzčák and Petr Bujok. 2019. Causal analysis of attacks against honeypots based on properties of countries. IET Information Security 13, 5 (2019), 435– 447. _eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1049/iet-ifs.2018.5141. doi:10.1049/iet-ifs.2018.5141
Our future work includes three directions. First, a longer deployment across more providers and address space, with file-transfer support, to test how much the vantage point and the honeypot interface shape the traffic. Second, a controlled experiment in which honeypots deliberately pass or fail verification probes, to measure whether surviving a check changes what attackers send next. Third, grouping non-interactive sessions into meta-sessions per campaign and developing the probe-passing metric into a benchmark against which LLM-based honeypots can be evaluated before deployment.
8
Conclusion
Our measurements show that most authenticated SSH attacks do not use an interactive shell. In our deployment, 99.23% of sessions consisted of a single non-interactive exec command and completed at machine speed; the independent Cowrie dataset showed the same pattern. This implies that shell-centric honeypot deployments and analyses systematically miss the dominant post-login behavior. Within this non-interactive traffic, we observed verification probes, including probes that test whether a target actually executes commands. These findings suggest two practical consequences for SSH deception: honeypots should support non-interactive exec requests to capture most authenticated traffic, and evaluation should emphasize per-command correctness and robustness to automated verification rather than session length or dialogue turns.
Acknowledgments This work was supported by the Ministry of Education, Youth and Sports of the Czech Republic through the e-INFRA CZ (ID: 90254).
References [1] AbdelRahman Abdou, David Barrera, and Paul C. van Oorschot. 2016. What Lies Beneath? Analyzing Automated SSH Bruteforce Attacks. In Technology and Practice of Passwords, Frank Stajano, Stig F. Mjølsnes, Graeme Jenkinson, and Per Thorsheim (Eds.). Springer International Publishing, Cham, 72–91. doi:10.1007/ 978-3-319-29938-9_6 [2] Eman Alibalić, Muris Sladić, and Sebastian Garcia. 2026. AdvancedSheLLM. https://github.com/stratosphereips/SheLLM [3] Daniel Ayzenshteyn, Roy Weiss, and Yisroel Mirsky. 2025. Cloak, Honey, Trap: Proactive Defenses Against LLM Agents. In 34th USENIX Security Symposium (USENIX Security 25). USENIX Association, USA, 8095–8114. https://www.usenix. org/conference/usenixsecurity25/presentation/ayzenshteyn [4] Robert A. Bridges, Thomas R. Mitchell, Mauricio Muñoz, and Ted Henriksson. 2026. SoK: Honeypots & LLMs, More Than the Sum of Their Parts? arXiv:2510.25939 [cs.CR]. doi:10.48550/arXiv.2510.25939 [5] CZ.NIC. 2017. Honeypot as a Service (HaaS). https://haas.nic.cz/ [6] Wenjun Fan, Zichen Yang, Yuanzhen Liu, Lang Qin, and Jia Liu. 2025. HoneyLLM: A Large Language Model-Powered Medium-Interaction Honeypot. In Information and Communications Security, Sokratis Katsikas, Christos Xenakis, Christos Kalloniatis, and Costas Lambrinoudakis (Eds.). Springer Nature, Singapore, 253–272. doi:10.1007/978-981-97-8801-9_13 [7] Daniel Fraunholz, Marc Zimmermann, Alexander Hafner, and Hans D. Schotten. 2017. Data Mining in Long-Term Honeypot Data. In 2017 IEEE International Conference on Data Mining Workshops (ICDMW). IEEE, USA, 649–656. doi:10. 1109/ICDMW.2017.92 [8] Amir Javadpour, Forough Ja’fari, Tarik Taleb, Mohammad Shojafar, and Chafika Benzaïd. 2024. A comprehensive survey on cyber deception techniques to improve honeypot performance. Computers & Security 140 (May 2024), 103792. doi:10. 1016/j.cose.2024.103792 [9] Adel Ka. 2023. 0x4D31/galah. https://github.com/0x4D31/galah [10] Ioannis Koniaris, Georgios Papadimitriou, and Petros Nicopolitidis. 2013. Analysis and visualization of SSH attacks using honeypots. In Eurocon 2013. IEEE, Zagreb, Croatia, 65–72. doi:10.1109/EUROCON.2013.6624967 [11] Ondřej Koutský. 2014. Monitoring and Analysis of Cyber Attacks. Master’s thesis. Masaryk University, Brno, Czech Republic. https://is.muni.cz/th/gguo9/
A
Ethical Considerations
Our honeypots logged only the traffic that attackers sent to them. We collected no personal data beyond source IP addresses, which we use only in aggregate and do not publish. No human subjects were involved in this study.
B
Generative AI Usage
The authors used LLM assistance (Anthropic Claude Opus 4.7) to improve the language, grammar, and flow of this paper. Additionally, LLM assistance was used to code-review data-processing scripts to automate the analysis. All ideas, structure, and text were created by the authors. The authors reviewed and edited all outputs. The authors take full responsibility for the content of the paper.
5