Anonymized case study. Client names, domains and identifying details are removed. Work carried out in July 2026.

In July 2026, we investigated a compromised WordPress site belonging to a law firm. The only full copy available for analysis was a recent backup. We found ten malicious files hidden in five randomly named folders, disguised as a legitimate plugin and theme. One of the tools was designed to find and attack other websites on the same hosting account.

The oldest malicious file was about three months old. This meant the attacker had potentially maintained access for months, and recent backups could not automatically be trusted.

We identified the malicious files, preserved the evidence, checked the live site and closed the access the attacker relied on.

What we found

The backup was an All-in-One WP Migration export containing the website files and database, with about 2,800 files in total. Ten were malicious. They came from three distinct payloads copied several times.

  • A web file manager, five copies. It allowed an attacker to browse, upload, edit, delete and change permissions on files under the web root. This also provided a way to read wp-config.php, which contains the database password.
  • A reconnaissance and spreading tool, three copies. It listed other websites on the shared server, checked which files and folders were writable, and allowed commands to be run.
  • An obfuscated version of the same tool, two copies. Encoded strings were used to make the malicious code harder for signature-based scanners to detect.

The files were placed in folders with random seven-letter names, inside directories made to look like a legitimate file-protection plugin and a child theme.

There was a reason for the multiple copies. Removing one malicious file would not remove the others. As long as another copy remained accessible, the attacker could still use it.

The oldest malicious file was dated about 92 days before the backup was taken. That gave us a minimum period of around three months during which the attacker had access.

What we did

We followed a structured cleanup process to avoid removing legitimate files or destroying useful evidence.

  1. Confirmed what was legitimate. We compared the site's actual plugins, theme and custom code against their known contents. This helped us identify the malicious files without removing legitimate functionality.
  2. Quarantined the files instead of deleting them. All five malicious folders were moved to a quarantine area. We recorded their hashes and timestamps to preserve the evidence for reporting.
  3. Checked the live website. A backup only shows the state of the site when it was created. We checked the live installation for the same infection rather than assuming that the backup told us everything.
  4. Closed the attacker's access. We rotated the WordPress security keys and salts to invalidate existing login sessions. We also changed the hosting FTP password and confirmed that the old password no longer worked. Exposed backup files were removed from the hosting storage.
  5. Flagged the other websites. Since the spreading tool was designed to target neighboring sites, we recommended checking every website under the same hosting account and treating them as potentially compromised until verified.

What website owners should take away

  • A backup is not automatically clean. If an attacker has access for months, the infection can also be present in multiple backups. Check before restoring. Our guide to scanning WordPress for malware explains how.
  • Pay attention to unexpected folders. Randomly named directories inside wp-content/plugins or wp-content/themes deserve investigation, especially when their contents do not match the legitimate software. See how to find a backdoor in WordPress.
  • Shared hosting creates shared risk. If websites run under the same account and have access to each other's files, compromising one can expose the others. Important sites should use separate accounts or isolated users where possible.

When to get help

If you are unsure whether a backup is safe to restore, check it first. Restoring an infected backup can bring the same backdoor straight back to the website.

Our WordPress malware removal service includes checking backups and other websites under the same hosting account. A security audit can also help identify weaknesses in the setup that allowed the attacker to get in.

The important point is simple: cleaning the visible infection is not enough. You need to check the backup, verify the live site, close the attacker's access and investigate the other websites that may have been exposed.