36 seconds of obscurity

We put a server online that served nothing but a blank default page: no content, no links, nothing worth stealing. We recorded every request that arrived for 54 days. It received 3,270 uninvited requests. Here’s what that means for anyone who runs a website.

A question we hear from clients, in one form or another, is: who would bother attacking us? The business is small, the website is a brochure, and there’s no customer data behind it. Surely attackers have better things to do.

Our research practice, Infra Research, decided to answer that with data rather than opinion. We pointed a hostname at a server on our hosting platform that did precisely nothing. It returned a generic “It works!” page to every request, and quietly recorded everything that arrived (every path, every header, every payload) for 54 days. The full write-up, with methodology and raw numbers, is published on Infra Research. This article is about what those numbers mean for your business.

The short version: the server was probed 3,270 times by 201 distinct sources, offered working exploits for ten different enterprise software products, and asked repeatedly for its payment-processor keys. Nobody was invited. Nothing was advertised. And none of it was personal.

The first knock came in 36 seconds

The server first answered a health check at 02:04:31 UTC. The first uninvited request from the internet arrived at 02:05:07, just 36 seconds later.

There’s a nuance worth being honest about: the hostname we used had been public before, on older infrastructure, so it was already sitting on somebody’s scan list. But that nuance is the lesson. Any name that has ever been on the internet (your domain, an old subdomain, a staging address someone once shared) stays on those lists indefinitely. There is no quiet period while you “finish setting things up”, and no such thing as being too obscure to find. If it answers, it gets scanned.

The traffic also never sleeps. Bucketed by hour of day, there was no morning peak, no weekend dip, no working-day shape at all. Nothing probing your website is a person; it’s automation running around the clock. And it isn’t a steady drizzle either. It’s a quiet baseline punctured by short, intense bursts from single machines.

The largest of those bursts was one machine firing 502 WordPress login attempts in 117 seconds, trying the same known-bad password 237 times against a login form that doesn’t exist, and then never returning. That pattern, one machine trying very hard for two minutes, is what a “spike in traffic” usually turns out to be.

It’s not about you

The single biggest category of hostile traffic was aimed at WordPress: login brute-forcing and reconnaissance sweeps hunting for WordPress installations across nineteen different directory paths. Our server has never run WordPress, or PHP at all.

The same blindness showed up everywhere. Over 54 days the server was offered working exploit payloads for Oracle WebLogic, F5 BIG-IP, Laravel, Atlassian Confluence, Microsoft Exchange, MikroTik routers, Synology NAS devices and more, none of which it runs.

This is the part that answers the “who would bother?” question. Nobody chose to attack this server, in the same way nobody chooses to attack your website. Automated tooling attacks everything, constantly, and follows up wherever something answers. The flip side is just as important: if you do run WordPress, as a very large share of Australian business websites do, you are not an edge case in this data. You are the primary target, receiving a third of the internet’s background hostility by default. Login rate-limiting, prompt patching and locked-down admin paths stop being nice-to-haves.

What they’re actually shopping for

The most revealing traffic was 174 requests hunting for configuration and secret files: stripe.yml, aws/credentials, payment.yml, credentials.yml, and CI pipeline definitions. These are not the classic movie-hacker targets. They are a shopping list of things that convert directly to money. A leaked Stripe key means transactions in your name. A leaked cloud credential means infrastructure billed to your card, often mining cryptocurrency at your expense before you notice.

These files exist in almost every modern web application. The attacks work because, on carelessly configured hosting, application code and its configuration sit in the same web-accessible folder, one misstep away from being served to anyone who asks. That is an architecture problem, not a vigilance problem. It’s why we build so that secrets are injected into applications at runtime and are never part of the web-servable filesystem in the first place. A request for /aws/credentials on our platform isn’t blocked by a rule someone remembered to write; there is simply nothing there to serve.

Who’s knocking: not who you’d think

The mental picture most people carry is a botnet of hacked home computers. The data says otherwise.

Every one of the top ten source networks was a cloud or hosting provider. Not a single residential internet connection. Much of it is free-tier and trial-credit capacity, rented by the attackers exactly as designed.

That has a practical consequence for defence: IP reputation lists built around home-PC botnets won’t catch this traffic, and blocking cloud providers outright means blocking the same networks your legitimate customers, partners and integrations use. Filtering by where traffic comes from is a losing game. What holds up is making sure there’s nothing exploitable for the traffic to find: current software, minimal attack surface, and secrets that aren’t reachable from the web. It also helps to key on the signals attackers can’t help leaking, like the fabricated browser identities that marked almost all of the hostile traffic in our capture.

One more finding worth knowing about: roughly 12% of the traffic was honest, self-identified scanning by security research services, commercial attack-surface monitoring, AI crawlers and certificate validation. A meaningful slice of your server’s visitors are now machines that tell you exactly who they are. Your logs are more legible than you might think, if anyone is reading them.

What this means for how we host

None of this is a reason for alarm. The background noise has always been there; we’ve simply measured it. But it does sharpen a few conclusions we were already building on.

Security by obscurity is not a strategy, because there is no obscurity: your site is found in seconds and scanned forever. Your real exposure is set by what you run, not by who you are. The popular, widely deployed platforms absorb the overwhelming majority of automated attacks, and anything unpatched eventually meets an exploit written for it. And because the attacks come from the same clouds legitimate traffic does, defence has to be architectural rather than reactive: fewer moving parts to exploit, secrets kept structurally out of reach, an edge that watches everything, and someone actually responsible for patching. For our managed clients, that someone is us.

Our advice, whether or not you host with us: assume everything you put online is being probed from the moment it answers, ask your provider where your configuration and credentials physically live relative to the web, and make sure patching is someone’s explicit job rather than everyone’s vague intention. The full research, including methodology and every number in this article, is published on Infra Research.