1. Executive Summary

A modern website compromise often isn’t as simple as:

“The hacker changed my homepage.”

A more sophisticated compromise can leave the visible website functioning normally while the attacker:

• uploads malicious PHP files
• creates hidden spam pages
• creates backdoors
• creates unauthorized administrator accounts
• modifies WordPress/plugin/theme files
• injects redirects
• manipulates search-engine crawling
• adds unauthorized Google Search Console ownership
• submits spam URLs
• monitors whether Google indexes the injected content
• maintains persistence so they can return after cleanup

The overall attack chain can look like this:

                         INTERNET
                            │
                            ▼
                  ┌──────────────────┐
                  │ Initial Access   │
                  └────────┬─────────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
          WordPress      Hosting       Credentials
          vulnerability  vulnerability  compromise
              │            │            │
              └────────────┼────────────┘
                           ▼
                    Web server access
                           │
                           ▼
                  ┌──────────────────┐
                  │ Persistence      │
                  └────────┬─────────┘
                           │
          ┌────────────────┼─────────────────┐
          │                │                 │
          ▼                ▼                 ▼
     Malicious PHP     Admin account     Verification
        files             creation          tokens
          │                │                 │
          └────────────────┼─────────────────┘
                           ▼
                   Search Console access
                           │
                           ▼
                 SEO / Spam / Redirects
                           │
                           ▼
                    Monetization

The crucial defensive principle is:

Search Console ownership is often a symptom of the compromise, not necessarily the initial point of compromise.

Google itself says that an unrecognized verified owner can indicate that a site has been hacked, and recommends removing both the owner and their verification tokens, followed by securing the underlying site. (Google Help)

---

2. What Is the Attacker Actually Trying to Achieve?

There isn’t one universal objective.

Common motivations include:

A. SEO spam

The attacker uses your domain to host pages promoting:

• gambling
• adult content
• pharmaceuticals
• cryptocurrency
• financial offers
• counterfeit products
• other affiliate businesses

For example:

https://example.com/random-page
https://example.com/cheap-product
https://example.com/offer

The legitimate owner may never see these pages in the site’s navigation.

---

B. Parasite SEO

This is particularly interesting.

The attacker wants:

Attacker content
       ↓
Your legitimate domain
       ↓
Google indexes it
       ↓
Search traffic
       ↓
Affiliate / advertising revenue

The attacker benefits from the reputation and history of an already-established domain.

---

C. Redirect traffic

The attacker may cause certain visitors to be redirected:

Google visitor
     ↓
Your domain
     ↓
Malicious/spam destination

But:

Direct visitor
     ↓
Normal website

This selective behavior can make the compromise difficult for the owner to notice.

---

D. Malware distribution

The compromised website can become a distribution point for malicious software.

---

E. Phishing

An attacker may create:

yourdomain.com/login
yourdomain.com/account
yourdomain.com/verify

that visually resembles another service.

The legitimate domain gives the fraudulent page additional credibility.

---

F. Long-term persistence

Sometimes the attacker’s objective isn’t immediate monetization.

They establish a backdoor and return later.

That’s why deleting one malicious file isn’t necessarily remediation.

---

3. Why Attackers Want Google Search Console Ownership

This is the part directly relevant to your SRESchool incident.

Google says a verified Search Console owner has the highest level of permissions for a property and can access sensitive search information and perform actions affecting the property’s presence/behavior in Google Search. (Google Help)

Search Console ownership can therefore be valuable to an attacker because it can give them:

Website compromise
       │
       ▼
Search Console ownership
       │
       ├── Monitor indexing
       ├── Inspect search data
       ├── Manage property access
       ├── Observe Google's treatment of pages
       └── Potentially manipulate certain search-related settings/actions

Google supports multiple ownership verification mechanisms, including HTML files, HTML tags and DNS-based verification. (Google Help)

This is why the verification mechanism is critical forensic evidence.

---

4. The Core Concept: Verification Tokens

A Search Console verification token is essentially evidence that Google uses to establish:

“This person controls something associated with this website.”

Google describes verification tokens as unique mechanisms associated with a specific user and property. (Google Help)

Examples include:

HTML file

googleXXXXXXXXXXXX.html

HTML meta tag

<meta name="google-site-verification"
      content="XXXXXXXXXXXX">

DNS TXT

google-site-verification=XXXXXXXXXXXX

Other Google-supported verification mechanisms can also involve services such as Analytics or Tag Manager. (Google Help)

---

5. How an Attacker Can End Up With a Verification Token

This is where defenders need to think in terms of capabilities.

An attacker needs some way to modify the location used for verification.

That capability might come from:

                    Attacker
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Website       DNS          Google
       access       access        account
          │            │            │
          ▼            ▼            ▼
     HTML/PHP       TXT record    Existing
       files                       account

Potential entry points include:

WordPress administrator compromise

An attacker obtains an administrator account.

Vulnerable plugin

A vulnerable plugin may allow unauthorized actions.

Vulnerable theme/custom code

Custom PHP code can expose dangerous functionality.

Stolen hosting credentials

For example:

• cPanel
• FTP
• SFTP
• SSH

DNS account compromise

The attacker controls the DNS provider and can manipulate verification records.

Shared-host compromise

WordPress itself notes that on shared hosting, another compromised site can potentially affect neighboring sites depending on host isolation. (WordPress Developer Resources)

Compromised developer workstation

A developer’s machine can expose:

• passwords
• SSH keys
• browser sessions
• FTP credentials
• cloud credentials

WordPress explicitly notes that compromised administrator computers can undermine server-side security. (WordPress Developer Resources)

---

6. Initial Access vs Persistence

This distinction is extremely important.

Initial Access

How did they get in?

Plugin vulnerability
Credential theft
WordPress account
Hosting account
DNS account
Server vulnerability

Persistence

How can they come back?

Backdoor
Malicious plugin
Modified theme
Injected PHP
Cron job
Unauthorized admin
SSH key
FTP account
Modified .htaccess
Database payload

You need to find both.

Otherwise:

Delete malware
      ↓
Attacker returns
      ↓
Malware recreated

---

7. Web Shells and Backdoors

A web shell is malicious server-side functionality that lets an attacker interact with the compromised server through HTTP.

Conceptually:

Attacker
   │
   │ HTTP request
   ▼
malicious PHP
   │
   ▼
server operation

The dangerous thing is that the file may look like an ordinary PHP file.

It might be:

random.php
cache.php
class.php
index.php
helper.php

Therefore:

Filename alone is not sufficient to determine whether a file is malicious.

You need to compare:

• file contents
• file location
• modification time
• ownership
• permissions
• known-good WordPress files
• plugin/theme version
• web-server logs

---

8. Why wp-content/uploads Is Interesting

WordPress uploads are normally used for media.

For example:

wp-content/uploads/2026/09/image.jpg

A PHP executable inside an uploads directory is therefore worth investigating.

For example:

wp-content/uploads/2026/09/random.php

doesn’t automatically prove compromise, but it is a strong investigation signal.

You can inventory PHP files without executing them:

find public_html/wp-content/uploads \
  -type f \
  \( -name "*.php" -o -name "*.phtml" \) \
  -print

Defensive principle: inventory first; don’t execute suspicious files.

---

9. SEO Cloaking

Another sophisticated technique is content differentiation.

Conceptually:

                 Request
                    │
                    ▼
             Detection logic
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     Normal visitor       Search crawler
          │                   │
          ▼                   ▼
   Normal website        Spam content

Or:

Direct visitor → normal site

Google result visitor → redirect

Specific country → spam

Specific device → normal

This makes manual investigation harder.

Therefore, testing only:

“Does the homepage look normal?”

is insufficient.

---

10. Database-Level Compromise

Not all malicious content exists in files.

WordPress stores enormous amounts of application data in MySQL.

Attackers may potentially abuse:

wp_options
wp_posts
wp_postmeta
wp_users
wp_usermeta

depending on the vulnerability.

For example, malicious content can exist as:

Hidden post
Injected option
Injected widget
Injected configuration
Unauthorized administrator

Therefore:

File scan
+
Database investigation

is much stronger than file scanning alone.

---

11. WordPress Administrator Compromise

Check:

WordPress → Users → All Users

Look for:

Unknown Administrator
Unknown Editor
Unknown account
Recently created user
Unexpected email address

An attacker with administrator privileges may have considerable ability to modify the application.

WordPress recommends strong passwords, two-step authentication, keeping software updated, and limiting unnecessary access. (WordPress Developer Resources)

---

12. Plugin Vulnerabilities

One of the major WordPress attack surfaces is third-party software.

Think:

WordPress core
     │
     ├── Plugin A
     ├── Plugin B
     ├── Plugin C
     ├── Theme
     └── Custom code

Every component increases the attack surface.

WordPress recommends keeping WordPress and plugins updated and deleting plugins that are no longer needed. (WordPress Developer Resources)

A strong operational rule is:

If you don’t need the plugin, remove it rather than merely disabling it.

---

13. Shared Hosting Makes This More Complicated

If several websites share one server:

Server
│
├── Site A
├── Site B
├── Site C
└── Site D

you need to investigate cross-account compromise.

WordPress explicitly warns that on shared hosting, compromise of another website can potentially lead to compromise of your site depending on the hosting environment. (WordPress Developer Resources)

Therefore, if:

SRESchool
+
other unrelated sites

are on the same server, don’t investigate SRESchool in isolation.

---

14. Why Attackers Put Multiple Accounts in Search Console

In your case you found:

rajesh@devopsschool.com
       ↓
legitimate

5 additional accounts
       ↓
unauthorized

There are several possible explanations.

Possibility 1 — Automated SEO operation

A system could be adding multiple accounts/properties.

Possibility 2 — Multiple campaigns

The attacker may use several accounts for redundancy.

Possibility 3 — Persistence

If one account is removed, another remains.

Possibility 4 — Multiple verification events

A compromised site may have been repeatedly modified.

Possibility 5 — Separate attackers

This cannot be determined merely from the Gmail addresses.

Do not infer the exact attribution without logs/evidence.

---

15. The Forensic Question

The most important question isn’t:

“Who are these Gmail accounts?”

It is:

“What changed on my infrastructure that allowed these accounts to verify ownership?”

That leads to:

Gmail account
     ↓
Search Console verification
     ↓
Verification token
     ↓
Where was token placed?
     ↓
Who could modify that location?
     ↓
How did they obtain that capability?

That is the investigation.

---

16. Evidence Collection

Before aggressively cleaning a compromised system, preserve evidence.

Collect:

Search Console

• notification email
• Users & Permissions
• Ownership History
• Verification Details
• Security Issues
• Manual Actions

WordPress

• users
• plugins
• themes
• WordPress version
• Site Health
• relevant database records

Server

• access logs
• error logs
• authentication logs
• FTP/SFTP logs
• SSH logs
• cPanel logs
• cron jobs

Files

• modification times
• suspicious PHP files
• .htaccess
• configuration files
• unexpected directories

DNS

• TXT records
• A/AAAA
• CNAME
• nameservers
• recent DNS changes if provider supports history

OWASP emphasizes that security logging is critical for detecting and investigating attacks and that logs themselves should be protected from tampering. (OWASP Cheat Sheet Series)

---

17. Establish the Timeline

A good investigation creates a timeline:

T0
Normal operation

T1
Initial compromise

T2
Malicious file uploaded

T3
Backdoor established

T4
Spam content created

T5
Search Console verification added

T6
Additional accounts added

T7
Google notification received

T8
Owner discovers compromise

Then correlate:

Search Console timestamp
        +
file modification timestamp
        +
web-server access log
        +
WordPress activity
        +
DNS activity

This is much more powerful than examining each event separately.

---

18. Useful Defensive Commands

Find recently modified files

find public_html -type f -mtime -14 \
  -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

Search for Search Console verification

grep -Rni \
  "google-site-verification" \
  public_html/

Find PHP files in uploads

find public_html/wp-content/uploads \
  -type f \
  \( -name "*.php" -o -name "*.phtml" \) \
  -print

Find recently modified PHP files

find public_html -type f \
  \( -name "*.php" -o -name "*.phtml" \) \
  -mtime -14 \
  -print

Check cron jobs

crontab -l

and, where appropriate:

ls -la /etc/cron.*

These commands are for inventory and investigation; don’t execute suspicious PHP files during analysis.

---

19. Search Console Incident Response

Google’s recommended sequence for an unrecognized verified owner is particularly relevant here:

Identify unauthorized owner
        ↓
Remove owner
        ↓
Open Verification Details
        ↓
Identify their tokens
        ↓
Remove ALL their tokens
        ↓
Secure the underlying site

Google explicitly warns that removing the owner/token can be only a temporary measure if the attacker still controls the site, because they may simply add their token again. (Google Help)

---

20. Don’t Confuse Domain Property and URL-Prefix Property

This causes a lot of confusion.

Domain property

sreschool.in

covers:

http://sreschool.in
https://sreschool.in
http://www.sreschool.in
https://www.sreschool.in
subdomain.sreschool.in

Google specifically says Domain properties include all protocol and subdomain variations. (Google Help)

URL-prefix property

https://www.sreschool.in/

is more narrowly scoped.

So:

sreschool.in

and

https://www.sreschool.in/

should not be assumed to have identical ownership records.

---

21. Complete Incident Response Model

A mature response looks like:

                 ┌───────────────┐
                 │    DETECT     │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │    CONTAIN    │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │    PRESERVE   │
                 │    EVIDENCE   │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │   ANALYZE     │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │    ERADICATE  │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │    RECOVER    │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │   MONITOR     │
                 └───────────────┘

---

22. Containment

Possible containment measures include:

• restrict administrative access
• disable unused FTP accounts
• rotate credentials
• revoke compromised sessions
• disable suspicious WordPress accounts
• restrict server access
• put the site behind a WAF
• temporarily restrict administrative interfaces
• isolate a compromised host if necessary

Don’t make destructive changes before collecting evidence if forensic investigation matters.

---

23. Eradication

The objective isn’t:

“Delete the file called hacker.php.”

It is:

Remove the attacker’s ability to return.

That can require:

Remove malware
+
Remove persistence
+
Patch vulnerable software
+
Remove unauthorized accounts
+
Rotate credentials
+
Remove malicious verification tokens
+
Fix permissions
+
Secure DNS
+
Secure hosting

---

24. Recovery

For a heavily compromised WordPress installation, rebuilding from a known-good source can be safer than attempting to manually identify every modified file.

A recovery model can be:

Known-good backup
       +
Clean WordPress core
       +
Verified plugins
       +
Verified theme
       +
Clean database
       +
Rotated credentials
       ↓
Rebuilt website

But make sure the backup itself predates the compromise.

WordPress recommends maintaining regular backups and notes that trusted historical snapshots can be valuable when a compromise isn’t detected immediately. (WordPress Developer Resources)

---

25. Credential Rotation

After understanding the compromise, rotate:

WordPress

• administrator passwords
• application passwords

Hosting

• cPanel
• FTP
• SFTP
• SSH

Database

• MySQL credentials

DNS

• DNS provider credentials

Cloud

• AWS/API credentials if applicable

Google

• Search Console owner account
• Google account sessions
• OAuth integrations
• Analytics
• Tag Manager

Don’t reuse passwords between these systems.

---

26. WordPress Hardening

A baseline hardening strategy:

WordPress updated
Plugin inventory
Theme inventory
Unused plugins removed
Strong unique passwords
2FA
Least privilege
File permissions
WAF
Backups
Monitoring
Centralized logs

WordPress recommends updating WordPress/plugins, using trusted plugin sources, limiting access, strong passwords, two-step authentication, backups, and other hardening measures. (WordPress Developer Resources)

You can also disable the built-in dashboard file editor:

define( 'DISALLOW_FILE_EDIT', true );

WordPress documents this as a hardening measure that prevents administrators from editing plugin/theme PHP through the dashboard. (WordPress Developer Resources)

It does not protect against an attacker who already has filesystem access, so it should not be considered a complete defense.

---

27. Monitoring

After recovery, monitor:

Files

New PHP files
Unexpected modifications
Permission changes

WordPress

New administrator
Plugin installation
Theme changes
Configuration changes

Server

SSH login
FTP login
cPanel login
Unexpected processes
Cron changes

DNS

TXT changes
Nameserver changes
A/AAAA changes
CNAME changes

Google

New Search Console owner
New verification token
Security Issues
Indexing anomalies
Spam URLs

OWASP recommends security logging and monitoring that can detect tampering, unauthorized access, and suspicious activity, with logs protected from alteration or deletion. (OWASP Cheat Sheet Series)

---

28. Detection Rules You Can Build

For a serious production environment, create alerts for:

NEW_WORDPRESS_ADMIN
NEW_SEARCH_CONSOLE_OWNER
NEW_GOOGLE_VERIFICATION_TOKEN
NEW_PHP_FILE_IN_UPLOADS
WORDPRESS_PLUGIN_CHANGED
WORDPRESS_CORE_CHANGED
UNKNOWN_CRON_JOB
NEW_SSH_KEY
NEW_FTP_ACCOUNT
DNS_TXT_CHANGED
DNS_NAMESERVER_CHANGED

This turns:

“I discovered the hack three weeks later”

into:

“We detected suspicious activity within minutes.”

That’s a huge improvement.

---

29. A Gold-Standard Security Architecture

For a production WordPress website:

                         INTERNET
                            │
                            ▼
                     ┌─────────────┐
                     │    CDN/WAF  │
                     └──────┬──────┘
                            │
                            ▼
                     ┌─────────────┐
                     │ Load Balancer│
                     └──────┬──────┘
                            │
                            ▼
                     ┌─────────────┐
                     │ Web Server  │
                     └──────┬──────┘
                            │
                 ┌──────────┴──────────┐
                 ▼                     ▼
             WordPress               Logs
                 │                     │
                 ▼                     ▼
             Database               SIEM
                 │                     │
                 └──────────┬──────────┘
                            ▼
                       Alerting

Add:

MFA
+
Least privilege
+
Immutable backups
+
WAF
+
Vulnerability scanning
+
File integrity monitoring
+
Centralized logging
+
DNS security
+
Credential rotation

---

30. The Most Important Lesson From Your SRESchool Case

The incident should not be framed simply as:

“Five Gmail accounts hacked Google Search Console.”

The more useful hypothesis is:

Something gave unauthorized parties sufficient control over a verification mechanism associated with the website.

The investigation should therefore follow:

Unauthorized Search Console owner
             │
             ▼
Verification method
             │
             ▼
Verification token
             │
             ▼
Where was token placed?
             │
      ┌──────┴───────┐
      ▼              ▼
 Website             DNS
      │              │
      ▼              ▼
Who could modify it?
             │
             ▼
How did they obtain access?
             │
             ▼
What persistence remains?

That is the root-cause investigation.

---

31. SRESchool Incident Checklist

For your actual incident, I’d use this checklist:

🔴 Immediate

• Preserve Google email
• Screenshot Search Console owners
• Screenshot Ownership History
• Screenshot Verification Details
• Remove unauthorized owners
• Remove their verification tokens
• Check Search Console Security Issues
• Check WordPress administrators
• Check DNS TXT records
• Check hosting accounts
• Check FTP/SFTP/SSH
• Preserve server logs

🟠 Investigation

• Determine initial access
• Identify modified files
• Identify malicious PHP
• Identify persistence
• Identify vulnerable plugin/theme
• Check database
• Check .htaccess
• Check cron
• Check redirects
• Search Google for spam URLs
• Check other websites on the same server

🟢 Recovery

• Remove malware
• Patch vulnerable software
• Rotate credentials
• Enable MFA
• Rebuild if necessary
• Restore known-good backup if appropriate
• Configure WAF
• Configure file monitoring
• Configure centralized logging
• Monitor Search Console

---

32. The Golden Rule

There are three levels of response:

❌ Weak response

Delete the hacker’s Search Console account.

⚠️ Better response

Delete account + verification token + suspicious files.

✅ Gold-standard response

Preserve evidence → identify initial access → contain → remove persistence → remove unauthorized verification → patch root cause → rotate credentials → rebuild/restore from trusted state → harden → monitor → document the incident.

That’s the difference between cleaning a hacked website and actually recovering from a security incident.

And in your SRESchool situation, the next forensic artifact I’d prioritize is the Verification Details + Ownership History, because those can connect the Google ownership event to the actual mechanism that was modified on the website or DNS. Google specifically recommends examining the unauthorized owner’s verification details and removing all associated tokens. (Google Help)

You might also like

WEBSITE HACKING & SEO SPAMINCIDENT RESPONSEUrology Hospitals, Doctors, and Modern Therapies: How to Navigate Your Care with ConfidenceDevSecOps vs SecOps: Understanding Their Roles