Hacked WordPress Site Recovery Specialist
what a hacked WordPress site recovery specialist does for you
Containment, forensic cleanup, hardening and a documented handover, done by senior engineers who do this work regularly rather than by a scanner plugin.
get a quoteContainment and forensics
We take the site offline safely, snapshot everything for evidence, then trace the entry point through access logs, file timestamps and database changes so we know exactly how the attacker got in.
Full malware removal
Core, plugins and themes are replaced from clean sources, injected code is removed from uploads, wp_options and wp_posts, and rogue admin users, cron jobs and .htaccess rules are stripped out.
Hardening and blacklist removal
Credentials rotated, salts regenerated, WAF and file integrity monitoring installed, then Google Safe Browsing, Norton and host suspension reviews requested and followed through until they clear.
how a hacked WordPress site recovery specialist works the incident
the first hour: contain without destroying evidence
The instinct is to delete suspicious files immediately. That destroys the evidence you need to find the entry point, and if you miss the backdoor the site is reinfected within days. The first thing a hacked WordPress site recovery specialist does is take a full snapshot: a tar of the web root, a mysqldump of the database and a copy of the last 30 days of access and error logs from the host. We then put the site behind a maintenance response (HTTP 503 with a Retry-After header so search engines do not drop the pages), rotate every credential that could be in play (WordPress admins, SFTP, database, hosting panel, API keys) and block outbound connections from PHP where the host allows it.
finding out how they got in
Most compromises come through one of a small set of doors: an unpatched plugin with a known CVE, a reused password on an admin account, a stale staging copy in a subfolder, or a neighbour site on the same cPanel account with a writable shared home directory. We reconstruct the timeline by cross-referencing file modification times with the access logs, look for the first POST request to a file that should never receive one, and check wp_users, wp_usermeta and wp_options (especially active_plugins, cron and siteurl) for changes. WP-CLI does much of the heavy lifting: wp core verify-checksums and wp plugin verify-checksums --all flag every modified core or repository file in seconds, and wp user list --role=administrator shows accounts that should not exist.
the cleanup
- Core, every plugin and every theme replaced from wordpress.org or the vendor’s clean package at the same version, then updated.
wp-content/uploadsscanned for PHP files and polyglot images (find uploads -name "*.php"is the start, not the end); PHP execution disabled in uploads via .htaccess or an nginxlocationrule.- Database injections removed from
wp_posts(script tags and iframes inpost_content),wp_options(widget and theme mods carrying base64 payloads) andwp_postmeta. - Rogue cron entries, must-use plugins dropped into
wp-content/mu-plugins, modifiedwp-config.phpincludes and.htaccessredirect rules removed. - A second pass with different tooling (Wordfence CLI, a fresh
maldetscan and manual review of anything usingeval,base64_decode,gzinflateorcreate_function) before we call it clean.
closing the door
Cleanup without hardening is a temporary fix. We regenerate the authentication salts in wp-config.php to force every session out, enforce two-factor authentication on administrators, install a web application firewall (Cloudflare WAF rules or Wordfence, depending on the hosting), lock file permissions to 644/755 with wp-config.php at 600, set DISALLOW_FILE_EDIT, and add file integrity monitoring so the next unexpected change triggers an alert rather than a customer complaint. If the host itself was the weak point, moving the site to an isolated environment is often the right answer; our AWS hosting migration for WordPress service gives each site its own instance, security group and IAM boundary.
getting off the blacklists and staying off them
Once clean, we request a review in Google Search Console (Security Issues), clear Norton Safe Web and McAfee SiteAdvisor where flagged, and work with your host to lift any suspension. Google reviews typically clear within one to three days once the site is genuinely clean; we monitor until they do. We also check for SEO spam injected into existing pages (Japanese keyword hacks, pharma cloaking that only shows to Googlebot) using curl -A "Googlebot" against key URLs, because a site can look fine in your browser and still be serving spam to crawlers.
You leave with a written incident report: entry point, timeline, everything that changed, and the hardening applied. The single biggest predictor of a fast recovery next time is a tested backup, which is why we usually pair recovery with an automated WordPress backup system stored offsite and versioned. Many clients then move onto website maintenance and support so updates, monitoring and patching are handled every month rather than after the next incident.
timeline and pricing
Most single-site recoveries are contained within hours and fully clean, hardened and delisted within 24 to 48 hours; multi-site cPanel accounts with cross-contamination take longer. Recovery is quoted as a fixed price once we have seen the site, with a straight answer within 24 hours of your first message, and no surprise invoices because the infection was worse than it looked. The step-by-step process is documented in Hacked WordPress Site Recovery: The Exact Process a Specialist Follows. If your site is compromised right now, contact us and a hacked WordPress site recovery specialist will respond the same day.
