Compromise & recovery · Intermediate · 30 minutes
How to scan a site for malware — Scan the Files, Then Read the Zone: Where a Compromise Hides From File Scanners
The scan came back clean, the site still misbehaves, and nobody has yet looked in the one place malware does not need a file at all.
The short answer
Run the server-side scanner and the application integrity check first, then read the DNS zone and the mail settings — because a compromise that reached your account can add a wildcard A record, a stray TXT, a rogue MX or a mail forwarder, none of which appear in a file scan and all of which keep working perfectly after every infected file has been deleted.
Below: what the outside world can tell you before you log in anywhere, the three scanning layers and what each is blind to, and the specific records to compare against what you believe is live.
By the Hosting & Domains team · Reviewed 24 August 2026
Intermediate
Level assumed
5
Stages in the procedure
Free
Cost of asking us
Proven
Where it was checked
No technical background needed. This was written for people who manage names rather than servers, proven on the platform we actually run, and honest about which parts are genuinely fiddly rather than merely unfamiliar.
One promise before step one: nothing here is a one-way door. Any step that is awkward to reverse is flagged, and the way back is printed beside it.
Start outside, because reputation attaches to the name
Spammy titles in search listings, browser interstitials, visitors describing redirects they never asked for. What shows from outside is usually the announcement; the internal scan is the confirmation. Check the public URL scanners and Search Console's security section, both of which report against the domain rather than the server.
That distinction matters more than it sounds. A blocklist entry follows the name, not the hosting, so moving the site to a different server changes nothing about it. The name is the thing with a reputation, and it is the name that has to be cleared.
Three scanning layers, each blind to something
The server-side scanner — Imunify360 on protected plans — inspects the files beneath the application from a level compromised code cannot easily hide from. A WordPress security plugin checks core files against the official checksums, which is about the clearest single piece of evidence in this field. An external URL scanner sees what a visitor's browser sees, including injected scripts that only fire for certain user agents.
Run all three when you suspect something. What hides from one is frequently obvious to another, and agreement between them is worth far more than a single clean result.
The records no file scanner reads
Open the zone editor and compare it against what you believe is published. Look for A records you did not create, particularly a wildcard entry that quietly gives an attacker every possible subdomain of your name. Look at the MX set and its priorities, because an added low-priority MX can intercept mail without disturbing normal delivery. Look at TXT records for an SPF line that has grown an unfamiliar include, and for verification strings proving your name to a service you have never used.
Then look outside the zone at the same layer: mail forwarders in the panel, auto-responders, additional email accounts, and any subdomain that exists without a document root you recognise. Every one of those survives a file clean-up untouched.
One positive means several
Malware installs itself with redundancy on purpose, so the obvious file dies and the quiet ones live on. Deleting the single flagged file and declaring victory is the commonest reason a site is compromised twice in a fortnight.
Treat a single positive as the start of a procedure rather than the end of an incident: full clean-up, patch the way in, audit the users, and read the zone. The scan tells you there is a problem; it does not tell you the size of it.
What is already running while you are not looking. On covered plans, server-level scanning runs continuously, so the deliberate deep scan is for incidents plus a quarterly sweep rather than a weekly ritual. Cadence matters far less than acting fully on whatever a scan turns up.
If everything scans clean and the behaviour persists, trust the symptoms. Injected database content, redirects buried in .htaccess, administrator accounts nobody created, recently modified files — scanners match known signatures, and a manual review catches the bespoke work. Support will read through it with you.
The account these steps were written against
Guides written against imaginary hosting go stale quickly. These are written against the real thing: the same panel, the same zone editor, the same defaults sitting in your account.
Order an annual plan and year one of the name's registration is on us.
- Every step run on this platform before it was published
- The clock on each record spelled out
- The failure mode printed beside the fix
- A desk that answers whatever the hour
Why Hosting & Domains
Standard on every plan
The clerical half is already done
Certificates issue themselves, the daily copy is taken without being asked, and the records are written when a name is added — so the guide covers only the decisions that are genuinely yours.
Five stages, none of them filler
Each stage is a short spell of deliberate clicking, and the ones that are genuinely fiddly are labelled fiddly.
The trap named before step one
The classic mistake on this particular task is named before you begin, which is the difference between the time estimate above and a lost evening.
Someone awake when a name breaks
Expiry dates and DNS faults keep no office hours, so the desk answers at whichever hour you find one.
Written from the ticket queue
Every trap named here came out of a real support ticket, which is why the awkward ones get named at all.
The way back, printed beside the risk
Anything awkward to reverse is flagged, with the route back written next to it rather than three paragraphs later.
Quick Start
Order placed to site online
- 1
Check what the outside world says about the name
Public URL scanners and Search Console's security section report against the domain. A blocklist entry follows the name wherever it is hosted, so this is where an incident becomes public.
- 2
Run the server-side scan
On protected plans the scanner inspects files from beneath the application, which sees things compromised code can hide from its own plugins.
- 3
Compare the core against its checksums
Compare core files against the official checksums. An altered core file is about as unambiguous as evidence gets in this field.
- 4
Read the zone against what should be published
Unfamiliar A records and any wildcard, extra MX entries at low priority, an SPF include you did not add, verification TXT strings for services you have never used.
- 5
Check the mail layer in the panel
Forwarders, auto-responders, extra mailboxes and stray subdomains. None of these live in a file, so none of them appear in a file scan, and all of them keep working after a clean-up.
Built In
Fitted to every plan
- cPanel, the panel most of the industry already runs
- A staging copy for rehearsing a change before it goes live
- WebP image optimisation built in at no extra charge
- A renewal figure identical to the one you first registered at
- A 99.9% uptime target, watched every hour of the day
- WordPress Toolkit, with the updates handled for you
- WordPress and 400+ other applications in a single click
- Webmail in the browser, with IMAP, POP and SMTP for any client
- A PHP version chosen per site from the control panel
- Plan changes applied in place, with no migration to arrange
Frequently Asked
Questions we field again and again
Can a compromise live entirely in DNS, with no infected file at all?
Yes, and those are the ones that outlast a clean-up. An added MX entry copies mail elsewhere. A wildcard A record hands an attacker every subdomain of your name for phishing pages hosted on their own server. A mail forwarder in the panel quietly duplicates every message. None of that touches a file, so a scanner reports clean while the problem continues.
The malware is gone but my domain is still on a blocklist. Why?
Because the listing is against the name and clears on the list operator's schedule, not yours. Request a review through Search Console and through whichever public scanners flagged you, having first made certain the site is genuinely clean — a rejected review is slower to recover from than a delayed one. Expect the reputation to return after the technical repair rather than alongside it.
How do I know which records I did not add?
Keep a written copy of the zone as it should be: A and www, the MX set with priorities, SPF, DKIM selector, and each verification TXT with a note of what it proves. Then a comparison takes a minute and needs no memory. Exporting the zone after any deliberate change is the cheapest habit on this page.
Is anything scanning while I am not looking?
On covered plans, yes — scanning runs continuously at server level, which is why the deep manual scan is reserved for incidents plus a quarterly sweep. What matters far more than frequency is following through completely on anything a scan reports, rather than deleting the one file it named.
Keep reading
How to Check DNS Propagation
Find out whether the internet has taken up your change, and why some resolvers have not — beginner level, about 5 minutes.
Node.js Hosting
Run Node.js applications alongside your sites, with SSH and Git included.
Business Hosting
Shared hosting carrying the whole developer kit, from SSH through Node.js and Python to PostgreSQL.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
Hold the name and the hosting behind one login.
A free certificate, a free migration, renewals billed at the original rate, and people on the desk around the clock. That is the whole offer.
View Node.js Hosting plans