Gold Standard Defensive Training Manual
WordPress • PHP • Hosting • DNS • Google Search Console • SEO Spam • Forensics • Recovery
Version 1.0 • September 2026
Defender-focused. Authorized environments only.
1. Executive Overview
This manual explains a recurring web-security incident pattern: a legitimate website is compromised, unauthorized files or accounts are introduced, spam or redirect infrastructure is created, and attackers obtain Google Search Console ownership so they can observe or manipulate the site’s search presence. The objective is to teach detection, containment, forensic reasoning, eradication, recovery, and prevention—not to provide instructions for compromising third-party systems.
Google states that an unrecognized verified Search Console owner can be a sign that a site has been hacked. Google also states that removing the owner alone may be temporary if the attacker can restore the verification token. Therefore, the incident must be treated as an underlying website/DNS/account compromise, not merely a Search Console permissions problem.
For the SRESchool-style case that motivated this manual, the key investigative question is: what capability allowed an unauthorized person to place or control a valid Search Console verification mechanism?
Key principle
SEARCH CONSOLE OWNERSHIP IS OFTEN A SYMPTOM. FIND THE ORIGINAL CONTROL PATH.
| Layer | What to investigate | Typical evidence |
| Owners, verification details, ownership history, Security Issues | Notifications, timestamps, tokens | |
| DNS | TXT/CNAME/nameserver changes | Provider audit history |
| Application | WP admins, plugins, themes, database | Users, versions, DB records |
| Filesystem | Unexpected PHP/HTML/configuration files | mtime, hashes, paths |
| Host | cPanel/SSH/FTP access, cron | Auth and control-panel logs |
| Network | HTTP requests, redirects, scanners | Web access/error logs |
| Identity | Google/hosting/DNS credentials | Sessions, MFA, API keys |
2. Learning Objectives
- Explain the attack chain from initial access through persistence, SEO spam, Search Console ownership, and monetization.
- Distinguish initial access from persistence and from post-compromise objectives.
- Investigate WordPress, PHP, DNS, hosting, Search Console, and logs as one connected system.
- Preserve evidence before destructive cleanup.
- Contain unauthorized access without accidentally destroying forensic clues.
- Remove Search Console owners and their verification mechanisms safely.
- Build a clean recovery plan using known-good software and backups.
- Implement controls for MFA, least privilege, WAF, file integrity, logging, monitoring, and credential rotation.
- Create practical SOC/SRE detection rules and incident runbooks.
3. Scope and Ethics
Use the procedures in this manual only on systems you own or are explicitly authorized to administer. Investigation commands are intended for inventory, evidence collection, and defensive validation. Do not use them to gain access to systems, accounts, or networks without authorization.
When an incident may involve personal data, payment information, regulated data, or material business impact, involve the organization’s incident-response, legal, privacy, and hosting/security teams as appropriate.
4. Attack Anatomy: What, How, and Why
4.1 The high-level chain
Internet
|
v
Initial Access
|– stolen credentials
|– vulnerable plugin/theme
|– hosting/DNS compromise
|– server/shared-host exposure
v
Execution / File Write
|
+–> malicious files
+–> modified PHP/theme/plugin
+–> database changes
+–> admin account
v
Persistence
|
+–> backdoor
+–> cron/task
+–> API/SSH/FTP credential
+–> hidden admin
v
Post-compromise objectives
|
+–> SEO spam
+–> redirects
+–> phishing
+–> malware delivery
+–> Search Console ownership
v
Monetization / continued access
4.2 Why SEO spam is attractive
- Attackers can exploit the trust and history of an established domain.
- Hidden pages may receive search traffic without changing the visible homepage.
- Affiliate or advertising models can monetize traffic.
- Search Console access can provide visibility into indexing and site-search behavior.
- Redirects can route selected visitors to external destinations.
4.3 Why attackers seek multiple accounts
Multiple unauthorized identities may provide redundancy, operational separation, or repeated access. Their presence alone does not establish attribution or prove that one individual controls every account. Treat account relationships as an investigation hypothesis and validate with timestamps, verification methods, server logs, and provider evidence.
5. Google Search Console Ownership Abuse
Google documents that a verified owner has the highest degree of permissions for a Search Console property. Google supports multiple verification methods, including HTML files, HTML tags, DNS, and integrations. A verification token is evidence used to prove ownership.
5.1 Domain vs URL-prefix properties
| Property type | Example | Scope |
| Domain | sreschool.in | Protocols, subdomains, and paths under the domain |
| URL-prefix | https://www.sreschool.in/ | Specific protocol/host/path prefix |
Do not assume that a Domain property and a URL-prefix property have identical user lists. When investigating an ownership alert, select the exact property named in the notification.
5.2 Unauthorized-owner workflow
- Preserve the notification and current Users & permissions view.
- Open Ownership History and record relevant events and timestamps.
- Open Verification Details for each unauthorized verified owner.
- Identify every verification mechanism/token associated with that owner.
- Remove the unauthorized owner.
- Remove all of that owner’s verification tokens as instructed by Google.
- Investigate the underlying website, DNS, hosting, or account compromise.
- Re-check ownership after remediation to ensure the account cannot reappear.
Google’s official guidance explicitly warns that removing an unwanted owner/token can be only a temporary solution if the attacker still controls the site. The underlying security issue must be fixed.
5.3 Evidence to preserve
- Original Search Console email and message headers where available.
- Property name and exact URL-prefix/domain property.
- Users & permissions screenshot/export.
- Ownership History.
- Verification Details for each unauthorized owner.
- Unused ownership tokens list after removal.
- Search Console Security Issues and Manual Actions.
6. Initial Access: How the Compromise May Start
6.1 Stolen credentials
Credentials can be stolen through phishing, malware, password reuse, browser/session compromise, exposed secrets, or third-party compromise. The affected identity may be WordPress, cPanel, FTP/SFTP, SSH, DNS, Google, or a cloud service.
6.2 Vulnerable WordPress component
WordPress installations have an application and dependency supply chain: core, plugins, themes, custom code, and integrations. A vulnerable or abandoned component can become an entry point. WordPress recommends keeping WordPress and extensions current and using trusted sources.
6.3 Shared-hosting exposure
Shared hosting changes the threat model. WordPress notes that if another site on the same shared server is compromised, your site can potentially be affected depending on host isolation. Treat the hosting account and neighboring sites as part of the investigation boundary.
6.4 DNS or identity compromise
If an attacker controls the DNS provider, they may be able to influence domain-level verification and routing. If a Google account or analytics/tag-management account is compromised, an attacker may gain a different route into verification or site administration.
6.5 Developer workstation compromise
A compromised administrator/developer endpoint can expose saved passwords, browser sessions, SSH keys, API tokens, or source-control credentials. Securing the endpoint is therefore part of website incident response.
7. Persistence: How Attackers Come Back
Persistence is the mechanism that survives your first cleanup attempt. A mature incident response asks not only ‘what file is malicious?’ but ‘what gives the attacker the ability to recreate it?’
| Persistence area | Examples to investigate | Evidence |
| WordPress | Unknown admin, malicious plugin/theme | Users, plugin list, DB |
| Filesystem | Backdoor, modified core, upload PHP | mtime, hashes, diffs |
| Scheduler | Cron or scheduled task | crontab, system scheduler |
| Access | SSH key, FTP/SFTP account | authorized_keys, provider logs |
| Hosting | Control-panel user/API token | cPanel/audit records |
| DNS | Unauthorized TXT/CNAME/NS | DNS history |
| Database | Injected option/content/user | DB diff and audit |
| Application | Modified .htaccess/config | Git/backup comparison |
7.1 Why deleting one file is insufficient
Attacker access
|
+–> backdoor A
+–> admin account
+–> cron persistence
+–> stolen hosting credential
+–> Search Console token
|
Delete backdoor A
|
+–> attacker still has B/C/D
|
v
Reinfection
8. SEO Spam, Cloaking, and Redirect Abuse
8.1 Hidden spam pages
Spam pages can be generated dynamically, stored as CMS content, or served from unexpected filesystem paths. They may not appear in navigation. Search operators and Search Console data can reveal content that a normal site walkthrough misses.
8.2 Redirect abuse
A compromised site may redirect visitors based on path, referrer, device, geography, or other request characteristics. This is why testing only the homepage from one browser is not sufficient.
8.3 Cloaking
Cloaking is the practice of serving materially different content to different request populations. Defenders should compare normal browser behavior, search-engine-visible content, server responses, and logs without assuming that a single successful homepage request proves the site is clean.
8.4 Search-engine reconnaissance
- Search the domain for unexpected indexed paths.
- Review Search Console indexing and security reports.
- Look for unexpected titles, descriptions, languages, or topics.
- Compare sitemap contents with the intended site.
- Investigate sudden URL spikes or strange directories.
9. WordPress Forensics
9.1 Account review
- List all users and roles.
- Identify newly created or unknown administrators.
- Check email addresses and creation/modification timestamps where available.
- Review application passwords and session/security plugins.
- Review recent administrative activity if audit logging exists.
9.2 Plugin/theme review
- Inventory every installed plugin and theme.
- Remove software that is unnecessary or unsupported.
- Update supported software from trusted sources.
- Compare plugin/theme files against known-good releases or vendor packages.
- Investigate recently changed files and unexpected PHP in media directories.
9.3 Configuration review
- wp-config.php and environment files.
- .htaccess and web-server configuration.
- Upload directories and executable file handling.
- PHP settings and dangerous writable directories.
- Database credentials and application secrets.
9.4 Defensive inventory commands
# Recently modified files
find public_html -type f -mtime -14 -printf ‘%TY-%Tm-%Td %TH:%TM %p\n’ | sort
# Search for Search Console verification strings
grep -Rni “google-site-verification” public_html/
# PHP files under uploads
find public_html/wp-content/uploads -type f \
\( -name “*.php” -o -name “*.phtml” \) -print
# Recently modified PHP
find public_html -type f \
\( -name “*.php” -o -name “*.phtml” \) -mtime -14 -print
# User cron inventory
crontab -l
These commands are for defensive inventory. Review suspicious content without executing it.
10. Filesystem and Web-Server Investigation
10.1 Timestamps
File modification time can help build a timeline, but it is not proof of attacker activity. Files can be legitimately deployed, restored, copied, or modified by automation. Correlate timestamps with logs.
10.2 Hashing
sha256sum path/to/suspicious-file.php
Hash suspicious files before modifying them when evidence preservation matters. Compare against known-good source packages or a trusted backup.
10.3 Web access logs
Look for unusual POST requests, repeated requests to nonexistent paths, access to administrative endpoints, bursts of 404s followed by successful writes, unusual user agents, and requests around the first suspicious file timestamp.
10.4 Error logs
Errors can reveal failed exploit attempts, unexpected includes, permission problems, PHP warnings, and application paths targeted by attackers.
10.5 Log integrity
OWASP recommends protecting logs from tampering and unauthorized access, and integrating monitoring outputs into incident response. Centralized logging reduces the risk that an attacker can erase the only useful local evidence.
11. DNS, Hosting, and Control-Plane Investigation
11.1 DNS
- Record current A/AAAA/CNAME/TXT/NS values.
- Identify every Search Console verification TXT record.
- Compare with historical DNS records if the provider offers history.
- Review provider login and change history.
- Check whether nameservers changed unexpectedly.
11.2 cPanel/hosting
- Review control-panel users and API tokens.
- Review FTP/SFTP accounts.
- Review SSH keys and recent logins.
- Review cron jobs.
- Review file-manager activity if available.
- Review malware-scanner history and quarantine events.
11.3 Shared server
If multiple sites share a host, determine whether they share users, writable directories, PHP-FPM pools, filesystem permissions, or management credentials. A compromise in one account should not be allowed to become a compromise of every account.
12. Incident Response Lifecycle
DETECT
|
v
PRESERVE EVIDENCE
|
v
CONTAIN
|
v
ANALYZE / SCOPE
|
v
ERADICATE
|
v
RECOVER
|
v
MONITOR / LESSONS LEARNED
12.1 Detect
Trigger examples: Search Console ownership alert, unexpected administrator, suspicious PHP file, malware alert, spam indexed pages, redirects, abnormal traffic, or DNS changes.
12.2 Preserve
Capture screenshots, logs, timestamps, hashes, configuration snapshots, and provider records before deleting evidence where feasible.
12.3 Contain
Limit the attacker’s ability to act: revoke compromised sessions, restrict administrative access, disable suspicious accounts, isolate a host when necessary, and block known malicious paths or traffic while preserving evidence.
12.4 Analyze
Determine the initial access path, persistence, affected systems, data exposure, and attacker objectives. Build a timeline.
12.5 Eradicate
Remove malicious code and persistence, patch vulnerabilities, eliminate unauthorized accounts, remove unauthorized verification mechanisms, and rotate secrets.
12.6 Recover
Restore from a known-good source, validate software integrity, test functionality, monitor closely, and return to production in controlled stages.
12.7 Lessons learned
Document root cause, detection gaps, response time, evidence quality, controls that failed, and improvements.
13. Building an Attack Timeline
| Time | Source | Event | Confidence |
| T0 | Deployment records | Known-good deployment | High |
| T1 | Web logs | Suspicious request pattern | Medium/High |
| T2 | Filesystem | Unexpected PHP modified | Medium |
| T3 | WordPress | Unknown administrator created | High |
| T4 | Search Console | Unauthorized owner verified | High |
| T5 | DNS | Unexpected TXT change | High if provider audit exists |
| T6 | Search Console | Spam/indexing activity | Medium/High |
| T7 | Detection | Owner receives alert | High |
Use synchronized clocks and consistent time zones. OWASP specifically highlights accurate timestamps as important for reconstructing attack sequences.
13.1 Evidence correlation
Search Console event
+
DNS/provider event
+
web access log
+
filesystem mtime
+
WordPress audit event
+
hosting login
=
probable attack sequence
14. Eradication and Recovery
14.1 When to rebuild
A rebuild is often safer when there is extensive unknown modification, a suspected root-level compromise, unreliable backups, or uncertainty about persistence. The decision should consider business continuity and forensic requirements.
14.2 Known-good recovery model
Known-good WordPress core
+
Known-good plugin/theme packages
+
Validated database
+
Clean configuration
+
Rotated credentials
+
Clean DNS
=
Controlled recovery
14.3 Credential rotation
- WordPress administrator credentials.
- Hosting/cPanel credentials.
- FTP/SFTP credentials.
- SSH keys.
- Database passwords.
- DNS provider credentials.
- Google account sessions and recovery mechanisms.
- Analytics/Tag Manager integrations.
- Cloud/API keys and CI/CD secrets where relevant.
OWASP recommends rapid revocation when secrets are exposed and emphasizes documented containment and remediation procedures.
15. Gold-Standard WordPress Hardening
| Control | Baseline | Gold standard |
| Authentication | Strong passwords | MFA + phishing-resistant methods where feasible |
| Authorization | Correct roles | Least privilege + periodic review |
| Plugins | Keep updated | Minimize attack surface + dependency inventory |
| Themes | Keep updated | Minimal custom code + integrity checks |
| Admin | Public login | Restricted access + WAF/rate limits |
| Files | Writable app tree | Minimize writable paths; protect uploads |
| Backups | Periodic backup | Encrypted, immutable/offline, tested restore |
| Logging | Local logs | Centralized + protected + alerting |
| DNS | Basic records | MFA + change alerts + registrar lock where appropriate |
| Search Console | Owners added manually | Owner review + alerts + token inventory |
15.1 Disable dashboard file editing
define( ‘DISALLOW_FILE_EDIT’, true );
This can reduce one administrative modification path, but it does not protect against an attacker who already has filesystem or database access.
15.2 Trusted software
WordPress recommends using trusted sources for plugins/themes and keeping WordPress current. Never treat a security plugin as a substitute for patching and access control.
16. Detection Engineering and SOC Rules
Turn the incident lessons into machine-detectable events.
| Rule | Trigger | Severity |
| NEW_SEARCH_CONSOLE_OWNER | New verified owner detected | Critical |
| NEW_VERIFICATION_TOKEN | New token/file/tag/DNS record | Critical |
| NEW_WP_ADMIN | New administrator account | Critical |
| PHP_IN_UPLOADS | Executable PHP under media directory | High |
| PLUGIN_CHANGED | Unexpected plugin/theme/core file changes | High |
| NEW_CRON | Unexpected scheduled task | High |
| NEW_SSH_KEY | Unexpected authorized key | Critical |
| DNS_TXT_CHANGED | Unexpected TXT record | High |
| DNS_NS_CHANGED | Nameserver modification | Critical |
| AUTH_ANOMALY | New country/device or repeated failures | Medium/High |
16.1 SIEM fields
timestamp
event_type
actor
source_ip
user_agent
target
resource
action
result
authentication_method
request_id
hostname
application
severity
correlation_id
OWASP recommends consistent logging, sufficient detail for investigations, protected log storage, synchronized clocks, and centralized monitoring/SIEM where appropriate.
17. SOC/SRE Incident Playbook
Trigger: Unauthorized Search Console Owner
- Declare a security incident and assign an incident owner.
- Preserve the Search Console notification and ownership screens.
- Capture Ownership History and Verification Details.
- Identify all unauthorized owners and verification methods.
- Remove unauthorized owners and all associated tokens.
- Check DNS for unauthorized verification records.
- Check WordPress administrators and recent changes.
- Check filesystem and web-server logs around the earliest event.
- Check hosting, FTP/SFTP, SSH, and control-panel access.
- Check for persistence: cron, backdoors, plugins, themes, database changes.
- Search for indexed spam, redirects, and unexpected content.
- Contain affected access paths and rotate credentials.
- Patch or rebuild from a known-good source.
- Re-verify Search Console ownership and Security Issues.
- Enable monitoring and document lessons learned.
17.1 Stop conditions
- Do not execute unknown PHP files.
- Do not overwrite or delete forensic evidence before preservation when investigation matters.
- Do not restore an untrusted backup into production.
- Do not assume Search Console cleanup equals incident remediation.
- Do not rotate one credential and leave shared/reused credentials unchanged.
18. Case Study: SRESchool-Style Incident
Scenario: The legitimate owner of sreschool.in receives a Search Console notification that an unfamiliar Gmail address has been added as an owner of https://www.sreschool.in/. The owner then discovers several other unfamiliar verified owners.
18.1 Initial observations
- Legitimate owner remains verified.
- Multiple additional owners are not recognized.
- Search Console reports verified ownership rather than ordinary user access.
- Website may still look normal.
- Potential suspicious files may also exist on the server.
18.2 Hypotheses
- H1: A website-level compromise allowed HTML/file modification.
- H2: A DNS compromise allowed ownership verification.
- H3: A Google/Analytics/Tag Manager identity was compromised.
- H4: Hosting credentials were stolen.
- H5: Multiple events are unrelated and need separate validation.
Do not select a hypothesis because it ‘sounds likely.’ Test each against provider logs, verification details, DNS history, server logs, and filesystem evidence.
18.3 Evidence matrix
| Evidence | Supports | Weakens |
| HTML verification token | Website file access | DNS-only hypothesis |
| DNS TXT token | DNS access | Website-only hypothesis |
| WP admin creation | Application compromise | Pure DNS hypothesis |
| cPanel login | Hosting compromise | Pure Search Console mistake |
| Google security event | Identity compromise | Pure server-only hypothesis |
| File mtime + HTTP log | Web exploitation/write path | Unrelated file change |
19. Safe Triage Command Reference
19.1 Filesystem
# Inventory recent changes
find public_html -type f -mtime -7 -printf ‘%TY-%Tm-%Td %TH:%TM %p\n’ | sort
# Find executable-like extensions
find public_html -type f \
\( -name “*.php” -o -name “*.phtml” -o -name “*.php5” \) -print
# Search for verification markers
grep -Rni “google-site-verification” public_html/ 2>/dev/null
# Hash a file for evidence
sha256sum /path/to/file.php
19.2 WordPress
# Examples; run from the WordPress directory
wp core version
wp plugin list
wp theme list
wp user list –fields=ID,user_login,user_email,roles
wp cron event list
Use WP-CLI only in an environment where you are authorized and where the CLI is already installed. Export results to evidence storage rather than changing the site during the initial collection phase.
19.3 Linux access review
# Current SSH authorized keys
cat ~/.ssh/authorized_keys
# Current user cron
crontab -l
# Recent authentication logs vary by distro
journalctl –since “7 days ago” | grep -Ei “ssh|sudo|authentication|session”
20. Data Exposure and Breach Assessment
A website compromise does not automatically mean sensitive data was exfiltrated. Determine what the compromised identity could access and what evidence indicates actual access or transfer.
- Identify databases and data classifications.
- Check application logs for suspicious read/export operations.
- Check cloud/storage access logs.
- Review API key use and unusual outbound traffic.
- Determine whether credentials or secrets were exposed.
- Preserve evidence before making broad deletions.
If personal, payment, health, or regulated information may be involved, involve the organization’s privacy/legal function and follow applicable notification requirements.
21. Reference Secure Architecture
Internet
|
v
CDN / WAF
|
v
Load Balancer
|
+——+——+
| |
Web tier Static assets
|
WordPress
|
+—–+——+
| |
Database Object storage
|
Backups
|
Immutable / isolated
Security plane:
Identity + MFA
Central logs / SIEM
File integrity monitoring
Vulnerability management
DNS monitoring
Search Console owner monitoring
Incident response
The exact architecture depends on traffic, budget, hosting model, and business requirements. The security goal is defense in depth and reduction of blast radius.
22. Incident Metrics
| Metric | Definition | Target direction |
| MTTD | Time from malicious activity to detection | Lower |
| MTTC | Time to contain | Lower |
| MTTR | Time to restore trusted service | Lower |
| Owner Alert Latency | Time from unauthorized owner to notification/response | Lower |
| Patch SLA | Time to remediate critical vulnerable components | Lower |
| MFA Coverage | Privileged accounts protected by MFA | Higher |
| Backup Restore Success | Successful tested restores | Higher |
| Log Coverage | Critical systems sending protected logs | Higher |
22.1 SRE/security SLO example
A practical organization might set an internal objective such as: every privileged identity uses MFA; critical Search Console ownership changes generate an alert; critical plugin vulnerabilities are triaged within a defined SLA; backups are restored on a recurring test schedule. Choose targets based on your actual risk and operational capacity.
23. Gold-Standard Incident Checklist
Detection
☐ Preserve alert/email
☐ Identify affected property
☐ Open Security Issues
☐ Capture ownership list
Evidence
☐ Ownership History
☐ Verification Details
☐ DNS history
☐ Web/server logs
☐ Filesystem timeline
☐ WP audit data
Containment
☐ Remove unauthorized owners
☐ Remove their tokens
☐ Revoke compromised sessions
☐ Restrict suspicious access
Eradication
☐ Remove persistence
☐ Patch vulnerable software
☐ Remove unauthorized accounts
☐ Rotate secrets
☐ Validate backups
Recovery
☐ Restore known-good state
☐ Test application
☐ Re-check Search Console
☐ Monitor after release
Prevention
☐ MFA
☐ Least privilege
☐ WAF
☐ File integrity monitoring
☐ Central logging
☐ DNS monitoring
24. Reporting to Google and Hosting Providers
Use factual language. Say ‘unauthorized verified owners’ rather than making unverified claims about the identity or intent of the account holders.
24.1 Google incident summary template
Subject: Unauthorized verified owners added to Search Console property
Domain: example.com
Affected property: https://www.example.com/
Legitimate verified owner:
owner@example.com
Unauthorized verified owners:
account1@gmail.com
account2@gmail.com
Observed events:
– Search Console ownership notification
– Unauthorized verified owners
– Verification methods/tokens identified
– Suspicious website changes (if confirmed)
Evidence available:
– Search Console notification
– Ownership History
– Verification Details
– Server/DNS logs
– Screenshots
Requested assistance:
– Investigation of ownership/verification events
– Guidance on additional account or property security measures
Report only facts you can substantiate. Attach evidence where the reporting channel permits.
25. Authoritative References
| Reference | URL | Use |
| Google Search Console — I don’t recognize this new owner | https://support.google.com/webmasters/answer/7281924?hl=en | Unauthorized owner response, token removal, underlying-site remediation. |
| Google Search Console — Managing owners, users, and permissions | https://support.google.com/webmasters/answer/7687615?hl=en | Owner roles, verified owners, permissions, and token handling. |
| Google Search Console — Verify your site ownership | https://support.google.com/webmasters/answer/9008080?hl=en | Ownership verification methods and verification behavior. |
| Google Search Console — Verification token | https://support.google.com/webmasters/answer/13180013?hl=en | Definition and purpose of verification tokens. |
| WordPress — Hardening WordPress | https://developer.wordpress.org/advanced-administration/security/hardening/ | WordPress hardening, updates, trusted sources, shared hosting, passwords, backups. |
| OWASP — Logging Cheat Sheet | https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html | Security logging, monitoring, protection, and incident-response integration. |
| OWASP — Secrets Management Cheat Sheet | https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html | Secret exposure, revocation, containment, and incident response. |
| OWASP — Authentication Cheat Sheet | https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html | Authentication monitoring and defensive controls. |
URLs are included for training/reference purposes. Consult the current official documentation when performing a live incident response because provider interfaces and recommended procedures can change.
Appendix A — One-Page Executive Runbook
WHEN A WEBSITE GETS AN UNAUTHORIZED SEARCH CONSOLE OWNER:
- Preserve evidence.
- Capture Users & Permissions, Ownership History, and Verification Details.
- Remove unauthorized owner(s).
- Remove every associated verification token.
- Check DNS and website files for the verification mechanism.
- Investigate WordPress users, plugins, themes, database, cron, hosting, SSH/FTP, and logs.
- Contain compromised identities and rotate secrets.
- Patch or rebuild from a trusted state.
- Check Security Issues, indexed spam, redirects, and unexpected URLs.
- Enable continuous monitoring and document root cause.
Appendix B — Golden Questions
- Who was the first unauthorized owner?
- When was the first verification event?
- What verification method was used?
- Where was the token stored?
- Who could modify that location?
- What account or vulnerability provided that capability?
- What persistence remains?
- What other systems share the same credentials or host?
- Was sensitive data accessible?
- How will we know if the attacker returns?
Appendix C — Final Principle
A successful cleanup is not ‘the website looks normal.’ A successful cleanup is: the attacker no longer has a viable access path, unauthorized verification mechanisms are removed, vulnerable components are fixed, credentials are rotated, the site is restored to a trusted state, evidence is preserved, and monitoring can detect recurrence.
Leave a Reply
You must be logged in to post a comment.