Back to evidence

Sanitized live incident

Attempted exploitation

Native source identity and targetable endpoints are private.

highopen
Confidence
99%
First seen
Aug 18, 12:29:27 PM PDT
Evidence through
Aug 18, 12:30:02 PM PDT
AI status
Complete
Likely true positive93% confidence

The evidence strongly supports a genuine command-injection attempt against target privatekind: the verified HTTP event was flagged for shell metacharacters with command tokens [redacted]. About four seconds later, event-driven process telemetry recorded a root-run dash shell in the detector-correlated workload [redacted], and the same observed PID later exited with a zero outcome [redacted]. This materially strengthens the incident, but does not prove that this particular request created the shell because workload routing and temporal correlation are not a unique request-to-process edge. The HTTP 400 status does not itself establish success or failure. The immutable detector classification remains attempted_exploitation; the appropriate adjudication is likely true positive, with possible execution rather than conclusively request-attributed execution.

Attack stage
Initial access: command injection attempt with possible workload command execution
Model
gpt-5.6-sol · 5 evidence calls

Observed impact

  • A dash shell executed as root in the correlated workload (PID 4135756) [redacted].
  • The observed shell lifecycle later exited with outcome zero; this proves process completion, not HTTP-request causality [redacted].

Deterministic signals

Http.command injection attempt88%

Request contains shell metacharacters and command tokens

1 observations · 1 http
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

1 observations · 1 process
Process.correlated exit99%

A previously correlated process lifecycle exited

1 observations · 1 process

Explicit uncertainty

  • The current evidence does not prove that HTTP event [redacted] uniquely caused process [redacted]; correlation is based on inferred workload routing and time proximity.
  • The HTTP status was 400, but status alone cannot determine exploit success or failure. The bounded HTTP summary does not disclose response semantics or establish server-generated command output.
  • No flow evidence event is cited by this incident, so request-related outbound connectivity, destination novelty, or network consequence cannot be assessed.
  • The source key is a traffic cluster and may represent a proxy, NAT gateway, or multiple workers rather than one human or agent.
  • No cited evidence establishes persistence, host escape, lateral movement, command-and-control, or data theft.

Recommended actions

  1. Preserve relevant gateway, application, and process telemetry, then isolate or recycle the affected workload according to incident-response policy while maintaining forensic artifacts.
  2. Reconstruct the application-side request trace and determine whether the vulnerable handler launched PID 4135756; inspect the observed parent PID 3076121 and any children or sibling processes around the incident window.
  3. Review the affected endpoint and parameters for unsafe shell invocation; remove shell interpolation, use parameterized APIs, and enforce strict input validation.
  4. Hunt for related command-injection patterns and unexpected root shells across target privatekind and the source cluster around the incident window.
  5. Review filesystem changes, credentials, secrets, and outbound network records associated with the workload. Rotate potentially exposed credentials if investigation finds access or disclosure.
  6. Do not treat the HTTP 400 or the shell's zero exit outcome as proof of exploit failure; validate using application logs and process lineage.