Engineering Case Study
Recognizing a Web Shell Before You Know What It Is
The site wasn't one we managed. We were brought in to look at it, and the first thing I did was pull it to a local environment.
Something was wrong before I could name it. There was a theme installed that we hadn't put there. The folder name was strange — not the kind of name a legitimate theme developer uses. The folder date didn't match anything else on the site.
I opened it. The first file was called database.php.
That combination — unfamiliar name, suspicious date, a file called database.php sitting at the root of a theme folder — was enough. Before I confirmed what I was looking at, I knew it wasn't supposed to be there.
It was an AnonSec web shell. A full attacker control panel embedded inside what appeared to be a WordPress theme: file browsing, shell command execution, mass defacement tools, persistence mechanisms. Anyone who had placed it there had complete control of the site.
The immediate response was straightforward: change all passwords, perform a malware scan, remove the theme. We documented the incident thoroughly before remediation — the structure of the shell, the capabilities it exposed, the indicators of how it had been placed. Deeper forensic investigation is available to the client if they want it.
The likely entry point was a vulnerability in a plugin, though a user upload couldn't be ruled out entirely. That uncertainty matters: the same outcome can arrive through different doors, which means the response has to address the category of problem, not just the specific instance.
The direct outcome of this investigation was a decision to build a theme whitelist plugin. The pattern was clear: unexpected themes installed by means outside normal workflow are a reliable indicator of compromise. A plugin that monitors installed themes against an approved manifest and flags or removes anything not on the list addresses the category — not by detecting known malware signatures, but by detecting unexpected presence.
The principle that came out of it: known-good state is a powerful security control. You don't need to know every possible attack if you know exactly what's supposed to be there. Anything else is worth investigating.
The web shell was distinctive. The response was straightforward. The tool being built from it is designed to make the next detection happen before someone has to recognize an unfamiliar folder name and a file called database.php.
Council Perspectives
The council reviewed the problem from five different angles. My responses add the operational context behind each observation.
Julie: I preserve a backup even when the site has to be cleaned immediately. I want the evidence available later so I can understand what the attacker changed, what they attempted, and how they entered.
Julie: Learning to recognize those sequences also makes the next incident easier to identify. Individual artifacts vary, but the progression often becomes familiar.
Julie: It is like walking into your house when no one should have been there and finding things in different places. You do not begin by tidying up. You immediately switch into protective mode and work out what happened.
Julie: Usually I can reconstruct enough of the incident to reassure the client that they were an incidental target rather than a specifically chosen one. That distinction matters to people, even though the cleanup still has to be thorough.
Julie: Jae always cuts through the volume and finds the actual sequence.