How to Check a Site for Malware and Close Security Holes

Site owners are usually the last to learn their site has been hacked. First Google flags the resource as dangerous, then the host suspends the account for sending spam, and only then does a customer write: “there is some casino ad popping up on your site”.

The unpleasant part is that most infections could have been spotted earlier — nobody was looking. Below is a check that takes ten minutes and needs no server access, plus the order of actions if the infection has already happened.

How sites actually get hacked

Forget the hacker deliberately targeting you. In 95% of cases it is more mundane: bots continuously crawl the internet testing sites for known vulnerabilities. They find an outdated plugin and upload malicious code. The site is then used not against you but as a resource: for sending spam, redirecting visitors to affiliate pages or hidden mining.

The three most common doors they come through:

• An outdated plugin or theme. The most common route in WordPress. A vulnerability is published and within hours bots are testing every site in the world.
• A stolen password. Often not from your site but from another service where you reused it. Or from an infected computer, through an FTP client that stores passwords in plain text.
• An exposed system file. More on this below — an underrated and very cheap way in.

Step 1. Scan the code for malicious signatures

Open the malware scanner and paste your address. The tool analyses the homepage code for typical infection markers:

• eval(atob(...)) — execution of encoded code. A normal site almost never contains this;
• hidden iframes of zero size — the classic way to load somebody else’s page invisibly;
• cryptocurrency miners that load the visitor’s processor;
• obfuscated JavaScript with variables such as _0x4f2a — code deliberately made unreadable;
• redirects to third-party domains through window.location.

It is important to understand the limits of such a check. We only see what is served externally. Malicious code can hide in server files, in the database, or be shown selectively — only to search crawlers or mobile visitors, so the owner notices nothing. A clean result therefore means “no obvious signs”, not “the site is definitely clean”.

Step 2. Check whether system files are publicly reachable

This is what we find more often than viruses, and it gives an attacker more than any hack.

The same tool tests typical paths. The two most dangerous:

The .env file — it usually holds database passwords, payment system keys and API tokens in plain text. If it opens by direct link, nothing needs breaking: a person simply opens the URL and reads your keys.

The .git/config directory — it lets somebody reconstruct your entire source code along with its change history. And that history often contains passwords that were committed once and later deleted: gone from the working copy, still in the history.

Alongside those, the scanner checks wp-config.php.bak, backup.zip, dump.sql, phpinfo.php and directory listing. Each of these is its own story about “put it there temporarily and forgot”.

If something turns up, block it at web server level immediately rather than just renaming it: bots try name variations too.

Step 3. Look at your security headers

The security headers check shows which protective mechanisms are enabled. The four that matter most:

The first three switch on with a few lines of server configuration and break nothing. CSP is more powerful but needs care: an overly strict rule will disable your own analytics or chat widget. Start in report-only mode, see what lands in the log, and only then enable blocking.

Step 4. Check the SSL certificate

The most mundane outage of all: the certificate expired and browsers now show visitors a red warning page. The site is alive, but nobody will enter it.

The SSL check shows the issuer and days remaining. Set a reminder two weeks before that date — even Let’s Encrypt auto-renewal occasionally breaks after a server configuration change, and you find out from your customers.

Step 5. Put passwords and access in order

The weakest link is almost always here. The minimum worth doing:

• Remove the admin account — that is the first username bots try. Create a new administrator with a different name and delete the old one.
• Replace any password that matches one you use elsewhere. Strong ones can be produced with the password generator.
• Enable two-factor authentication in the admin panel if your CMS supports it.
• Review the user list. An extra administrator you did not create is the clearest sign the site is already compromised.
• Password-protect staging versions at server level. The .htpasswd generator does this, and it also keeps drafts out of search indexes.

What to do if the infection already happened

The order matters. The most common mistake is starting with file cleanup while leaving the attacker’s access intact: a day later everything returns.

1. Change every password. Hosting, FTP, SSH, admin panel, database. This comes first, because infections usually start with stolen access.
2. Restore a clean backup made before the infection date. How to set up backups so such a copy always exists is covered in our article on website backups.
3. Update the CMS and every extension. Skip this and you will be hacked the same way next week.
4. Review the admin user list and delete accounts that are not yours.
5. Check scheduled tasks (cron) — attackers routinely leave a script there that restores the infection.
6. Submit the site for review in Google Search Console if it was flagged as dangerous. Without this the browser warning stays even after cleanup.

If you cannot manage it yourself, that is a perfectly normal reason to call in specialists. Cleaning an infected site without experience often ends with parts of the working functionality being deleted along with the malware.

Checklist: ten minutes once a month

1. Malware scan — signatures and exposed system files.
2. Security headers — at least HSTS and X-Frame-Options.
3. SSL — more than two weeks until expiry.
4. Admin user list — nobody extra.
5. CMS and plugin updates — everything current.

It costs no time, and it finds the problem before Google does. The remaining checks — speed, indexability, email — live in our catalogue of 43 tools.

If the site is already behaving strangely and working it out alone is hard, get in touch and we will take a look.