Process Access occurs when one process opens or interacts with another process, usually to read memory, inspect state, or inject activity. Attackers use it for credential theft, reconnaissance, and code injection. Defenders should monitor suspicious cross-process access, especially when low-trust processes target security tools, browsers, or authentication-related processes.
What Process Access Actually Means
process access is the operating-system interaction where one process opens another process and requests visibility or control over its memory, state, threads, or execution flow. In practice, that can mean reading memory for inspection, querying status for reconnaissance, or writing into a target to influence behaviour. The security significance comes from the fact that the target process often already holds useful data, trusted context, or active sessions.
The concept is broader than “process reading process.” Some interactions are benign diagnostics, but the same mechanism is also used for injection, tampering, and credential access. That is why cross-process activity is treated as a high-signal telemetry source in endpoint detection and response, especially when the source process is low trust or newly seen.
How Attackers Use Cross-Process Access
Attackers often abuse process access to move from initial foothold to higher-value material without needing direct file theft. If a process can open a browser, a security agent, or an authentication component, it may be able to extract secrets from memory, observe tokens before they are protected at rest, or insert code into a trusted execution path. That makes the technique useful for both reconnaissance and post-compromise action.
The most concerning pattern is asymmetric trust: a low-privilege or unfamiliar process targeting a sensitive one. A process that reaches into browser memory, endpoint security software, or login-related components can signal credential theft, session capture, or defense evasion. The same mechanism can also be used to disable visibility by interfering with monitoring tools before the broader compromise becomes obvious.
Process access is closely related to the defensive problem of Sysmon Guide material on process access telemetry, because the key question is not simply whether one process touched another, but whether the access pattern matches normal administrative or application behaviour.
What Defenders Should Watch For
Normal process interaction is common, so the practical challenge is separating expected automation from suspicious inspection or injection. Defenders should look for unusual access rights, repeated handle opens to the same sensitive target, and access from processes that do not normally need visibility into memory or internal state. Process lineage matters too, because a legitimate tool launched from an unexpected parent can be more suspicious than the tool itself.
Higher-risk targets include browsers, credential managers, authentication components, and security tooling. Those processes often hold valuable runtime material, so access to them can indicate attempts to harvest secrets, observe user activity, or blind detection. A mature monitoring strategy correlates process access with creation of child processes, remote-thread style behaviour, abnormal module loading, and other signs that the access was a staging step rather than a one-off diagnostic action.
For Windows environments, MITRE D3FEND Guide is useful context because it frames process-lineage analysis, process spawn analysis, and related defensive techniques as part of a broader detection model rather than a single event type.
When Process Access Becomes a Security Incident
Process access becomes materially risky when the target contains secrets, trusted session material, or security controls that can be altered from memory. At that point the event is no longer just an observation about one process touching another, it becomes a potential precursor to credential theft, code injection, or tampering with monitoring and authentication paths.
It is also more serious when the source process has no operational reason to inspect the target. A browser helper reaching into a security agent, a script host reaching into login components, or an unsigned process opening privileged system software should raise immediate suspicion. The concern is not only the access itself, but the trust boundary it crosses and the actions that become possible once memory and execution state are exposed.
Risk and Threat Considerations
Cross-process access is risky because it often bypasses file-based controls and reaches straight into live trust boundaries. Once a process can inspect another process’s memory or execution state, attackers may be able to steal in-memory secrets, hook behaviour, or interfere with security software before traditional controls notice the compromise.
Failure mechanism: The control assumption fails when a low-trust or compromised process is allowed to open a high-value target with permissions broad enough to read memory, query state, or inject activity. That creates an execution path for credential theft, reconnaissance, and tampering without needing to exfiltrate data from disk.
Impact: The result can be session hijacking, privilege escalation, loss of monitoring fidelity, or deeper compromise of browser, authentication, and endpoint protection processes. In practice, this can convert one foothold into broader access across user sessions and protected workflows.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Process access commonly supports code injection and memory tampering against another process. |
| T1003 — OS Credential Dumping | Reading another process's memory is a common path to stealing credentials from live sessions. | |
| Recommendation — Correlate suspicious cross-process access with injection indicators and investigate the target process immediately. Hunt for memory access to browsers, auth tools, and LSASS-like targets when credential theft is suspected. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Process-access telemetry and endpoint logs are needed to detect suspicious cross-process behaviour. |
| Recommendation — Centralize and retain endpoint process-access logs so abnormal target access can be investigated quickly. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Cross-process access events need review and correlation to separate normal diagnostics from attack activity. |
| SI-4 — System Monitoring | System monitoring is directly relevant to detecting unauthorized process inspection, tampering, or injection. | |
| Recommendation — Review process-access events with correlated host telemetry to identify suspicious access patterns. Monitor high-value processes for unauthorized handle opens, memory reads, and injection-related behaviour. | ||
Practitioner Guidance
What to verify: Treat process-access alerts as high context events. Verify the source process, its parent, its signer or trust level, and whether it normally needs that target process at all. If the target is a browser, authentication component, or security tool, require a stronger justification than for routine application-to-application interaction.
What to prioritise: Prioritise memory-reading and injection-style access over ordinary diagnostics. If the same host also shows suspicious child processes, unusual module loads, or tampering with security telemetry, escalate quickly because the access is likely part of an active attack chain rather than a benign inspection.
Practitioner takeaway: The key judgement is not whether process access happened, but whether the source should ever have been trusted to inspect that target in the first place.
Related resources from NHI Mgmt Group
- When does just-in-time access work better than standing privilege for agents?
- How should teams reduce AWS access sprawl without slowing engineering work?
- How can security teams make just-in-time access work for automated workflows?
- What breaks when access reviews are not tied to a lifecycle process?