Skip to main content
HostingSeller
Shop plans

Reseller runbook · Estate hygiene · 30 minutes

How to scan a site for malware — One Infected Client Account Is Everybody's Problem

The client whose site is infected is not the client who will ring you first — the others will, about mail that stopped arriving.

Straight answer first

Scan at server level rather than from inside each site, because compromised application code can hide from its own plugins. Imunify360 stands guard on every client site on a reseller package, which makes the estate view — not the site view — the one to work from when you sell hosting rather than own one site.

Then treat one positive as an estate event, not a site event. Shared outbound mail reputation, shared addresses and shared credentials mean an infection on one account can produce symptoms on several. Confirm before you tell anybody anything, and assume more than one file is involved.

Written by the Hosting Seller staff · Checked 24 August 2026

Intermediate

Skill assumed

5

Stages in the runbook

Free

Cost of support

Tested

Verified on our platform

A site owner scanning for malware is answering a question about their own business. You are answering a question about a shared platform: whether this is one account's problem or the beginning of everybody's.

That reframes the whole exercise. The scan is the easy part. The judgement is in what you check next, what you tell whom, and at what point you start charging for the work.

Why an infection on one account reaches the others

Client accounts are separated, so a compromise does not walk across the disk from one to another. What it does travel through is reputation. Outbound mail from a hijacked contact form gets your sending flagged, and the clients who notice are the ones whose invoices stop arriving — none of whom have anything wrong with their own sites.

The other shared surface is you. Credentials you reused, an FTP account you issued across two accounts, a laptop with saved passwords for the whole estate. When one client account goes, the first thing to check is not the other sites but the credentials that touch them.

Scanning the estate instead of one site at a time

Site-by-site scanning does not survive contact with forty accounts. Work from the server-level scanner that covers every account on the package, and set yourself a fixed rhythm to read its reports rather than opening it when somebody complains. The value of a scanner is entirely in whether anyone looks at the output.

Cross-check the accounts that matter with the application's own integrity tools — a WordPress security plugin comparing core files against official checksums is about as clear as evidence gets. Reserve that manual pass for the client sites where a compromise would be most expensive rather than trying to do it everywhere.

What you tell the client, and at what point

Do not send the first message on suspicion. Confirm with the server-level scan and one corroborating signal — a modified core file, a blocklist entry, an obvious injection — and then send a message that says what you found, what you have already done, and what you need from them.

The tempting mistake is silence while you clean, on the theory that a fixed problem needs no announcement. It does. Clients find out from customers, from a browser warning or from a search result, and a client who learns about it from anyone but you has learned something about you as well.

Charging for the clean-up without losing the account

Scanning is included in what they pay for; recovery is work. Set the boundary in the care plan so you are quoting from a policy rather than negotiating during a crisis, and separate the emergency containment — which you do immediately, unbilled if you like — from the clean-up, which is scoped and charged.

The cause determines the tone. An outdated plugin the client refused to let you update is a chargeable conversation you should have documented in advance. A platform-side problem is yours. Knowing which one you are in before you write the message is most of the skill.

A shield icon standing in for site security and DDoS filtering

Protection on every account, not just the flagship

Imunify360 is on guard on every client site you create on a reseller package, so the smallest account gets the same scanner as the largest. That is what makes an estate-level routine possible instead of a per-client upsell.

Daily backups across every account and a restore you run yourself mean the recovery path exists before the scan finds anything.

  • Imunify360 on guard on every client site
  • Daily backups across every client account
  • Restores you run yourself, in minutes
  • DDoS filtering out at the network edge

Why Hosting Seller

On every plan, as standard

Estate-level, not site-level

The routines assume forty accounts and a fixed rhythm, because per-site scanning is what does not get done.

Reputation treated as the real risk

The first consequence of an infection is usually mail, and the page starts there rather than with file counts.

Client comms scripted

When to tell a client, what to say, and what silence costs you are written out rather than left to instinct.

A billing boundary you can quote

Containment and clean-up are separated so you have a policy to point at instead of a negotiation.

Included on every account

The scanner covers every client site on a reseller package, so nothing here depends on an upsell.

People to escalate to at any hour

Support answers for you and your clients around the clock, including during an incident.

First Steps

From choosing to live

  1. 1

    Check what the outside already knows

    Search results with unfamiliar titles, browser warnings, blocklist entries, client reports of redirects. External symptoms usually name the problem an internal scan then confirms, and they are also what your other clients are seeing.

  2. 2

    Run the server-level scan across the account

    Imunify360 reads the files underneath the application, which is what matters when compromised code can hide from the site's own plugins. This is the scan whose result you act on.

  3. 3

    Corroborate before you tell anybody

    One clear second signal — a modified core file against official checksums, an injected redirect, a blocklist entry. Confirmed beats fast when the message you are about to send names somebody's business.

  4. 4

    Check your credentials and your mail reputation next

    Not the other sites: the things that actually cross between them. Shared FTP accounts, reused passwords, outbound mail volume. This is where one client's incident becomes several clients' symptoms.

  5. 5

    Scope the clean-up before you start it

    Containment now, clean-up quoted. Assume more than one file, because malware installs itself redundantly, and price the job on that assumption rather than on the first result the scanner returned.

In the Box

Packed with every plan

  • Imunify360 on guard on every client site
  • Daily backups taken across every client account you create
  • DDoS filtering handled out at the network edge
  • WHM for you, and a cPanel of their own for every client account
  • cPanel, the panel your clients and your contractors already know
  • Real people answering, for you and for your clients, at any hour
  • Mailboxes carrying the client's own domain, filtering fitted to each one
  • A 99.9% uptime target, watched by monitoring day and night
  • Client-account allowances of 100, 250 or 500, depending on the package
  • Seven days' money back on reseller hosting, thirty on hosting plans

Across the Counter

Things people ask us all the time

Does an infected client site affect the other sites on my reseller?

Not through the filesystem — accounts are separated. It reaches them through shared reputation and shared credentials: hijacked outbound mail gets your sending flagged, and any FTP account or password used across two accounts turns one incident into two. Check credentials and mail before you check other sites.

Is Imunify360 included on the accounts I create for clients?

Yes, on reseller packages it stands guard on every client site rather than only on the accounts you would have chosen to protect. That is what makes an estate-wide routine possible: the scanner is already on the small accounts, which are usually the ones that get compromised.

Should I tell a client their site is infected before I have proof?

No. Confirm with the server-level scan plus one corroborating signal first. But do not go silent while you clean either — clients discover these things from customers and search results, and finding out from anyone but you costs more trust than the incident itself.

How often should I scan an estate of client sites?

Continuously at server level, and read the reports on a fixed schedule rather than when somebody complains — weekly for a small estate, and a manual integrity pass on the two or three accounts where a compromise would be most expensive.

Read next

  • Node.js Hosting

    Node applications for clients, without leaving the panel your team knows.

  • Business Hosting

    The step up for a client whose site now earns its keep.

Moving your site to another host? Start with this checklist.

A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.

One email brings the checklist, then now and again a note about running a site properly. Leave the list whenever you feel like it. Our privacy policy spells out the rest.

Protect every client site, not just the big one.

Imunify360 on guard across every account you create, daily backups underneath, and people to escalate to at any hour.

See Node.js Hosting plans