Process Memory Read via /proc Filesystem

How the attack works

A process (or a subprocess spawned by an AI agent) opens files like /proc/*/mem, /proc/*/environ, /proc/*/maps, /proc/*/fd, or /dev/mem belonging to another running process. These files let it read that process's memory contents and environment variables without needing filesystem write access or a credential file to exist. Malware planted in compromised AI framework packages uses exactly this technique to lift cloud and Kubernetes credentials that only ever exist in memory. Because nothing touches disk, file-integrity monitoring and credential-file scanners miss it entirely.

Netzilo detection

Why it matters

Cloud account tokens and Kubernetes service-account credentials can be stolen while sitting only in memory, giving an attacker a path to further compromise cloud infrastructure without leaving the usual file-based traces.

What you can do

• →Restrict which processes can read /proc/*/mem, /proc/*/environ, and /dev/mem for other users' processes (e.g. via ptrace_scope hardening or seccomp/AppArmor profiles).
• →Avoid storing long-lived cloud or Kubernetes credentials in process environment variables; use short-lived tokens fetched on demand instead.
• →Review AI framework and agent dependencies for supply-chain tampering before deployment.
• →Investigate unexpected reads of /proc/*/mem or /proc/*/environ from subprocesses spawned by agents, distinguishing them from known profiler/debugger tools like gdb, pprof, or valgrind.

Known benign look-alikes

• Performance profilers reading /proc/*/maps for memory analysis (gdb, pprof, valgrind wrappers)
• Container runtimes inspecting /proc/*/cmdline to enumerate processes
• Debuggers attached to a developer's own process during troubleshooting

References

• https://attack.mitre.org/techniques/T1005/
• https://www.kaspersky.com/blog/critical-supply-chain-attack-trivy-litellm-checkmarx-teampcp/55510/

Related threats