Incident report: the hidden ELF backdoor on a 261-account WHM server

The client operates a single WHM server carrying 261 cPanel accounts — WordPress sites plus several high-volume WooCommerce shops. The engagement began when one of those shops started appearing as malicious in VirusTotal results, which is a revenue problem long before it is a technical one.

The first round of evidence looked conclusive. Wordfence reported 283 infected files on the affected site, spread across several plugin files and the active theme. ImunifyAV, running on the cPanel side, produced a comparable file-level picture. A full SQL export of the site database was searched for injected markup, encoded values, unknown administrators, and modified options — and came back clean.

That combination is the finding. A pure file-modification infection, with no database persistence, no rogue administrator, and no obfuscated PHP loader, means the attacker never needed WordPress-level persistence — because something outside WordPress already had permission to rewrite those files whenever it wanted.

It did. A 1,388,544-byte packed x86-64 ELF executable was staged in the cPanel account’s home directory at ~/.config/htop/defunct — outside public_html, in a hidden folder that belongs to a legitimate Linux process viewer. No WordPress scanner reads that path, and no database export contains it.

Nobody on the estate received a security alert first. The shop owner discovered the problem the way most owners do: a public reputation service flagged the domain, and the consequences — browser warnings, ad-platform rejections, nervous customers — arrived immediately.

The natural request at that point is “clean the 283 files so the listing clears.” On a single-site install that is sometimes the whole job. On a WHM server with 261 accounts, an infection that rewrote files inside several plugins and the active theme raises a different question, and it is the only question worth answering first: not which files were changed, but what had the ability to change them.

1. 01

   A shop was flagged publicly

   A WooCommerce store on the estate began showing as malicious in VirusTotal results — a reputational and revenue event that set the response clock, not a technical alert.

2. 02

   Wordfence scan

   283 files flagged on the affected site across several plugins and the active theme: widespread modification of legitimate files, not one isolated dropper.

3. 03

   ImunifyAV account scan

   The cPanel-side scanner returned a comparable file-level picture. Nothing in what the client saw pointed above the document root.

4. 04

   Database review

   A complete SQL export was searched for injected markup, base64 blobs, unknown administrators, unexpected autoloaded options, and scheduled events. It was clean.

5. 05

   Scope widened to the server

   With a shared WHM boundary, several revenue-critical stores, and a file-write capability nobody could account for, the engagement moved from site cleanup to server incident response.

A clean database export is usually reported as good news. In this case it was the strongest indicator that the investigation was not finished. Most commodity WordPress infections leave something behind in the database, because that is how they survive a file cleanup: an injected script in the options table, an extra administrator, a scheduled event that rewrites the dropper. None of that was present.

The absence of an obfuscated PHP loader pointed the same way. Injected PHP is how an attacker regains file-write access through the web application. If files are being rewritten and no such loader exists, the write capability is arriving from somewhere else — a compromised system account, stolen SSH or SFTP credentials, or a process running as the account user.

So the correct reading of “Wordfence: 283 files, ImunifyAV: same, database: clean” was never “almost clean.” It was “we have found the damage and none of the mechanism.”

Lockora Security Audit was used to get a fast, consistent posture and integrity picture across the WordPress installations — core file integrity, hardening state, component exposure, and a full user and capability review. Lockora is our own plugin, published in the WordPress.org directory; it is used in engagements like this one because it produces the same structured output on every site in an estate, which makes the outliers obvious.

What that audit produced was not the backdoor. It produced the elimination. Once core integrity, configuration, users, roles, and the database were all accounted for, the remaining explanation for repeatedly rewritten plugin and theme files was no longer inside WordPress. It was underneath it.

The rest of the work was a filesystem review from root SSH on the WHM server: enumerate what exists, bound the search by the time window the infected files provide, and look specifically for things that have no business being in a hosting account.

1. 01

   Establish a trusted vantage point

   Work from root SSH on the WHM server rather than from inside a single cPanel account, so the review is not limited by the permissions — or the visibility — of a user that may already be compromised.

2. 02

   Bound the time window

   Use the modification timestamps of the infected plugin and theme files to define a search window instead of scanning 261 accounts blindly. Everything written inside that window is a candidate.

3. 03

   Enumerate outside the document root

   Review the account home directory itself: dot-directories such as .config, .cache, .local, and .ssh, plus temporary and mail paths. These are the locations a WordPress scanner never reads and an owner never opens.

4. 04

   Look for executables where none belong

   A hosting account serving WordPress has no legitimate reason to contain a user-owned, multi-megabyte compiled binary. File type, size, permission bits, and creation date are enough to isolate it — no reverse engineering required.

5. 05

   Record before touching

   Capture the full path, ownership, permission mode, size, timestamps, and SHA-256 hash, and preserve a copy of the file, before any removal decision is taken. Deleting the only evidence turns the rest of the investigation into guesswork.

6. 06

   Classify with a second opinion

   Submit the artifact for targeted scanning and compare its path and characteristics against published research, rather than trusting a single signature match in either direction.

The file was not PHP, not a script, and not part of any installed application. It was a compiled Linux executable, deliberately placed in a directory that belongs to htop — a legitimate interactive process viewer whose configuration lives in ~/.config/htop on a normal system — and named to resemble a dead process entry in a listing.

The properties below are the complete set of observations retained from the review. The hash and path are published on purpose: they are indicators other administrators can check against their own servers.

The ~/.config/htop/defunct path is highly distinctive, and it is chosen for exactly the reasons that make it effective: htop is a legitimate tool, ~/.config is a legitimate hidden configuration directory, and “defunct” reads as a dead process entry to anyone skimming a listing. Nothing about the location looks like malware until you ask why a shared hosting account contains a compiled binary at all.

That path, combined with a packed x86-64 ELF of roughly this size in a hosting account, matches the Global Socket (gsocket) deployment pattern documented in Sansec’s malware research and in independent handler reports. On that basis the artifact is assessed with high confidence as a gsocket covert backdoor component.

gsocket itself is legitimate open-source software from The Hacker’s Choice. It establishes an end-to-end encrypted TCP session between two endpoints through a public relay network, addressed by a shared secret instead of an IP address and port. For an attacker holding a hosting account, that is close to ideal: no inbound port has to be opened, NAT and firewall rules are bypassed by design, and the traffic is encrypted and outbound, so a perimeter built around inbound rules never sees it.

Two observations argue against a fully activated channel at the moment of discovery. There was no defunct.dat — the paired file that commonly holds the shared secret — and no cron entry, shell profile, or startup reference invoking the binary. The plausible readings are that the capability was staged but not yet activated, that the launcher and key file were removed by an earlier partial cleanup or by the operator, or that activation used a route not preserved in the retained evidence. The available evidence does not settle which.

It is tempting to conclude that Wordfence and ImunifyAV underperformed. They did not. They answered the questions they are built to answer, and the backdoor sat outside those questions.

Wordfence is a WordPress plugin. It runs inside the WordPress installation, and its file scanning is oriented around WordPress core, plugins, themes, and PHP content in the document root. A compiled binary in the account home directory is not in scope, contains no PHP for pattern matching to match, and is not reachable over the web at all.

ImunifyAV runs server-side and can see the account home. When the file was scanned directly it did match — as SMW-HEUR-ELF. That classification is a broad heuristic meaning roughly “an ELF binary where one is not expected in a user home directory,” not a gsocket-specific signature. Heuristics of that class are well known for flagging legitimate binaries, which is precisely why they get triaged as noise, allowlisted wholesale, or switched off. What the retained evidence does not establish is which of those happened here — only that nothing in the client’s scan results led anyone to that file.

• WordPress security plugins are scoped to the WordPress installation; the account home directory sits above it.
• The ~/.config directory is hidden, so it does not appear in ordinary FTP or File Manager listings unless hidden files are shown.
• htop is legitimate software, so a ~/.config/htop directory looks like normal user configuration to anyone glancing at the tree.
• A compiled ELF binary contains no PHP, so PHP-oriented pattern matching has nothing to match on.
• Heuristic ELF detections are noisy by nature and are frequently dismissed, allowlisted, or disabled after false positives.
• The database is the wrong place to look for a backdoor that never needed WordPress in the first place.
• A per-site scan result is evidence about one document root — never about the server the document root sits on.

The mapping below describes behavior in shared vocabulary. It does not identify a threat actor, and it separates what was observed on disk from what the tool class is capable of. Where a mapping rests on the assessed identification rather than on observed execution, that is stated in the confidence line.

Every check below is read-only. Run them from a trusted device with root access, and preserve what you find — path, owner, permission mode, size, timestamps, and hash, plus a copy of the file — before deleting anything. A deleted artifact cannot be classified, and an unclassified artifact leaves you guessing about how far the compromise reached.

A match is not automatically this backdoor. Legitimate binaries do live in home directories on some systems, and heuristic ELF detections produce false positives. The point of the table is to tell you which observations deserve an explanation, not to declare every one of them malicious.

1. 01

   Preserve the artifact and its context

   Keep the binary, its hash, its timestamps, its ownership, and the surrounding directory listing. This is the only material that can later answer how far the compromise reached.

2. 02

   Isolate the affected account

   Restrict or suspend the account rather than the whole server where the business allows it, and remove the account user’s ability to execute binaries from its home directory.

3. 03

   Treat the account user as compromised

   Everything that user could reach is in scope: its document roots, its cron, its SSH keys, its mail, its databases. Everything it wrote since the artifact’s creation date is untrusted until it is verified.

4. 04

   Rotate credentials across the estate

   WHM and cPanel logins, SSH keys, FTP and SFTP accounts, database users, WordPress administrators and application passwords, API tokens, payment and shipping integrations, and deployment secrets — rotated from a device that is not part of the incident.

5. 05

   Rebuild the infected application files

   Replace WordPress core, plugins, and themes from verified sources rather than stripping injected lines. 283 flagged files is a rebuild, not an edit — and hand-editing leaves the ones nobody flagged.

6. 06

   Sweep every other account

   A backdoor in one account on a 261-account server is a server-level finding until the same method has been applied to the others. Shared owners, shared deployment routines, and shared backups are the priority order.

7. 07

   Close the enabling condition

   Establish how the account user could write to plugin and theme files at all, how a binary could be dropped and executed from a home directory, and whether account isolation on the server actually holds under test.

8. 08

   Re-check after normal operation resumes

   Verify after caches expire, cron runs, plugin updates apply, and traffic returns. That is the point at which an incomplete cleanup reveals itself — not the moment the homepage looks right.

Wordfence found 283 infected files and was right. ImunifyAV agreed at the file level and was right. The database export was clean and that was true. A cleanup built on those three results would have removed the visible damage, restored the shop, and cleared the public listing — while leaving a remote-access capability inside a hosting account that had write permission over every file it had just rewritten.

The finding came from one deliberately unglamorous step: looking outside the application, with root access, at the directories a site owner never opens. That step is the difference between a site cleanup and a server incident response, and on an estate of 261 accounts sharing one boundary it is not optional.

Client identifiers, domains, account names, and log excerpts are withheld from this report. The file hash and the path are published on purpose — they cost an attacker nothing and they let another administrator check their own server tonight.