Hacked Website Recovery and DDoS Mitigation

A hacked website hits a business from every direction at once: customers see a browser warning and leave, Google demotes or delists your pages, your host suspends the account, and every hour offline is revenue and trust you do not get back. A DDoS attack does the same damage without even breaking in. When it happens, you need two things fast: a clean, working site back online, and the hole that let it happen closed so you are not back here next week. Spy and Monitor provides emergency hacked website recovery and DDoS mitigation: forensic-grade cleanup, backdoor hunting, blocklist removal, WordPress-specific repair, SEO spam cleanup, layered DDoS defense, and hardening that lasts. This page explains how to recognize a compromise, exactly how a professional recovery runs, what the Google warning process involves, how DDoS protection actually works in plain language, and what it all costs.

How do I know if my website has been hacked?

Some compromises deface your homepage; the dangerous ones hide. Watch for these signs.

• Browser and search warnings. "This site may be hacked" under your Google listing, or a red "Deceptive site ahead" interstitial in Chrome.
• Redirects you did not create. Visitors (often only mobile visitors, or only visitors arriving from Google) get bounced to pharmacy, casino, or adult sites. Conditional redirects that skip logged-in admins are a classic trick, which is why owners are often the last to know.
• Strange search results. Your site ranking for Japanese text, pharmaceuticals, replica watches, or essay services you never wrote about. Search your domain with a site: query and look for pages you do not recognize.
• Host or email trouble. Your hosting account suspended for malware or outbound spam, or your domain suddenly landing in spam folders.
• Unknown admin users, modified files, new plugins you did not install, or file change dates on core files that do not match any update you performed.
• Performance collapse or a traffic flood that takes the site offline, which may be a DDoS attack rather than an intrusion.

What should I do in the first 30 minutes, before help arrives?

A few moves in the first half hour protect the recovery; a few common instinctive moves sabotage it. Do these.

1. Change your passwords from a clean device. Hosting panel, admin accounts, FTP, and the email tied to them, in that order. If your own computer might be the source of the stolen credentials, do not use it for this.
2. Do not delete anything yet. The instinct is to rip out every suspicious file immediately, but those files and the logs around them are the evidence that reveals the entry point. Deleting them feels productive and usually guarantees the cause is never found.
3. Do not restore a backup over the live site yet. Restoring overwrites the forensic picture, and if the backup is newer than the intrusion (which it usually is, since infections precede symptoms by days or weeks), you restore the infection along with your content.
4. Download a copy of your access and error logs now. Many hosts rotate logs within days, and the request that delivered the exploit may be in a file that disappears tonight.
5. Note what you observed and when. The first redirect report, the Google warning, the suspension email. Timestamps narrow the log search from millions of lines to thousands.

Our emergency response process, step by step

Order of operations matters enormously in incident response. Cleaning before snapshotting destroys the evidence of how the attacker got in; restoring before finding backdoors guarantees reinfection. Here is the sequence we run.

1. Contain and isolate. We put the site into maintenance mode or restrict it at the edge so the infection cannot serve malware to more visitors, send more spam, or spread to neighboring sites on the same account. Admin passwords, hosting panel, FTP/SSH, and database credentials are rotated immediately, because we have to assume all of them are burned.
2. Snapshot for forensics. Before changing anything, we take a complete copy of the files, database, and available logs. This preserves the evidence that tells us how the attacker entered, what they touched, and whether data was taken, and it protects you if the incident later has legal or insurance implications. Access logs are gold: they show the exact request that delivered the exploit.
3. Clean or rebuild: the decision. Light infections are cleaned in place. Deep ones, where core files are riddled with injected code or the compromise is months old, are often faster and safer to rebuild: fresh core software, fresh plugin copies from official sources, your verified content and database carried over after inspection. We make this call early and tell you why, because choosing wrong wastes days.
4. Find everything, especially the backdoors. We scan and manually review files and the database for malware, injected scripts, and above all web shells: small hidden files (often disguised with innocent names or buried in upload folders) that give the attacker a remote control panel into your server. Attackers almost always plant several. Removing the visible damage while missing one backdoor is the number one reason sites are rehacked within days, so we hunt for them specifically: in files, in the database, in scheduled tasks, and in rogue admin accounts.
5. Close the entry point. Root-cause analysis from the logs and file evidence: an outdated plugin, a stolen password, an exposed admin panel, a vulnerable theme. Cleaning without closing the door is theater.
6. Restore, verify, and monitor. The site goes back live, we verify every function works, submit blocklist reviews, and watch the logs closely for return visits from the attacker, which are routine in the first days after a cleanup.

WordPress hack cleanup: the specifics

Most of the sites we recover run WordPress, because most of the web does, and WordPress compromises follow patterns we know by heart.

Where infections hide in WordPress

• Plugins and themes. The entry point in the large majority of WordPress hacks is a vulnerable or abandoned plugin. We inventory every plugin and theme, check each against known vulnerability databases, delete anything abandoned or nulled (pirated premium themes are pre-infected more often than not), and reinstall keepers from official sources.
• Core files. We compare WordPress core against pristine copies, byte for byte, which exposes injected code instantly. Modified files are replaced, not patched.
• wp-config.php. A favorite target because it loads on every request and never gets overwritten by updates. We inspect it for injected includes, rotate the database credentials it contains, and replace the secret authentication keys and salts, which forcibly logs out every session the attacker may hold.
• The database. Injections hide in posts and widgets as malicious script tags, in stored options (a favorite is code stuffed into autoloaded options), and as rogue administrator accounts. We sweep wp_options, wp_posts, and wp_users, and audit every account with elevated privileges.
• Uploads and hidden folders. PHP files have no business in your uploads directory; finding one there is nearly always a web shell. We also check .htaccess files at every level, a common home for malicious redirect rules.

SEO spam hacks: Japanese keyword and pharma injections

Two infections deserve special mention because they destroy your search presence specifically. The Japanese keyword hack floods Google's index with thousands of auto-generated Japanese-language pages on your domain, usually selling counterfeit goods, often visible only to Googlebot while normal visitors see your site as usual. The pharma hack does the same with pharmaceutical spam, sometimes by silently rewriting your existing pages' titles and content only when a search crawler visits, a technique called cloaking. Cleanup for these goes beyond malware removal: we remove the spam pages and the code generating them, find and delete the rogue sitemaps the attacker registered, check Search Console for hijacked verification (attackers often verify themselves as owners of your property to manipulate the index, and that access survives a cleanup unless explicitly revoked), and request removal of the spam URLs from the index. Rankings recover after the cleanup, but the longer the spam stays indexed, the slower the climb back, which is one of the strongest arguments for moving fast.

Getting off Google's blocklist

If Google flagged your site, removal of the warning is its own workflow and we run it as part of every recovery. In Google Search Console, the Security Issues report lists exactly what Google detected and on which sample URLs, which is also useful cleanup intelligence. Once the site is verifiably clean and the entry point is closed, we file a review request describing what was found and what was fixed. Malware reviews are typically processed within a few days; spam-related manual actions can take longer. A failed review extends the timeline and damages credibility with the next reviewer, which is why we never submit until we are certain the site is clean. We also check your domain against the other blocklists that matter (browser vendors, antivirus vendors, email blocklists if the server was sending spam) and clear each one.

DDoS attacks in plain language

A distributed denial of service attack does not break into your site; it buries it. Thousands of compromised machines flood you with traffic until real customers cannot get through. Understanding the two basic kinds helps the defense make sense.

Volumetric attacks (layers 3 and 4): the firehose

These attacks aim raw traffic at your network connection, like pointing a firehose at a letterbox. The content of the traffic is junk; the volume is the weapon. No single server can absorb a large one, which is why the defense is to stand behind a network that is bigger than the attack: a content delivery network with massive global capacity soaks up the flood across hundreds of locations before it ever reaches your server.

Application-layer attacks (layer 7): the fake customers

These are sneakier. Instead of raw volume, the attacker sends what look like legitimate requests, thousands of searches, login attempts, or cart additions per second, each one forcing your server to do real work. The volume can be low enough to slip past volumetric defenses while still flattening your database. The defense here is smarter, not just bigger: rate limiting, bot detection, challenge pages that machines fail and humans pass, and rules that recognize the attack's fingerprint.

The mitigation stack we deploy

• CDN with DDoS absorption (Cloudflare or equivalent) in front of your site, so attack traffic hits their global network instead of your server.
• Origin protection. The CDN only helps if attackers cannot bypass it. We restrict your server to accept traffic only from the CDN and make sure the server's real address is not leaked through DNS history, email headers, or subdomains, the most commonly missed step in DIY setups.
• Web application firewall (WAF) rules that filter exploit attempts and attack patterns at the edge.
• Rate limiting on expensive endpoints: login pages, search, APIs, checkout.
• Under-attack escalation: for an attack happening right now, we can typically get a site behind edge protection within hours, enable challenge mode so real users pass and bots fail, and tune rules live as the attacker adapts.

Hardening: making the next attack fail

Recovery without hardening just resets the clock. Before we close an engagement, we work through a hardening checklist with you.

• All software updated, with automatic updates for security releases, and a schedule for the rest.
• Unused plugins, themes, and accounts deleted entirely, not just deactivated. Every installed extension is attack surface.
• Strong unique passwords and two-factor authentication on every admin, hosting, FTP, and database account.
• Admin panel protected: limited login attempts, renamed or access-restricted login URL, no shared accounts.
• Correct file permissions and PHP execution disabled in upload directories, which neutralizes the most common web shell trick.
• Automatic offsite backups, tested by actually restoring one, because an untested backup is a hope, not a plan.
• File integrity monitoring and uptime alerts, so the next anomaly pages you in minutes rather than surfacing as a Google warning weeks later.

For sites that have been hit once, or that handle payments or customer data, the strongest follow-up is a proactive security test by our ethical hacking and penetration testing team, which finds the next weakness before a criminal does. Our article on why businesses hire website security experts explains when that investment makes sense.

What you receive: the post-incident report

Every recovery ends with a plain-language report: how the attacker got in, what they did, what was cleaned and how, whether there is evidence data was accessed (which can matter legally, since breaches of customer data carry notification duties in many jurisdictions), what hardening was applied, and what we recommend next. It is written to be handed to a boss, a client, an insurer, or a regulator. If the incident may lead to a legal claim or a dispute, our digital forensics team can extend the investigation with full chain-of-custody evidence handling.

Clean in place or rebuild? How we decide

This is the judgment call that most affects your timeline, so here is how we make it. Cleaning in place is right when the infection is recent and contained, the entry point is clearly identified, core files verify against pristine copies after replacement, and the site is too complex or customized to rebuild quickly. Rebuilding wins when the compromise is old enough that no trusted backup exists, when injected code is spread through hundreds of files, when nulled or abandoned components mean large parts of the codebase cannot be trusted at all, or when the time to verify every file exceeds the time to reinstall fresh software and migrate verified content. A rebuild is not starting over: your content, design, and data come with you after inspection; only the executable code is replaced wholesale. We make this call within the first hours, explain the reasoning, and give you the timeline for each path, because the wrong choice here is the difference between one day of work and four.

Monitoring and retainers

Most clients keep us on after recovery in a lightweight monitoring arrangement: malware and integrity scanning, uptime and blocklist monitoring, update management, and priority response if anything recurs. The economics are straightforward: the monitoring typically costs a small fraction of a single emergency cleanup, and it converts the next incident from a multi-day crisis into a same-day fix, or prevents it outright. It also matters because attackers revisit: a site that was vulnerable once gets rescanned by the same crews for months afterward.

What does hacked website recovery cost?

Honest answer: it depends on the depth of the compromise and the size of the site. A straightforward single-site malware cleanup is a modest, fixed-price engagement, often completed within a day. A deep compromise involving SEO spam cleanup, blocklist recovery across multiple services, a rebuild, and DDoS protection rollout is a larger project measured in days. Emergency response carries a priority premium because we drop other work to take it. In every case you get a clear scope and a fixed quote after a short assessment, before any work begins, and we will tell you honestly when a simple restore-and-harden is all you need. One figure worth holding onto: the cost of professional recovery is almost always a small fraction of what the downtime, lost rankings, and lost customer trust are already costing you per week.

A closing note: some site owners, desperate after an attack, contact a hacker to strike back at whoever hit them. Revenge hacking is a crime and usually hits an innocent hijacked server anyway. Our certified ethical hackers for hire put that energy into your defenses instead: cleanup, hardening, and mitigation that keeps you online no matter who attacks.