Guide · ImunifyAV detections
An ImunifyAV detection is a question, not a verdict.
Your host’s panel is showing a list of infected files, or an email arrived saying malware was found on your account. The two obvious reactions — delete everything it flagged, or dismiss it as another false positive — are both guesses, and on a shared server both are expensive. This guide explains what ImunifyAV actually scanned, how to read a detection name, how to decide whether a specific finding is real, and — the part almost nobody covers — what a clean ImunifyAV result does not tell you.
Published Last reviewed
- Symptom
- ImunifyAV or Imunify360 reporting infected files on your account
- What it is
- A server-side scanner with signature, heuristic, and hash-based detections
- Main risk
- Deleting the output while the mechanism stays — or ignoring a real finding
- First step
- Read the detection name and preserve the file before acting on either
What was scanned
What ImunifyAV actually looked at — and what it did not
ImunifyAV runs server-side rather than inside WordPress, which makes it genuinely more capable than a WordPress security plugin in one specific way: it can read the whole hosting account, including the home directory above the document root, not just the files inside the application. That is a real advantage and it is worth understanding before you dismiss its output.
What it does is match files against signatures, hashes, and heuristics. What it does not do is explain how those files got there, identify what has write access to them, or tell you whether anything else on the server shares the same cause. A detection list is an inventory of damage. It is not an account of the mechanism, and the two are routinely confused.
The free ImunifyAV tier detects but does not clean; ImunifyAV+ and Imunify360 add cleanup and quarantine. That distinction matters when your host says the issue has been “handled” — ask whether files were cleaned, quarantined, or merely listed, because the three leave you in very different positions.
Reading the detection
How to read a name like SMW-INJ-… or SMW-HEUR-ELF
The detection ID is structured, and learning to read it tells you most of what you need before you look at the file at all.
| Part of the name | What it means | Why it changes your response |
|---|---|---|
| SMW | Server malware — the detection concerns a file on the server. | The finding is about your hosting account, not about a visitor’s browser. |
| CMW | Client malware — content that targets the site’s visitors. | Treat as a visitor-facing incident: reputation, browser warnings, and disclosure may follow. |
| INJ | Injection — malicious code added to an otherwise legitimate file. | Restore the file from a trusted source. Do not delete it; something legitimate depends on it. |
| SA | Stand-alone — the whole file is malicious. | The file has no legitimate purpose. Preserve a copy, then remove it once access is rotated. |
| BLKH | Blackhash — the file matched a known-bad hash. | A high-confidence identification of a specific known artifact. |
| HEUR | Not in CloudLinux’s published table of method codes. In practice it marks a heuristic rather than a signature match — a judgement about shape, not an identification. | Lower confidence, and the class most often dismissed. It still requires an explanation before it is cleared. |
| ELF, php, js and similar suffixes | The file type the detection applies to. ELF is a compiled Linux executable. | An ELF detection inside a hosting account is a different kind of event from an injected PHP file — see below. |
Real or false positive
Is it a false positive? How to decide without guessing
Both wrong answers are common: the internet is full of advice to whitelist heuristic detections wholesale, and equally full of people deleting legitimate binaries their own plugins installed. Work through the file instead.
- 01
Identify what the file belongs to
Trace the path. A binary under a plugin’s own directory — image-optimisation plugins ship gifsicle, optipng, and pngquant, for example — has an obvious owner. A file in a location no installed software claims does not, and that absence is itself the finding.
- 02
Compare against a trusted copy
For an INJ detection on a core, plugin, or theme file, download the same version from its official source and diff them. An injection shows up immediately and you get the exact inserted block as evidence. This single step resolves most detections on application files.
- 03
Check the timestamps against a deployment
A file modified during an update, a deployment, or an editor session you can account for is explainable. A file written at 03:00 on a day nothing shipped is not — and the modification window is what you will use to bound the rest of the search.
- 04
Ask whether the file type belongs there at all
A hosting account that serves web pages, mail, and configuration has no ordinary reason to contain a multi-megabyte compiled binary. Legitimate exceptions exist, but each one should have an owner you can name. “Probably fine” is not an owner.
- 05
Get a second opinion on the artifact, not on the category
Submit the specific file for independent scanning rather than searching for whether its detection name is generally a false positive. The general answer tells you nothing about your file.
- 06
Preserve before you resolve it either way
Record path, owner, permission mode, size, timestamps, and SHA-256, and keep a copy — whether you are about to delete it or whitelist it. A whitelisted file that turns out to matter is as hard to investigate later as a deleted one.
The case for not dismissing it
The detection everyone ignores was the one that mattered
The advice you will find most often for heuristic ELF detections is that they are noise — add them to the allowlist and move on. That advice exists for a reason: the detection genuinely does flag legitimate binaries, including plugin-bundled tools and, on some panels, the control panel’s own files. Enough administrators have been burned by it that the reflex is now to switch the whole category off.
On the 261-account WHM server documented in our incident report, that same class of detection — an Imunify heuristic ELF classification — was the only tool that flagged the actual backdoor. Wordfence reported 283 infected files and correctly described every one of them. The database export was completely clean. The thing that mattered was a packed x86-64 ELF binary sitting in a hidden folder in the account home directory, outside the web root, and the heuristic was right about it.
What the evidence does not establish is what happened to that detection on that server before we arrived — whether it was triaged as noise, allowlisted with the rest of the category, or simply never routed to anyone. Only that nothing in what the client saw led anybody to the file. That is the failure mode worth guarding against: not a scanner that missed something, but a correct detection that nobody acted on.
What clean does not mean
Why a clean result is a narrower statement than it sounds
A clean scan is evidence that the files ImunifyAV read did not match the patterns it knows. That is a useful statement and a much narrower one than “the account is clean”, let alone “the server is clean”. Several things sit outside it entirely.
- Signature and hash matching identifies known artifacts. A freshly built or repacked payload has no signature to match yet.
- It reads files. It does not read the running process table, so a process whose executable has already been deleted from disk leaves nothing for it to find.
- Persistence that is configuration rather than content — a cron entry, an SSH key in authorized_keys, a control-panel API token, a PHP startup directive — is not malware in a file and is not what the scanner is looking for.
- Stolen credentials are not a file at all. An attacker with your SFTP password does not need anything on disk that a scanner could detect.
- A per-account scan is a statement about one account. On a shared server, the neighbouring account with the same artifact is outside its scope.
- Database content is not covered by a filesystem scan — though note the inverse trap: a clean database alongside many modified files usually means the write capability lives outside the application, not that things are nearly fine.
What to do
The order that keeps your options open
- 01
Export the detection list before anything changes
Save the full list with paths, detection names, and timestamps. Quarantine actions and cleanups will change what you can see, and the original list is the only complete record of the starting state.
- 02
Resolve the INJ detections by restoring, not editing
Injected core, plugin, and theme files get replaced from official sources. Stripping the inserted lines by hand leaves the ones nobody flagged, and there are always ones nobody flagged.
- 03
Explain every SA and heuristic detection individually
Each stand-alone or heuristic finding needs a named owner or an escalation. This is where the real findings hide, precisely because it is the tedious part.
- 04
Use the timestamps to bound a wider search
The modification window from the detection list tells you what else to examine across the account — crontabs, dot-directories, SSH keys, PHP configuration — rather than scanning everything blindly.
- 05
Rotate credentials if anything is confirmed
A confirmed compromise means the account user’s credentials are in scope: control-panel login, SFTP, database users, application passwords, API tokens, and any SSH keys. Rotate from a device that is not part of the incident.
- 06
Only then clean, and verify after normal operation resumes
Re-check the account days later, once cron has run, caches have expired, and real traffic has returned. A cleanup verified in the minutes after it finishes has not been tested against the only thing that matters — whether anything comes back.
Common questions
Common questions about ImunifyAV detections
ImunifyAV flagged files but Wordfence says the site is clean. Which is right?
Both, probably. They read different things. Wordfence scans inside the WordPress installation; ImunifyAV reads the hosting account, including the home directory above the document root. A file flagged by one and not the other is usually a scope difference, not a contradiction — and the file outside WordPress is the more interesting of the two.
Can I just delete every file it flagged?
Not safely. An INJ detection means malicious code was added to a legitimate file, so deleting it removes functionality your site needs — restore it from a trusted source instead. Only SA detections describe files that are entirely malicious, and even those should be preserved before removal so the compromise can be understood.
My host says the account is clean now. Is the incident over?
Ask what was actually done: cleaned, quarantined, or just listed. Then ask what was checked beyond file content — crontabs, SSH keys, API tokens, PHP startup configuration, the process table, and the other accounts on the same server. A clean file scan does not cover any of those.
Should I turn off heuristic ELF detection? It keeps producing false positives.
No. Whitelist the specific files you have identified and can account for, and leave the category enabled. The case documented on this site is exactly why: that category produced the only detection that found a real backdoor, on a server where everything else came back clean.
The same files keep coming back after quarantine. What is happening?
Something is recreating them. The usual candidates are a cron entry, a PHP startup directive such as auto_prepend_file in a .user.ini, a running process, or a second compromised account on the same server. Quarantining the output does nothing about the generator — find the generator.
Is ImunifyAV enough on its own?
For detecting known file-based malware on a hosting account, it is a reasonable layer and better scoped than a WordPress-only plugin. It is not a server review: it does not examine the process table, account isolation, control-panel access, or the relationships between accounts on a shared server. Those need a root-level look.