In Part 1, we watched what happened when a basic internet-facing honeypot was placed online for one hour.
The first phase was mostly discovery. Scanners found the server, web probes arrived, SSH brute-force attempts started, and traffic came from multiple countries and cloud providers. Nothing about the system was advertised, indexed, or promoted, but the internet still found it quickly.
That was the first lesson.
A server does not need to be important to be attacked. It only needs to be reachable.
Part 2 is where the experiment became more interesting. This time, we moved beyond simple discovery and started observing actual interaction. Not just scans, not just connection attempts, and not just failed logins.
We saw attackers log in to the honeypot environment and begin running commands.
And once that happened, the behavior became much more revealing.
From Scanning to Interaction
During this one-hour window, the honeypot recorded 1,327 total attack events.
Some of those events were simple scans. Others were connection attempts, brute-force activity, service fingerprinting, or automated probing. That distinction matters because not every "attack" means someone got a shell.
A large part of internet noise is shallow. A bot checks whether a service exists, collects a banner, tries a few requests, and moves on. But a smaller subset of activity crosses the line into interaction.
In this experiment, 61 SSH and Telnet sessions reached the point where commands were executed.
That was the interesting part.
Those sessions showed what happens when an attacker, or more realistically an automated bot, believes it has gained access to a real Linux system.
Credential Guessing: The First Door They Tried
Before attackers can run commands, they need to get through the login prompt. In a honeypot, that gives us a useful look at the usernames and passwords bots are trying in the wild.
The most targeted username was exactly what most defenders would expect: root.
Attackers are still heavily betting on the simplest possible Linux target. If SSH is exposed, they are going to try root. They are also going to try application names, database users, cryptocurrency-related names, and generic service accounts.
Some of the observed username attempts included root, admin, ubuntu, test, test1, test2, deployer, deploy, postgres, oracle, centos, sysadm, user33, buser, esuser, rouser, ftpuser1, appuser, wwwuser, hdfs, trader, trading, exchange, bitcoin, ethereum, minecraft, teamspeak, lighthouse, danial, vncuser, and pi.
This mix is interesting because it shows several attacker assumptions at once. They are looking for default Linux users. They are checking database and infrastructure accounts. They are also testing application or industry-themed accounts such as trader, trading, exchange, bitcoin, and ethereum.
That last group is worth paying attention to. Attackers are not only trying generic credentials. They are also guessing based on what kind of system they hope they found. A server that looks like it might be related to finance, crypto, or trading gets username guesses that match those themes.
The password attempts told the same story from the other side. Some notable entries included: 123456, 12345678!, 123456789, 1Qaz2wsx!, Passw0rd, P@$$w0rd, Admin#123, Qwerty@123321, Qwerty12345, Welcome2026@, Oracle2024, Azerty2025, trader, and 3245gs5662d34.
A few patterns stand out immediately.
Weak numeric passwords are still everywhere. Variants of 123456, 123456789, 11111, 2222, and 0000 appeared in the dataset.
Keyboard walks and predictable complexity tricks are common. Passwords like 1Qaz2wsx!, 12qwaszx, and Qwerty12345 look complex to a human but follow keyboard patterns and are well-known in credential lists.
Symbols and capitalization get added to weak base words. P@$$w0rd, Passw0rd, Admin#123, and admin+123 are classic examples of people meeting complexity requirements without achieving real strength.
Themed credentials appeared. The password trader standing alongside usernames like trader, trading, and exchange suggests bots were testing credentials shaped by what kind of system they hoped to find.
What Happened After Login
Once inside the fake shell environment, the behavior followed a clear pattern.
The attackers started by checking the system. They looked at basic information such as the current user, system type, CPU, memory, disk space, and available tools. This reconnaissance is simple, but it tells us a lot. Even low-level bots need to decide what kind of machine they have landed on before choosing what to do next.
Some sessions attempted to create users. Others interacted with SSH keys, adding or deleting access. Several checked resources like disk, CPU, and memory. Some tried to clean up files and processes that looked like they belonged to other malware.
That last part was one of the most interesting findings.
The attackers were not only trying to use the machine. They were trying to prepare it, clean it, and potentially keep it for themselves.
Reconnaissance First
A lot of the early commands were basic system checks: uname, whoami, id, disk checks, memory checks, and CPU inspection. This is typical post-login behavior. The attacker wants to know what kind of system they are dealing with, what permissions they have, and whether the machine is useful.
Most of it looked automated. The commands appeared in patterns that suggest scripts were running through a checklist.
A bot does not need to understand the system deeply. It only needs enough information to decide whether to deploy a payload, attempt persistence, or move on.
Persistence Attempts
Some sessions moved beyond reconnaissance and started touching access mechanisms.
We saw behavior related to creating users and manipulating SSH keys. SSH keys are especially interesting because they are a clean way to come back later. If an attacker can place their own public key into an authorized_keys file, they may not need the original password again. Even if the weak password is changed, that key could still allow access if it remains in place.
Some activity also involved deleting or replacing keys. That can be about cleanup, but it can also be about competition. A compromised machine is not always controlled by one actor. Multiple bots may find the same exposed system, and each one may try to remove traces of the others.
Cleaning Other Bots
One of the clearest examples was a command chain that removed temporary scripts, killed processes with related names, cleared access deny rules, and terminated sleep processes.
Temporary directories are commonly abused by malware because they are writable on many Linux systems. Scripts get dropped there, executed, and sometimes abandoned. Killing processes with matching names suggests the attacker was trying to terminate existing malware or previous bot activity. Clearing deny rules may remove restrictions that could interfere with access.
This was not just "run a payload and leave." It looked more like: remove old scripts, kill competing processes, clear anything that might block access, prepare the machine for the next stage.
Botnet landlord behavior. The compromised server becomes a resource, and different bots compete over it. They want CPU, bandwidth, persistence, and control. If another bot is already there, they may try to kick it out.
Geography and Reputation
In Part 1, we saw early traffic from several countries during the discovery phase. In Part 2, the more interactive sessions also came from geographically diverse infrastructure.
The most notable sources during this window were associated with Indonesia, Turkey, and Austria. The Indonesian source had the highest VirusTotal detection ratio in this sample, followed closely by activity from Turkey.
We are intentionally not publishing the source IP addresses. Raw IPs can be misleading. The country shown in logs usually represents where the traffic appeared to originate from, not necessarily where the real operator is. It could be a compromised VPS, a proxy, a rented server, a residential bot, or one small piece of a much larger botnet.
Why Only 61 Sessions Ran Commands
Out of 1,327 total attack events, only 61 sessions resulted in command execution.
That ratio is useful because it shows how much of the internet's hostile background noise is shallow. Many systems scan. Fewer attempt credentials. Fewer still reach the point where they believe they have access.
This gives us a simple behavioral funnel: a lot of scanners touch the system, some try to authenticate, a smaller group enters the fake shell, then a smaller group begins post-login activity.
For defenders, this distinction is important. Firewall logs may show connection attempts. Authentication logs may show brute-force behavior. But command telemetry shows what the attacker wanted to do after access. That last layer is where the story becomes much more useful.
What This Teaches Beginners
The biggest lesson from this second phase is that compromise behavior is often automated, repetitive, and fast.
There was no cinematic attacker carefully exploring the machine. What we saw looked much more like scripts running through a checklist: check the system, check permissions, check resources, try to create access, modify keys, remove competitors, prepare for payloads.
Most internet-facing machines are not initially touched by elite operators. They are touched by automation at scale. And automation does not care who owns the server, whether it has a domain name, or whether the system was deployed five minutes ago.
If it is reachable, it gets tested. If it accepts weak credentials, it gets used.
Defensive Takeaways
Exposed remote access services should be treated seriously. Telnet should not be exposed on a real system. SSH should use key-based authentication and ideally some form of restriction such as IP allowlisting, VPN access, or cloud firewall rules.
Logging matters. The most interesting details were not visible from basic connection logs alone. Command-level telemetry was needed to understand what attackers attempted after login.
Password complexity rules alone are not enough. Many attempted passwords look complex but are still predictable. Keyboard walks, years, and simple numeric sequences remain heavily abused.
Persistence can happen quickly. Automated tooling can attempt to add users or SSH keys almost immediately after login.
Bots compete. The cleanup behavior showed that attackers expect other malware to already exist on compromised systems. Vulnerable machines are part of a crowded underground economy.
What Comes Next in Part 3
Part 3 is where things get more interesting.
Instead of only watching SSH and Telnet behavior, we are going to introduce additional protocols and more realistic deception paths. We also want to move beyond the honeypot itself and start exploring attacker infrastructure: payload sources, command-and-control patterns, download servers, and whether the commands point back to known botnets.
The goal is to answer better questions. Where did the payload come from? Was the infrastructure reused? Were multiple sources using the same scripts? Can we map relationships between IPs, domains, hashes, credentials, and command patterns?
Part 1 showed how fast the internet finds you.
Part 2 showed what the first wave does once it thinks it got in.
Part 3 will follow the trail further.
Stay tuned.
Next Episode → Honeypot: Operation Nightfall — Part 3