Proc Filesystem (T1003.007) is a credential access sub-technique for Linux. The proc filesystem is a pseudo-filesystem that exposes kernel data structures. Adversaries may read it to gather credentials from process memory.
How attackers use it
MITRE explains the mechanism. For each process, the maps file under /proc/PID shows how memory is mapped, and the mem file provides access to the process address space for debugging. With root privileges, an adversary can search those locations in every process for patterns that look like credentials. MITRE gives an example of using a regular expression with grep against the maps file to find readable memory ranges.
Without root, a process can still look at its own memory. MITRE notes that some services keep credentials in clear text in process memory. A process running with a web browser's permissions could search its own memory for website credential patterns, and also find adjacent memory holding hashes or cleartext.
How to detect it
MITRE's analytic describes multi-step access to the maps and mem files, combined with privilege escalation or credential scraping binaries. In the broader credential dumping strategy, MITRE adds the targets: services that store credentials, such as sshd or login, and tools such as gcore or gdb.
Using auditd or an endpoint agent with file access events:
- Alert when a process other than a debugger you expect opens another process's mem or maps file.
- Alert on gdb or gcore running against sshd, login or other authentication services on production servers.
- Correlate with a recent privilege change such as sudo or su.
How to reduce the risk
MITRE lists:
- Password Policies: complex, unique root passwords across all systems.
- Privileged Account Management: follow best practices in restricting access to privileged accounts so hostile programs cannot reach sensitive information.
Beyond that, remove debuggers from production images where you can, and reduce how many people hold root.
What makes this one tricky
The proc filesystem is not a file in the usual sense. There is no file on disk to protect or to scan. Memory is exposed through a kernel interface, so the control points are different: who may attach to a process, and who has root.
Services that keep secrets in memory are the main exposure. Most do so out of necessity, since a process that authenticates users must hold something at some point. The risk grows when a service keeps clear text for longer than it needs to, or when the box also runs many unrelated programs.
Reducing exposure in practice
- Run fewer things on hosts that handle credentials. A bastion host that only does SSH has a smaller memory neighborhood than a general application server.
- Restrict ptrace through the kernel setting shown above, so ordinary processes cannot read each other.
- Remove debuggers from production images where nothing needs them.
- Limit root and sudo, since MITRE notes the broad search needs root.
- Rotate credentials that sit in memory for long periods, so a stale value is worth less.
Tuning the detection
Debuggers and some monitoring agents read proc files legitimately. List them by path, allow them, and alert on the remainder. The pairing MITRE describes is the useful one: access to the mem or maps file of an authentication service, close in time to a privilege change.
Check your own environment
On a Linux host, see the current setting that governs how processes may attach to each other (read-only):
cat /proc/sys/kernel/yama/ptrace_scope
A higher value means stricter limits on tracing other processes. The value 0 is the most permissive. If the file is missing, your kernel may not include the Yama module, so check your distribution's documentation.
Also check whether debuggers are installed on servers that do not need them:
command -v gdb gcore
Quick check
Which two proc files does MITRE name?
The maps file, which shows how a process's memory is laid out, and the mem file, which gives access to the process's virtual address space.
