PHP2Shell incident response after an unpatched server

Separate vulnerability remediation from incident recovery

The patch workstream establishes that the runtime is corrected and the active service uses it. The incident workstream asks what happened during the exposure, what the attacker could access, whether anything persists and what is required to restore trust. Neither workstream replaces the other. A package transaction cannot remove every possible backdoor, while a clean-looking homepage cannot show which runtime is installed.

Use careful status language. “Potentially exposed” describes a service for which the fix was not yet verified. “Suspicious activity” describes observations that need interpretation. “Confirmed compromise” requires supporting evidence. Do not call every out-of-memory error an attack, or treat the absence of an alert as proof that nothing happened. The difference determines how you communicate, preserve evidence and allocate specialist effort.

Stabilise the situation and choose proportionate containment

Name a response lead and a technical owner, then decide how to prevent further harm while retaining the ability to investigate. NCSC guidance distinguishes disconnecting a system from powering it down because these actions have different operational and evidential consequences. Where an experienced responder is available, agree the containment method before destroying volatile information. Where harm is continuing, act promptly and document why the chosen action was necessary.

A maintenance response is useful only if it prevents untrusted traffic from reaching the affected handler. Test the actual containment. Do not leave a direct origin, alternate hostname or administration endpoint publicly usable because only the main domain was changed.

Preserve evidence that can answer the business questions

Collect the available records through approved administrative access and store them privately with their origin and collection time. NCSC’s technical response guidance emphasises usable logs and evidence for triage and analysis. For a PHP website, connect the request path, authentication activity, application changes and hosting events rather than gathering unrelated screenshots with no timeline.

• The service inventory and previous/current package or image identities.
• Web-server and application logs for the exposure window, including their retention limits.
• Administrative, hosting-panel and deployment access records where available.
• Copies or snapshots of suspicious files, configuration and relevant system state before destructive cleanup.
• Known changes made by your own responders, with timestamps and the reason for each change.

Restrict access because logs and forensic material may contain personal data, credentials or business information. Do not upload a whole server archive to a public scanning site or attach customer records to an initial support enquiry. If evidential requirements, encryption or complex hosting access make collection difficult, involve a competent incident-response specialist rather than improvising a destructive process.

Investigate the permissions and systems actually at risk

Frame the investigation around the service’s capabilities. Which directories could its account write? Which database credentials or service keys were accessible? Did multiple sites share that account? Could it contact internal services or reach backups? These questions turn a general vulnerability alert into an organisation-specific impact assessment. They also prevent an unsupported jump from a website process compromise to a claim of full network control.

Review unexpected administrators, scheduled tasks, application bootstraps, recently modified executable files and configuration changes in context. A filename or timestamp alone is not a reliable verdict: legitimate deployments can change many files, and an attacker may manipulate timestamps. Compare with trusted deployment history and known-good sources. If you cannot distinguish legitimate state from unauthorised changes, that uncertainty is a reason to consider rebuilding.

Rebuild when confidence in the existing server is inadequate

Create the recovery environment from a trusted image or supported installation source and verify its runtime correction before it receives public requests. Obtain application code, dependencies and plugins from their legitimate suppliers or reviewed source repository. Treat the compromised environment as evidence and a source of data to assess, not as the unquestioned master from which to clone everything.

1. Establish clean administration and a trusted destination for recovery.
2. Install the supported corrected runtime and necessary application components.
3. Restore only assessed business data and reviewed configuration; do not blindly copy every executable file.
4. Remove the initial access route and address any additional persistence or account compromise found.
5. Replace exposed credentials through trusted access and update dependent services safely.
6. Validate functionality, access controls and monitoring before staged reconnection.

NCSC’s recovery guidance warns that restoration before attacker eviction can allow an incident to restart. The practical lesson for a website is to define the confidence needed to reopen it, not merely the point at which the homepage renders. A fresh runtime around an unchanged malicious plugin or compromised deployment key is not a trusted recovery.

Replace access safely and assess data impact separately

Use a clean administrative device or trusted management path before changing secrets. Identify what the affected application or attacker could access, then replace the relevant credentials, tokens and sessions in a coordinated order. Avoid changing a password on a still-compromised system and assuming the new secret cannot be captured. Check integrations, scheduled tasks and emergency access so the rotation does not silently break the recovery environment.

In parallel, involve the person responsible for privacy, contractual and customer obligations. Establish what data was accessible, what evidence indicates actual access or loss, and which uncertainties remain. Reporting requirements depend on the facts and applicable duties; a runtime alert alone does not establish that every organisation must notify every customer. Preserve the assessment and obtain qualified advice where needed. Do not postpone that work until all technical questions are answered.

Example: a static fallback while the enquiry service is rebuilt

Imagine a small UK consultancy that discovers an unexplained scheduled task on its unverified PHP server. The response lead keeps a simple static contact page on a separate trusted service while the original server is isolated for evidence collection. The administrator builds a corrected environment, restores reviewed website content and replaces the credentials the original application could read. The enquiry form is tested with a designated mailbox before reopening.

This hypothetical approach separates business continuity from premature restoration. The company does not need to tell customers that the entire investigation is finished just because a contact route is available. It can describe the limited service honestly while technical responders determine the scope. The safe fallback buys useful time without returning the questionable server to public use.

Set reconnection criteria that can be checked

• The affected runtime’s fix is documented and active across the recovery scope.
• The team has addressed known unauthorised access and persistence, with remaining uncertainty recorded.
• Application code and restored data have a defensible source and review history.
• Required credentials and sessions have been replaced or revoked through trusted access.
• The business workflows pass agreed tests, and errors or suspicious changes will be monitored.
• The response lead has approved staged reconnection and named the owner of follow-up work.

Continue monitoring after reopening and retain a route to contain the service again if new evidence appears. Record what improved the response and what delayed it: missing logs, shared accounts, untested backups or unclear supplier ownership. CyberXperts can assist with website recovery scoping and verification, but no responsible recovery assessment should promise certainty beyond the evidence available.