Recently, we investigated an unexpected increase in cloud hosting costs for one of our customers websites. There was no obvious reason for it. A successful marketing campaign, increased website traffic or a change in visitor behaviour could all have explained the higher bill, so the first step was simply to find out where the additional usage was coming from.
At first glance, nothing seemed obviously wrong. The website loaded normally, and the server appeared to be running as expected, albeit at a slightly higher load than usual. Yet the Amazon Web Services (AWS) bill had risen significantly, suggesting something behind the scenes was consuming far more bandwidth than expected.
As the investigation progressed, it became clear that the additional cost wasn’t the result of genuine visitors at all. It was being generated by legitimate automated systems crawling thousands of fake pages that had been created after the website had been compromised.
What happened?
The compromised website had been injected with malicious code that generated thousands of fake web pages. These weren’t pages that a normal visitor would ever encounter, but they could be discovered by search engines, AI crawlers and other automated systems that constantly explore the web.
Instead of crawling a normal website with a few hundred pages, these bots suddenly had tens of thousands of URLs to investigate.
https://example.com/?h=52501248327
https://example.com/?z=1845954143
https://example.com/?i=39242109800
Each URL appeared unique, so the crawlers treated every one as a new page.
Why would an attacker do this?
Perhaps the biggest surprise is that increasing the client’s AWS bill was not the attacker’s objective.
In many cases, compromised websites are used to generate large numbers of spam pages that promote counterfeit products, gambling websites, fake services or other content the attackers want search engines to discover. By hijacking an established website with a good reputation, they hope their pages will rank more highly in search results than if they created a brand new website from scratch.
Some attacks are also designed to insert hidden links to other websites, artificially boosting their search engine rankings. Others aim to distribute malware or redirect visitors to fraudulent websites. The exact purpose varies, but the common goal is usually to profit from the reputation and trust that the compromised website has already built up.
In this case, the attackers had created thousands of fake URLs that appeared to be genuine pages. As those pages were discovered and indexed by search engines and AI crawlers, they also triggered requests for images stored in Amazon S3. The resulting increase in bandwidth usage, and the AWS bill that followed, was simply an unintended side effect of the attack rather than its primary purpose. Ironically, had those additional costs not attracted attention, the compromise might have remained undetected for much longer.
How did it happen?
It’s the question every website owner asks after a security incident, but unfortunately it’s not always possible to identify the exact point of entry.
In most cases, attackers gain access by exploiting a known vulnerability in a WordPress plugin, theme or, less commonly, WordPress itself. The vast majority of attacks aren’t targeted at a particular business. Instead, automated tools continuously scan the internet looking for websites running software with known vulnerabilities. If they find one, the attack is often completely automated.
Once inside, attackers can modify files, inject malicious code and create content that appears entirely legitimate to visitors, search engines and AI crawlers.
The unexpected visitors
After reviewing the server logs, it became clear that much of the traffic wasn’t coming from hackers at all. Instead, it was coming from well-known organisations whose automated systems routinely crawl websites.
These included:
- Meta (Facebook)
- OpenAI’s GPTBot
- Other legitimate web crawlers
These organisations weren’t attacking the website. They were simply doing what they’re designed to do – discovering and indexing web content. Unfortunately, because the compromised website was continually generating new fake pages, these crawlers kept requesting more and more content.
Why did this affect AWS?
The website used Amazon S3 to store and serve its images rather than hosting them on the web server. This is a common optimisation that improves performance and reduces the load on the server. However, every fake page generated by the malicious code still referenced numerous images stored in Amazon S3.
As automated crawlers requested more and more fake pages, it’s likely they also downloaded the associated images. Every image served from Amazon S3 contributes towards bandwidth usage.
- An automated crawler discovers a fake web page.
- WordPress generates the page as if it were a genuine page.
- The page references dozens of images stored on Amazon S3.
- The crawler downloads those images.
- AWS records the bandwidth used and charges for the data transferred.
- Repeat this thousands of times and the costs soon begin to mount.
One crawler requesting one page isn’t a problem. Thousands of crawlers requesting thousands of fake pages soon adds up to a significant amount of bandwidth.
The bots downloading the content weren’t criminals. They were search engines, AI crawlers and social media preview services doing exactly what they’re supposed to do – discovering new web pages. Unfortunately, because the website had been compromised, they were repeatedly crawling content that should never have existed.
What you can do
- Keep WordPress, themes and plugins updated.
- Use a reputable security plugin such as Wordfence and investigate warnings promptly.
- Regularly review important files such as
wp-config.phpfor unexpected changes. - Restrict access to the WordPress administration area wherever practical.
- Set up AWS billing alerts so unexpected spending is detected quickly.
- If you use Amazon S3 to serve website assets, remember that every image download contributes towards your bandwidth usage.
- Consider using services such as Cloudflare to help reduce unnecessary automated traffic reaching your website.
The bottom line
Website security isn’t just about protecting data. A compromised website can quietly increase your running costs without bringing your server to its knees or displaying obvious signs that anything is wrong. Sometimes the first indication that something is amiss isn’t a customer complaint or a defaced homepage. Sometimes it’s something less obvious.
The biggest lesson from this investigation isn’t really about AWS or WordPress at all. It’s that unexpected behaviour almost always has an underlying cause. Whether it’s a sudden increase in costs, unusual traffic, a slower website or something that simply doesn’t feel right, it’s worth investigating rather than dismissing it.
In this case, following the evidence uncovered a compromised website that might otherwise have continued unnoticed. Good monitoring, regular maintenance and a willingness to investigate the unexpected can often prevent a small anomaly from becoming a much bigger problem.