How people usually find out
- •Search results show someone else’s text instead of your pages, or the browser flags the site as dangerous,
- •The host sends a malicious-activity notice and threatens to suspend the account,
- •A customer calls asking why they were redirected to a site that is not yours,
- •Your email starts landing in spam, because someone else was sending from your server.
All four have one thing in common: somebody outside tells you, once it has already cost money or reputation. A typical site is not broken into by a person but by automation: bots sweep addresses around the clock, fingerprint the engine and its add-ons, and fire a ready-made exploit at a known hole. You were never the target — the open door was.
What the audit looks at
We connect to the server over SSH, read-only — nothing needs to be installed on it. From the outside, by URL alone, only symptoms are visible; the malicious code itself sits in the files and in the database.
- •Engine and repository add-on files are compared against official reference builds — which exposes both a planted file and a patched core,
- •We look for web shells, miners and persistence: scheduler jobs, autostart entries, modified system files,
- •We check whether the server hands strangers what it should not: .env, the .git folder, database dumps, configuration pages,
- •Administrators in the engine database are reviewed: recently added, unnecessary, plus injections into autoloaded options,
- •Versions of the web server, language runtime, database and the engine itself are matched against known vulnerabilities,
- •Web server logs are parsed: traces of intrusion attempts, who knocked and with what,
- •The state of the defences is reviewed: certificate expiry and algorithm, brute-force blocking, password policy.
What you get
- •A report with an overall grade and findings by severity — each says what it means and what to do,
- •An email straight away if malware is suspected or the state is critical, not a report at the end of the month,
- •No repeat email for the same unfixed setting — otherwise alerts get muted by day two,
- •The access key is stored encrypted and deleted together with the server when you remove it.
What we do not do
This matters more than a feature list: a client who expected treatment and got a diagnosis is entitled to feel misled.
- •We do not clean the site silently. The audit changes nothing on the server — any fix is a separate, agreed step,
- •We do not guarantee you will not be breached. This is diagnostics, not perimeter security: between runs we are not watching,
- •We neither make nor keep backups. That stays on your side; we can only check that yours actually restores,
- •We do not audit a site “by URL”: without server access you see symptoms, not the cause,
- •We do not promise to find every piece of malware. We promise to show what was verified by comparison, what by heuristics, and what was not checked at all.
Why a one-off clean-up is not enough
A one-off clean-up removes the symptom but does not close the door. If the way in is unchanged — the same un-updated plugin, the same weak password, the same theme downloaded from a torrent — they come back through it, often precisely because they know it is still open. Which is why the check is worth repeating rather than doing once.
Frequently asked
Will you fix the site if you find an infection?
The audit changes nothing on the server — it reads the state and returns a prioritised list of problems. Remediation is separate work and starts only once you agree to it: first you see what was found and what it means, then you decide.
Why do you need server access rather than just the URL?
From the outside you only see consequences — a redirect, someone else’s text in search results, a browser warning. The malicious code itself sits in files and in the database, and that is the only place it can be found.
Is it safe to give you access?
Read-only access is enough, the key is stored encrypted and is deleted together with the server when you remove it. The audit commands are fixed in code: the model reads their output, it does not decide what to run on your machine.
How is this different from the hosting antivirus?
A hosting antivirus matches known signatures. We compare engine and repository plugin files against official reference builds, which exposes both a planted file with no signature and a modified core. Where no public reference exists — paid or bespoke components — heuristics are all that remain, and we say so plainly.
How often should this run?
The first audit shows today’s state. After that it is worth repeating: a one-off clean-up removes the symptom, but if the way in is still open, they come back through it. You choose the cadence, from manual runs to daily.
What do we get at the end?
A report with an overall grade and a list of findings by severity, each with what it means and what to do about it. If malware is suspected or the state is critical, the email arrives immediately rather than at the end of the month.
We cover this in more depth on the blog: signs your website has been hacked, how to check a website for malware, the server audit checklist and hacked through an outdated CMS.