How sites actually get compromised, and how not to be the easy one.
In security the assumed cause is usually 'nothing is wrong'. Here is how sites actually get compromised, why the top of that list is preventable, and how a fix is proven shut from the outside.
In this article 4 sections
- In security, the assumed cause is 'nothing is wrong'. Most people don't know they've been breached.
- Our monitoring and threat-intelligence feeds are wired to open the ticket, so the first message is usually ours. Catching it first is the job.
- Sites get compromised in boring ways. Outdated software and things left unintentionally open lead the list, and both are exactly what an audit before go-live and continuous patching catch.
- Finding the breach is only half of it. When we close one, we prove the door is shut by re-attacking from an address we don't trust. If we can still reach it, it isn't fixed.
There's a tell in every security call. The customer's assumed cause is usually the worst one there is: nothing is wrong. They didn't call because something looked off. They called because we told them. By the time a breach is visible to the person who owns the site, it has usually already happened.
In security, the assumed cause is 'nothing is wrong'
“In security, the customer's assumed cause is usually 'nothing is wrong'. They didn't know they were breached.”
That is the whole difference. Not that breaches don't happen. They do, on every platform, to every kind of site. The difference is who sees it first: a detection layer watching for the signatures of a compromise, or a threat-intelligence feed flagging traffic that shouldn't exist, while the site's own dashboard still reads green. Our monitoring and those feeds are wired to open the ticket, which is why the first message is usually ours.
How sites actually get compromised
Strip away the movie version and the ways sites actually get compromised are boring, and they repeat. Here's the ranking, most common first. None of the top of this list is clever.
Outdated or end-of-life software
The most common way in, by a wide margin. An app running a publicly known vulnerability, exposed to the internet, years behind on patches. Internet-exposed and years behind on patches is all it takes. The exploit is off the shelf. No cleverness required.
Something left unintentionally open
No exploit needed. The door was just open. A data store bound to every network interface with no authentication. A world-readable config or debug file. A CMS leaking its usernames over an open API. A forgotten staging subdomain still answering. Nobody broke in. They walked in.
The origin reachable behind the CDN
The site sits behind a CDN, but the real server still answers directly if you can find it, and its address is often sitting in the domain's own mail DNS. The front door is guarded while the back door is propped.
Credential brute-force with no Layer-7 defense
A login page with nothing in front of it at the application layer, hammered until something gives. A Layer 3/4 firewall waves this straight through: to a port filter, it looks like normal traffic to a port that has to stay open.
Weak, reused, or exposed credentials with no MFA
A password that leaked somewhere else, reused here, with no second factor to make it useless. The lock was fine. The key had already been copied.
Outbound spam from an already-compromised account
Often the first outward sign of a breach that already happened. The account isn't the target. It's the launch pad, and the spam is the smoke, not the fire.
Phishing and social engineering
The human layer. No software bug involved. Someone was simply convinced to hand over the keys.
Look at the top two. Outdated software and things left unintentionally open. Neither is a clever attack. Both are exactly what a disciplined audit before go-live and continuous patching catch before anyone tries the handle. That's the entire case for managed security. Most break-ins aren't broken into. They're walked into. And the walk-in is preventable.
Catching it first is the job. Proving it's shut is the difference.
Finding the breach is half the job. The half almost nobody does is proving the fix actually held. When we close a compromise, we don't take the dashboard's word that the port is shut. We re-attack the origin the way an attacker would: from a box in another of our datacenters, on an egress the firewall was never told to trust. If our own scanner can still reach it, it isn't fixed. Only when the door is shut from the outside, from an address we don't trust, do we call it closed.
“The job isn't just fixing the breach. It's catching it first, and then proving from the outside that the door is shut.”
That method, re-attacking your own origin from an untrusted vantage and confirming what an attacker would actually see, is its own discipline, and it gets its own post. We prove it's shut from the outside walks the full playbook.
Seven ways to not be the easy one
None of the top of that taxonomy needs a genius attacker. Which means most of it is preventable by not being the easy target. Seven habits, in the order they pay off.
Patch or retire
If it's internet-exposed and unmaintained, it's a liability. Update it or take it down. There's no third option that ends well.
Assume the origin will be found
Lock it to the CDN's IP ranges so only the CDN can reach it, and stop leaking its address in your mail DNS. A hidden origin isn't hidden if your own DNS announces it.
An L3/4 firewall is not a WAF
Port filtering doesn't read requests. Brute-force, injection, and app-layer abuse all ride through on ports you have to leave open. You need a defense that inspects Layer 7.
Audit before you declare done
'It works' is not 'it's closed.' Check what's exposed, what's world-readable, what's still bound to the public internet, before go-live, not after the notice arrives.
Assume credentials leak. Make them useless off-whitelist.
MFA everywhere, and bind the sensitive paths to known addresses. A stolen password should open nothing on its own.
Watch the watcher
Monitoring that goes blind and still reports green is worse than no monitoring, because it buys false calm. Confirm the detector can actually see.
Prove the fix from the outside
The only test that counts is the attacker's-eye view. Re-attack from an address you don't trust and confirm the door is shut.
Straight answers
How do websites actually get hacked on managed hosting?+
Mostly two boring ways. Outdated or end-of-life software running a publicly known vulnerability while exposed to the internet, and things left unintentionally open: a data store with no auth, a world-readable config file, a forgotten staging subdomain. Clever exploits are far down the list. Most break-ins are walk-ins.
How would I even know if my site was breached?+
Often you wouldn't, and that's the point. Our monitoring and threat-intelligence feeds are wired to open the ticket, so the first message about a compromise is usually ours. The assumed cause on the customer's side is usually 'nothing is wrong.' Outbound spam or a third-party notice is frequently the first outward sign, and by then it has already happened.
Is my server secure if it has a firewall?+
A firewall at Layer 3/4 filters ports; it doesn't read requests. Credential brute-force, injection, and application-layer abuse all travel over ports you have to leave open, so they look like normal traffic to it. A firewall is not a WAF. Stopping those needs a defense that inspects Layer 7.
Can attackers find my origin server if it's behind a CDN?+
Frequently, yes. The CDN only helps if the origin can't be reached directly, and the origin's real address often leaks in the domain's own mail DNS. Lock the origin to the CDN's IP ranges and stop announcing it in DNS, or the guarded front door has the back door propped open.
On managed hosting, who's responsible for patching my apps?+
The platform and the application are different jobs, and the gap between them is where sites get compromised. We keep the platform hardened and audit before go-live. But an end-of-life app running a known vulnerability is a shared risk. The managed value is that a disciplined audit before go-live and continuous patching catch most of it before anyone tries the handle.
Not sure what is exposed? Ask before someone else finds out.
Bring it to an engineer, not a ticket queue. We check what is reachable from the outside and tell you plainly what to close, then prove it is shut.
Talk to an engineerYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer