GSC SEO Ranking Malware Highjack

Phase 1 — Discovery

From a GSC email to a full security breach

D1

Client flagged repeated Google Search Console warnings

The client had been receiving GSC notification emails about pages on his site that were not being indexed. He had contacted me repeatedly about these, not understanding what they meant. A 4-page business website should not be generating indexing errors — this was the first indicator that something was seriously wrong.

D2
GSC revealed the true scale of the breach ⚠ 3,450+ injected pages

            Checking the GSC account showed the scope of the attack immediately. A site with 4 legitimate pages had:
            
                    GSC Status
                    Reason
                    Pages
                  
                    Not Indexed
                    Crawled — currently not indexed (spam injection)
                    3,389
                  
                    Not Indexed
                    Alternate page with proper canonical tag
                    28
                  
                    Not Indexed
                    Server error (5xx)
                    25
                  
                    Not Indexed
                    Not found (404)
                    2
                  
                    Indexed
                    Legitimate pages + spam pages Google had already indexed
                    587

GSC Status	Reason	Pages
Not Indexed	Crawled — currently not indexed (spam injection)	3,389
Not Indexed	Alternate page with proper canonical tag	28
Not Indexed	Server error (5xx)	25
Not Indexed	Not found (404)	2
Indexed	Legitimate pages + spam pages Google had already indexed	587

D3

Google search confirmed the spam injection in full

Running a site:prideceilingsdrywall.co.za search on Google revealed everything. Alongside the 4 legitimate business pages, the results were filled with spam product listings in Japanese — Canon laser printers, Nike trainers, and Japanese retail products — all appearing to be hosted on the client’s domain. Google had already crawled and indexed hundreds of these pages, which was actively poisoning the site’s SEO profile.

GSC Indexing Dashboard

3.45K not indexed / 587 indexed — showing the spike in crawled spam pages

📸 Screenshot — Google Site Search Results

site:prideceilingsdrywall.co.za showing Japanese spam product pages indexed under the client’s domain

Google Site Search Results for Japanese Spam

📸 Screenshot — Google Site Search Results

site:prideceilingsdrywall.co.za showing Japanese spam product pages indexed under the client’s domain

⚠ Why this type of attack is so damaging

Japanese keyword spam (also called “pharma hack” or “SEO spam injection”) is a specific class of attack where malware silently creates thousands of pages targeting Japanese search queries. These pages get indexed under the victim’s domain, associating their site with spam content. Google responds by either deindexing pages or penalising the site’s overall search rankings — even the legitimate pages. Left unaddressed, this can permanently damage a domain’s reputation with Google.

Phase 2 — Forensics

Getting in and understanding the damage

F1

wp-admin was inaccessible — gained access via SSH from the host

The attacker had locked the client out of the wp-admin dashboard. With no frontend access, the only path in was at the server level. SSH credentials were obtained directly from the hosting provider, allowing access to the server’s file system and the ability to run WP-CLI commands from the terminal.

F2
WP-CLI user list revealed two rogue administrator accounts ⚠

            Running wp user list via the SSH terminal revealed the full user table. The legitimate client account was present — but two additional administrator accounts had been created by the attacker:
            WP-CLI — wp user list (output)
| ID | user_login                       | display_name | user_email                       | roles         |
  1  | inf@prideceilingsdrywall.co.za   | (client)     | inf@prideceilingsdrywall.co.za   | administrator
  3  | Sindie                           | Sindie       | sindie2465@gmail.com             | administrator
  4  | zetgifari                        | zetgifari    | boss@gmail.com                   | administrator

            ID 3 (Sindie / sindie2465@gmail.com) and ID 4 (zetgifari / boss@gmail.com) were both unknown. Two rogue admin accounts — the attacker had created a backup account in case one was removed.
          

F3

Rogue admin accounts removed and client’s password reset via WP-CLI

Both unauthorised administrator accounts were deleted immediately via WP-CLI. The client’s own password was then reset via the command line to restore wp-admin access without needing the compromised login flow:

WP-CLI — Remove rogue users and restore access
# Remove both rogue admin accounts
wp user delete 3 –reassign=1
wp user delete 4 –reassign=1

# Reset client’s password to regain wp-admin access
wp user update 1 –user_pass=”[new-secure-password]”

F4
Core file checksum verification revealed extensive malware ⚠

            Before any cleanup began, a backup was taken — database and all files — then core file integrity was checked:
            WP-CLI — Backup and checksum verification
# Full backup before touching anything
wp db export backup.sql
tar -czf backup.tar.gz public_html

# Verify WordPress core file integrity
wp core verify-checksums

            The output was extensive — dozens of Warning: File should not exist errors across wp-includes, wp-admin, and the root directory. Unknown files had been injected throughout the core file structure. The installation would not verify against checksums at all.
          

📸 Screenshot — SSH Terminal / WP-CLI

wp user list output showing rogue admin accounts, and wp core verify-checksums warning output

Phase 3 — Remediation

Cleaning the site, the database, and Google

R1
WordPress core forcibly re-downloaded and reinstalled ⭐

            With the core files verified as compromised, the only correct response was to replace them entirely. The --force flag overwrites all core files with clean copies from the official WordPress repository, while --skip-content leaves themes, plugins, and uploads untouched:
            WP-CLI — Force reinstall clean core files
wp core download –force –skip-content

# Re-run verification to confirm clean state
wp core verify-checksums
Success: WordPress installation verifies against checksums.

R2

Malware files in the root folder manually deleted

The injected files identified by the checksum verification — including rogue index.php files, unknown .htaccess entries, and fabricated directory structures — were located and deleted from the server root. These were the files responsible for generating the thousands of spam product URLs that had been served to Google’s crawler.

R3

Security keys reshuffled to invalidate any active attacker sessions

Even with the rogue accounts removed and core files replaced, the attacker may have still held valid session cookies. Reshuffling the WordPress secret keys and salts immediately invalidates all active sessions — including any the attacker might still have open — and forces all users to re-authenticate:

WP-CLI — Invalidate all sessions
wp config shuffle-salts
Success: Shuffled the salt keys.

R4

MySQL database repaired to remove any injected spam links

The database was inspected and repaired to ensure no spam links or malicious redirects had been inserted into the database itself — a common secondary injection point in this type of attack. Database transients (cached query results) and accumulated post revisions were also cleared to ensure no residual spam data remained in the tables.

R5
Google Search Console — spam URLs removed and clean sitemap resubmitted ⭐

            Cleaning the server was only half the job. The thousands of spam pages that Google had already crawled and indexed under the client’s domain still existed in Google’s index — and would continue to damage the site’s SEO rankings until they were removed. Two actions were taken in GSC:
            1
A URL removal request was submitted for the entire /items/ path prefix — removing all URLs with that prefix from Google Search for six months, giving the legitimate site time to recover its correct index state.
2
The clean XML sitemap (containing only the 4 legitimate pages) was resubmitted to GSC, signalling to Google exactly what the site should contain and prompting a re-crawl against the clean state.

📸 Screenshot — GSC URL Removal Request

Removal request for /items/ prefix and clean sitemap resubmission

Phase 4 — Hardening

Locking the site down against re-entry

Hardening 01

2FA enabled on all accounts

Two-factor authentication was activated for all WordPress user accounts. Even if credentials are compromised in future, the attacker cannot log in without the second factor.

Hardening 02

Login attempts limited

Brute-force login protection was configured to limit and lock out failed login attempts. This closes the most common vector for credential attacks against WordPress admin accounts.

Hardening 03

All passwords changed

Every user account password was reset to a strong, unique credential. With salts reshuffled and passwords changed, any previously stolen session data or credentials is completely invalidated.

Hardening 04

Full security scan performed

A complete security scan was run post-cleanup to confirm no residual malware, backdoors, or injected files remained anywhere in the installation — themes, plugins, uploads, or root.

ℹ Why hardening after a hack is non-negotiable

Cleaning malware without hardening the site is like fixing a broken lock and leaving the key in the door. Attackers often leave backdoors — hidden access points that allow re-entry even after the visible malware is removed. The hardening steps taken here close the primary re-entry vectors: credential reuse, brute-force login, and active sessions from stolen cookies.

Aftermath

What the site looks like after recovery

✓
Site fully restored: All malware files removed, WordPress core replaced with verified clean files — confirmed by checksum
✓
Both rogue admin accounts deleted: zetgifari (boss@gmail.com) and Sindie (sindie2465@gmail.com) removed from the user table
✓
GSC spam URLs removed: Removal request submitted for the entire /items/ prefix — thousands of spam pages blocked from Google Search
✓
Clean sitemap resubmitted: Google recrawl initiated against the correct 4-page sitemap — legitimate pages reindexed cleanly
✓
Database cleaned: All transients and post revisions cleared — no residual spam content remaining in any database table
✓
Security keys reshuffled: All active sessions invalidated — including any the attacker may have still held
✓
2FA and login limits active: Site hardened against credential attacks and brute-force login attempts going forward
✓
Total resolution time: under 2 hours from first SSH access to clean site, clean GSC, and full hardening complete

📄 Incident Report

Incident: WordPress site compromise — Japanese keyword SEO spam injection with rogue admin account creation
Detected: Via repeated Google Search Console indexing alerts | Resolved: Under 2 hours
Root cause: Attacker gained admin access (vector unknown — likely compromised credentials or vulnerable plugin), created two rogue administrator accounts, injected malware files into the WordPress core directory, and generated 3,450+ spam product pages under the client’s domain for Japanese search traffic.
Resolution: SSH access via host. Rogue admin accounts removed via WP-CLI. Client password reset. Full backup taken. Core files force-reinstalled and verified. Malware files deleted from root. MySQL database repaired. Security keys reshuffled. GSC spam URL removal requested and clean sitemap resubmitted. 2FA and login limits applied.
Prevention: 2FA enforced on all accounts. Login attempt limits active. Regular security scans recommended. Periodic user list audits advised.

Skills Demonstrated

What this incident showcases

Server-level incident response under pressure

This was a live site under active attack with no wp-admin access and thousands of spam pages already in Google’s index. Resolving it required server-level access, forensic diagnosis, and a coordinated response across the file system, the database, and Google Search Console simultaneously. That combination of skills is rare — most WordPress administrators can work in the dashboard. Fewer can operate confidently via SSH and WP-CLI when the dashboard has been taken away from them.

SSH server access: When wp-admin is locked out, the only path in is at the server level. Knowing how to work there is a hard differentiator.
WP-CLI forensics: User list inspection, password reset, core checksum verification, salt reshuffling, and database export — all performed from the terminal without dashboard access.
Malware identification and removal: Using wp core verify-checksums to identify injected files, then surgically removing them without touching legitimate content.
GSC incident management: Knowing that cleaning the server is only half the job — the spam URLs already in Google’s index also need to be removed, and the correct sitemap needs to be resubmitted to trigger a clean recrawl.
Security hardening post-incident: 2FA, login limits, salt reshuffling, and full user audit applied as a standard post-compromise checklist — not an afterthought.