WordPress Hacked? 8 Steps We Used to Recover the Site

First-Hour Dos and Don’ts

Our WordPress Hack

\u0259
\u00e7
\u015f

We created a new AWS Lightsail instance and moved the website. The site looked clean until we imported the old WordPress database.

The spam came straight back.

That result showed us that the infection did not live only in the old server files. The database still carried the malicious content.

Lock the Hacker Out

When you find a WordPress hacked site, secure access before you remove visible spam. Deleting casino links will not help when the attacker can still use an administrator account, application password, active session, plugin, or server backdoor.

Save the Evidence

• Record when you first noticed the attack and include your timezone.
• Capture screenshots of affected pages.
• Save unknown users, roles, and application-password details.
• Record spam keywords, domains, redirects, and foreign-language phrases.
• Note recent plugin, theme, server, and account changes.
• Record Search Console or hosting warnings.
• Document every recovery action.

WordPress also recommends documenting a compromise before cleanup in its official hacked-site recovery guidance.

Back Up Before Cleanup

Run the backup command from the server terminal, not from the WordPress editor, browser, or MariaDB prompt.

Connect to the Server

If you use AWS Lightsail, open your instance and choose Connect using SSH. Other hosts may provide a browser terminal, SSH credentials, or a hosting console.

Open your WordPress wp-config.php file and locate:

define('DB_NAME', 'your_database_name');
define('DB_USER', 'your_database_user');
define('DB_PASSWORD', 'your_database_password');

$table_prefix = 'wp_';

Write down the values for DB_NAME, DB_USER, and the table prefix. Keep the database password private.

Create the Database Export

mysqldump -u DATABASE_USER -p DATABASE_NAME > wordpress-backup.sql

Replace:

• DATABASE_USER with the value from DB_USER
• DATABASE_NAME with the value from DB_NAME

MariaDB will ask for the database password. Enter the value from DB_PASSWORD. The terminal may not show characters while you type. That is normal.

Confirm the Backup Worked

ls -lh wordpress-backup.sql

The output should show the file name and a size greater than zero.

We created:

• An AWS Lightsail snapshot
• A full copy of the website files
• A complete MariaDB export
• A copy of the affected page record
• Screenshots of suspicious accounts
• A list of spam keywords and domains

Why the Hack Returned

Moving the website to a clean server removed the old server environment, but it did not clean the imported data. When we imported the old database, WordPress brought back the infected homepage and revisions.

How SEO Spam Works

SEO spam happens when an attacker injects unauthorized keywords, links, pages, or redirects into a trusted website.

• Spam-link injection
• Casino spam
• Search spam
• Japanese keyword spam
• Pharmaceutical spam
• Search-engine poisoning

Why Attackers Add Spam

• Place gambling links on a trusted domain
• Use the website’s authority
• Improve another site’s rankings
• Create spam pages for search engines
• Hide links inside legitimate content
• Redirect visitors
• Generate affiliate revenue
• Damage rankings and reputation

How They May Get In

• Outdated plugins
• Vulnerable themes
• Stolen administrator passwords
• Malicious or nulled plugins
• Compromised SSH credentials
• Infected backups
• Weak hosting passwords
• Unpatched WordPress
• Unauthorized application passwords
• Compromised integrations
• Exposed database credentials

These possibilities do not prove the original entry point. Use logs and evidence before you assign blame.

Find Spam in MariaDB

Before You Search

Collect exact indicators from the hacked page first:

• Casino or betting terms
• Unknown domains
• Foreign-language phrases
• Redirect URLs
• Spam brand names
• Suspicious HTML or script fragments

Start with one or two specific indicators. Very broad words may return legitimate content.

sudo mariadb

MariaDB [(none)]>

USE DATABASE_NAME;

Database changed

SHOW TABLES;

$table_prefix = 'wp_';

SELECT ID, post_title, post_type, post_status
FROM wp_posts
WHERE post_content LIKE '%spam-keyword%'
   OR post_content LIKE '%casino%'
   OR post_content LIKE '%plinko%';

WHERE post_content LIKE '%unknown-domain.com%'
   OR post_content LIKE '%betting-brand%'
   OR post_content LIKE '%casino%';

SELECT post_type, post_status, COUNT(*) AS total
FROM wp_posts
WHERE post_content LIKE '%spam-keyword%'
   OR post_content LIKE '%casino%'
   OR post_content LIKE '%plinko%'
GROUP BY post_type, post_status;

page          publish
post          trash
revision      inherit
oembed_cache

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('show_on_front', 'page_on_front');

SELECT ID, post_title, post_name
FROM wp_posts
WHERE post_type = 'page'
  AND post_status = 'publish'
  AND (
      post_content LIKE '%spam-keyword%'
      OR post_content LIKE '%casino%'
      OR post_content LIKE '%plinko%'
  );

POST_ID

SELECT ID, post_date, post_title
FROM wp_posts
WHERE post_type = 'revision'
  AND post_parent = POST_ID
ORDER BY post_date DESC
LIMIT 20;

SELECT ID, post_date,
CASE
    WHEN post_content LIKE '%spam-keyword%'
      OR post_content LIKE '%casino%'
      OR post_content LIKE '%plinko%'
    THEN 'INFECTED'
    ELSE 'NO KNOWN SPAM FOUND'
END AS revision_status
FROM wp_posts
WHERE post_type = 'revision'
  AND post_parent = POST_ID
ORDER BY post_date DESC;

SELECT ID, post_date
FROM wp_posts
WHERE post_type = 'revision'
  AND post_parent = POST_ID
  AND post_content NOT LIKE '%spam-keyword%'
  AND post_content NOT LIKE '%casino%'
  AND post_content NOT LIKE '%plinko%'
ORDER BY post_date DESC
LIMIT 5;

REVISION_ID

SELECT LEFT(post_content, 1000)
FROM wp_posts
WHERE ID = REVISION_ID;

SELECT post_content
FROM wp_posts
WHERE ID = REVISION_ID;

CREATE TABLE wp_posts_backup_page AS
SELECT *
FROM wp_posts
WHERE ID = POST_ID;

SELECT ID, post_title
FROM wp_posts_backup_page;

UPDATE wp_posts AS page
JOIN wp_posts AS revision
  ON revision.ID = REVISION_ID
SET page.post_content = revision.post_content
WHERE page.ID = POST_ID;

SELECT ID, post_title
FROM wp_posts
WHERE ID = POST_ID
  AND (
      post_content LIKE '%spam-keyword%'
      OR post_content LIKE '%casino%'
      OR post_content LIKE '%plinko%'
  );

EXIT;

Check Where Else It Hides

Restoring the page removes visible spam only from that record. Search other WordPress locations before you treat the site as clean.

Inspect Post Metadata

SELECT post_id, meta_key
FROM wp_postmeta
WHERE meta_value LIKE '%spam-keyword%';

Record the post_id and meta_key. Match the post_id with the related page before you edit anything.

Search WordPress Options

SELECT option_name
FROM wp_options
WHERE option_value LIKE '%spam-keyword%';

Record each returned option_name. WordPress options may contain widget data, theme settings, plugin settings, URLs, scheduled data, or cache values.

Review Spam Comments

SELECT comment_ID, comment_post_ID
FROM wp_comments
WHERE comment_content LIKE '%spam-keyword%';

Record the comment_ID, then review it in WordPress Dashboard → Comments. Do not open the submitted URL.

Expand the Search

Create a search list from the evidence:

• Every spam keyword
• Every unknown domain
• Every redirect destination
• Every foreign-language phrase
• Every suspicious brand
• Every encoded string
• Every unusual script fragment

Search relevant plugin tables when the infection involves a page builder, SEO plugin, cache plugin, redirect plugin, or custom content system.

Why Deleting Users Failed

Malicious access or content may remain inside posts, pages, revisions, metadata, options, widgets, menus, comments, plugin tables, application passwords, active sessions, PHP files, cron jobs, scheduled tasks, caches, and server processes.

A Subscriber normally cannot edit published pages through standard permissions. The attacker may also have gained administrator access, changed a role, used an API credential, exploited a plugin, modified the database, compromised hosting, or installed a backdoor.

What SEO Spam Damages

Remove Every Backdoor

Rotate Credentials Again

Rotate WordPress, hosting, AWS, database, SSH, SFTP, SMTP, CDN, API, application, and plugin credentials after cleanup.

Replace WordPress Core

Use a clean official copy. Review .htaccess, index.php, wp-config.php, and theme PHP files.

Reinstall Plugins and Themes

Use trusted vendor copies. Remove unused, abandoned, nulled, pirated, or unknown software.

Audit Every User

Review administrators, wp_users, wp_usermeta, roles, sessions, and application passwords again.

Update the Full Stack

Update WordPress, plugins, themes, PHP, MariaDB, Ubuntu, and server packages. Updates close known weaknesses but do not remove existing backdoors.

sudo apt update && sudo apt upgrade -y

This command updates Ubuntu packages. It does not update WordPress, plugins, or themes, and it does not remove malware. Restart services when required, then confirm that the website still works.

Scan the Uploads Folder

.php
.phtml
.phar

Record paths and timestamps, back up suspicious files, compare them with known legitimate files, and review nearby server activity.

Inspect Scheduled Tasks

Review WordPress cron, Ubuntu cron, plugin schedules, AWS automation, server timers, and unknown background processes.

Check Search Console

Look for unknown URLs, gambling queries, foreign-language terms, sudden index growth, security warnings, manual actions, unexpected sitemaps, ownership changes, and ranking drops. Request validation only after cleanup.

Stop the Next Attack

Protect Access

• Enable 2FA.
• Use unique passwords.
• Limit administrators.
• Audit application passwords.
• Restrict SSH.
• Use SFTP.

Keep Software Clean

• Update the full stack.
• Use trusted vendors.
• Remove unused software.
• Avoid nulled or pirated files.

Protect the Server

• Use a web application firewall.
• Apply least-privilege permissions.
• Disable PHP execution in uploads when appropriate.
• Create and test off-server backups.

Watch for Changes

• Monitor WordPress and server logs.
• Track file changes.
• Scan the database for spam terms and domains.
• Review users and roles.
• Moderate comments safely.
• Monitor Search Console.
• Check old databases before importing them.

Recovery at a Glance

What Finally Worked

1. We checked administrators.
2. We recorded suspicious details.
3. We revoked unauthorized application passwords.
4. We avoided opening spam links.
5. We changed credentials and enabled stronger authentication.
6. We ended sessions.
7. We backed up the server, files, and database.
8. We searched wp_posts.
9. We found the infected live page.
10. We inspected revisions.
11. We verified and restored a clean revision.
12. We searched other tables.
13. We reviewed files, plugins, users, and scheduled tasks.
14. We rotated credentials again.
15. We checked Search Console and monitored for reinfection.

For hands-on learning across cloud, cybersecurity, AI, and professional certifications, explore our Mockcertified practice tests.

WordPress Hack FAQs