One IP address sent 57,803 requests to our server in a single morning.
A second address from the same range sent another 13,280. Add a third and the total passed 80,000 requests, probing for a way into the websites hosted there.
These weren’t customers browsing products or reading articles. They were automated requests looking for weaknesses.
On a 16-core server, the load average reached 40. Within eight minutes of blocking the source, it was back below 1.
That’s how much disruption automated traffic can cause, even when it doesn’t successfully break into anything.
What were they looking for?
The scanners worked through the websites on the server, probing for more than fifteen known backdoor filenames.
A backdoor allows an attacker to retain unauthorised access to a compromised website. Malicious files left behind can provide a route back in, even after the visible damage has been repaired.
These scanners were looking for the fingerprints of previous hacks, checking whether somebody else had already left an opening they could use.
None of the files they were looking for existed on the sites they scanned.
But unsuccessful requests still create work. At sufficient volume, that work can affect the performance of the server and the websites running on it.
A locked door can keep someone out. It doesn’t stop them spending the morning rattling the handle.
Thousands of login attempts, barely a dozen real users
In another log window, we recorded 5,244 requests targeting login and XML-RPC functionality.
Across those websites, there are perhaps a dozen people who legitimately need to log in.
XML-RPC is an interface that allows software to communicate with WordPress. It can support legitimate integrations, but it also attracts automated authentication attempts.
The mismatch is obvious. A handful of real users does not explain thousands of requests to these entry points.
Some automated attacks try to guess passwords. Others test credentials stolen from unrelated services, hoping someone has reused the same password. This is known as credential stuffing. OWASP explains how it works.
A website doesn’t need to be famous to attract this activity. Automated tools can work through addresses and test familiar entry points without caring what the business does.
The traffic came from familiar cloud providers
Our rate limiting turned away more than 1,000 requests from seven scanner IP addresses.
Every one of those addresses was hosted on Microsoft Azure or Google Cloud.
That doesn’t mean Microsoft or Google were conducting the attacks. It means the traffic originated from infrastructure on their networks.
The same cloud services that businesses use to run applications can also be used to run scanners and malicious scripts. A recognisable provider does not make a request trustworthy.
Rate limiting helps control this behaviour by restricting how frequently particular requests can be made. The settings need to suit the website, allowing customers and legitimate services to work while limiting abuse.
They try more than the login page
Login attempts are only one route.
Scanners also look for vulnerable plugins, outdated applications, exposed backups and configuration files that should never be publicly accessible.
Other requests test whether forms, uploads or application features can be manipulated into exposing information or executing unwanted instructions.
The server itself has additional entry points to consider, including remote administration and hosting management services. Those need their own access controls and maintenance.
This is why website security involves several layers. A strong administrator password matters, but it cannot fix a vulnerable plugin. A website security plugin cannot protect every service running on the server.
The website can add to its own workload
Some of the activity in our logs came from WordPress itself.
In one sample, 18,000 requests were associated with WordPress cron, the mechanism used to trigger scheduled tasks.
WordPress can check whether scheduled work is due when a request reaches the site. Bot visits can contribute to triggering that background activity, alongside genuine visitors.
That doesn’t mean every visitor runs every scheduled task. But it does mean incoming traffic can create work beyond loading the page being requested.
Those internal requests weren’t attacks. They were additional workload that needed to be understood.
When investigating server load, counting visitors is only part of the picture. You also need to understand what the application does in response.
The incidents are getting closer together
We’ve recorded eight load or security incidents on this server since June, with the gap between incidents shrinking from months to around a fortnight.
That is our experience on one server. It is not a claim that every website faces the same volume or pattern.
It does show why monitoring matters. A website can appear to be working normally while unwanted activity builds in the background. By the time customers notice slow pages or failed requests, the pressure is already affecting the service.
AI adds another concern. Tools that help developers write and adapt software can also help attackers create and modify scripts. Cloudflare’s threat research describes generative AI being used in network mapping and exploit development. Cloudflare’s threat report
Our logs don’t establish whether these particular scanners were created using AI. They do establish the volume of requests, what those requests targeted and the effect on the server.
Helping businesses deal with the aftermath
Alongside defending against bot traffic, we’ve recently rebuilt a website after it had been hacked.
Recovery work brings a different set of challenges. Getting the visible pages back online is one part of the process. Understanding the original weakness, reviewing access and checking what else may have been affected are equally important.
We’ve also encountered an online shop that accumulated 172,000 fake customer accounts through open registration.
Fake-account abuse is different from a break-in. It can exploit a feature that is working as designed but lacks appropriate controls.
Registration should be available where the business needs it, with protection against automated abuse. Where it serves no purpose, leaving it open creates unnecessary exposure and cleanup work.
What managed hosting actually involves
Hosting gives your website somewhere to run. Managed hosting also provides someone to look after the environment it runs in.
The distinction becomes clear when something goes wrong. A server can be online and technically working while thousands of automated requests make the websites on it painfully slow. Simply confirming that the server is switched on doesn’t solve the problem.
Someone needs to investigate what’s happening, identify the source and take appropriate action. In the incident described above, blocking the offending traffic brought the load back below 1 within eight minutes.
But management also includes work between incidents: maintaining server software, reviewing security alerts, managing capacity and checking that backups are completing and can be restored. It means adjusting protection as traffic changes and investigating recurring problems instead of repeatedly restarting services.
There’s an important boundary to explain here too. Managing the server and maintaining the website are separate responsibilities. WordPress, plugins, themes and custom code need their own updates and checks. A hosting package should make clear which of those tasks it includes, who handles them and what support is available if something goes wrong.
For a business owner, the value is having those responsibilities understood and covered. You shouldn’t have to interpret server logs yourself or work out who to call while customers are struggling to use your website.
That’s the conversation worth having about hosting: who is looking after it, what are they responsible for, and what happens when it needs attention?
If you’re unsure what your current hosting covers, talk to Bollabo.