WordPress hacked: behind the defaced site, a compromised server

The WordPress site has been defaced. That visible change triggers an emergency intervention. This is a staging site, the environment used to prepare changes before sending them to production. Restoring the proper page might seem a reasonable place to start. But how far have the attackers got?

Behind this hacked WordPress site, the investigation finds several backdoors, retrieved data and a miner hidden on the server. The web account’s permissions reach far beyond the site itself. The machine also hosts other services, and data transfers connect it to production.

Understanding why this incident required a rebuild means following that widening scope: from the visible page to the access left open to attackers, then to what that access could reach. This anonymised account presents the findings in increasing order of severity, rather than the order in which they were discovered. It follows Cascading vulnerabilities with the case of a secondary service whose compromise put an entire machine at risk.

A major vulnerability in WordPress core allowed remote code execution without logging in. No vulnerable plugin or stolen password was needed: a standard installation of an affected version was enough. Searchlight Cyber described this chain, named wp2shell.

WordPress released the fix and triggered forced updates on compatible installations. The race began immediately. ELLIO observed the first probes on its decoy network the following day, followed by a mass campaign less than two days after the patch was published. Site discovery and exploitation attempts were already happening at scale.

The chain was becoming automated. Tools tested targets, sought to retrieve data and attempted to establish lasting access. Elastic ran a public tool in its lab that chained exploitation, plugin deployment and command execution. An internet-facing staging site was within the same search space as a public website.

In our case, production had applied the patch before the first attempts retained in its logs. The move to the fixed version is visible there and is consistent with an automatic update. Staging, however, was compromised. Why its update was delayed remains unknown. That difference mattered: the patch had closed the vulnerability in production before the observed attacks arrived.

On staging, administrator accounts had been added through the attack. The intruders therefore had credentials to return through the site’s administration interface. Malicious plugins provided further access among WordPress’s legitimate components.

Remote command scripts had also been planted. These backdoors let someone instruct the web server to read files, write others and launch programs with that account’s permissions. Some were concealed in subdirectories or disguised as ordinary files. Removing one malicious plugin would leave other entry points intact.

The data had been reached too. Records documented retrieval of the configuration file, which contains database credentials, and an SQL extraction. The problem now extended beyond what visitors could see. Information had been retrieved, and the secrets held in the configuration needed replacing.

Restoring the page would have left usable accounts, code capable of accepting commands and database access that had already been exposed. Even after an update, a backdoor remains useful: the attacker no longer needs to exploit the original vulnerability to return. The response had to find those access points and examine what they had enabled.

Another use of the machine emerged: it had been mining cryptocurrency. The software found was XMRig, a Monero miner. It ran under the web server account, using the server’s resources for the attackers’ benefit.

Its installation was designed to blend into the system. Files were concealed inside a hidden directory whose name resembled a system service, followed by another hidden subdirectory. Cache and library names made the contents less conspicuous. Modification timestamps had been falsified to make the files look older than their actual deployment.

The miner also had a restart mechanism. A scheduled task called a watchdog script every five minutes. Stopping a single process would leave behind the means to start it again. The retained logs establish prolonged activity over several weeks: the server had been working for people other than its legitimate users.

This presence widened the investigation again. Scheduled tasks and files outside WordPress had to be examined, including the system’s temporary directories. The different intrusions cannot be attributed to a single actor. They did, however, leave several ways to use and revisit the same machine.

The most dangerous finding lay in the web account’s permissions. The account running WordPress belonged to a group with access to the container engine. That access makes it possible to launch a container with access to the host’s files and take control of the host. Code execution inside the site could therefore reach beyond WordPress.

The investigation did not establish a takeover as root, the system administrator account. But compromise was confirmed, and the account in use had a path to host control. Under those conditions, the whole machine had to be treated as compromised and rebuilt. Removing only the identified files would not make it a trustworthy place to run services and store secrets again.

Other services shared this host. Their files, configurations and any secrets accessible with the permissions obtained fell within the scope of the investigation. Although staging existed to prepare a website, its permissions had placed it close to resources far beyond that purpose.

There was also a route to production: file and database synchronisation. Transfers from staging to production were documented. If a synchronisation carries a malicious file or an administrator account added to the database, it can carry the compromise alongside the expected changes. The destination server need no longer be vulnerable to the original flaw.

Patched production therefore remained exposed to that mechanism. The checks performed did not establish contamination through this chain. The transfers, the states transferred and the credentials authorising them still needed examination. The boundary between preparation and production also depended on what could cross it.

The response brought many people together. Evidence had to be preserved, dangerous access closed, legitimate services maintained and recovery prepared. Evidence was retained before removals. The machine was reinstalled, backups examined and secrets replaced.

The order matters. A backup can contain the same malicious files as the site just removed. A fresh secret placed on a machine that remains compromised can be retrieved in turn. Recovery therefore combined selecting what to restore, a reinstalled system and credential rotation, rather than simply putting the old directory tree back online.

Rebuilding also changed the boundaries. Organising infrastructure by environment and site, with dedicated servers, reduces the shared perimeter. SQL accounts are restricted to the site’s database. Service account permissions are reviewed to prevent web access from granting host control. Transfers to production are part of that review: their credentials and the content they carry affect the destination service’s security.

Staging is now protected by HTTP authentication. Sensitive paths, including configuration and backup files, are explicitly denied; valid credentials do not grant access to those files. Scripts are blocked in the relevant directories. Administration and image uploads were checked after hardening to preserve the workflows people need.

Maintenance now produces records that can be inspected. A system scheduler triggers it under a service account, with a lock against concurrent runs, logged errors and a last-success date. Actual scheduled runs were observed. WordPress core and eligible plugins and themes from the official repository are covered; private and premium components require their own follow-up. Monitoring for a missing success still needs to be connected and verified.

Settings are described in Terraform and Ansible, runtime versions have been modernised, and checked reruns on staging produced no changes. The team now has a configuration it can reproduce and examine. This collective effort brought the organisation out of the emergency with rebuilt infrastructure and a thoroughly revised security policy.

For a business leader, this case offers another way to assess secondary services: what access do they open, what can they send to production, and what recent evidence shows that maintenance works? A technical and organisational diagnostic helps establish the missing answers. Application and operational security then means maintaining those boundaries, including for a site whose downtime once seemed inexpensive.