When a small UK business contacted Gtec Media, their website had suddenly gone offline without warning. There had been no recent changes, no obvious errors, and no clear explanation from their hosting provider beyond a temporary suspension due to “suspicious activity.”
Like many SMEs, they assumed their website was “just working in the background.” In reality, it had been under attack for weeks.
The Initial Problem
The client reported that their website had become intermittently slow before going completely offline. Shortly after, their hosting provider suspended the account to prevent further damage to the server.
From the outside, it looked like a typical outage. Internally, it was something very different.
What We Discovered
Once access was restored, the first step was to review raw server logs. Almost immediately, a clear pattern emerged. There were thousands of repeated requests targeting a single file: /xmlrpc.php.
These requests were not occasional or random. They were continuous, automated, and running day and night. In some cases, hundreds of login attempts were being executed within a single request using XML-RPC’s multicall functionality.
This type of activity is significantly more aggressive than standard login attacks and is often missed by basic security setups.
Further inspection showed that the website had no restrictions in place for XML-RPC. The feature was fully exposed, allowing attackers to probe and interact with it freely.
The Impact on the Website
The attack had two immediate effects. First, it placed sustained pressure on server resources, which contributed to the site slowing down before eventually failing. Second, it significantly increased the risk of a successful login compromise.
Although no full defacement had occurred yet, the volume and intensity of the attack meant it was only a matter of time. In many similar cases, attackers eventually gain access, inject malicious scripts, or use the compromised site to send spam or participate in wider attacks.
The hosting provider’s suspension, while disruptive, likely prevented further damage.
Why This Happened
The root cause was not a single vulnerability but a lack of hardening. XML-RPC was enabled by default, and no additional controls had been implemented to restrict or monitor its use.
This is extremely common. Many business websites rely on default configurations, assuming that hosting providers or basic plugins are handling security. In reality, these setups often leave critical entry points exposed.
XML-RPC is particularly attractive to attackers because it allows a large number of actions to be executed in a single request. This makes brute-force attacks faster, more efficient, and harder to detect.
How We Fixed the Issue
The first step was to immediately block access to XML-RPC at the server level. This stopped the attack traffic instantly and reduced server load.
From there, a full hardening process was carried out. Login mechanisms were secured, unnecessary access points were restricted, and vulnerable configurations were corrected. Additional monitoring was implemented to detect any further suspicious activity.
Once these measures were in place, the website was brought back online in a stable and secure state.
📊 Before vs After (Measured Impact)
Before Hardening:
• Continuous XML-RPC attack traffic detected
• Thousands of automated requests per hour
• Server resources under sustained load
• Website performance degraded
• Hosting account suspended due to suspicious activity
• High risk of full compromise
After Hardening:
• XML-RPC endpoint fully blocked
• Malicious requests reduced to near zero
• Server load stabilised immediately
• Website performance restored
• No further suspicious activity detected
• Attack surface significantly reduced
The Key Takeaway
What stood out in this case was not how sophisticated the attack was, but how routine it is. The activity observed on this website is happening constantly across thousands of WordPress sites.
Most business owners are completely unaware of it.
By the time a problem becomes visible, the damage is often already done. Websites go offline, data is put at risk, and emergency fixes become necessary.
Don’t Wait for a Problem to Appear
This case highlights a simple reality. If a WordPress website is not actively hardened, it is being probed and tested continuously.
At Gtec Media, we focus on preventing these issues before they escalate. A properly secured website not only reduces risk but also avoids downtime, lost revenue, and unnecessary stress.
If your website has never been hardened, there is a strong chance it is already being targeted.
👉 Get a Security Check and find out before it becomes a problem.
