A PHP WAF Alert Is an Investigation Lead: Reconstructing Origin Exposure

TL;DR

A WAF event records a detection and an action at a particular point in the traffic path. It does not, by itself, establish whether PHP executed attacker-controlled code, whether a different path reached the origin or whether earlier activity succeeded. Build a timeline that connects edge events, origin requests, process behavior and changes to assets. Keep observations separate from hypotheses, preserve evidence before destructive recovery where feasible, and update the runtime regardless of whether the investigation finds compromise. The case below is fictional and provides a method for reasoning, not an account of a real victim.

The hearing opens with two incompatible conclusions

At fictional publisher Fern Press, an analyst sees a surge of WAF events associated with PHP exploitation attempts. One manager concludes that the company has been breached because the graph is alarming. Another concludes that the company is safe because the events say blocked. Both conclusions exceed the evidence presently available.

The incident lead writes a narrower statement: the edge recorded traffic matching a particular rule and reported a particular action during a specified interval. The team still needs to establish which routes were covered, whether the action occurred before or after origin processing, and what the origin and host records show.

Cloudflare's October 21 report states that it observed attack traffic targeting customers and deployed protections for the PHP flaws. It also describes request-and-response detection and recommends applying the PHP update. That report establishes vendor observations and protective behavior; it is not evidence that Fern Press, or any particular reader's service, was compromised.

The analysis below uses a constructed evidence hearing. Its times, systems and findings are invented. The hearing format forces each conclusion to identify its supporting observation and its remaining uncertainty. It is especially useful when a rapidly developing incident encourages people to substitute a compelling narrative for a documented chain of events.

Exhibit one: the edge event

The analyst exports the relevant events with their times, rule identifiers, action fields, request paths and available correlation identifiers. She records the query interval and filters used. An exported set without its selection criteria can later be mistaken for a complete record of all traffic, even when it represents only one rule or one hostname.

Cloudflare's Security Events documentation explains the event interface and its analysis features. Operators should check the retention, sampling and access properties applicable to their service rather than assuming that every visible dashboard is a complete forensic archive. The display's convenience does not determine the evidence's completeness.

Fern Press's export shows that the rule action was block for the selected events. The analyst does not translate that field into “nothing reached any backend.” She first identifies the rule type and enforcement stage. A response-side control can act after the origin has already processed a request, so the location of the action matters to the inference.

A second analyst checks whether the events belong to the production publishing hostname or a separate staging hostname. This sounds administrative, but mixing them can lead to a serious scope error. The same account can contain several applications with different runtime versions, origins and security policies.

The question the event can answer

The edge record can support a statement about what the edge detected and did. Depending on the available fields and architecture, it may also support a correlation with an origin request. It cannot independently establish every action inside the origin process, every request sent through a different route or the absence of earlier successful activity.

The incident lead therefore treats the event as a starting point for collection. Its value lies in narrowing time, path and traffic characteristics. A high-confidence detection can justify urgent containment without being promoted into a complete explanation of compromise. Operational action and evidentiary certainty do not have to move at the same speed.

The team also avoids treating a rule name as a stable technical specification. Vendors can update detection logic while retaining a readable label, or rename rules as understanding improves. Save the relevant rule identifier and dated configuration context so that later review can reconstruct which control was active.

Exhibit two: the route that bypasses the edge

Fern Press's main hostname is proxied through its WAF. Its origin also has an older direct hostname used by a partner integration. That hostname does not appear in the selected edge events. The absence is expected because the requests take a different path; it says nothing about whether the direct route was used.

Cloudflare's origin-protection guidance addresses the distinction between protecting proxied traffic and restricting access to an origin. For Fern Press, the immediate task is an inventory of actual entry points, including alternate hostnames, addresses, load balancers and partner routes. The team should not test or scan infrastructure it does not own or have permission to assess.

The network owner compares routing and firewall configuration with the service inventory. She identifies which connections can reach PHP and which terminate elsewhere. A historical DNS record may be a lead, but current reachability and authorization depend on the present configuration. Record what was observed rather than assuming every old address is still active.

If a direct route is unnecessary, the service owner can restrict it through the approved operational process. If it supports a real partner dependency, document that dependency and choose a controlled containment measure. Breaking a critical integration without understanding its purpose can create an avoidable outage while leaving another unexamined route open.

The hearing's conclusion is now more precise: the main proxied route had the observed edge control, while a separate authorized integration route requires origin-side investigation. This does not prove an attacker used the second route. It prevents the team from using the first route's protection as evidence for the entire service.

Exhibit three: origin requests and their limits

The application team retrieves origin access logs for the relevant interval. It preserves the original records and works from controlled copies where practical. The NIST forensic guide provides a foundation for integrating collection and analysis into incident response. Its publication is historical, so teams should combine its evidentiary principles with current tooling and organizational procedures.

The origin log includes request times, paths, status codes and some correlation identifiers. A successful HTTP status is not proof of a successful exploit. An error status is not proof of failure. The application can emit a normal response after an unintended side effect, and a malicious request can fail before any useful operation occurs.

Likewise, a missing application log entry does not prove the request never reached PHP. A runtime failure may occur before application logging begins. Logging configuration, buffering, process termination or incomplete collection can also create gaps. The team should document the logging boundary before interpreting silence.

Fern Press correlates edge and origin events where a trustworthy identifier exists. Where it does not, analysts use time, route and other fields as weaker associations and label them accordingly. A plausible match between two records is not automatically a unique match, especially during a burst of similar traffic.

Align clocks without erasing uncertainty

Suppose the edge reports an event at 14:03:10 UTC and the host reports a process failure at 14:03:17 UTC. Those timestamps alone do not establish a seven-second causal chain. The clocks can differ, the event fields can represent different stages, and the logs can be written after the activity they describe.

The team checks known clock offsets and timestamp definitions where available. It preserves original timestamps and records any normalization used for analysis. Changing every field into a common display time without retaining the original can make the final timeline look more exact than the evidence supports.

When uncertainty remains, use intervals. An event may have occurred within a bounded window rather than at one confidently comparable instant. This still helps distinguish plausible sequences from impossible ones. A careful interval can be more informative than an invented exact ordering.

Exhibit four: process behavior

The host team examines available process telemetry, service-manager records and crash reports. It asks whether PHP workers terminated unexpectedly, launched unusual child processes or made unexpected outbound connections. Each observation needs context: a legitimate image-conversion workflow can create child processes, and a scheduled job can contact a new endpoint for an authorized reason.

An unfamiliar process name is a lead, not a verdict. Compare executable identity, parent relationship, arguments where safely available and the application's expected behavior. Avoid copying secrets embedded in arguments or environment values into broad incident channels. The OWASP logging guidance emphasizes purposeful logging and handling of sensitive information; an investigation should not create a second exposure through careless evidence sharing.

A crash can establish that something failed without establishing code execution. The team should distinguish a resource-exhaustion symptom, a memory-safety report and evidence of an unauthorized action. These observations can have different implications for containment and recovery, even if they occur near the same traffic burst.

At Fern Press, a worker restarted during the interval, but the available record does not identify the request responsible. Analysts preserve the finding as an unexplained restart. They do not manufacture a causal link simply because the WAF graph and restart graph overlap visually.

Cross-examination: three hypotheses remain

The hearing considers three broad hypotheses. The first is that the observed attempts were contained before causing a harmful origin action. The second is that some requests reached the origin and caused failures without established compromise. The third is that an unauthorized action occurred through an examined or unexamined path. These are working hypotheses, not exhaustive descriptions of everything an attacker could do.

For each hypothesis, the analysts name expected evidence and evidence that would weaken it. Confirmed unauthorized file creation by the PHP process would weaken the first explanation. A worker crash with no further telemetry would not, by itself, distinguish the second from the third. A direct route with incomplete logs leaves a coverage gap rather than proving use of that route.

This table prevents the team from treating all findings as equivalent indicators of a breach. It also prevents the opposite error of dismissing a serious integrity violation because a WAF appeared to be working. Evidence from different layers answers different questions and should be combined with its provenance intact.

The incident lead asks analysts to propose at least one reasonable alternative explanation for each major finding. This is not an exercise in minimizing risk. It makes the conclusion more reliable by exposing assumptions that would otherwise remain hidden. An alternative should be testable against records, not an unlimited excuse to disregard inconvenient evidence.

Examine changes to assets and authority

If the host evidence suggests unauthorized activity, broaden the investigation according to the assets and privileges available to the affected process. A PHP worker may have access to application files, database credentials, object storage or other services. The scope depends on the actual deployment, not on the language name alone.

Compare relevant files and configuration with trusted deployment artifacts. A difference can arise from authorized runtime behavior as well as intrusion, so identify which paths are expected to change. Upload directories, caches and generated assets need different interpretation from immutable application code. A single undifferentiated filesystem diff can overwhelm reviewers with harmless noise.

Inspect changes to accounts, permissions and scheduled execution where the affected identity could make them. Preserving a visible suspicious file while missing a new credential can leave the organization exposed after cleanup. The investigation should follow authority boundaries: what could this identity read, modify, execute or delegate?

Data access requires its own evidence. Finding a compromised process does not automatically establish which records were read or exported. Conversely, an absence of export logs does not prove no data left if those operations were never recorded. State the available evidence and its collection limits when communicating possible impact.

The organization's incident-response lead should involve legal, privacy and business owners when the facts require their decisions. This article does not prescribe notification obligations for a jurisdiction or contract. The technical contribution is a clear account of affected systems, observed actions, plausible access and unresolved uncertainty that those decision makers can use.

Containment and preservation share the same clock

The team cannot always wait for perfect evidence before reducing exposure. A service may still be vulnerable or show active unauthorized activity. NIST SP 800-61 Revision 3 places incident response within ongoing cybersecurity risk management. For Fern Press, this means choosing containment based on current consequences while continuing to improve the evidence.

Before restarting, rebuilding or deleting a suspicious artifact, ask whether an available preservation step can retain useful evidence without materially delaying necessary protection. The answer depends on the system, the available expertise and the urgency. A generic instruction to collect everything first can be as unhelpful as an automatic rebuild that destroys the only useful record.

Document the action, reason and expected evidence loss when immediate containment takes priority. If a worker must be terminated, record what was known before termination and what could not be collected. This makes later uncertainty understandable and avoids blaming investigators for evidence that an operationally justified action necessarily removed.

Keep evidence access controlled. Original logs, memory captures or disk images can contain customer data and secrets. Use the organization's established handling procedures, retention rules and authorized storage. A rapid incident does not make a public file-sharing link an appropriate evidence repository.

Recovery changes the system you are investigating

Rebuilding a host replaces state. Rotating a credential changes future access. Updating PHP changes susceptibility. These are useful recovery actions, but they also change what later observations can tell you about the earlier interval. Preserve the timeline of those actions alongside the timeline of suspected activity.

At Fern Press, the team records when the fixed runtime entered service, when the direct route was restricted and when an application credential was replaced. Later failed authentication attempts can then be interpreted against the credential change. Without that context, the same failures might be misread as an unrelated application regression.

A restored service should be checked against trusted artifacts and expected behavior, with the investigation findings informing the recovery plan. Merely restarting the previous environment does not address a demonstrated integrity violation. The appropriate recovery scope depends on what the evidence establishes and what confidence can reasonably be regained.

The team should also confirm that old images, alternate regions or scheduled tasks cannot restore the vulnerable runtime. This is a recovery-path concern, distinct from determining whether exploitation occurred. Keeping the work streams separate makes it possible to finish the runtime update while acknowledging that impact analysis remains open.

Report uncertainty in operational language

Fern Press's first internal update says: “We observed attempts matching the vendor's PHP detection rules. The primary route applied blocking actions. We are checking an alternate origin route and investigating an unexplained worker restart. The fixed runtime rollout is in progress.” Every sentence describes evidence or work currently supported by evidence.

That update is more useful than either “we are fully protected” or “all customer data is compromised.” It tells service owners what has been observed, where uncertainty remains and which actions are underway. It also gives later updates a clear basis: an alternate route can be assessed, a restart can be explained and a rollout can be verified.

When evidence changes, update the conclusion explicitly. If the restart is traced to an authorized deployment, say so and retain the earlier hypothesis as resolved. If an unauthorized change is confirmed, state the affected asset and the basis for the finding. Avoid quietly replacing one narrative with another while leaving readers unable to understand what changed.

For customer-facing communication, use the same factual discipline with less operational detail. Do not publish sensitive indicators, internal addresses or speculative attacker attribution merely to make the statement appear technical. Explain the service impact, protective actions and next update in terms appropriate to the audience and the organization's disclosure obligations.

Decide what a negative finding actually means

Suppose the completed review finds no unauthorized file changes, no unexpected account modifications and no corroborating outbound activity in the available records. This is useful evidence. Its strength depends on whether the relevant systems were monitored, whether the records cover the exposure period and whether the expected actions would have been visible.

A negative finding should therefore name its scope: no evidence of the specified activity was found in the listed sources over the stated interval. It should not expand into a universal claim that nothing happened. This wording is not evasive when accompanied by concrete collection coverage; it is an accurate description of the investigation's reach.

The team can improve confidence by combining independent observations. A trusted artifact comparison, host telemetry and application records may cover different aspects of an unauthorized action. Independence is imperfect, especially when all logs reside on the same potentially affected host, so account for their common failure modes rather than merely counting data sources.

If a critical interval has no usable records, record that gap and assess whether the remaining uncertainty requires broader recovery. The decision can be conservative without inventing evidence of compromise. An organization can choose to rebuild or revoke credentials because the consequences of uncertainty are unacceptable, while remaining honest about what was and was not observed.

Close the hearing with a claim register

The final register separates established facts, resolved hypotheses, unresolved gaps and completed protective actions. Each established fact links to evidence. Each unresolved gap names an owner or a reason it cannot presently be resolved. This prevents a successful patch rollout from automatically closing the historical investigation.

Fern Press's constructed case ends with a verified runtime update, a restricted alternate route and a worker restart explained by an authorized deployment. The available evidence supports containment of the observed attempts on the examined main route. A short retention gap on the alternate route remains documented, and the organization chooses additional credential replacement and recovery checks because of that uncertainty.

The team also records what would change its conclusion. A provider notification, a newly recovered log segment or an unexpected use of a retired credential can reopen a specific hypothesis. This is more useful than declaring the investigation permanently finished. It gives later responders a precise way to connect new evidence to the earlier assessment without discarding all of the work already completed.

For the next incident, Fern Press improves correlation identifiers, evidence retention and origin inventory because those were the actual weaknesses in this review. It does not simply buy a larger dashboard or promise to watch alerts more closely. The changes follow from the questions the team could not answer efficiently.

A WAF alert is valuable because it can start this process early. Its value is reduced when it is asked to prove more than it records. Treating detection, delivery, execution and impact as separate claims produces a response that is both faster to act and more careful about what it tells people.

Sources

• Cloudflare: October 21 PHP protections and observed attack traffic.
• Cloudflare: Security Events documentation.
• Cloudflare: protecting an origin server.
• NIST SP 800-61 Revision 3: incident-response recommendations.
• NIST SP 800-86: integrating forensic techniques into incident response.
• OWASP: Logging Cheat Sheet.