Back to evidence

Sanitized live incident

Attempted exploitation

Native source identity and targetable endpoints are private.

highopen
Confidence
99%
First seen
Aug 20, 12:10:59 PM PDT
Evidence through
Aug 20, 1:56:07 PM PDT
AI status
Complete
Likely true positive92% confidence

Likely genuine command-injection exploitation activity. Multiple HTTP requests carried shell metacharacters and command tokens, while root-run dash shells and child discovery commands were observed in the routed workload during the same narrow windows (HTTP [redacted]; process [redacted] and [redacted]). A whoami child completed successfully, and later root shell/head chains targeted sensitive files. This strongly supports execution in the workload, but the evidence supplies only workload/time correlation—not a unique request-to-process trace edge. Authorization is unknown, and no cited flow evidence establishes actual outbound communication.

Attack stage
Command-injection exploitation with workload execution and discovery
Model
gpt-5.6-sol · 7 evidence calls

Observed impact

  • Root-run shell execution was observed in the processor workload ([redacted]).
  • A root-run whoami discovery process executed and exited successfully ([redacted]; [redacted]).
  • Root shell/head process chains targeted sensitive files; successful data access or disclosure was not established ([redacted]; [redacted]).
  • Network-client-class shell processes were spawned, but no socket connection or egress consequence was established ([redacted]).

Deterministic signals

Http.surface enumeration92%

Broad unauthenticated route and HTTP method enumeration observed

1689 observations · 12 http
Http.command injection attempt88%

Request contains shell metacharacters and command tokens

207 observations · 12 http
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

442 observations · 12 process
Process.correlated network client80%

An outbound-capable client process appeared in the correlated workload and request window

5 observations · 5 process
Process.correlated exit99%

A previously correlated process lifecycle exited

560 observations · 12 process
Process.correlated discovery command80%

A discovery process appeared in the correlated workload and request window

314 observations · 12 process
Process.correlated sensitive file command80%

A process command targeted a sensitive file in the correlated workload and request window

29 observations · 12 process

Explicit uncertainty

  • The evidence does not provide a unique request-to-process trace or parentage edge; process attribution to any particular HTTP request remains inferential.
  • The first cited network-client shell at [redacted].790278595Z predates the [redacted].874173038Z HTTP request, illustrating why temporal proximity cannot be treated as unique causality.
  • No incident-cited flow event was available to the bounded flow-evidence tool, so actual outbound connection establishment, destination, and transferred data are unknown.
  • HTTP response-body summaries provide sizes and hashes but no verified command-output semantics here; HTTP 200 or 500 status alone cannot establish success or failure.
  • The source key is a traffic/workload cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • Authorization is unknown; the activity could be an approved security test, although its command-injection and root-process pattern is strongly suspicious.
  • Sensitive-file targeting is observed at the command level, but successful reading, disclosure, persistence, host escape, lateral movement, and data theft are not established.

Recommended actions

  1. Treat the workload as potentially compromised: contain or isolate the affected processor instance if operationally safe, while preserving process, application, and gateway telemetry.
  2. Correlate application request logs, worker/job identifiers, and distributed traces with the cited HTTP and process timestamps to establish a request-to-process edge and identify the vulnerable handler.
  3. Review and patch the command-construction path; eliminate shell invocation for request-derived data, use structured APIs/argument arrays, and apply strict allowlisting and authentication.
  4. Capture and review the cited process trees and sensitive-file targets; compare the workload image and writable filesystem with a known-good deployment before restoring service.
  5. Inspect workload and network telemetry for actual connections associated with the cited process lifecycles. Do not infer egress solely from the network-client process classification.
  6. Review credentials and secrets accessible to the root-running workload; rotate them if investigation shows the sensitive targets were successfully read or disclosed.
  7. Reduce privilege by running the service as a non-root user, applying least-privilege filesystem permissions, and restricting unnecessary egress and shell/tool availability.
  8. Determine whether the source cluster belongs to an authorized scanner or test system; if not, block or rate-limit it and preserve indicators for broader hunting.