Four working back doors
Identical 35 KB file managers that let anyone upload files and run commands on the server.
administrator/templates/LlBKpbmJ.php + 3 copiesCase 001 · June – October 2026
In June 2026, a small-business owner’s websites started sending her visitors to scam pages. This is what was hiding inside them, how they were rebuilt without keeping a single line of the old code, and how the owner took control of them again.
01 22 June · What visitors saw
Her photos, her prices, her words — all still there. But depending on the site and the hour, a visitor got pop-up ads, a fake “Click Allow” page, a shopping site carrying a stranger’s affiliate code, or nothing but an error. And the login page she used to fix things had disappeared.
Swipe for all four →
02 April → 16 June · The silent part
Files planted in the sites were dated as far back as April. Working back doors — small programs that let an outsider upload and run anything — were in place by early May. Then, on 16 June at 09:33, all three websites were altered within the same seven seconds.
All three sites lived in a single hosting account. To visitors they were three separate businesses; to the server they were three folders in the same home. Once one was opened, all of them were.
File dates can be forged, so April is the earliest trace — not necessarily the start. How the attackers first got in can’t be proven from the files alone.
03 22 – 23 June · The first 48 hours
The first job wasn’t fixing anything. It was getting control back, and preserving the evidence exactly as it was — without ever letting the infected code run again.
The account’s recovery email belonged to a domain that no longer existed. Access came back through the hosting company’s support, the domain registrar and an old set of file-transfer credentials. No guessing, no “hacking back”.
Every file and every database from all three sites, over an encrypted connection: 103,105 files, about 2.5 GB.
Stored read-only with nothing allowed to run, outside any web server, never opened in a browser.
Malware and persistence checks on the machine used for the work came back clean.
04 23 June · Inside the files
The snapshot was compared, byte for byte, with the official core releases. 29,396 matched exactly. The other 73,709 included extensions, custom content and confirmed attack code. A mismatch alone does not mean a file is malicious.
Identical 35 KB file managers that let anyone upload files and run commands on the server.
administrator/templates/LlBKpbmJ.php + 3 copiesA disguised 60 KB program that spread the infection into new folders and fetched more.
media/vendor/joomla-custom-elements/js/index.phpFolders imitating a different website system, hidden inside the real one as cover.
wp-admin/ · wp-includes/ · wp-blog-header.php18,529 paths where the malware nested a folder inside itself — up to 26 levels deep.
…/pagination/pagination/pagination/wp/Listed in one site’s sitemap, so that search engines would find and show them.
sitemap: 10,460 foreign URLsServer logs show the hidden code executing on six different days in June — not just lying there.
error_log: 14 · 16 · 18 · 19 · 20 · 22 JuneThe host’s automatic scan had marked 440 files as cleaned. The back doors and the redirects survived it.
440 × “dangerous code removed”62 user accounts, nine with full control, none with two-factor login. Years-old webshop orders and a newsletter list were still stored on the server.
users: 62 · super users: 9 · 2FA: 0Real paths to the back doors. They sat in folders that look like ordinary parts of the site, often nested inside copies of themselves, where nobody browsing the files would think to look.
05 23 – 25 June · The decision
The audit found widespread changes, hidden back doors and damage left after an earlier cleanup. For this case, rebuilding gave us a clearer basis for trust. Only reviewed words and pictures were carried across. Other sites may be suitable for a targeted repair.
Find and remove the cause and remaining access. In this case, an earlier cleanup had left working back doors behind.
Starts from nothing. Only content that has been checked comes across, one piece at a time.
She had used the same editor for years and was wary of learning a new one. So before deciding, she tried the new editor on a copy of her own site. Then she chose it.
06 23 June → 2 July · Rebuilt from the blueprint
Each page was rebuilt one at a time from the evidence — layout, menus, text, spacing, the exact size and position of every picture — to preserve the familiar visitor experience while replacing the compromised implementation.
07 30 June · A new foundation
The old sites ran programs on the server for every visit, with a database behind them and 187 add-ons that all needed updating. The new ones are finished pages, delivered from a global network. Editing uses a separate sign-in. The editor, hosting accounts and dependencies still need to be maintained.
The public pages no longer need the old server or its database. Email stayed with its existing provider.
08 30 June → 1 July · The move
Her web addresses were pointed at the new sites while email kept flowing to the mailbox it always had. One old setting would have quietly taken the email along with the website — it was split off before the switch.
09 July → August · Checking the other doors
One of her email accounts had been signed into from abroad. The review identified seventeen accounts needing password and sign-in checks. And the old server still held leftovers in places no website uses.
The dated case record lists the account and old-server work below. It is not a current audit of every account.
17 accounts identified for password and sign-in checks
10 August · Cleaning up Google
The August case record reports 10,356 Google results for one site, with attacker pages in 967 of the 1,000 results sampled. Removed addresses were given not-found or gone responses, and the real pages received titles, descriptions and structured data. The animation illustrates the intended cleanup, not a measured search-ranking result.
Illustration. The spam titles are representative, not copied.
11 6 July → 14 October 2026 · The keys, handed back
She logs in with her email, changes a sentence or adds a photo, and presses Save. About a minute later it’s live — and every save is kept as a version that can be restored. She can change the words and the pictures. The editor keeps routine content changes separate from the page layout.
Animated example: a heading is typed into the editor, Save is pressed, and the live page updates.
12 July–October · Still looking after it
A newer edit was replaced by an older one just 0.6 seconds later. A deployment check was added to stop a stale build replacing a newer published save.
Old mail filters had thrown away legitimate messages. Suspicious mail now goes to a spam folder instead of disappearing.
One site moved to a new domain name, with mail routing and redirects arranged, and the search-engine change of address submitted.
↺ Summary
→ What this kind of work involves
Inspecting a site’s files, logs and accounts without running any of it.
Chapters 03 – 04Page by page, from the evidence, with nothing that can run carried over.
Chapters 05 – 07Plan domains, email, redirects and search settings together, and check them after the move.
Chapter 08Passwords, two-factor login, access keys, old accounts and leftovers.
Chapter 09Removing what an attacker left in Google, and getting the basics right.
Chapter 10An editor the owner can use, with routine changes kept separate from the layout.
Chapters 11 – 12If you’re not sure what is running underneath your own website, I’m happy to take a look.
Tell me about your website →