How an exposed server became a weapon, findings of our own experiment

The Two-Minute Warning

Imagine building a small, quiet cabin in the middle of a vast digital wilderness. No address is shared, no signs are put up. The lights are simply turned on, and the door is closed behind you.

In the physical world, it can take weeks, months, or even years before a stranger knocks on your door. But on the internet – the modern Wild West – the “strangers” are already there. They aren’t humans with maps; they are relentless, automated ghosts that patrol every square inch of the landscape, 24 hours a day.

When we deliberately deployed a misconfigured SNMP (Simple Network Management Protocol) service, we left it exposed on purpose. We set the timer and prepared ourselves for a long wait.

It took less than 2 minutes.

Before the virtual ink was even dry on our configuration file, the first “knock” arrived. A cold, automated probe from a server halfway across the globe had already cataloged our existence. This wasn’t a targeted hit by a master hacker; but the result of relentless, automated scanning. It wasn’t looking for sensitive data or a specific company; it was simply seeking out an open door, any door, in the digital landscape.

In those first two minutes, our service ceased to be “ours”. It became a known entity in a global database of targets. The countdown to abuse hadn’t just begun; it was already halfway over.

Why was it so fast?

The internet is currently being “riddled” by thousands of scanning engines like Shodan, Censys, and private botnets. These tools can scan the entire IPv4 address space (every single possible IP address) in less than an hour. When you go “live,” you aren’t hidden; you are simply a new coordinate on a map that is being redrawn every few minutes.

Setting the trap: The Vulnerable SNMP Service

To catch a predator, you have to know what they like to eat. When deciding how to bait our digital trap, we didn’t want to use some complex, newly discovered zero-day vulnerability. We wanted something common, something ubiquitous, and most importantly, something that relies on everyday human oversight.

Enter SNMP (Simple Network Management Protocol).

In the IT world, SNMP is the silent workhorse. It’s the protocol that allows administrators to monitor the health of routers, switches, and servers. But in the Wild West of the internet, an exposed SNMP service is the equivalent of leaving your horse untied with gold in the saddlebags. We chose  this protocol for two very specific technical reasons:

1. The “Fire and Forget” Nature of UDP
   Unlike web traffic (TCP), which requires a polite, three-way digital handshake to establish a connection, SNMP operates over UDP (User Datagram Protocol). UDP is connectionless. It doesn’t check IDs; it just receives a message and blindly fires a response back to the return address. This “fire and forget” mechanism is the exact flaw that makes amplification attacks possible, as attackers can easily forge (spoof) that return address.
2. The Infamous “Public” Password
   Older, widely used versions of this protocol (like SNMPv2c) don’t use modern encryption or robust authentication. Instead, they rely on the “community string” (essentially a plain-text password). Even worse, the default read-only community string on thousands of devices straight out of the box is simply public.

So, the trap was built. A server was spun up, UDP Port 161 was opened to the internet, and the community string was set to public. No effort was made to advertise it, and no domain names were pointed to it. The default settings were simply left intact—essentially hanging a giant, invisible neon sign that only automated scanning robots could see.

And as we saw at the two-minute mark, they were definitely looking.

Phase I: The Great Reconnaissance (0-48 Hours)

That two-minute mark was just the beginning. Over the next 48 hours, our server logs began to read like a guestbook for the internet’s most relentless, unseen wanderers. But surprisingly, this initial wave of traffic wasn’t destructive. It was entirely methodical.

If you were watching the network traffic, you wouldn’t see a massive cyberattack unfolding. Instead, you’d see the digital equivalent of scouts mapping the territory.

Who is Knocking?

It is crucial to understand that the “people” finding our server weren’t actually people. They were autonomous scripts, relentless crawlers, and sprawling botnets. Some of these are pseudo-legitimate, like Shodan or academic researchers indexing the internet. But many are malicious;variants of the Mirai botnet or custom scanning tools deployed by cybercriminal syndicates.

These automated scouts are constantly combing through the 4.3 billion possible IPv4 addresses. When they hit our IP address on UDP port 161, they didn’t try to brute-force a complex password. They simply asked a standard question using the default “public” community string: “What are you?” (Technically, an SNMP GET request for the system description).

The Quiet Before the Storm

When our server politely responded to that “public” request with its system details, the scouts didn’t immediately launch an attack. They just took notes.

This 48-hour window was the “Quiet Before the Storm.” Attackers don’t usually exploit a vulnerable SNMP server the second they find it. Instead, they catalog it. They are building massive, hidden databases of vulnerable endpoints;a sprawling list of thousands of “reflectors” just like ours. Our server was quietly added to a registry, likely to be rented out or used by a botnet or stress-testing service on the dark web.

For two days, our server sat there, receiving these tiny, probing requests from all over the world. The doorknob was being rattled, the lock was found to be broken, and the address was jotted down. The weapon was loaded; it just hadn’t been fired yet.

    Scanner IPs mapped on the world map

Phase II: The Weaponization (The 48-Hour Mark)

Right around the 48-hour mark, the nature of the traffic hitting our server completely changed. The quiet, methodical knocks of the scouts were gone. Instead, our server was suddenly slammed with aggressive requests. The reconnaissance phase was over; the weaponization had begun.

But here is the twist that makes the internet so dangerous: We were not the target of the attack. We were the weapon.

The attackers who cataloged our open server two days prior had sold or used our IP address as part of a distributed denial-of-service (DDoS) campaign. Specifically, they were using our poorly configured setup to launch an SNMP Reflection and Amplification Attack.

Victim IPs mapped on a world map

To understand how our innocent server was turned into a digital sledgehammer, you have to break down the two halves of this attack:

The Reflection (The Spoofed Address)

Remember how SNMP operates over UDP, the “fire and forget” protocol that doesn’t verify identities? Attackers exploit this by forging, or “spoofing,” their IP address.

Imagine sending a heavy, postage-due package through the mail, but writing your enemy’s address in the “Return To Sender” field. When the post office can’t deliver it, they bounce that heavy package straight to your enemy.

In the digital world, the attacker sends a tiny data packet to our vulnerable server, but they forge the packet’s source IP to look like it came from their intended victim. Our server processes the request and politely “reflects” the answer back to the victim, who never asked for it.

The Amplification (The Force Multiplier)

Reflection alone is annoying, but amplification is devastating. The attacker doesn’t just ask our server a simple question; they use a specific SNMP command called ”GetBulkRequest”.

The attacker sends a tiny request (maybe 60 bytes of data). But that specific command tells our server to dump as much data as possible in response. Our server happily complies, generating a response of 1,500 bytes or more.

By routing their attack through our server, the attacker just multiplied their firepower. For every 1 megabyte of traffic the attacker spends, our server blasts the innocent victim with 20 to 30 megabytes of junk data.

Now, imagine the attacker doing this simultaneously with 10,000 other vulnerable servers just like ours. A lone attacker with a standard internet connection can suddenly generate an explosionof traffic capable of knocking massive corporate networks offline. Within two days of turning our server on, we were actively participating in taking someone else down.

The Anatomy of an Amplification Factor

To truly understand why attackers love this protocol, you have to look at the math. In the DDoS world, efficiency is everything. Attackers measure this efficiency using an “Amplification Factor”: the ratio between the size of the tiny request they send and the size of the massive response your server blasts at the victim.

Different protocols have different multipliers. Here is how SNMP stacks up against other protocols exploited on the internet:

Our Targets

Top 20 victims on the world map

The Crossfire: Who Were We Attacking?

Once our server was weaponized at the 48-hour mark, it became a blind accomplice in a much larger crime. In the amplification attack, the victims rarely know who the original malicious actor is; they only see a stampede of traffic coming from compromised services exactly like ours. We weren’t the target,we were the weapon! So, where was our server aiming?

The Unlucky Targets

When we analyzed the logs, the scale of the crossfire was staggering. Our server was tricked into firing at over 5000 unique IP addresses. The attackers were spoofing these addresses, tricking our server into sending massive, unprompted data dumps their way.

The top 20 targets took the absolute brunt of the abuse, and the sheer variety of these victims proves that the digital Wild West respects no borders. TThe most frequently targeted IP address on our list belonged to the Bangladesh Government. Within days, that quiet, poorly configured cabin in the woods became part of a distributed attack against a sovereign nation’s infrastructure, joining a random mix of international ISPs and hosting providers.

The Disguise: Picking the target

When the attackers aimed our server at their victims, they didn’t just forge the destination IP address; they also forged the Source Port. This is the digital equivalent of putting a fake uniform on a delivery driver so security guards (the firewalls) let them in.

Looking at our logs, the top spoofed source ports the attackers used were 53, 80, 443, 8080:

• Port 53 (DNS)
• Port 80 & 8080 (HTTP)
• Port 443 (HTTPS)

By forcing our server to reply using these ports, the attackers were dressing the attack traffic up as trusted, everyday internet services. The victim’s firewall sees the tidal wave of data and assumes, “This is just a very large reply from a web server or a DNS lookup the user requested.” By the time it realizes the trick, the network pipe is already choked.

The Damage

Whether intentional or not, our server responded to each request as expected and sent back amplified responses. To understand the efficiency of this attack, look at the math from our server’s perspective over this short period:

• Total Connections:5 million
• Incoming Traffic (The Trigger): ~1.28 GB
• Outgoing Traffic (The Blast): ~41.9 GB

Over 8.5 million times, an attacker sent a tiny, spoofed request to our server. They spent about 1.28 GB of bandwidth to “pull the trigger.” In response, our server blasted out 41.9 GB of junk data at the victims.

That is an average amplification factor of 32x. For every single megabyte the attacker used to ping us, we slammed the victim with 32 megabytes of garbage.

The Motives

Why were these specific IPs targeted? In the modern DDoS ecosystem, attacks are rarely personal. Our server was likely swept up by a “booter” or “stresser” service. An illegal platform on the dark web where anyone can pay a few dollars to rent a botnet and knock a target offline. The motives range from geopolitical hacktivism to corporate extortion, or even rival phishers/spammers/… trying to disconnect their opponents. The actors pulling the strings don’t care about our server, and they often don’t even care about the victims. They only care about the chaos they can sell, and our 32x multiplier made their product that much stronger.

Lessons from the Frontier

So, what does this two-minute discovery and two-day weaponization teach us? It serves as a stark reminder of the realities of modern network security.

• Obscurity is a myth: The internet is mapped continuously. You cannot hide a service simply by keeping it quiet or putting it on an unadvertised IP. If it has a public IP address, it will be found in minutes.
• Defaults are dangerous: Relying on default settings is an open invitation to automated abuse. Security requires active configuration.
• Exposure is a liability: Services like SNMP were designed for internal network management, not public internet exposure. If a service doesn’t need to be facing the internet, it must be locked behind a firewall or VPN.
• You are the weapon: Security isn’t just about protecting your own data anymore. If you leave your digital doors open, malicious actors won’t necessarily rob you; they will use your house as a sniper’s nest to attack someone else.

Conclusion: Securing the Digital Homestead

Our experiment proved that the internet remains a lawless frontier for the unprepared. It took less than two minutes for the scouts to find our vulnerability, and just 48 hours for the outlaws to turn it into a weapon.

In this landscape, there is no such thing as being “too small to target.” Attackers don’t care about who you are; they care about your bandwidth and your public services. To survive in the digital world, you have to assume that someone is always checking your door handles. Lock them.