Forensics lab · Intermediate · 30 min
Malware Scanning: What Each Scanner Can and Cannot See
You need to answer compromised or clean with evidence — checksums against upstream, file timestamps, and a scanner that sits below the application it is checking.
The short answer
Rank your evidence by how hard it is to fake: a checksum comparison against the official release beats a modification timestamp, which beats a signature match, which beats an external symptom — and run the scanner from below the application rather than inside it.
That ordering matters because the common failure here is a false negative. A plugin scanner executes inside the code that may already be compromised, and a signature scanner only knows the patterns it has been taught. Checksums do not care about either: they simply notice that a file no longer matches what upstream published.
By the HostingFast team · Reviewed 15 August 2026
Intermediate
Assumed level
5
Stages to verified
Free
Support cost
Proven
Proven on our platform
Half an hour of methodical checking, most of it from the command line. SSH with WP-CLI is available on every shared tier, which is what makes the checksum route practical.
The scanning layer is already running: ImunifyAV+ sweeps every site on the Sprint and Turbo tiers, and Imunify360 covers Nitro and the business plans. This guide is about interpreting what it reports and covering what it cannot see.
Rank the evidence before you collect it
Strongest first: wp core verify-checksums compares every core file against the hashes WordPress published for that version, so an altered file is arithmetic rather than opinion. Next, file modification times, which are reliable unless someone has deliberately touched them. Then signature scanning, which finds known patterns and misses novel ones. Weakest — but often first to arrive — is the external symptom: a browser warning, a spammy title in a search listing, a customer mentioning a redirect.
Collect in that order and you will rarely be stuck. Collect only the weakest kind and you end up with a strong feeling and nothing to act on.
Why the scanner's position in the stack decides what it sees
A security plugin runs as part of the application. If the compromise has reached that application's code, it is running inside the thing it is auditing, and a payload that unhooks or whitelists itself is a well-known technique. A server-level scanner runs as a separate process with its own view of the filesystem, which is a materially different vantage point.
Use both, and know which is which. ImunifyAV+ or Imunify360 examining the files underneath the application will see things the application's own plugin cannot; the plugin, in turn, knows about the application's database and its user table, which the file scanner does not read.
Reading timestamps without fooling yourself
find . -type f -name '*.php' -mtime -14 lists the PHP files modified in the last fortnight, which on a stable site should be a very short list. Anything in wp-content/uploads is immediately suspicious, because uploads should contain media, not code.
Two caveats keep this honest. Modification time can be set by anyone who can write the file, so a backdated file is entirely possible; ctime, shown with find -printf or stat, is harder to forge. And a mass update legitimately touches hundreds of files, so check what you deployed recently before you read the list as evidence.
The four places a clean scan tends to miss
The database: injected script tags in post content or option rows, and a rogue administrator in the users table. The .htaccess files: a conditional redirect near the top of the file, often applying only to requests without a referrer. The crontab: a scheduled task that reinfects the site every hour, which makes the compromise look like it keeps coming back. And mail: forwarders and filters nobody created, quietly copying everything to an outside address.
Conditional payloads are the reason the site can look fine to you and broken to everyone else. Test the way the attacker segmented: curl -A 'Googlebot' https://example.com and compare the output with a normal request. A redirect that fires for one user agent and not another is a fingerprint, not a coincidence.
The scanning already running under your account
ImunifyAV+ sweeps every site on the Sprint and Turbo tiers, and Imunify360 covers Nitro and the business plans — server-level scanning that sits below whatever application you are running.
Full SSH access with Git and Composer is on every shared tier, which is what makes checksum verification and timestamp forensics practical rather than theoretical.
- Evidence ranked by how hard each kind is to fake
- Commands for checksums and timestamps, in full
- The four blind spots a file scanner does not cover
- Engineers on the desk at any hour of the incident
Why HostingFast
Standard on every plan
A ranked evidence model
Checksums, then timestamps, then signatures, then symptoms — so you spend your half hour on the strongest evidence available.
Scanner position explained
Why a plugin auditing its own application is a weaker vantage point than a process running underneath it.
Honest about timestamps
mtime can be forged and mass updates muddy the list, so the guide says how to read it rather than trusting it blindly.
The conditional payload, reproduced
A curl command with a crawler user agent, which is how you see what your visitors and Google are seeing.
Blind spots named
Database rows, .htaccess, cron and mail forwarders — the four places a file scan quietly does not look.
Server-level scanning included
Imunify runs on the platform already, so the strongest scanning layer is not an add-on you have to buy.
Quick Start
From order to online
- 1
Reproduce the symptom deliberately, from outside
curl -A 'Googlebot/2.1' https://example.com and a normal request, then compare. Check the site: query in a search engine for injected titles. A payload that only fires for some visitors will never show up in your own browser.
- 2
Verify the application against upstream
wp core verify-checksums names every core file that no longer matches the published release. It is the single highest-value command on this page, and it takes seconds over SSH.
- 3
List what changed, then subtract what you changed
find . -type f -name '*.php' -mtime -14. Cross off your own deploys and updates. Look hard at anything left, especially under uploads, where PHP has no business being.
- 4
Read the server-level scan report
ImunifyAV+ on Sprint and Turbo, Imunify360 on Nitro and the business tiers. It sees the filesystem from outside the application, so treat a hit here as stronger evidence than a plugin's opinion.
- 5
Sweep the four blind spots, then assume plurality
Database options and users, every .htaccess, the crontab, and mail forwarders. One confirmed hit means look for more: payloads are installed with redundancy, and a single deletion is not a clean-up.
Built In
Loaded onto every plan
- ImunifyAV+ malware sweeps on the Sprint and Turbo tiers
- Imunify360 on the Nitro tier and both business plans
- Full SSH access with WP-CLI, Git and Composer on every shared plan
- Daily backups with self-service restores, so a clean point always exists
- Backups every six hours on the Nitro tier
- LiteSpeed caching in the server, with a purge you control
- Per-site PHP version switching from the control panel
- Free SSL on every plan, renewed automatically before it can expire
- Money-back cover: 30 days on hosting plans, 7 on reseller
- Human support on duty every hour of every day
Frequently Asked
What people ask us most often
Every scanner reports clean but visitors get redirected — where do I look next?
Four places, in this order. The database: injected script in post content or an option row, plus any administrator account you did not create. Every .htaccess on the account, looking for a conditional rewrite near the top. The crontab, for a task that reinstalls the payload on a schedule. And mail forwarders. Then reproduce it properly with curl -A 'Googlebot/2.1', because a payload that segments by user agent or referrer is invisible to a browser you are already logged into.
Can I trust file modification times after a compromise?
Partly. Anyone who can write a file can set its mtime, so a backdated file is a real possibility and a short list of recent changes is not proof of innocence. ctime is harder to manipulate and worth checking with stat. Use timestamps to generate leads and checksums to confirm them — the hash comparison does not care what date the file claims.
Which scanner is running on my plan?
ImunifyAV+ sweeps every site on the Sprint and Turbo tiers, and Imunify360 runs on Nitro and both business plans. Both operate at server level, below the application, which is exactly the vantage point a plugin scanner cannot have. You can still run an application-level scanner alongside; it knows about the database, which the file scanner does not.
How often should a site that never changes be scanned?
The server-level sweep runs continuously, so the honest answer is that scanning is not the thing you need to schedule. What you should schedule is the checksum comparison — monthly is plenty on a static site — because that is what catches a file changing when nothing should have changed. A site nobody edits is the easiest kind to audit: the expected diff is empty.
Keep reading
How to Check DNS Propagation
Query the resolvers directly instead of trusting a propagation map's colours.
How to Install a LAMP Stack
Apache, MySQL and PHP assembled by hand, with the versions pinned by you.
Malware (Glossary)
What the category covers, and why a signature match is weak evidence.
Node.js Hosting
Node.js deployed natively, with the runtime and process manager under your control.
Business Hosting
More cores, more RAM and priority support for a site doing real work.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Scanning that sits below your application.
Imunify protection on every site, SSH with WP-CLI for checksum verification, daily backups you restore yourself, and engineers reachable at any hour.
View Node.js Hosting plans