When You Give the Internet More to Find, It Finds More
Part 1 showed how fast a server gets discovered. Fourteen minutes was all it took before the first probe arrived.
Part 2 showed what happens in the first hour. Credential guessing. Post-login commands. Bots competing over the same fake system like landlords evicting tenants.
Part 3 is different.
This time we extended the window to twelve hours, expanded the attack surface significantly, and started following the trails attackers left behind. Not just logging what hit us - but investigating where it came from, what it wanted, and what it was part of.
In twelve hours we recorded 24,435 attack events across multiple protocols and services. The number is significant but the breakdown behind it is more interesting than the total.
We also want to address something directly in this part. If you are reading this and thinking your organisation is too small, too obscure, or too unimportant to be targeted - this experiment was specifically designed to challenge that assumption. This server was online on a weekend. It had no domain name. It was not advertised anywhere. Nobody knew it existed. And it still received over twenty four thousand attack events in twelve hours. Size and importance are irrelevant to automated scanners. Reachability is the only criteria that matters.
What We Exposed This Time
In the previous experiments the surface was intentionally minimal. SSH, Telnet, and a basic web portal. That was enough to generate meaningful data but it left a lot of the threat landscape invisible.
For this phase we made a deliberate decision to expand the attack surface significantly. The reasoning was straightforward - the more services we exposed, the richer the picture we could build of what the internet is actively scanning for. It worked. Within minutes of the server coming online, probes were arriving across multiple protocols simultaneously.
The full list of services we monitored:
- Remote access: SSH on port 22, Telnet on port 23
- File transfer: FTP on ports 20 and 21
- Web services: HTTP on port 80, HTTPS on port 443
- Databases: MySQL on port 3306, MongoDB on port 27017, Redis on port 6379, MSSQL on port 1433
- Network services: SMB on port 445, MQTT on port 1883, SNMP on port 161
- Industrial protocols: Modbus on port 502, IEC-104 on port 2404, IPMI on port 623, proprietary meter protocols on ports 1025 and 10001
- VoIP: SIP on port 5060
- Email: SMTP on port 25
- Remote management: PPTP on port 1723
Each service was a deliberate trap. Each one represents something real organisations run every day. And each one attracted a different kind of attacker with a different objective.
The important point here is that automated scanners do not care whether a service is a honeypot or a real production system. They are not making that determination. They see an open port responding to a known protocol and they proceed. That means everything we observed is a direct mirror of what would happen to any real server running the same services.
The Numbers Behind the Noise
Of the 24,435 total events:
- SSH and Telnet accounted for just over 21,000 - roughly 86 percent of all activity
- VoIP probes came in at approximately 1,000
- SMB and service exploitation attempts reached 851
- Web application attacks through our HTTP services totalled 653
- Redis probes came in at 624
- Android debug bridge probes reached 398
- Industrial protocol probes across all ICS services totalled around 119
- General protocol traps caught 99 events
- Printer protocol probes logged 87
- Mail service probes recorded 47
The distribution tells a clear story. SSH and Telnet dominate because they offer the highest value outcome - a remote shell. Everything else is opportunistic. Attackers scan for databases, industrial systems, and VoIP because those services have specific exploitable value, but shell access on a Linux system remains the primary prize.
SSH and Telnet: Still the Front Door in 2026
It would be easy to dismiss SSH brute forcing as a solved problem. Use key authentication, disable passwords, done. But the volume of attempts - over twenty thousand in twelve hours against a single honeypot - tells you that this approach is still working somewhere at scale.
The credential patterns were consistent with what we saw in Part 2 but expanded. Attackers tried default Linux users, database service accounts, application names, cryptocurrency themed credentials, and generic admin variations. The wordlists being used are not random. They are curated over years of real compromise data, updated regularly, and deployed automatically.
Telnet received a meaningful share of this traffic too. Telnet is a protocol from a different era. It sends everything including credentials in plaintext. It has no encryption, no authentication integrity, and no protection against interception. It should not exist on any production system in 2026. And yet it is still running on routers, IoT devices, industrial equipment, and legacy servers across the internet. Attackers know this. That is why they still scan for it.
FTP told the same story. An even older protocol, equally unencrypted, still present on millions of systems. The attacks against our FTP service were automated credential attempts mixed with service fingerprinting. The goal is simple - file access, potential upload capability, and a foothold.
These three protocols share something important. They were built for a different internet. An internet where trust was assumed, networks were small, and the idea of automated global scanning did not exist. We are now running those same protocols on an internet that looks nothing like the one they were designed for.
What Happens When a Real System Gets Compromised: The Recon Phase
This is something worth addressing directly for readers who are following this series for defensive purposes.
Everything we documented in Part 2 and Part 3 - the system checks, the resource inspection, the permission queries - maps directly to what a threat hunter will find when investigating a real Linux compromise.
When a real attacker lands on a real system, the first thing they do is reconnaissance. Not because they are curious. Because they have to. They do not know where they are. They do not know what the machine is used for, what access it has, what other systems it can reach, or whether it is worth keeping. The recon phase answers those questions.
On a compromised Linux system the forensic evidence of this phase is consistent and recognisable. Shell history files show commands like uname -a, whoami, id, hostname, ifconfig, ip a, cat /etc/passwd, w, last, and ps aux. These are not dangerous commands on their own. They are standard system administration queries. But when they appear in sequence shortly after an unusual login event, they are the fingerprint of an attacker orienting themselves in a new environment.
This is exactly what threat hunters look for. The recon sequence is one of the clearest early indicators of post-compromise activity on Linux systems. It appears before anything destructive happens. It appears before persistence is established. It is the window where detection is possible before the situation becomes significantly worse.
What we observed in our honeypot sessions was a perfect replica of this pattern. Automated scripts running system checks in a fixed order, collecting the output, and making decisions based on what they found. The scripts do not know they are in a honeypot. They run the same checklist they would run on any system. And that checklist looks identical to what investigators find on genuinely compromised production servers.
If you are building detection capabilities on Linux infrastructure, the recon sequence is where to start. Logging shell commands, monitoring for unusual sequences of read-only system queries shortly after authentication events, and correlating login sources against known threat intelligence are all meaningful controls that address this phase specifically.
What Happened After Login
Sessions that progressed past the login prompt followed the same behavioral pattern we documented in Part 2, but this time we saw the next stage clearly.
After the standard post-login checklist - system identification, resource inspection, permission checks - some sessions initiated a download.
A remote file retrieval command was executed pointing to an external server. The payload retrieved was a PHP-based remote shell. Not a sophisticated tool. Not a zero day. A well-known class of malware used to establish persistent web-based access to a system, usable through any browser, designed to blend into web server environments.
The command used the no-clobber flag, which means the script was written to avoid overwriting the file if it already existed. That is a small detail but a meaningful one. It suggests the tooling behind this was designed to operate across many targets simultaneously. If the file is already there from a previous run, skip the download. Do not waste bandwidth. Move on.
After retrieval the session attempted to establish persistence, manipulate process lists, and remove traces of competing activity. The landlord behavior we described in Part 2 was present here again, more clearly this time.
Following the Infrastructure
This is where Part 3 goes somewhere the previous entries did not.
One of the payload delivery sources led us to perform a full infrastructure lookup. What we found was a layered picture that is increasingly common in modern attack infrastructure.
The IP address resolved to a network block registered in the Netherlands. The organisation listed a UK address. The block itself was created in January 2026 - just weeks before it began appearing in our telemetry. The routing entries showed dual ASN paths, suggesting the infrastructure was designed with redundancy or obfuscation in mind.
The reputation data was decisive. Nineteen out of ninety-two vendors on a major threat intelligence platform flagged this source as malicious. That is not a false positive rate. That is a confirmed bad actor operating from freshly registered infrastructure.
This pattern has a name in the security research community: bulletproof hosting. Infrastructure registered under shell organisations, often cycling through multiple jurisdictions, specifically designed to resist abuse complaints and takedown requests. The organisation names sound legitimate. The registration paperwork exists. But the infrastructure exists to serve malicious operations.
What makes this particularly notable is the timeline. This network block was registered in late January 2026. By March it had routing entries. By the time it hit our honeypot it was already flagged by nearly a fifth of the threat intelligence vendors that evaluated it. From registration to active malicious use in under three months.
That is the operational tempo of modern attack infrastructure.
VoIP: The Attack Surface Nobody Talks About
One thousand probes against our VoIP service in twelve hours was one of the more surprising findings for readers who have not encountered this before.
SIP, the Session Initiation Protocol, is the foundation of most modern VoIP infrastructure. It handles call setup, routing, and authentication for internet-based phone systems. It runs on businesses, call centres, hotels, healthcare facilities, and any organisation that moved away from traditional phone lines.
Attackers target SIP for a specific reason: toll fraud.
A compromised SIP endpoint can be used to make calls that are billed to the victim. International calls. Premium rate numbers. Routes that generate revenue for the attacker while the legitimate account holder receives the invoice. It is one of the oldest and most consistently profitable forms of cybercrime, and it operates almost entirely under the radar of most security teams because it does not look like a typical breach.
The probes against our VoIP service were registration attempts and credential guessing. Automated tooling cycling through common SIP usernames and weak passwords looking for an open door. If any of those attempts had succeeded against a real system, the victim might not have noticed until a phone bill arrived.
Databases: What Attackers Want From Each One
Redis, MySQL, MongoDB, and MSSQL each attracted different traffic profiles.
Redis received over 600 probes. Most were connection attempts and service fingerprints, but some progressed to command attempts. The classic Redis attack vector involves configuration commands used to redirect where the database writes its data files. If Redis is running with elevated permissions and write access to sensitive directories, an attacker can use this to write SSH keys, scheduled tasks, or web shells directly to the filesystem without ever touching the operating system through conventional means. Redis was never designed to be internet-facing. It was designed to be a fast internal cache. Every Redis instance exposed to the internet without authentication is a potential system compromise waiting for the right attacker.
MySQL and MongoDB attracted credential attempts and query probes. Databases hold the actual data organisations care about. Customer records, financial information, credentials, intellectual property. An exposed database without authentication or with default credentials can be fully exfiltrated by automated tooling in minutes.
The industrial protocol services received lower volumes but the nature of those probes was qualitatively different. These were not generic scanners. The traffic patterns suggested tooling specifically designed for industrial control system reconnaissance. Someone out there is actively mapping ICS infrastructure on the public internet. The volumes are low because the targets are specialised. But the intent behind those probes is in a different category from credential stuffing.
The Geography Shifted
In Part 1 and Part 2 the honeypot was hosted in the United Kingdom. For this phase we moved to Germany.
The top source countries over the twelve hour window included the United States, China, South Africa, Bulgaria, Vietnam, France, South Korea, Brazil, Hong Kong, and India. A genuinely global distribution hitting a server that had existed for less than a day.
We want to be precise about what geographic attribution means and does not mean here. The country associated with an attacking IP tells you where the infrastructure is registered or physically located. It does not tell you where the human operator is. Most of what hit us was automated. Botnets and scanning infrastructure are distributed across compromised machines, rented servers, and purchased VPS instances spanning dozens of countries. The apparent origin is frequently not the real origin.
What geographic data does tell you is something about infrastructure preferences. Certain regions host more bulletproof infrastructure. Others have large concentrations of compromised consumer devices that get folded into botnets. Others are simply large cloud hosting markets where attackers rent capacity the same way legitimate businesses do.
The most useful signal is not the country. It is the autonomous system, the registration timeline, and the reputation data.
The Worm Economy
Much of what attacked us was not operated by humans in real time. It was worm and botnet infrastructure - self-propagating malware that scans, compromises, recruits, and scans again. Each newly compromised machine becomes another scanner. Each new scanner finds more targets. The network grows without requiring continuous human involvement.
This is why the numbers scale so quickly. A single campaign does not need a thousand operators. It needs a thousand already-compromised machines, each running the same automated playbook. Find exposed services. Try the credential list. If successful, check the system, pull the payload, establish persistence, add this machine to the pool.
The competing bot behavior we documented - processes being killed, files being deleted, access credentials being replaced - is the natural consequence of this model. Multiple campaigns are running the same playbook against the same exposed systems. They are not coordinating. They are competing. The machine is a resource and whoever holds it uses it.
Two Very Different Threats: Automated Scanners vs a Focused Attacker
Everything we documented in this series so far has been predominantly automated. Bots, worms, scanners, and credential stuffing tools running continuously without human attention. Understanding that threat is important. But it is equally important to understand what it is not.
There is a meaningful difference between automated scanning and a focused human operator - or team - specifically targeting your organisation. Understanding that difference is not a reason to feel safer. It is a reason to think more carefully about your actual risk profile.
Automated scanning operates at internet scale. It does not know your company name. It does not care what industry you are in or what data you hold. It sends probes to every reachable IP address looking for open ports, known vulnerabilities, and weak credentials. When it finds something it can use, it uses it. The entire process is mechanical. The goal is volume - compromise as many systems as possible and extract whatever value exists. Your server is not a target. It is a number in a range.
A focused attacker is completely different.
A focused attacker - whether an individual, a criminal group, or a state-sponsored team - has chosen you specifically. They have a reason. Maybe it is your data, your customer base, your financial systems, your intellectual property, or your position in a supply chain that leads somewhere more valuable. Whatever the reason, the approach changes fundamentally.
They will spend time on reconnaissance before touching a single system. They will map your internet-facing infrastructure, identify your technology stack, research your employees on professional networks, look for exposed credentials in data breach dumps, review your job postings for technology clues, and study your partners and suppliers for indirect entry points. All of this happens before a single connection attempt reaches your network.
When they do move, they move carefully. They look for the path of least resistance - an employee with a weak password, a forgotten system that missed a patch cycle, a third party with access to your environment, a misconfigured cloud storage bucket, an old VPN appliance running outdated firmware. They test quietly. They avoid triggering alerts. They may spend weeks in this phase.
If they gain access they do not announce themselves. They move laterally. They escalate privileges. They map internal systems. They find what they came for. And depending on their objective they either extract quietly, establish long-term persistence, or deploy something destructive when the time is right.
The automated scanner gives you days or hours before something bad happens if a credential works. A focused attacker gives you nothing if they are skilled and patient.
The Uncomfortable Truth About Untested Infrastructure
Here is the reality that this entire series is building toward.
If a determined person or team decides to find weaknesses in your infrastructure and you have never seriously asked what those weaknesses are - you are working with a significant disadvantage.
Penetration testing, red team exercises, attack surface reviews, and continuous exposure monitoring are not luxuries reserved for enterprises with large security budgets. They are the basic due diligence of operating infrastructure that matters. They exist to answer a simple question before an attacker does: what can someone find, and what can they do with it?
The organisations that discover their own weaknesses first can fix them quietly. The organisations that discover their weaknesses through an actual incident fix them publicly, expensively, and often after significant damage has already been done.
This experiment ran a server for twelve hours on a weekend and captured over twenty four thousand events. Automated scanners found it, probed it, attempted credentials, pulled payloads, and tried to establish persistence - all without a single human making a deliberate decision to attack it. That is the background noise of the internet.
Now imagine the same server was your actual infrastructure, and somewhere in that noise was one patient, well-resourced, specifically motivated attacker who had already spent three weeks learning everything about your organisation before making their first move.
The automated wave you can defend against with fundamentals - strong authentication, minimal exposure, logging, patching. The focused attacker requires something more: knowing your own infrastructure as well as they do, or better. That means testing it. Challenging your own assumptions. Finding the forgotten system, the misconfigured service, and the weak link in your supply chain before they do.
If someone wants to find something in your infrastructure and you are not testing, not thinking about exposure, and not asking hard questions about what you have running and why - eventually something finds a way in. Not because you were specifically chosen. Not because you are important enough to warrant attention. But because you were reachable, something was weak, and the internet never stops looking.
The question is not whether this is happening to your infrastructure. It is whether you are logging it, detecting it, and responding to it.
If You Still Think You Are Too Small to Be a Target
We want to close with something direct.
This server was online on a weekend. It had no domain name, no associated business, no published IP address, no reason for anyone to know it existed. It was a blank server in a data centre in Germany. And in twelve hours it received 24,435 attack events from sources across more than ten countries.
Scanners do not have target criteria based on company size or perceived importance. They scan everything. They find everything that responds. They try everything that looks like it might work. Whether your organisation has ten employees or ten thousand is completely irrelevant to a bot cycling through an IP range at two million probes per hour.
The small business that thinks it is invisible is running the same exposed RDP port, the same default database credentials, and the same unpatched VPN appliance as the enterprise that knows it is a target and has a security team watching it. The difference is the enterprise gets detected and contained. The small business finds out months later when the ransomware deploys or the data shows up for sale.
Size is not protection. Obscurity is not protection. Being on a weekend when the IT team is not watching is not protection.
Reachability is the only variable that matters to the automated threat. And for the focused human attacker, a small organisation with weak security and valuable data or useful supply chain access is often a more attractive target than a large enterprise with mature defences.
Think about what you have exposed. Test it before someone else does.
What Comes Next
Part 3 followed a trail from a honeypot probe back through routing records and reputation data to infrastructure that tells a story about how modern attack operations are built and maintained.
Part 4 will go wider.
We want to know whether the sources that hit us are connected. Do multiple attacking IPs share the same payload servers? Do the same credential lists appear across different campaigns? Can we draw a map between attack sources, delivery infrastructure, and the tooling they deploy?
Part 1 showed how fast you get found.
Part 2 showed what the first wave does.
Part 3 followed the infrastructure back to its source.
Part 4 will ask whether any of it is connected.
This research series is conducted in a controlled environment using dedicated honeypot infrastructure. No production systems were involved. All source IP addresses are intentionally withheld. This content is published for educational and defensive security awareness purposes.