How to Recover a Hacked WordPress Site: Step-by-Step Guide

If you run WordPress sites, this is something you hope never happens.

Recently, two of my websites (pakspace.com and zubair.pk) were compromised. Instead of just cleaning them, I took it further — full recovery + security hardening.

This guide walks you through everything I did, in a practical, real-world way.

🚨 Signs Your WordPress Site Is Hacked

Here’s what raised the alarm:

• Unknown admin user: bbp_support_agent
• PHP files inside /wp-content/uploads
• Suspicious activity in database
• Possible unauthorized access

These are classic indicators of compromise.

🧩 How WordPress Hacks Typically Work

🔍 Step 1: Identify Unauthorized Access

I checked users directly via database:

php -r '
require "/path/to/wp-config.php";
$mysqli = new mysqli(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME);
$res = $mysqli->query("SELECT user_login, user_email FROM wp_users");
while($row = $res->fetch_assoc()){
    print_r($row);
}'

👉 Found:

• Legit users ✅
• Rogue admin ❌

✔️ Deleted malicious admin immediately

📁 Step 2: Remove Malicious Files

Biggest red flag:

PHP files inside /uploads

Scan:

find /home/... -type f -path "*/wp-content/uploads/*.php"

Removed suspicious files.

Verify cleanup:

find /home/... -type f -path "*/wp-content/uploads/*.php" ! -name "index.php"

✔️ Clean

🗃️ Step 3: Scan Database for Malware

Used safe queries:

SELECT option_name, option_value
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%iframe%'
   OR option_value LIKE '%base64_decode%'
   OR option_value LIKE '%eval(%';

👉 Result:

• Only ad scripts
• No obfuscated payloads

✔️ Database clean

🔌 Step 4: Inspect MU Plugins

Found:

wp-content/mu-plugins/woocommerce-analytics-proxy-speed-module.php

Checked manually:

• readable code
• no obfuscation

✔️ Safe

🔐 Step 5: Block PHP Execution in Uploads

Added .htaccess:

<Files *.php>
deny from all
</Files>

✔️ Prevents future shell execution

🔑 Step 6: Rotate WordPress Salts

Generated:

curl -s https://api.wordpress.org/secret-key/1.1/salt/

Replaced in wp-config.php

✔️ Logged out all sessions

⚠️ Step 7: Database Password Rotation (What Went Wrong)

Tried automating password rotation…

💥 Broke both sites.

Root cause:

• MySQL host mismatch (localhost vs 127.0.0.1)
• Script corrupted wp-config.php

Fix:

• Restored backup
• Recovered instantly

🛠️ Recovery Flow

🔒 Step 8: Security Hardening (CRITICAL)

After cleanup, I didn’t stop there.

✅ Enabled 2FA Everywhere

• WordPress admin (via plugin)
• SSH server access

[ Password ]
     +
[ 2FA Code ]
     =
Strong Authentication

👉 This alone blocks most attacks.

✅ Server Hardening Done

Key improvements:

• Disabled unnecessary services
• Secured SSH (no weak auth)
• Limited access points
• Ensured proper file permissions
• Checked cron jobs for persistence
• Verified no hidden processes

✅ WordPress Hardening

Added:

define('DISALLOW_FILE_EDIT', true);

Also:

• removed unused plugins/themes
• updated everything
• enforced strong passwords

✅ Final State

• ✔ Malware removed
• ✔ Rogue admin removed
• ✔ Database clean
• ✔ Uploads secured
• ✔ Salts rotated
• ✔ 2FA enabled (WP + SSH)
• ✔ Server hardened
• ✔ Sites fully operational

🛡️ Key Lessons

1. Uploads folder = biggest risk
2. Always check for rogue admins
3. Don’t blindly automate config edits
4. Backups are lifesavers
5. 2FA is non-negotiable
6. Server-level security matters as much as WordPress

🔁 Ongoing Monitoring

Run periodically:

find /home/... -type f \( -path "*/uploads/*.php" -o -name ".*.php" -o -name "*.phtml" \)

Should always return nothing.

💬 Final Thoughts

Cleaning a hacked WordPress site isn’t just about removing malware.

It’s about:

• understanding the attack
• removing persistence
• hardening everything afterward

If you skip hardening, the attacker will come back.