A website is never really “finished”. It is more like a house that needs doors checking, windows repairing and locks changing from time to time.
That is especially true now that websites are being targeted by attacks which are far more technical than the old-fashioned attempts to guess a password or send out obvious spam.
Recently, Retirement Postponed was attacked. The site is now operating normally, but the incident was a useful reminder of how complicated modern website security has become.
The protection we already had
Retirement Postponed was not being left unattended. We already had several important protections in place:
- Uptime monitoring to alert us if the website became unavailable.
- Patchstack monitoring for WordPress vulnerabilities.
- Regular WordPress, plugin and theme updates carried out by Preston.ie.
- Cloudflare protection and caching.
- Server-level monitoring and backups.
These measures helped reduce the risk and made it possible to respond quickly. They also helped confirm when the public site was working normally again.
However, no individual security measure can prevent every type of attack. Monitoring can tell you that a site is down, but not always that a visitor is seeing something malicious. A vulnerability scanner can identify known problems, but not necessarily a newly hidden backdoor. Regular updates are essential, but attackers may still use stolen credentials, misconfigured services or compromised third-party systems.
Security is therefore a combination of prevention, monitoring, maintenance and response.
What happened?
The attack involved several different parts.
Malicious files had been placed inside the WordPress installation, including hidden PHP files designed to give an attacker access to the website. A disguised plugin was also found. It was able to hide itself from the normal WordPress plugin list and run code that should not have been there.
At the same time, visitors were being shown a fake security check. It looked like a CAPTCHA, but it was not a genuine protection used by the website. Its purpose was to persuade visitors to interact with malicious code.
The attack did not stop at the website itself. Cached versions of the site and a Cloudflare Worker were also involved. The Worker was able to change what visitors received in their browsers, even after the original website files had been cleaned.
This is one of the important lessons from the incident: cleaning the website files is not always enough. A modern website may have several layers:
- The WordPress files
- The database
- The server
- PHP and other background services
- Caches and performance systems
- Cloudflare or another content delivery network
- Browser-based scripts and external services
Every one of those layers needs to be checked.
Why was it difficult to fix?
The attack was not a single obvious file that could simply be deleted.
The malicious code was hidden among legitimate website files. Some of the injected content was disguised or decoded only when it ran. The Cloudflare code fetched further instructions from outside the website and tried to behave differently depending on the visitor and their browser.
There were also signs that the attackers were looking for ways into website backup and migration tools. Those tools are useful, but they can become attractive targets because they may be able to export, import or write large parts of a website.
Modern attacks can involve automated scanning, stolen passwords, hidden scripts, fake browser checks, cloud-based code and carefully timed changes. Some of these techniques may be assisted by AI or other automated tools. It is not always possible to prove exactly how an attacker created each part of an attack, but the result is clear: attacks are becoming more organised, faster and more technically capable.
The risks
The immediate risk was to visitors. Someone arriving at the site could have been shown a fake CAPTCHA or malicious browser content.
There were also risks to the website itself:
- Attackers could have changed pages or added hidden links.
- Existing administrator sessions could have been stolen.
- Website passwords could have been exposed.
- Backup files could have contained sensitive information.
- Malicious code could have been used to attack visitors or other websites.
- Cached content could have continued serving the attack after the original files were cleaned.
That is why it was important not simply to remove the visible problem and carry on.
What we did
First, evidence was preserved. Logs, suspicious files, configurations and hashes were saved so that the incident could be understood rather than guessed at.
The confirmed malicious files and plugin were quarantined. WordPress security salts were changed to invalidate existing sessions. Administrator passwords were reset, and the website software was brought up to date.
The Cloudflare Worker and its routes were investigated. The malicious behaviour was neutralised, the affected routes were removed and the caches were purged.
The server was also updated. PHP was upgraded, the server operating system packages were updated, the kernel was updated and the machine was rebooted. Database passwords and hosted-site passwords were rotated, and old website copies and backup archives were moved outside the public serving directories.
The other WordPress installations on the server were checked and updated as well. Database backups were made before the updates, and the public sites were tested afterwards.
What we learned
The existing monitoring and patching arrangements were valuable, but this incident showed why they need to be combined with deeper checks.
The most important lesson is that security is not a one-off job. A website needs:
- Strong, unique passwords
- Updated WordPress, plugins, themes and server software
- Backups kept outside the public website directory
- Regular checks for unfamiliar users and files
- Careful control of administrator and hosting accounts
- Monitoring of cloud services and cached content
- A plan for what to do when something goes wrong
It is also important not to assume that a clean-looking webpage means that everything is clean. The page may be coming from a cache. A cloud service may be changing it. A database may be generating content that is not visible in the files. A hidden scheduled task may be waiting to run later.
The site is now back to normal
The fake CAPTCHA and cryptocurrency-related browser injection are no longer being served. The malicious Worker routes were removed, the origin files were checked, the server was upgraded and the public website was tested again.
There is no useful lesson in pretending that attacks are simple. They are not. The work required to resolve this one was considerably greater than deleting a suspicious file or changing one password.
But there is a positive lesson too. A careful, staged response works. Preserve the evidence, contain the problem, check every layer, rotate the credentials, update the software, and test the result from the point of view of a normal visitor.
That is how a website gets back on its feet.
And, rather like retirement itself, it is better to plan for the unexpected before you need to.