For SOC and security engineering

Investigate runtime threats
with the evidence in view.

A suspicious shell or credential read needs context. Primod brings observed process activity and workload identity into the investigation, with request context where available.

01

Start with what the sensor observed.

Review the activity that triggered a rule, its process ancestry, and the evidence that supported the finding. Distinguish a completed action from a failed attempt before deciding what it means.

app.primod.io / runtime / alerts / checkout-service
Runtime alert HighIllustrative scenario · Product UI preview

Web process launched a shell

Workload
checkout-service · Deployment
Namespace
production
Process chain
web worker → /bin/sh
Observed activity
Shell launch followed by a token read and an outbound connection attempt
Interpretation
Consistent with suspicious command execution and credential access
Response
Observe — no action blocked
+0 msPOST /api/uploadRequest observed · Included only in this trace-supported example Observed
+18 msWeb process launches /bin/sh Succeeded
+43 msProcess opens service-account token fileNo token value displayed Succeeded
+91 msConnection to 203.0.113.10:443 Failed

Relative times are documentation data, not a measurement. The timeline supports investigating credential access; it does not establish successful exfiltration.

Where it ran

Podcheckout-service-7d9f6c-x2k4p
Nodenode-pool-b-03
Containercheckout
Image digestsha256:9f2c…a1e0

Request context

Method · route: POST /api/upload

Trace · span: supplied by instrumentation

Detection details

Rule: rce-shell-web-ancestor · rev 3

Technique mapping: as provided by the rule

Evidence quality

Complete · Process ancestry complete for this alert

Limited · Some events may be missing: capture reported lost events on this node during the window

Illustrative attack scenario · Product UI preview

02

Follow the sequence.

Inspect related alerts in an incident timeline. A shell launch followed by a token read and a connection attempt gives an analyst more to investigate than an isolated process name.

The timeline describes observed activity; it does not prove every step of an attack was captured.

app.primod.io / runtime / incidents / checkout-service

Observed sequence

  1. +0 ms

    POST /api/upload

    Observed
  2. +18 ms

    Web process launches /bin/sh

    Succeeded
  3. +43 ms

    Process opens service-account token file

    Succeeded
  4. +91 ms

    Connection to 203.0.113.10:443

    Failed
Runtime alert HighIllustrative scenario · Product UI preview

Web process launched a shell

Workload
checkout-service · Deployment
Namespace
production
Process chain
web worker → /bin/sh
Observed activity
Shell launch followed by a token read and an outbound connection attempt

Same illustrative scenario as the homepage · Product UI preview

03

Give engineering a concrete starting point.

Identify the workload, namespace, and image associated with the finding. Available request and process context helps the team that owns the service investigate the same evidence.

04

Know the limits of the finding.

Review capture gaps and available coverage before reasoning from missing activity. A quiet alert stream is not proof that a workload is safe.

Questions teams ask.

Can this identify the root cause automatically?
The evidence supports investigation. It does not, by itself, prove an exploited CVE or every causal step.
Can we use the evidence in incident review?
Rule provenance, event outcomes, and workload context support review. Retention, export, and audit requirements should be confirmed for your deployment.

Walk through a runtime investigation.

Request a demo