The Importance of Regular Malware Scanning

Why website malware goes unnoticed

Most people picture malware as something that crashes a site or plasters it with warnings. In practice, compromised websites are often designed to stay quiet. Injected code may show spam links only to search engine crawlers, redirect only visitors arriving from search results, or activate only on mobile devices. The owner logs in, sees a normal homepage, and has no idea anything is wrong.

That silence is what makes regular scanning important. The longer an infection runs, the more damage it can cause: visitors exposed to malicious scripts, spam pages indexed under your domain, mail from your server flagged as spam, and browser or search engine warnings that can take time to clear even after cleanup. Scanning turns an unknown, open-ended problem into a known, fixable one.

What website malware typically looks like

Malware on web servers comes in a handful of recurring forms. Knowing them helps you choose tools and interpret results.

Many infections combine several of these. A backdoor is frequently the first piece, used to plant everything else and to re-infect the site after a partial cleanup.

External versus server-side scanning

There are two broad approaches, and they catch different things.

External (remote) scanning

An external scanner fetches your pages like a visitor or crawler would and inspects what comes back: injected scripts, known malicious URLs, spam keywords, unexpected redirects and blocklist status. It needs no server access, so it is easy to set up and useful for checking what the outside world sees.

Its limits are equally clear. It cannot see files that are not linked, dormant backdoors, malicious cron jobs or code that only triggers under certain conditions.

Server-side scanning

A server-side scanner inspects the filesystem, and sometimes the database, directly. It compares files against known malware signatures, flags suspicious patterns such as obfuscated code, and can check integrity against original versions of a CMS or plugin.

It is more thorough but requires access and some care: overly aggressive patterns produce false positives, and a scanner running on an already compromised server might be tampered with. Ideally you use both approaches together.

Building a practical scanning routine

How often you scan depends on the site’s complexity and risk. A brochure site with few changes needs less attention than an online shop with dozens of plugins. The schedule below is a reasonable starting point to adapt, not a fixed standard:

In addition, run an unscheduled scan after any of these events:

• Installing or updating themes, plugins or extensions, especially from unfamiliar sources.
• A disclosed vulnerability in software you run.
• Unexplained traffic changes, new pages appearing in search results, or reports of redirects.
• Someone leaving the team or a suspected credential leak.
• Hosting migrations or restores from backup.

Make scan results actionable

A schedule only helps if someone reads the output. Decide in advance who receives scan reports, how quickly they must review them and what counts as urgent. Send alerts to a monitored shared address or ticketing queue rather than one person’s inbox, so holidays and staff changes do not create blind spots. Keep a short log of each finding and its resolution; over time it shows which plugins, folders or processes cause repeated trouble.

It also helps to record a baseline after a confirmed clean state: the list of admin users, cron entries, file counts per directory and checksums of core files. Comparing against that baseline makes unexpected changes stand out, even when no signature matches. Tune noisy rules instead of ignoring them, since a report full of false positives quickly trains people to skip it.

Useful command-line checks

If you have shell access, a few simple commands complement dedicated scanners. They do not prove a site is clean, but they surface changes worth investigating.

# Files modified in the last 3 days under the web root
find /var/www/example -type f -mtime -3 -print

# PHP files inside upload directories (usually should not exist)
find /var/www/example/uploads -type f -name "*.php"

# Common obfuscation patterns (expect some false positives)
grep -rlE "eval[[:space:]]*[(]|base64_decode[[:space:]]*[(]|gzinflate[[:space:]]*[(]" /var/www/example

# Scheduled tasks for the web user
crontab -l -u www-data

Open-source tools such as ClamAV, together with signature sets aimed at web files, can automate signature scanning on Linux servers. Many CMS platforms also offer security plugins with integrity checks; for WordPress, for example, the official command-line tool can verify core files against checksums:

wp core verify-checksums
wp plugin verify-checksums --all

Treat any match as a lead, not a verdict. Legitimate code sometimes uses functions like base64 decoding, so review flagged files before deleting anything.

What to do when a scan finds something

A detection can be stressful, but a calm, ordered response works better than deleting files at random.

1. Preserve evidence. Take a copy of the affected files, logs and database before changing anything. It helps you find how the attacker got in.
2. Contain. Put the site in maintenance mode or restrict access if visitors are being harmed.
3. Rotate credentials. Change passwords and keys for hosting, FTP/SFTP, database, CMS admins, API tokens and, if any risk exists, your registrar and DNS accounts.
4. Clean from known-good sources. Replace core files, themes and plugins with fresh copies from the official source, or restore a backup taken before the infection, and remove unknown files and admin users.
5. Find and fix the entry point. Outdated software, a vulnerable plugin, weak passwords or exposed configuration are common causes. Without fixing it, re-infection is likely.
6. Rescan and request reviews. Scan again from inside and outside. If a search engine or browser flagged the site, use their review process once you are confident it is clean.

If the site handles payments or personal data, check your obligations around breach notification with a qualified advisor. This article is not legal advice.

Reducing the chance of infection in the first place

Scanning catches problems; hardening reduces how many there are to catch. The basics are well known but often skipped:

• Keep the CMS, plugins, themes and server software updated, and remove anything unused.
• Use unique passwords and multi-factor authentication for every admin and hosting account.
• Give accounts and file permissions only the access they need, and disable PHP execution in upload directories where possible.
• Serve the site only over HTTPS, ideally with HSTS.
• Keep regular, tested, off-server backups so you can restore a clean version quickly.

Account-level security matters too: an attacker who takes over your registrar can redirect the whole domain without touching the server. See the guide on securing your registrar admin account for that side.

Finally, document these hardening steps alongside your scanning routine so new team members inherit both, rather than relying on one person’s memory of how the site was secured.

Keeping an eye on the whole stack

Malware scanning is one part of operational hygiene alongside renewals, certificates and hosting. If you manage several sites, keep a single inventory of each domain, its host and its renewal dates so nothing falls through the cracks. TLDix hosting tracking can hold that inventory and send reminders, and the hosting lookup helps confirm where an older or inherited site actually runs before you start scanning it.