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.

2. Revoke Unknown Access

Open each administrator profile and review Application Passwords.

• Check the credential name.
• Match it to an approved tool.
• Review creation and last-used details.
• Check the last-used IP address when available.
• Revoke anything your team cannot identify or authorize.

Changing the login password may not remove API access.Review and revoke application passwords directly from each user profile.

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

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.

Finish the Recovery Checks

Restoring the clean revision fixed the visible page, but we did not stop there. We checked the areas that could bring the spam back.

Review Users Again

Check administrators, wp_users, wp_usermeta, active sessions, and application passwords one more time. Confirm that every remaining account and integration belongs to your team.

Replace WordPress Core

Replace WordPress core files with a clean official copy. Review .htaccess, index.php, wp-config.php, and active theme PHP files before you reuse anything from the compromised server.

Reinstall Plugins and Themes

Install fresh copies from the official repository or original vendor. Remove unused, abandoned, unknown, nulled, or pirated software.

Scan the Uploads Folder

Investigate unexpected executable files in uploads:

.php
.phtml
.phar

Record file paths and timestamps, create a backup, and compare suspicious files with known legitimate files before deleting them.

Inspect Scheduled Tasks

Review WordPress cron events, Ubuntu cron jobs, plugin schedules, AWS automation, server timers, and unknown background processes. A scheduled task may recreate users or restore deleted malware.

Update the Full Stack

After you restore the site and confirm compatibility, update WordPress, plugins, themes, PHP, MariaDB, Ubuntu, and server packages.

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.

Check Search Console

Look for unknown indexed URLs, gambling or foreign-language queries, security warnings, unexpected sitemaps, ownership changes, and sudden index growth. Request validation or reindexing only after the website stays clean.

Recovery at a Glance

What Finally Worked

1. We recorded the unknown administrator and application-password details.
2. We revoked unauthorized access and ended active sessions.
3. We created server, file, database, and page-record backups.
4. We confirmed the database name and table prefix.
5. We searched wp_posts using the spam terms visible on the page.
6. We identified the affected published page and its saved revisions.
7. We manually verified a clean revision before restoring it.
8. We confirmed that the update affected one row.
9. We searched metadata, options, and comments for the same indicators.
10. We reviewed users, files, plugins, and scheduled tasks before monitoring the site.

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

WordPress Recovery FAQs