Where to start when a site has been compromised

Compromised sites often have more than one vulnerability, so fixing a single issue may not be enough. After you find and patch one problem, keep looking for others. A good first step is to review the most common ways spammers successfully attack websites.

To investigate properly, you'll need administrator-level shell or terminal access to your web, database, and file servers. You should also be comfortable with shell commands, able to read code such as PHP or JavaScript, and prepared to run two separate antivirus scanners.

Before running any scanner, be aware that vulnerability scanners are not the same as antivirus scanners. Vulnerability scanners are more invasive and can cause unintended damage, so follow all instructions—such as making a full backup—before using one.

Check administrator machines for malware

If an administrator's computer is infected, a hacker may have installed spyware that records keystrokes, capturing login credentials for your site. Run several reputable antivirus (AV) scanners on every machine used to sign in to the site, as well as on the web server and any devices used to update content. No single scanner is foolproof against new malware, so multiple scans reduce false positives and give you more data points.

If a scanner finds spyware, a virus, a trojan horse, or another suspicious program, examine the server logs for activity tied to the administrator who owns that machine. The hacker may have tampered with the logs, but if they haven't, matching the administrator's username to unusual commands in the log is strong evidence that the infection led to the breach.

Look for weak or reused credentials

Weak passwords are easy to guess, and reused passwords become worthless after a single breach elsewhere. A strong password mixes letters, numbers, and punctuation, and avoids dictionary words or slang. Each application should have its own unique password.

Scan the server logs for repeated login attempts targeting an administrator account, or for an administrator executing unexpected commands. Note the timestamps of any suspicious activity—knowing when the hack began helps you determine which backups are still clean.

Verify software is current

Check that the operating system, content management system, blogging platform, and every application or plugin running on the server is at the latest version. Search the web for security advisories tied to the exact versions you have installed. If a known advisory matches, outdated software is a likely entry point. Even if it isn't the culprit, keeping software current is a necessary best practice going forward.

Inspect for permissive coding practices

Open redirects

An open redirect is a URL structure intended to let users reach another page or file on the site, but it can be abused to send them to an attacker's destination. A legitimate example looks like this:

http://example.com/page.php?url=http://example.com/good-file.pdf

An abused one might point to a malware site:

http://example.com/page.php?url=malware-attack-site>

If Search Console flagged example URLs that redirect to undesirable destinations, your site is likely being exploited this way. To prevent it, check whether your software has open redirects enabled by default, whether your code can block off-domain redirects, and whether you can sign redirects so only properly hashed, cryptographically verified URLs are allowed through.

SQL injections

SQL injection occurs when a hacker inserts rogue commands into user input fields and your database executes them. This can update records with spam or malware content, or dump valuable data to the attacker. If your site uses a database—and especially if the site was hit with malware—an injection is a real possibility.

Log into the database server and look for suspicious content in ordinary text fields, such as embedded iframes or scripts. For any questionable values, verify that user input is validated, properly escaped, or strongly typed so it cannot be executed as code. If input reaches the database unchecked, SQL injection is very likely the root cause.