How websites actually get hacked

When a small business website gets compromised, the owner's first assumption is usually that somebody chose them. A competitor, a disgruntled ex-employee, somebody who took offense.

It's almost never that. The overwhelming majority of website compromises are fully automated, and your business wasn't part of the decision.

What actually happens

Software scans the internet continuously looking for specific things: a particular plugin at a particular version with a published vulnerability, a login page that will accept unlimited password attempts, an exposed configuration file, a server running an unsupported version of something.

When a vulnerability is disclosed publicly, the details are available to everybody at once, including the people writing the scanners. Exploitation of newly published website vulnerabilities typically begins within days, sometimes within hours, because the work of finding vulnerable sites is done by machines rather than by people.

Your site isn't interesting to them. Your server is. It can send spam, host phishing pages, mine cryptocurrency, redirect your visitors somewhere profitable, or simply be sold as access to somebody who has a use for it.

The actual entry points, in order

1. A known vulnerability in something you installed

The cause behind most of the compromised sites we're called to look at, by a wide margin, and the same picture the major vulnerability trackers publish each year. Not core software, which is generally well maintained and updated automatically, but the plugins, themes and modules added on top of it.

The pattern is consistent: a vulnerability is disclosed, a patch is released, and a large number of sites don't apply it. Some because nobody is watching. Some because the plugin has been abandoned and there's no patch. Some because the site owner is afraid an update will break something, which is a reasonable fear addressed by staging rather than by not updating.

2. Credentials

Reused passwords that appeared in somebody else's breach, weak administrator passwords, or an account belonging to a former employee that was never removed. Automated login attempts run against every WordPress site continuously, regardless of size.

3. A compromised computer belonging to somebody with access

Malware on a developer's or an administrator's machine harvests saved FTP and hosting credentials. The website was never attacked at all; the credentials were simply collected and used.

4. A neighbor on shared hosting

On poorly configured shared hosting, a compromise of one site on the account, or occasionally on the server, can spread sideways. This is why cleaning one site on an infected hosting account is temporary work.

5. Everything else

Genuinely novel attacks against a specific small business exist and are rare. If you're in that category you generally know why.

What compromise looks like from the outside

• Visitors redirected somewhere else, often only on mobile, or only when arriving from a search result, which is why the owner sees nothing wrong
• Search results for your domain listing pages you've never seen, often pharmaceutical or gambling copy in a language your business doesn't operate in
• A browser warning shown to visitors, which usually means a reputation service has flagged the site: Google Safe Browsing for Chrome, Firefox and Safari, Microsoft SmartScreen for Edge. They're separate lists with separate review requests, so check both. A certificate error looks similar and means something else entirely
• A hosting account suspended, usually for outbound spam or resource abuse
• New administrator accounts, or an existing account with a changed email address
• Bounce messages arriving for email you never sent

Note how many of these are invisible to the owner. Cloaking, which shows one version of a page to search engines and another to humans, is standard practice in this kind of attack precisely so the site owner doesn't notice.

What actually prevents it

In rough order of how much risk each one removes for the effort involved:

1. Patch promptly. Not eventually. The window between disclosure and automated exploitation is short, so the useful measure is how quickly you apply an update rather than whether you eventually do.
2. Remove what you don't use. WordPress will not run a deactivated plugin's code, but the files are still sitting on your server and can still be requested directly, which is exactly what a scanner does. Delete rather than deactivate.
3. Real passwords, and two-factor authentication on administrator accounts. WordPress needs a plugin for this. It removes most of the second entry point, though it's worth confirming your chosen plugin also covers XML-RPC and application passwords, because several don't.
4. Fewer, better maintained components. Check when a plugin was last updated before installing it, and again occasionally afterward. Abandoned plugins are permanent liabilities.
5. Least privilege. Not everybody needs an administrator account. Most people who have one don't need it.
6. Backups stored somewhere the web server can't reach. A backup on the same server gets encrypted or deleted along with everything else.
7. Supported versions of everything. Including PHP, which people forget is software with a support lifecycle.

Where security plugins fit

They're useful and they aren't a strategy. A security plugin runs inside the application it's protecting, which is a structurally weak position: if the application is compromised, so is the plugin.

The bigger problem is that they create confidence. A dashboard with a green tick on a site running an abandoned plugin from 2021 is worse than no dashboard at all, because somebody has now been told it's fine.

If it has already happened

Two things matter more than speed.

First, stop touching it. Everything you need to work out how they got in is sitting on the server right now, and most of it's destroyed by the instinctive first response, which is to start deleting things that look wrong. Take a full copy of the files, the database and the access logs before anything else happens, and keep it somewhere separate.

Second, treat cleaning and fixing as two different jobs, because they are. Removing the injected files restores the site to how it looked last week, including the part that let somebody in. Cleanup without a diagnosis buys you roughly the interval between one scan and the next.

The part nobody wants to hear

There's no configuration that makes a website permanently safe, and anybody selling you one is describing something they can't deliver.

What you can do is stop matching the pattern: current, minimal, properly credentialed, backed up somewhere the web server can't reach, and watched by something that notices when files change. None of that will impress anybody in a meeting. It's most of the actual answer.