A website can continue to look normal while unauthorised access remains in the environment. In the incident described in this case review, investigators found that a visible failure was not the first sign of compromise. The useful lesson is operational: a working homepage or checkout cannot prove that a WordPress installation is clean.
What the investigation needed to establish
The response began by building a timeline from hosting and application logs, then comparing it with recent account, file and software changes. The review looked beyond the obvious upload location for persistence in administrator records, scheduled tasks, configuration, themes and plugins. A secondary copy of the affected environment was retained for analysis before cleanup.
The source account describes suspicious upload activity followed by hidden access and changes across more than one application layer. That pattern should be investigated rather than assumed from one alert. Logs can show requests and outcomes, but they do not always establish the full cause. Confirm the vulnerable component and the point of entry with evidence before naming a vulnerability or supplier.
Containment and recovery
The defensible response is to coordinate with the host, restrict compromised access, preserve evidence and identify the persistence mechanism. After containment, remove unauthorised files and users, repair or replace affected components, patch the entry point, and reset all credentials and active sessions that may have been exposed. Restore only from a verified clean backup.
Then test the site, review security alerts and monitor for recurrence. A firewall or malware scanner can contribute useful signals, but neither proves that every backdoor has been found. The recovery report should record what was confirmed, what remains uncertain and which controls now have an owner.
Lessons for site owners
- Keep supported software and remove extensions that are no longer needed.
- Separate sites and credentials where practical so one compromise has less reach.
- Retain logs and test backups before an incident occurs.
- Agree who can isolate the site, contact the host and approve recovery.
- Treat exact timestamps, vulnerabilities, indicators and remediation numbers as evidence that must be checked before publishing a case study.
This is an incident-response account, not a claim that one product or control prevents all breaches. Each environment needs a response based on its evidence, exposure and business impact.
