Anyone who runs a server with SSH exposed to the internet sees the same pattern in the logs: a steady stream of automated scanners trying to log in, hour after hour, from addresses all over the world. The common picture of what comes next—an attacker landing a shell, looking around the system, and typing commands—is almost entirely wrong. The reality, recorded across eleven research honeypots over 15 days, looks nothing like that.

Massive dataset from Frankfurt honeypots

Eleven SSH honeypots were deployed on cloud servers in Frankfurt, Germany, for 15 days in late May and early June 2026, as part of a study by researchers at Czech Technical University in Prague. Together they logged 177,622 authenticated sessions, meaning every single one was an attacker who successfully logged in. The split among those sessions was lopsided: non-interactive sessions—where a client logs in, runs a single command, reads the output, and disconnects—accounted for 99.23% of the total. Interactive shell sessions, the kind the honeypot field was built to study, came to only 0.10%. File transfers made up the small remainder.

A non-interactive session works in a particular way. The client authenticates, issues a single command through an SSH exec request, and the server closes the channel without allocating a terminal. The whole exchange finishes in under a second—faster than a person can type. These are scanners and exploit scripts running at machine speed, logging in to confirm a fact about the host and moving on. The sheer volume underscores how automated modern SSH attacks have become.

Results validated by independent dataset

The honeypots ran on a modified version of an open-source tool called AdvancedShelLM, which uses a large language model to generate realistic shell output. A locally hosted model handled most sessions, with two OpenAI models as backup. The backend governed the responses the honeypots returned, and the measurement concerned the traffic attackers sent, which the model does not influence.

To confirm the result held beyond their own deployment, the researchers compared it against an independent dataset from CZ.NIC, the operator of a honeypot service built on thousands of Cowrie sensors. That dataset held more than a quarter of a million logged-in sessions over the same window. Among sessions that carried at least one command, 92.67% carried exactly one command. The pattern held on hardware run by a different operator, reinforcing that non-interactive traffic is not an artifact of a single honeypot implementation.

Most traffic is reconnaissance

The ten most common non-interactive commands covered 41.59% of that traffic, and most of them gather basic facts about the machine. Variants of uname, which reports the operating system and kernel, sat at the top of the list. Others asked for the processor count, the logged-in user, the graphics hardware, and the system uptime. These commands collect information that tells an automated campaign whether the box is worth a second look or belongs to a known vulnerability profile.

This aligns with the broader trend of automated reconnaissance: attackers build weaponized databases of vulnerable hosts by scanning the internet at scale. The honeypot data suggests that after authentication, most tools simply probe for OS type, architecture, and uptime before deciding whether to attempt exploitation. The rarity of interactive sessions means that full-blown manual intrusions are far less common than logs imply, but the noise they create must still be managed.

Some scanners check whether you are the trap

A smaller group of commands had a different job: testing whether the thing answering them runs commands for real. The team recorded 2,178 sessions of this kind. One campaign sent a base64-encoded string and decoded it—an operation that returns a known answer on a working system. Others asked for simple arithmetic, dumped the contents of a binary, or wrote a file and read it back.

This carries weight for the newer class of honeypots built on language models. A model can produce shell output that looks plausible but is wrong. A scanner that checks the math, decodes the string, or confirms that a file persists catches the difference in a single command. Success for these honeypots comes down to surviving that check. The fact that such checks exist shows that attackers are becoming more sophisticated in distinguishing real servers from research traps.

Honeypot operators fingerprinting attackers is old ground. The reverse showed up here as well: a handful of sessions looked for the tells of known honeypots, listing processes for Cowrie or kippo and testing whether system files were writable. The counts were small, and the authors treat them with care, but it underscores an arms race between defenders and automated adversaries.

Scanners tested outputs and machine state. The team screened every session for prompt-injection strings and for mentions of AI or model names, and found none of either. Worry about attackers talking their way past a language model has little support in this data, at least for now. However, the potential remains, and honeypot operators must stay vigilant as LLM-based defenses become more common.

A habit that settled years ago

The historical record points to a settled behavior. CZ.NIC’s archive runs back to 2017 and holds more than 400 million sessions, and non-interactive traffic has been the majority since around 2018. One sharp move came in October 2024, when the non-interactive share climbed to 97.4% in a single month—a jump of more than seventeen percentage points—alongside a spike in total volume. That spike may correlate with the release of new automated scanning tools or the discovery of widely exploitable vulnerabilities, but the long-term trend is clear: interactive attacks are a tiny fraction of the threat landscape.

The result carries a warning for how honeypots get judged. Many designs measure success by engagement, counting how long an attacker stays and how many commands they run. A traffic stream made almost entirely of single sub-second commands gives those metrics little to work with. A honeypot that only offers an interactive shell and refuses non-interactive requests records a version of attacker behavior the honeypot itself created—a distorted view of reality.

The login attempts filling the logs are mostly triage. An automated client confirms the host is real, files it for later, and leaves. The value sits in recognizing that pattern and grouping the noise into campaigns, so a thousand one-second touches resolve into the handful of operations behind them. For defenders, this means shifting from analyzing individual sessions to identifying campaign fingerprints across millions of events.

From a security operations perspective, the dominance of non-interactive SSH traffic has implications for intrusion detection systems. Signature-based detection of malicious commands may miss the vast majority of traffic if it focuses only on interactive shells. Instead, analyzing sequences of single-command logins from distinct IP addresses and correlating them with known scanner patterns can yield more actionable intelligence. The study also highlights that even something as simple as a uname -a can be part of a coordinated campaign, not a random probe.

The research adds to a growing body of evidence that the internet’s threat landscape is overwhelmingly automated. Honeypots that fail to simulate realistic non-interactive responses will record either nothing or skewed data. AdvancedShelLM and similar tools represent a step forward, but the arms race continues: as honeypots get better, scanners get better too. The presence of commands designed to detect honeypots proves that attackers are already adapting.

Network administrators should take away several lessons. First, rate-limiting and blacklisting IP addresses that send only single-command SSH sessions can reduce noise, but must be done carefully to avoid blocking legitimate automation. Second, deep analysis of the commands themselves can reveal campaign infrastructure—for example, the same base64 decoder appearing across thousands of sessions likely belongs to the same toolchain. Third, the near absence of interactive attacks suggests that for most attackers, the goal is information gathering, not immediate exploitation. That information feeds later, more targeted attacks.

In the end, the study’s core finding is straightforward: the SSH threat is not what it appears to be. The logs show a firehose of logins, but virtually all of them are machine-speed probes that last less than a second. Defenders who fail to understand this will waste time analyzing non-events. The real work is in aggregating those probes into clusters and tracking the actors behind them—a shift from incident response to intelligence-driven defense.

Source: Help Net Security News