Back to evidence

Sanitized live incident

Suspicious activity

Native source identity and targetable endpoints are private.

criticalopen
Confidence
99%
First seen
Aug 18, 11:57:51 AM PDT
Evidence through
Aug 18, 12:28:15 PM PDT
AI status
Complete
Likely true positive92% confidence

Likely true positive for suspicious root-level command execution inside the workload, but not proof of external exploitation. Event-driven process evidence shows a root dash shell spawning discovery command id [redacted], later followed by a root dash/head chain classified as targeting a sensitive file [redacted]. Additional root dash executions continued through [redacted]36Z [redacted]. The repeated shell, discovery, and sensitive-file pattern strongly supports genuine suspicious activity. However, no HTTP or flow references are available to identify an initiating request or network consequence, and authorization or lab activity cannot be excluded.

Attack stage
Execution, discovery, and sensitive-file access
Model
gpt-5.6-sol · 8 evidence calls

Observed impact

  • Root-context shell and discovery processes executed inside the protected workload.
  • A root-context shell spawned a sensitive-file tool, showing sensitive-file targeting; content disclosure is not established.
  • Repeated shell activity continued for several minutes, increasing concern beyond a single incidental process.

Deterministic signals

Process.observed discovery command88%

An event-driven discovery command was observed in a protected workload without correlated HTTP evidence

4 observations · 4 process
Process.observed shell spawn99%

An event-driven shell execution was observed in a protected workload without correlated HTTP evidence

25 observations · 12 process
Process.correlated exit99%

A previously correlated process lifecycle exited

27 observations · 12 process
Process.observed sensitive file command99%

An event-driven process targeted a sensitive file in a protected workload without correlated HTTP evidence

2 observations · 2 process

Explicit uncertainty

  • No HTTP evidence reference is cited by the incident; HTTP evidence queries could not verify an initiating request. Request-to-process causality, originating action, and remote actor remain unknown.
  • No flow evidence reference is cited by the incident; outbound network activity, command-and-control, or exfiltration cannot be assessed from the available evidence.
  • The bounded process summaries omit exact arguments, sensitive-file identity, and command output. They establish process execution and sensitive targeting, not the data read or disclosed.
  • The source key is a derived workload cluster, not a verified human or remote-agent identity.
  • Authorization context is unavailable. Root inside a workload and newly observed shells can reflect administrative, test, or lab activity, although the repeated discovery and sensitive-file pattern makes benign activity less likely.
  • No cited evidence proves host escape, persistence, lateral movement, command-and-control, or data theft.

Recommended actions

  1. Promptly validate the activity with the workload owner and compare the timestamps and common parent PID 3075746 against approved deployments, health checks, automation, and operator sessions.
  2. If the activity is not immediately authorized, isolate or suspend the workload using established response procedures while preserving process, container, and orchestration telemetry.
  3. Investigate the full ancestry and executable provenance of parent PID 3075746, including the container image, entrypoint, service account, deployment revision, and initiating control-plane event.
  4. Preserve and review file-access/audit telemetry around [redacted]40Z to identify the sensitive target and determine whether any content or credentials were actually exposed.
  5. Review surrounding process telemetry beyond the cited interval for downloads, file writes, persistence attempts, credential use, or additional discovery; do not infer those consequences without evidence.
  6. If credential material is confirmed to have been accessed, rotate only the affected secrets and redeploy from a trusted image; otherwise avoid broad rotation based solely on the sensitive-target classification.
  7. Reduce recurrence by avoiding unnecessary workload root privileges, applying least-privilege service accounts, and restricting shell/tool availability where operationally feasible.