How a sophisticated attacker turned shared hosting infrastructure into a persistent phishing platform, and why system-level backdoors make traditional website cleanup impossible

In November 2025, our team at SecureWP received a request to investigate suspicious login activity on a WordPress site. On the surface, it looked like a standard compromise.
However, a deep forensic audit revealed something far more disturbing. This wasn’t a new infection. The client’s hosting account had been serving as a hidden banking fraud infrastructure for over three years, completely unbeknownst to them.

The Anomaly: The “Referer” That Revealed a Cluster-Wide Infection

The investigation began when the client noticed unrecognized admin login activity in November 2025. But when we analyzed the access_logs and external reputation data, the timeline didn’t align with a recent hack.

We discovered that the client’s account had been harboring malware since at least 2022.

How did this go unnoticed for three years? The client’s primary websites were hosted as “Add-on Domains,” with their files located outside the main public_html directory. This left the default public_html folder empty and unused by the client.

The attacker seized this opportunity. They planted a sophisticated phishing kit inside this abandoned public_html directory. Because the client never used or checked this folder, the malware remained invisible to them.

The “Smoking Gun”: The most damning evidence came from Google Safe Browsing records. We found multiple blacklisting entries dating back to March 2022. Crucially, Google hadn’t just blacklisted a domain; they had blacklisted specific URL paths that included our client’s username:

This proved that while the phishing pages were being viewed through other domains on the server, the malicious files were physically hosted on our client’s account and had been for years.

Technical Analysis: The Backdoor Mechanism

While the public_html folder hosted the phishing content, the attacker needed a way to maintain access even if the passwords were changed. They achieved this by compromising the server’s operating system itself.

1. The .bashrc Persistence Method

The attacker targeted the .bashrc file, a standard Linux configuration script that runs automatically every time a user logs in.

The file contained a line of code designed to look like a harmless system comment:

To an untrained eye, this appears to be a random number generator seed. However, decoding the Base64 string revealed a malicious payload that executed the following logic:

  1. Check Process: It checks if a process named “defunct” is already running.
  2. Launch Stealth Process: If not, it launches a binary from a hidden directory: /home/[username]/.config/htop/defunct.
  3. Mask Identity: It uses process name masking to disguise the malware as [slub_flushwq], a legitimate Linux kernel process name.

This command executed silently, suppressing all error messages, and ensured webs-hell back connect was re-launched every time the account owner or a legitimate admin logged in.

2. Weaponizing LiteSpeed Defaults

The server was running LiteSpeed Web Server, which maintains compatibility with Apache features, including mod_userdir. By default, LiteSpeed often keeps this feature enabled (allowing access via http://server-ip/~username/), and the hosting provider failed to disable it for this shared environment.

This oversight allowed the attacker to configure dozens of other compromised websites on the same LiteSpeed cluster to load content directly from our client’s infected public_html folder.
This architecture was ingenious:

  • The Client (The Host): Unknowingly hosted the malware in an unused folder. Their actual live sites (Add-on domains) remained clean and untouched, raising no alarms.
  • The Neighbors (The Proxies): Other websites on the same server were used to display the content. If one neighbor domain got blacklisted, the attacker simply rotated to another neighbor, all while the phishing software remained safely hidden in our client’s account.

Why This Method is Particularly Dangerous

This specific attack architecture rendered standard security practices useless.

  • Invisible to WordPress Plugins: Because the backdoor resided in the .bashrc file (the operating system layer), no WordPress security plugin could detect it.
  • Survives “Clean” Reinstalls: Even if you deleted every file in the public_html folder and reinstalled WordPress, the .bashrc backdoor would remain active, allowing the attacker to reinfect the site instantly.
  • Bypasses Password Changes: Changing the WordPress admin password or the hosting account password does not stop a running system process. The attacker maintained a persistent connection regardless of credential updates.
  • Mimics System Processes: By naming the malicious process [slub_flushwq], the attacker hid in plain sight. Most administrators glancing at a process list would assume it was a standard kernel operation.

Why Detection Took Three Years

This breach went undetected from 2022 to 2025 due to a “perfect storm” of sophistication and negligence.

  1. Legitimate Disguise: The attacker used “Add-on Domains” to keep the main public_html directory empty, ensuring the client never saw the malicious files.
  2. Hosting Provider Negligence: The hosting provider ignored years of Google Safe Browsing blacklists targeting their IP range. They also failed to monitor for cross-account file access, a clear indicator of a mod_userdir exploit.
  3. Shared Hosting Blind Spots: In a shared environment, customers cannot see the running processes of other users. The client had no way of knowing their account was being accessed by neighbor domains.
  4. No System Integrity Checks: A simple file integrity scan of .bashrc would have flagged the modification immediately. The hosting provider did not perform these scans.

The Solution: Secure Migration

Because the compromise was rooted in the operating system, cleaning the website files was impossible.

We executed a secure migration strategy:

  1. Forensic Preservation: We documented the logs and .bashrc payloads as evidence.
  2. Clean Build: We deployed a fresh WordPress installation on a secure, verified hosting environment where mod_userdir is disabled and account isolation is enforced.
  3. Selective Migration: We moved only the clean Add-on domain content, leaving the infected public_html directory and system files behind.
  4. Hardening: We implemented Web Application Firewalls (WAF) and strict file integrity monitoring.

Since the migration, the client has operated since now with zero security incidents.

Key Takeaways for Website Owners

This case highlights a critical reality in WordPress security: your site is only as secure as the server it lives on.

  1. Audit Unused Directories: Attackers target “abandoned” folders like public_html. Ensure they are empty if unused.
  2. Check Your Reputation: Search for your hosting username or IP in blacklist databases. You might be a “sleeper” host for a phishing network.
  3. Audit Your Hosting Provider: Ask specifically if they use LiteSpeed and if mod_userdir is disabled. If a neighbor site can load your files, your security is compromised.
  4. Demand System-Level Security: Ask your provider if they scan system files like .bashrc for unauthorized modifications.

 

Is your WordPress site experiencing persistent issues? If you suspect your hosting environment is compromised, do not rely on automated cleaners. Contact SecureWP for a comprehensive forensic assessment and secure migration