From Crisis to Clean: How We Saved a Hacked WordPress Site with 1,970 Infected Files

We uncovered the hacked WordPress site during our onboarding process, and the client had no idea their site had been compromised, let alone completely pwned—meaning it was fully controlled and exploited by an attacker. What made things even worse — it was a membership website, meaning user data and activity were at risk. The situation required our immediate attention to regain control. Nearly 2,000 files were infected, multiple database tables were corrupted, the client was on the precipice of losing user trust. Their digital storefront—critical to their business—was effectively a playground for cybercriminals.

We found malware embedded in plugins, core files compromised, and rogue PHP scripts lying in wait for their next malicious move. This wasn’t a run-of-the-mill cleanup—it was a total rehabilitation.

Let’s break down how our team at SiteCare tackled this digital disaster and restored their site to health.

A snapshot of the damage: When malware runs amok

From the moment we accessed the compromised environment, we could see the infection was widespread. Our security tool flagged 1,970 malicious files and one rogue script, many of which were in critical plugin directories like:

• ProgressAlly: Malicious JavaScript files like progressally-post.js were injected to exploit front-end functionality.
• Tracking Code Manager: Hackers exploited i18n assets (e.g., select2-4.0.13/i18n/en.js) to distribute phishing links disguised as language support files.
• Custom PHP backdoors: Files such as fooster1337.php in plugin directories acted as “backdoor scripts,” allowing attackers to regain access even after initial cleanup.

In cases like this, hackers often use obfuscation techniques to conceal malicious payloads within legitimate-looking files. These scripts can include a variety of base64-encoded strings, randomized function names, and chained operations to hide their true intent. All of these are digital trojan horses. On the surface everything looks copacetic, but deep within the code there are serious threats that can be difficult to detect.

Beyond the files, the database was infiltrated. One table was completely compromised with injected spam links and redirects targeting unsuspecting users. This isn’t just an annoyance—it’s an SEO nightmare. Google flags infected sites, meaning the client’s traffic and reputation were both circling the drain.

How we took back control of the hacked WordPress site: A multi-layered approach

If you’re looking for how-to steps for cleaning malware from a hacked WordPress site, I recommend checking out Malcare’s guide for cleaning a malware infection. To see how our team tackled this particularly messy infection, read on.

1. Immediate containment

First, we quarantined the infected environment. By temporarily taking the site offline, we halted malicious activity and ensured the infection wouldn’t spread further. This step is crucial in limiting the scope of damage, particularly for membership sites where user data and transaction and usage activity are at risk.

We also reset all access credentials—including admin accounts, SFTP, and database connections—to lock out unauthorized access. Hackers often create hidden admin accounts to maintain control after a breach, so a thorough audit of user roles was essential.

2. File-level malware cleanup for a hacked WordPress site

Cleaning nearly 2,000 infected files required a combination of automated and manual techniques:

• Automation with precision: We used malware scanners to identify files with known malicious signatures. Tools can quickly flag patterns, but they’re not perfect. For example, they can’t reliably detect obfuscated scripts that resemble legitimate code.
• Manual code review: Our team went line by line through critical files—especially in /wp-content/plugins/and the client’s themes. For instance, we found and removed suspicious base64-encoded payloads, often embedded within JavaScript and PHP files. Example: eval(base64_decode('aWYoIWZ1bmN0aW9uX2V4aXN0cygnaGVsbG8nKSl7ZXZhbCg...')); This is a classic hacker trick: encoding malicious functions to avoid detection.
• File restoration: Where possible, we replaced infected files with clean copies from the WordPress repository or official plugin directories. In some cases, we patched custom code instead of overwriting it to preserve functionality.

3. Database repair

The database presented a unique challenge. Infections at this level typically involve SQL injection attacks where hackers insert malicious scripts into tables. In this case:

• The posts table contained spammy redirects embedded in post content, targeting external phishing domains.
• Metadata tables included injected payloads designed to execute silently during routine operations.

To clean the database:

Analyzed backup snapshots: We compared the current database against backups to identify discrepancies. This helped us pinpoint the injected data and restore tables to their original state.

Sanitized input fields: For example, any field accepting user input (e.g., comments, custom forms) was scrubbed to remove embedded scripts.

Hardened database permissions: We limited write access to critical tables and enforced stronger user authentication for database connections.

4. Strengthening security

Once the malware was eradicated, we shifted our focus to hardening the site. This included:

• Implementing a Web Application Firewall (WAF): The client’s site now filters malicious traffic before it even reaches the server.
• Configuring real-time monitoring: Using a security stack that includes server-level logging, file change detection, and proactive alerts.
• Regular backup schedules: Incremental backups ensure we can restore the site quickly in case of future issues.
• Disabling dangerous PHP functions: Functions like eval() and exec()—often used in backdoors—were disabled at the server level.