Process Access is an attempt by one process to open or interact with another process, often to read memory, query information, or inject code. Attackers use it for credential theft, tampering, and lateral movement, so defenders should watch for unusual cross-process access and privilege use.
How Process Access Works
Process access is the act of one running process opening or interacting with another process. That interaction can be benign administration, but it can also expose memory, handles, loaded modules, command lines, or other runtime state that attackers want.
Because the target is already executing in a trusted operating context, process access is often more sensitive than file access or ordinary network activity. It can cross a boundary that defenders assume is stable, especially when a higher-privilege process touches a lower-privilege one or when cross-process access is unexpected for the workload.
Why Process Access Matters to Defenders
Process access is important because it can reveal whether a process is reading protected memory, probing security tools, or trying to attach to another process for tampering. The same primitive is used by debugging tools and incident responders, so context matters: the signal is not process access itself, but unusual or high-risk process access.
In practice, defenders care about who is accessing whom, with what privilege, and for what purpose. Cross-process interaction becomes more suspicious when it targets credential-bearing applications, security agents, browsers, shells, or other high-value processes.
Common Abuse Patterns
Attackers use process access to support credential theft, code injection, and lateral movement. A common pattern is to open a process, read or manipulate memory, and then reuse the stolen material or the injected execution path to move deeper into the environment.
This behaviour is often a precursor to broader compromise rather than the final objective. If the access succeeds against a privileged or sensitive process, the attacker may gain session material, secrets, or the ability to blend into legitimate execution paths.
Telemetry that records process access, process creation, module loading, and handle use can help distinguish normal administration from suspicious interaction. Sysmon Guide is useful here because it covers process access visibility, configuration, filtering, and tamper-aware detection use cases.
Detection and Control Considerations
Detection works best when process access is correlated with parent-child lineage, privilege changes, code injection indicators, and sensitive target selection. A single event may be legitimate, but repeated access to security products, credential stores, or system processes deserves closer review.
Controls should focus on least privilege, attack surface reduction, and strong monitoring of privileged endpoints. Event pipelines need enough fidelity to show the source process, target process, access rights, and timing so analysts can separate maintenance activity from abuse.
Authoritative control frameworks consistently treat this as an access and monitoring problem. CIS Controls v8, NIST SP 800-53 Rev 5 Security and Privacy Controls, and MITRE ATT&CK Enterprise Matrix are all relevant because they connect process abuse to access control, audit logging, and adversary tradecraft.
Risk and Threat Considerations
Process access becomes risky when attackers can target sensitive processes, because memory access and code injection can bypass ordinary application boundaries. The danger is not just theft of data in memory, but the possibility of reusing trusted execution to evade controls and move laterally.
Failure mechanism: Unusual or overprivileged process access lets an attacker inspect, alter, or inject into another process, often before traditional file-based or network-based controls can intervene.
Impact: The result can be credential theft, session compromise, tampering with security tools, or execution inside a trusted process context that is harder to detect and contain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Process access often precedes injection, memory tampering, and process manipulation. |
| T1003 — OS Credential Dumping | Cross-process reads are a common mechanism for stealing credentials from memory. | |
| Recommendation — Map suspicious cross-process activity to T1055 and hunt for injection and tampering chains. Correlate process-access alerts with credential-dumping indicators and protect high-value endpoints. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Process access needs detailed audit telemetry to support detection and investigation. |
| AC-6 — Least Privilege | Limiting process privileges reduces unauthorized access to other running processes. | |
| Recommendation — Generate detailed endpoint audit records for sensitive process interaction events. Restrict process privileges so only approved tools can open sensitive processes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Process-access monitoring depends on centralized, retained endpoint logs. |
| Recommendation — Centralize and retain endpoint logs that expose process access, privilege use, and injection signals. | ||
Practitioner Guidance
What to watch for: Treat process access as a high-value telemetry source on endpoints that handle credentials, browser sessions, security tooling, or administrative workflows. The practical question is whether the access pattern matches normal operations, not whether process access exists at all.
Governance implication: Define which processes are allowed to interact, which privileges are acceptable, and what constitutes an investigation-worthy access pattern. That makes it easier to separate sanctioned admin tooling from abuse that deserves escalation.
Practitioner takeaway: The strongest detections usually come from combining process-access events with privilege, parentage, and target sensitivity, rather than treating any single event as proof of compromise.
Related resources from NHI Mgmt Group
- What breaks when access reviews are not tied to a lifecycle process?
- What breaks when agent access is managed in a separate governance process?
- Who is accountable when a shared-device access process fails compliance or audit review?
- When does a ticketing process create more access risk than it reduces?