If you're reading this because your site is defaced, blacklisted, sending spam, or just "acting weird" — you're not alone, and you're not the first. Our incident response team cleans up compromised hosting accounts and servers every month. Below are five real cases, with names, domains, and identifying details removed, that show the patterns we see over and over, and what actually fixes them versus what just buys a few weeks before reinfection.
Case 1: The reinfection loop nobody could explain
A mid-sized reseller hosting account kept coming back infected within days of every cleanup. Three cleanups, three reinfections. The scanner kept flagging the same malware signature, and the client assumed their host's malware scanner was broken.
What we actually found: the original break-in had planted a backdoor script disguised as a caching plugin file, but the real persistence was a set of leaked account credentials that never got rotated after the first incident. Every cleanup removed the malware but left the front door key in the attacker's pocket.
The fix: full credential rotation (hosting panel, database, SSH/SFTP, and any API keys stored in config files) at the same time as malware removal, not after. Removing malware without rotating credentials is like changing the locks but handing the burglar a copy of the new key.
Lesson: if you keep getting reinfected after cleanup, the malware isn't your real problem — an untouched credential or a forgotten admin account is.
Case 2: No firewall, no backups, and a brute-force that had been running for months
A routine server audit for a new client turned up something alarming: there was no firewall configured at all — every service was directly reachable from the internet — and there hadn't been a working backup in over two months. Log analysis showed sustained brute-force login attempts against SSH and the database port, day and night, for weeks before anyone noticed.
What saved this one: we caught it during a proactive audit, before the brute-force succeeded. Not every case is this lucky.
The fix: a properly configured firewall restricting access to only the ports and IPs that need it, rate limiting on login attempts, and a verified, tested off-site backup schedule — because a backup you've never restored from isn't a backup, it's a hope.
Lesson: the absence of an incident is not the same as the absence of risk. If you don't know when your last successful backup restore test was, you don't actually have backups.
Recognize any of these symptoms?
Think Your Site Might Be Infected?
WordPress or Laravel malware removal, full credential rotation and hardening included — a flat fee, one-time, not a $200+/year subscription.
Check My Site — From $59 →Case 3: A RAT hiding in plain sight
One of the more unsettling cases involved a server that had been quietly compromised for weeks by a remote access trojan (RAT) — malware that gives an attacker persistent remote control, not just a defacement or a spam script. It survived a routine reboot and several surface-level malware scans because it was designed specifically to blend into normal system processes.
What we actually found: by the time we were engaged, the same disk that hosted the site had also failed, and the only backup available had died on the exact same day as the disk. Full data loss was narrowly avoided by rebuilding from an older secondary source.
The fix: deep forensic scanning, not just a surface plugin scan, a full OS reinstall rather than "cleaning" a rootkit-level infection in place, and a second, independent backup location that doesn't share a failure point with the primary server.
Lesson: if your only backup lives on the same box as your website, you don't have a backup strategy — you have a single point of total failure waiting for a bad day.
Case 4: Root compromise, twice, because nothing was rotated
A server suffered a full root-level compromise. It was cleaned. It was compromised again. Both times, the same root password and the same firewall configuration were still in place after the "fix," because the cleanup addressed the symptom (malicious files, rogue processes) without addressing the actual attack surface (weak or reused root credentials, no firewall management layer).
The fix: a root compromise isn't a file-cleanup job, it's a rebuild-and-rotate job. Full credential rotation across every privileged account, a firewall/security layer that survives a reboot, and a clean reinstall of anything the attacker had root access to, because you can't fully trust any file on a box the attacker owned.
Lesson: if a server was ever root-compromised, "we removed the bad files" is not the same as "the server is secure again."
Case 5: The undocumented backdoor account
During cleanup of a server that had suffered repeated intrusions, we did a full audit of every account with SSH access, not just the ones the client remembered creating. Buried in the list was a third authorized key, under an innocuous-looking name, that nobody on the client's team recognized or had created. It had almost certainly been planted during an earlier compromise as long-term, low-visibility persistence.
The fix: a full authorized-keys and user-account audit on every server that's ever had a security incident, not a spot-check, an exhaustive one, followed by locking down SSH access to known keys and IPs only.
Lesson: attackers don't always come back through the same door they used the first time. If a server was ever compromised, assume they left themselves a spare key somewhere until you've proven otherwise.
The pattern across all five
Every case above has the same shape:
- Malware or unauthorized access is found and removed.
- The reason the attacker got in — a leaked credential, an open port, a missing firewall rule, an untested backup, a planted account — is left untouched.
- Weeks later, it happens again.
Removing malware is the easy 20% of the job. The other 80%, credential rotation, firewall hardening, backup verification, and a full access audit, is what actually stops it from coming back. Most cheap "malware removal" services only do the first 20%.
Where the actual fix comes from
Prevent this from happening again
Hosting That's Hardened by Default
Our managed WordPress hosting runs every site in a read-only document root, so a compromised plugin can't write a new PHP file anywhere PHP would execute it. Roughly 49,000 malware signatures re-scan every 5 minutes, and xmlrpc.php, wp-config.php and PHP execution inside uploads are all blocked at the firewall by default.
See Managed WordPress Hosting →How our Malware Removal & Server Hardening service works
If your site or server is compromised right now, here's exactly what we do, in order:
- Triage — confirm the scope: is it a single hacked website, a full account, or root-level server access?
- Forensic scan — identify every malicious file, backdoor, and unauthorized account, not just the one signature your scanner flagged.
- Clean or rebuild — surface-level infections get cleaned in place; root-level or rootkit-level compromises get rebuilt from a clean base, because you can't fully trust an owned system.
- Full credential rotation — every password, API key, and SSH key touched by the compromised environment.
- Hardening — firewall rules, rate limiting, and access restrictions so the same door doesn't open twice.
- Backup verification — confirmed, tested, off-site backups so a future incident, or a dying disk, isn't a total-loss event.
- Post-cleanup monitoring — we don't disappear after step 6. We watch for reinfection signals for a defined period after cleanup.
If you're dealing with any of the symptoms above, reinfection after cleanup, a blacklisted domain, unexplained server load, or just a gut feeling that something's off, talk to our security team before it gets worse.
Some technical details in the cases above have been generalized and identifying information removed to protect client confidentiality. The failure patterns, attack techniques, and remediation steps described are accurate representations of real incidents we've handled.
