When people think about cyberattacks, they usually imagine highly sophisticated operations where an attacker spends weeks targeting a specific company, government agency, or high-profile individual. Those attacks absolutely happen, but they are not what most internet-facing systems encounter first.
What most exposed systems experience is far less dramatic and far more automated.
The moment a server becomes publicly reachable, it enters a noisy ecosystem filled with bots, scanners, opportunistic attackers, researchers, and occasionally more advanced threat actors constantly searching for exposed infrastructure. They look for weak credentials, open ports, vulnerable web applications, outdated services, misconfigured cloud systems, and anything they can exploit quickly.
Most people never witness this layer of the internet because they are not intentionally exposing systems and watching what happens next.
That is exactly why we started this series.
We want to build multiple honeypots across different protocols and environments to understand how attackers behave during discovery, reconnaissance, and exploitation. We're starting simple so beginners can follow along, but each experiment will become progressively more complex. Over time we'll move into higher interaction honeypots, more realistic deception environments, additional protocols, better telemetry pipelines, and deeper threat analysis.
This first experiment was intentionally lightweight. We wanted a clean baseline before making things significantly more complicated.
What Is a Honeypot?
For beginners, a honeypot is a decoy system intentionally designed to attract suspicious or malicious activity.
It can be a fake SSH server, a login portal, a vulnerable web application, an exposed database, or even a full simulated enterprise environment. The goal is not necessarily to stop attackers. The goal is to observe them.
We intentionally place something online that looks legitimate enough to attract attention, then we monitor how quickly it gets discovered, what services get targeted first, and what techniques attackers attempt.
Sometimes attackers interact manually.
Most of the time, the first thing you see is automation.
That is exactly what happened here.
The Environment We Built
For this first test, we deployed the honeypot on a VPS hosted in the UK through a well-known cloud provider. We are intentionally not publishing the provider name or the server IP addresses.
That distinction matters because there is a major difference between an on-premise honeypot and a VPS-based honeypot.
An on-premise honeypot lives inside infrastructure you physically control, such as a home lab, private datacenter, or corporate network. Traffic hitting those systems may reflect activity aimed at a specific organization, ISP range, or geographic location.
A VPS honeypot is different. It exists inside public cloud infrastructure where IP ranges are constantly scanned because attackers know new systems are deployed there every day.
This experiment strongly suggested that the specific cloud range we were placed in was being actively monitored for discovery opportunities.
The fact that our system was physically hosted in the UK but quickly received traffic from infrastructure linked to Russia, the Netherlands, the United States, and Indonesia highlights how globally distributed internet scanning has become. Attack infrastructure rarely stays localized.
Why We Chose SSH and a Fake AI Web Portal
We intentionally kept the first setup simple.
We exposed SSH on port 22 and deployed a web login page referencing an AI platform.
For beginners, SSH stands for Secure Shell, and it is one of the most commonly used protocols for remotely managing Linux servers. Developers, cloud engineers, and system administrators use SSH to remotely log into servers, deploy applications, transfer files, and troubleshoot systems.
Because SSH is so common, attackers constantly scan for it.
Weak passwords, default credentials, and poorly secured servers make SSH a frequent target.
Alongside SSH, we deployed a fake AI-themed login portal.
Why AI?
Because right now anything related to AI infrastructure tends to attract attention. Organizations are rapidly deploying AI dashboards, automation tools, APIs, and internal machine learning systems. We wanted to see whether something that looked like an AI platform would attract early reconnaissance.
It did.
The Saturday Night Experiment
We deployed the honeypot on a Saturday night and left it online for one hour.
We did not advertise it.
We did not attach a public domain.
We did not promote it anywhere.
It simply existed online.
Within just 14 minutes, the first web request arrived from infrastructure originating from Russia. VirusTotal showed that 11 out of 94 vendors flagged the source as malicious. The activity appeared limited to discovery and reconnaissance. No exploitation attempts followed.
This was not particularly surprising. Russian infrastructure frequently appears in global scanning activity and broader cybercrime investigations. That does not automatically imply state-sponsored involvement, but seeing reconnaissance traffic from that region was expected.
At around 22 minutes, things became more interesting.
Our SSH service was targeted by infrastructure operating from the Netherlands and hosted through Google cloud services. VirusTotal showed that 6 out of 94 vendors flagged the source as malicious.
This source launched approximately 189 username and password combinations against the SSH service. The usernames included common targets such as oracle, demo, linux, and several administrator-related accounts.
This was classic brute force behavior.
The Netherlands initially stood out because we did not expect it, but after looking deeper, it makes sense. The country hosts significant global infrastructure, major datacenters, and cloud services. Attackers frequently abuse legitimate infrastructure in regions with strong hosting availability. The geographic source does not always represent the real attacker.
At approximately 26 minutes, another probe arrived from infrastructure hosted in the United States through Microsoft. VirusTotal showed that 8 out of 94 vendors flagged the source as malicious.
This was expected. The United States hosts a large percentage of global cloud infrastructure, so seeing scanners originate from US-based providers is extremely common. One request targeted /hudson, which suggests automated reconnaissance searching for older Jenkins or Hudson administrative interfaces.
At approximately 49 minutes, another reconnaissance attempt arrived from Indonesia. VirusTotal showed that 2 out of 94 vendors flagged the source as malicious.
This was another unexpected result.
Indonesia is not typically one of the first regions people think about when discussing threat infrastructure, but attackers frequently route traffic through compromised servers, rented VPS infrastructure, and botnets spread across multiple countries.
The apparent geographic origin rarely tells the full story.
What We Can Learn From This
The first major takeaway is speed.
Our system was discovered in just 14 minutes.
That means automated discovery systems are constantly scanning cloud infrastructure for new hosts.
The second takeaway is that web reconnaissance happened before aggressive SSH brute forcing.
That suggests many attackers prioritize quick service fingerprinting before committing resources to deeper attacks.
The third takeaway is geographic distribution.
In only one hour, our UK-hosted honeypot received activity linked to four different countries. That demonstrates how distributed modern attack infrastructure has become.
The fourth takeaway is that most early-stage activity was reconnaissance.
Many organizations focus heavily on exploitation and malware deployment while overlooking the discovery phase that happens before larger attacks.
This experiment gave us a direct look into that early phase.
Why This Matters for Beginners
One of the biggest misconceptions beginners have is believing that a newly deployed server remains invisible until someone shares the IP address or domain.
That is not how the internet works.
The moment a publicly reachable service comes online, it can quickly become visible to automated scanners searching for opportunities.
That is why security fundamentals matter so much.
Weak passwords. Default credentials. Exposed admin panels. Poor logging. Unpatched systems.
These mistakes become very expensive when automated systems are constantly searching for vulnerable targets.
What Comes Next
This was intentionally the simplest experiment in the series.
One SSH service. One fake AI login portal. One hour online. And that alone was enough to reveal how noisy and aggressive internet reconnaissance really is.
In future parts of this series, we'll deploy more advanced honeypots, simulate additional services, increase interaction levels, and build stronger telemetry pipelines to better understand attacker behavior.
This was only Part 1.
And the internet found us much faster than most people would expect.
Next Episode → Honeypot: Operation Nightfall — Part 2