Guides
Each guide starts from a symptom owners and server administrators actually search for, explains what is really happening, shows how to confirm it safely, and sets out what a complete fix requires. Server and hosting guides come first, because that is where the mechanisms a site cleanup misses usually live. Written from real incident work — free to read, with no email, form, or account.
Triage
Most incidents announce themselves through someone else: a browser, Google, your host, a scanner, a customer. Find the message or symptom closest to yours and start with the guide beside it.
| Message or symptom | What it usually means | Start here |
|---|---|---|
| Chrome shows “Deceptive site ahead” or “Dangerous site” | Google Safe Browsing saw the site serve deceptive or harmful content to someone, often only under victim conditions | Deceptive site ahead warning |
| Google results say “This site may be hacked”, or show Japanese titles under your domain | Spam pages or injected content were indexed under your domain, usually cloaked so you do not see them | Japanese keyword hack |
| Your host suspended the account for malware | The host’s scanner flagged files in the account; the notice lists damage, not how it got there | Host suspended the site for malware |
| ImunifyAV or cPanel reports infected files | Files matched malware signatures; whatever wrote them may be somewhere the scan does not read | ImunifyAV found infected files |
| Several accounts on one WHM server are flagged | A server incident, not a set of unrelated site infections | WHM or cPanel server hacked |
| You found defunct or defunct.dat in ~/.config/htop | A gsocket backdoor: an encrypted outbound shell into the hosting account | gsocket backdoor (defunct.dat) |
| Files, dot-directories, or executables you cannot explain above public_html | Something was planted where WordPress scanners never look | Hidden files in a Linux home directory |
| Deleted malware reappears on a schedule, or a cron job nobody recognises | A scheduled task is re-downloading or rebuilding what you remove | Malicious cron jobs on cPanel and Linux |
| The host says the account is sending spam, or the server IP is on a blacklist | A compromised mailbox, a malicious script, or an abused form is sending mail | Server sending spam (Exim) |
| A .user.ini or auto_prepend_file line you did not write | Code that runs before WordPress and can rewrite files as fast as you delete them | auto_prepend_file malware |
| Every scanner says clean, but a warning is still up | A stale flag, cloaked delivery, or a mechanism outside what the scanner reads | Scan clean but still flagged |
| Visitors report a fake CAPTCHA or “verify you are human” step | The site is serving a ClickFix lure to its visitors | Fake verification page |
| Visitors are redirected to ads or scam pages, but you are not | A cloaked redirect injection that targets search or mobile visitors | WordPress redirecting to spam |
| Customers report card fraud after buying from your store | The checkout may be skimmed while every order still succeeds | WooCommerce checkout skimming |
| An administrator account you never created | Persistence from an active compromise, not a glitch | Unknown admin user in WordPress |
| The same infection returns after every cleanup | Something survived: a startup directive, a scheduled task, a credential, or a neighbouring site | WordPress keeps getting hacked |
| An insurer or client sent a security questionnaire | You need evidence for each control, not a yes | Cyber-insurance requirements |
| An advanced-cache.php, object-cache.php or db.php in wp-content that no installed plugin owns | A loader using a reserved drop-in name, which runs before every plugin | Drop-in backdoors |
| Customers say checkout asked for their card twice, or showed an error and then a different card form | A script injected a fake card form in front of the real gateway; the first entry went to the attacker | Fake payment form at checkout |
| A plugin folder nobody installed, a hello.php with extra code, or an active plugin missing from the list | A backdoor packaged as a plugin and named to be overlooked | Fake WordPress plugins |
| View-source shows String.fromCharCode, document.write or an unknown <script src> in your pages | Script injected into the database: posts, widgets, or the siteurl and home options | fromCharCode script injection |
| Google Ads disapproves ads for a “Compromised site” or malicious software, or suspends the account | Google’s checks found the landing pages compromised or serving harmful content; the site has to be clean before an appeal can succeed | Google Ads compromised-site appeal |
| Search Console reports “Harmful downloads” or “Uncommon downloads” | The site serves or links to files Safe Browsing considers malicious, unwanted, or too rarely seen to trust | “Harmful downloads” in Search Console |
| RewriteCond lines on HTTP_REFERER or HTTP_USER_AGENT in .htaccess, or the same .htaccess in every folder | Malicious rewrite or handler rules: cloaked redirects, a prepended loader, or a lockdown protecting a backdoor | .htaccess malware rules |
| An unfamiliar hook in wp cron event list, or malware that returns every few minutes on a site with no server access | A scheduled WP-Cron event whose callback rewrites files or content | Malicious WP-Cron event |
| A PHP file in wp-content/mu-plugins that nobody installed, or a Must-Use tab you never noticed | A loader that runs on every request without activation and survives a plugin cleanup | Rogue mu-plugins loader |
| Search Console emails “Social engineering content detected” | Safe Browsing saw deceptive pages on the site — phishing, fake support, fake downloads or a fake verification prompt — and will warn visitors | “Social engineering content detected” |
| Google shows “This site may be hacked” under your search result | Google indexed spam pages, injected links or altered content on the domain, often cloaked so only crawlers and searchers see it | “This site may be hacked” label |
| An add_action on woocommerce_checkout_process, woocommerce_checkout_order_processed or woocommerce_payment_complete in a file you cannot place | PHP running inside the order flow, able to read what customers submit and copy it elsewhere | Rogue WooCommerce checkout hooks |
| An @include with \x2f or \057 escapes at the top of index.php, wp-load.php or wp-config.php | A loader that runs a hidden payload — often a fake .ico or .png — on every request | Obfuscated @include in core files |
| A database scan or query shows base64_decode, eval or gzinflate inside wp_options | A payload stored in the options table, run by a loader file elsewhere | base64_decode in wp_options |
| A subscriber, customer or custom role can reach Settings, Plugins or Users | The role definitions in wp_user_roles or one user’s capabilities were altered | wp_user_roles tampered |
| Files named wp-vcd.php, wp-tmp.php or class.theme-modules.php, or ads on the site you never placed | WP-VCD, brought in by a nulled theme or plugin and spread to the site’s other themes | WP-VCD malware |
Exact-match diagnostics
Database · Script injection
Scripts injected into post content, widgets or the site URL options run in every visitor’s browser. How to find them read-only, why serialised data must be fixed with WP-CLI, and what wrote them.
Read the script-injection guideDatabase · WP-Cron
A malicious WP-Cron event lives in one row of the options table and runs on ordinary page views. How to read the schedule without running it, find the code behind a hook, and remove both in the order that holds.
Read the WP-Cron event guideDatabase · wp_options
An encoded blob in an autoloaded option is a payload waiting for a file to run it. How to find every suspect row read-only, tell plugin data from a loader, and remove both halves in the right order.
Read the wp_options injection guideDatabase · Roles and capabilities
Administrator rights can be granted without creating an administrator: by editing a role’s definition, or one user’s capabilities. How to read both read-only and put them back without breaking plugin roles.
Read the roles-tampering guideExact-match diagnostics
Files · Drop-in backdoors
Drop-ins load before every plugin without being activated, and caching plugins write them legitimately. How to tell a real one from a loader, and remove a rogue one safely.
Read the drop-in backdoor guideFiles · Impostor plugins
Backdoors get installed as plugins named like real ones or like parts of WordPress. How to verify every plugin against WordPress.org and the disk, and remove the fakes.
Read the fake-plugin guideFiles · .htaccess
RewriteCond lines on HTTP_REFERER or HTTP_USER_AGENT, a php_value auto_prepend_file, .ico files handled as PHP, or the same .htaccess in every folder. What each malicious rule does, how to compare against WordPress’s standard block, and how to clean them all.
Read the .htaccess malware guideFiles · Must-use plugins
Must-use plugins run on every request without activation and can hide themselves and rogue admins. How to read the folder directly, tell your host’s files from a loader, and remove it.
Read the mu-plugins guideFiles · Core-file includes
An escaped include above WordPress’s own code loads a hidden payload on every request. How to find every copy, decode the path without running it, and remove both halves.
Read the core-file include guideFiles · WP-VCD
WP-VCD arrives inside nulled themes and plugins, injects code into functions.php, writes companion files into wp-includes and spreads to every other theme. How to find each piece, why deleting the files is not enough, and why every nulled copy has to go.
Read the WP-VCD guideExact-match diagnostics
Google · Google Ads
Ads stop when Google judges the landing page compromised or serving malicious software, and repeat problems can reach the whole account. The pre-appeal checklist: clean site, clean Safe Browsing status, clear Search Console — then one appeal.
Read the Google Ads appeal checklistGoogle · Search Console
Your site serves or links to software Google considers malicious or unwanted. Where injected download links and planted files hide in WordPress, how to find them in uploads, the database and the logs, and how “uncommon downloads” differs.
Read the harmful-downloads guideGoogle · Search Console
Google found pages on your site that trick visitors: phishing forms, fake support numbers, fake downloads or fake verification prompts. Why you often cannot reproduce it, where the pages hide, and what Google expects before a review.
Read the social-engineering guideGoogle · Search results
The label means Google indexed content on your domain that a third party put there — usually spam pages or injected links you cannot see. How to find what Google saw, remove it properly, and ask for the label to come off.
Read the “may be hacked” guideExact-match diagnostics
WooCommerce · Fake payment form
A second card form, a payment step that errors once and then works, or card fields outside the gateway’s iframe. How the injected form works, how to prove it from a browser, where the script hides, and who to tell.
Read the fake payment form guideWooCommerce · Checkout hooks
An add_action on woocommerce_checkout_process or woocommerce_checkout_order_processed in a file no extension owns. How server-side skimmers use checkout hooks, how to list every callback and the file it lives in, and how to tell an extension’s hook from a rogue one.
Read the checkout hook malware guideServer and hosting forensics
When the mechanism sits in the hosting account or the server rather than inside WordPress, a site cleanup removes the damage and leaves the cause. These guides cover the layer above the web root.
Server · WHM / cPanel
One account flagged on a shared control-panel server is a server incident. Why per-site scans miss the mechanism, what to preserve and contain first, and the root-level sweep that decides whether the incident is really over.
Read the WHM/cPanel response guideServer · gsocket backdoor
A packed binary hiding in ~/.config/htop is a gsocket backdoor — an encrypted outbound shell that survives every site cleanup. How to check each account, confirm it without running it, and remove it in the right order.
Read the gsocket backdoor guideServer · Hidden files
Backdoors that survive site cleanups live where WordPress scanners never look: dot-directories, executables, and SSH keys in the account’s home directory. How to sweep it read-only, tell the control panel’s own folders from planted ones, and what to preserve before removing anything.
Read the hidden-files guidePersistence · Cron jobs
A scheduled task that re-downloads a shell rebuilds whatever you remove. Where scheduled tasks hide on cPanel and Linux — user crontabs, /etc/cron.d, systemd timers, WP-Cron — how to read one without running it, and the order to remove it in.
Read the malicious-cron guideServer · Outbound spam
Outbound spam from a cPanel server comes from a compromised mailbox, a malicious script, or an abused form, and each needs a different fix. How to find the account and script from the Exim queue and logs, and why delisting comes after the cleanup, not before.
Read the outbound-spam guideAlert · ImunifyAV
A detection list is an inventory of damage, not an account of the mechanism. How to read a detection name, tell a real finding from a false positive without guessing, and understand what a clean result does not cover.
Read the ImunifyAV detections guidePersistence · PHP startup
A PHP auto_prepend_file directive runs before WordPress and before every plugin inside it, so it can rewrite what you just removed. Where it hides, how to tell it from Wordfence's legitimate use of the same setting, and the removal order that holds.
Read the auto_prepend_file guideContradiction · Clean scan
A clean scan and a live warning are not a contradiction — there are four reasons they coexist, and they need completely different responses. How to tell which one you have before you request a review.
Read the clean-scan triage guideSymptom · Hosting suspension
The suspension notice lists flagged files and asks you to clean and reply. Deleting them gets you reinstated — and re-suspended. What the host actually knows, what to ask for, and the sequence that lifts a suspension once.
Read the hosting-suspension guideConfiguration · Cloudflare
If the origin server answers direct requests, every WAF rule is optional for an attacker who finds its address — and addresses leak through DNS history, subdomains, and email. How to check and close it.
Read the origin-exposure guideWordPress site symptoms
What visitors, customers, and Google see when a WordPress site is compromised — and what each symptom usually means underneath.
Symptom · Fake verification page
A fake CAPTCHA or Cloudflare-style check on your own site means it is compromised and serving ClickFix malware to your visitors. How to confirm it without infecting yourself, and why deleting one file never removes it.
Read the fake-verification guideSymptom · Spam redirects
Visitors land on ads or scam pages while the site looks normal to you — the signature of a cloaked redirect hack. Where the redirect hides, how to reproduce it under the victim’s conditions, and what a durable fix involves.
Read the redirect-hack guideSymptom · Repeat infection
A site that is reinfected after every cleanup is not unlucky — something survived. The five places most cleanups never check, from database persistence and PHP startup directives to identities and neighboring sites.
Read the reinfection guideSymptom · Japanese search results
Japanese titles and counterfeit-goods pages under your domain in Google are the Japanese keyword hack: cloaked SEO spam generated on your site. Where it hides, why deleting pages fails, and how the index recovers.
Read the Japanese keyword hack guideSymptom · Browser warning
The red Safe Browsing warning means Google saw your site serving deceptive content. What triggered it, why review-before-cleanup backfires, and the removal sequence that works the first time.
Read the warning-removal guideSymptom · Unknown account
Accounts do not create themselves. A rogue administrator is persistence from an active compromise — what to capture before deleting anything, how to find hidden siblings, and the response that closes the door.
Read the rogue-admin guideSymptom · Card fraud reports
Checkout skimming steals card data while every order still succeeds. The signals that reveal a skimmed WooCommerce checkout, how to confirm it without destroying evidence, and the obligations that follow.
Read the checkout-skimming guideAssurance and comparisons
For the questions that come before an incident: how the site stands today, what an insurer or client will ask, and what a security plugin can and cannot tell you.
Resource · Free download
The control areas a professional audit reviews — access, software, hosting, recovery, monitoring — as a checklist you can run against your own site. Free HTML and PDF, no email required.
Open the audit checklistAssurance · Cyber insurance
Insurer questionnaires are answered under a duty of accuracy, and most are written for a company with laptops. What each question means for a site and its server, and what evidence actually answers it.
Read the cyber-insurance guideAssurance · Security plugins
A security plugin runs inside WordPress with the site’s own permissions. What Wordfence and similar plugins do well, the layers they cannot see — scheduled tasks, SSH keys, the process table, neighbouring accounts — and when an independent review is worth it.
Read the Wordfence comparisonDeeper reading
The guides draw on documented engagement work: a coordinated ClickFix infection investigated across more than 30 WordPress and WooCommerce sites, a hidden ELF backdoor found on a 261-account WHM server after every scan came back clean, and an e-commerce site whose reinfection cycle ended only when the surviving persistence and access paths were closed.
Common questions
Treat it as likely if any of these is true: visitors, customers, Google, or your host report something you cannot reproduce; an administrator account exists that nobody created; files, scheduled tasks, or PHP settings appear that nobody changed; or the site sends mail or redirects traffic it should not. Seeing nothing yourself proves little, because most infections hide from logged-in owners and direct visits. Start from the message or symptom in the table above, and confirm under the conditions the report describes before changing anything.
Sometimes, if you can do all of it: preserve evidence first, rebuild core, plugins, and themes from trusted sources instead of editing infected files, check the database, users, PHP startup files, and scheduled tasks, and rotate every credential from a clean device. Deleting the files a scanner lists is not a cleanup. If the infection returns, customer card data may be involved, or the indicators sit outside the site in the hosting account or on the server, the problem is larger than one site and is worth handing to someone who does this routinely.
Not before you know when the compromise began and have preserved the current state as evidence. A backup taken after the intrusion restores the infection with it, and even a clean backup restores the same vulnerable software and the same stolen credentials. Restore only a backup you can show predates the compromise, then close the entry path, update everything, and rotate credentials before the site is public again.
Often both. A clean scan means the files that tool read did not match patterns it knows at the moment it read them. The flag may be stale after a real cleanup, the malware may be cloaked so it hides from you and from the scanner, the mechanism may sit outside what the scanner reads — the database, a PHP startup file, the home directory, a scheduled task — or the flag may concern something other than malware. Find out what the flagging party actually saw, and when, before requesting a review.
Typically $120–$500 for a single infected site, with most single-site cleanups completed in 1–3 business days. Multi-site fleets, missing hosting access, and repeat-reinfection investigations are scoped individually, and the written proposal states the exact fixed fee before work begins. The pricing page lists the ranges for every service, including server-level work.