SSH Honeypots May Miss Most Post-Login Attacks by Focusing on Interactive Shells

SSH honeypots may be missing most post-login attacker behavior because many are designed around interactive shell sessions, while real attackers increasingly use fast, automated, non-interactive commands. A new Ghost Without Shell study found that 99.23% of authenticated SSH sessions in its deployment were non-interactive.

The research was conducted by Veronica Valeros, Muris Sladić, and Sebastian Garcia from Czech Technical University in Prague. The team deployed eleven SSH honeypots for 15 days and collected 177,622 authenticated sessions.

The key finding is simple: attackers usually do not log in, open a shell, and type commands manually. Most authenticate, run one command through SSH exec mode, read the output, and disconnect in less than a second.

What the Researchers Found

The results challenge a long-standing assumption in SSH deception research. Many honeypots are built to keep attackers inside a realistic shell, but the study found that interactive shell activity made up only a tiny share of post-login sessions.

A report from Help Net Security highlighted the same point, noting that the measured traffic looked more like machine-speed scanning than a person manually exploring a system.

The researchers also validated their result against a separate Cowrie-based dataset from CZ.NIC’s Honeypot as a Service network. That independent dataset showed the same broad pattern, which reduces the chance that the finding came from one unusual honeypot deployment.

Session type	Sessions observed	Share of total
Non-interactive SSH exec	176,256	99.23%
Interactive shell	179	0.10%
File-transfer attempts	1,187	0.67%
Total authenticated sessions	177,622	100%

How Non-Interactive SSH Attacks Work

In a normal interactive SSH session, a user logs in and receives a shell prompt. The user can then type multiple commands, inspect output, change directories, and continue working.

Non-interactive SSH works differently. The client authenticates, sends a single command through an exec request, receives the response, and disconnects without opening a terminal shell.

For attackers running automated campaigns, this is faster and easier to scale. A bot can test thousands of systems with one command each, then decide which targets deserve more attention later.

• Attackers authenticate with guessed, reused, or leaked credentials.
• The SSH client sends one command through exec mode.
• The server returns output without allocating an interactive shell.
• The attacker disconnects almost immediately.
• The command often checks system identity, hardware, uptime, or whether the target behaves like a real host.

Common Commands Show Fast Reconnaissance

The study recorded 9,384 distinct non-interactive command strings. However, the top ten commands accounted for 41.59% of non-interactive traffic, showing that a relatively small set of automated probes drove much of the activity.

Common commands included uname, whoami, nproc, lspci, and uptime. These commands collect basic host details such as kernel version, architecture, active user, CPU count, graphics hardware, and uptime.

The same command patterns also appeared in the CZ.NIC dataset, suggesting that automated campaigns reached different honeypot networks with similar reconnaissance logic.

Command type	What attackers learn	Why it matters
uname variants	Kernel, OS, hostname, architecture	Helps classify the target system
whoami	Current user identity	Shows what privilege level the login received
nproc	CPU count	Helps estimate system capacity
lspci checks	Hardware and graphics devices	May help identify useful mining or compute targets
uptime	System running time and load	Helps assess stability and activity

Verification Probes Are a Problem for LLM Honeypots

Some non-interactive commands did not simply collect host details. The researchers found 2,178 simulated-shell check sessions designed to test whether the system executed commands correctly.

These checks included base64 decoding, arithmetic expressions, binary reads, timing checks, and state tests where a command writes data and then reads it back. A real system should return exact results, while a simulated shell may produce plausible but wrong output.

This is especially important for AI-powered honeypots. The AdvancedShelLM paper describes an LLM-based SSH honeypot built to improve stateful deception, but the new measurement study shows that attackers may judge realism with one exact command rather than a long conversation.

Why Interactive Metrics Can Mislead Defenders

Many deception systems measure success through engagement time, command count, or how long an attacker stays connected. Those metrics make sense when attackers open shells and explore manually.

They make less sense when the dominant behavior is a single command that completes in around a fraction of a second. A short session may not mean the honeypot failed. It may mean the attacker’s automation completed exactly what it intended to do.

The research paper argues that SSH honeypot evaluations should report which modes they support, including shell, exec, and file-transfer subsystems, and should measure whether responses match real system behavior.

• Session length is a weak metric when most sessions are automated.
• Command count can hide the value of one high-signal probe.
• Shell realism matters less if attackers never request a shell.
• Correct output matters more when probes test exact command behavior.
• Researchers should separate shell, exec, and file-transfer traffic in datasets.

Cowrie Validation Made the Result Stronger

Cowrie remains one of the best-known SSH and Telnet honeypots. The Cowrie documentation describes it as a medium-to-high-interaction honeypot designed to log brute-force attacks and shell interaction.

The Czech Technical University researchers compared their deployment with a dataset from CZ.NIC Honeypot as a Service, which simulates an operating system and records commands from attackers who log in through SSH or Telnet.

In the matching window, that independent dataset contained 255,728 logged-in sessions from 6,579 unique source IPs. Among sessions that had at least one command, 92.67% contained exactly one command.

Dataset	What it showed	Why it matters
Eleven AdvancedShelLM honeypots	99.23% of authenticated sessions were non-interactive	Shows the pattern in a controlled research deployment
CZ.NIC Cowrie dataset	92.67% of command-carrying sessions had one command	Confirms the pattern in an independent honeypot network
Historical HaaS archive	Non-interactive traffic has been common since at least 2018	Suggests this is not a sudden one-week anomaly

What This Means for SSH Honeypot Design

Honeypots should support non-interactive exec requests if they want to capture the dominant post-login behavior seen in this study. A shell-only system may record the traffic it allows, not the traffic attackers actually send.

Designers also need accurate command output. If a probe asks the system to decode a string, calculate a number, show a binary file, or preserve a file write, the honeypot needs to behave like a real host.

That may push LLM honeypots toward hybrid designs. The ShellGames paper proposes a shell simulator with techniques such as persistent state, speculative command execution, and routing complex commands to a sandboxed environment.

LLM Honeypots Still Have a Role

The study does not make LLM-based honeypots useless. It shows that they need to solve a different problem than long-form attacker conversation alone.

For non-interactive attacks, the main test is not whether the honeypot sounds convincing over many turns. The main test is whether it returns correct, consistent, and fast responses to automated probes.

The AdvancedShelLM research focuses on improving stateful SSH deception, while the ShellGames research highlights consistency, persistent state, and command accuracy. Those areas now look more important because attackers may only give the system one chance to answer correctly.

Limitations of the Study

The study focused on honeypots in commodity cloud address space that accepted any credentials. That is useful for measuring broad internet scanning, but it may not reflect how a targeted attacker behaves after compromising a specific production server.

The researchers also note that their deployment refused file-transfer attempts. That means the measured share of file-transfer behavior should be read carefully, since the honeypot interface itself shaped what could happen after authentication.

Still, the matching result in the CZ.NIC HaaS network gives the finding more weight. It shows that the single-command pattern appeared outside the researchers’ own sensors.

How Security Teams Should Adapt

Security teams that use SSH honeypots should review what their sensors actually support. A honeypot that ignores or mishandles exec requests may miss the first and only command an automated attacker sends.

Teams should also update how they evaluate honeypot success. A useful sensor may not keep attackers connected for long, but it should record exec commands accurately, respond realistically, and help analysts group short sessions into broader campaigns.

Help Net Security’s coverage of the research makes the same practical point: the value lies in recognizing automated patterns and turning many one-second touches into campaign-level intelligence.

• Enable logging for SSH exec requests, not only interactive shells.
• Record command mode, command output, duration, source IP, credentials, and termination reason.
• Separate non-interactive, interactive, and file-transfer sessions in reports.
• Test honeypots against exact-output probes such as decoding, arithmetic, file writes, and timing checks.
• Group repeated single-command sessions into campaigns instead of treating each as isolated noise.
• Do not judge honeypot success only by dwell time or number of commands.

Bottom Line

The study shows that SSH attackers are often automated, fast, and non-interactive after login. They do not need a convincing shell prompt if their goal is to run one probe and move on.

That finding does not end the use of SSH honeypots. It means the field needs better measurement. Honeypots should capture SSH exec mode, return accurate command results, and report session type clearly.

The Cowrie project and newer LLM-based deception work show how important SSH honeypots remain for threat intelligence. The next step is making sure they see the behavior attackers actually use, not only the behavior older honeypot models expected.

FAQ