Process Access is logged when one process opens or queries another process, often to inspect memory, tokens or handles. Defenders use it to detect credential theft, injection and process tampering. Watch for access to security tools, authentication processes and high-value system processes, especially when the source process is unusual or lacks a normal administrative context.
What process access means in detection terms
process access is logged when one process opens or queries another process, creating visibility into memory inspection, token handling, handle enumeration, and similar inter-process activity. That log line is valuable because many high-impact attacks on Windows and similar platforms start with one process reaching into another to steal secrets, tamper with execution, or probe security tooling.
In practical terms, the event matters most when the target is a security product, an authentication component, a browser, or a privileged system service. Those targets often hold material that attackers can reuse immediately, so the log is less about the API call itself and more about the relationship between the source process, the target process, and the privilege context in which the access occurred.
On the defensive side, process access is one of the clearest ways to observe behaviours that would otherwise be invisible at the command-line level, including credential dumping, process hollowing, injection staging, and attempts to disable or inspect monitoring tools. The value comes from correlation: the same access pattern can be benign in a debugger or EDR workflow, but suspicious when it originates from an unusual parent process or a user session that should not be touching protected processes.
What makes a process access event suspicious
The strongest signal is not simply that access happened, but that it happened unexpectedly. Access to LSASS, EDR services, browser processes, shell processes, or other high-value services is far more concerning when the source process is unsigned, recently dropped, running from user-writable paths, or operating outside a normal administrative workflow.
Context also matters. A legitimate admin tool, endpoint agent, or debugger may open other processes as part of its normal function, while malware often does so to read memory, extract tokens, or alter execution state. That is why defenders should compare the source image, command line, parent-child chain, integrity level, and timing against known-good operational patterns rather than treating every access event as equal.
For deeper technique mapping, Process Access often sits alongside process lineage, memory inspection, and handle abuse patterns described in MITRE D3FEND Guide, while Sysmon Guide helps teams tune the event source, filters, and downstream SIEM handling so the signal stays usable.
How defenders should use process access logs
Use the event as an investigation trigger, not as proof of compromise by itself. The first question is whether the source process should ever touch the target process, and the second is whether the access occurred with the kind of rights that enable memory reading, duplication, or tampering. If the answer to either question is no, the event deserves immediate triage.
Investigation should follow a short path: identify the source binary, determine whether it is expected on that host, check whether the target is a high-value security or authentication process, and look for nearby indicators such as token theft, unusual child processes, module loads, or follow-on network activity. That sequence usually tells you whether the access was part of routine administration or part of an intrusion chain.
If the organisation already uses policy baselines or alerting around process access, this is a good place to enforce allowlists for trusted admin tools and monitoring software. Where those baselines exist, they should be narrow enough to permit legitimate operations but strict enough to surface new access paths into protected processes.
Risk and Threat Considerations
Process access is a high-value telemetry source because it often exposes the moment an attacker moves from foothold to credential theft, injection, or tampering. The risk is highest when the target process contains reusable authentication material or when the source process can inherit the same trust context as a legitimate admin tool.
Failure mechanism: Attackers abuse process access to read memory, duplicate handles, inspect tokens, or interfere with a privileged or security-sensitive process, then reuse that access for persistence, lateral movement, or defense evasion.
Impact: Successful abuse can expose credentials, disable monitoring, corrupt security tooling, or provide a stepping stone into other systems through stolen sessions or tokens.
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 commonly supports memory tampering and injection workflows. |
| Recommendation — Map suspicious cross-process access to T1055 and hunt for injection follow-on activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Process-access logs are only useful when reviewed and correlated for abuse indicators. |
| Recommendation — Correlate process-access events under AU-6 to spot credential theft and tampering patterns. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | This detection relies on collecting and retaining process-access telemetry for analysis. |
| Recommendation — Centralise process-access logs under CIS-8 and retain them for threat hunting. | ||
Practitioner Guidance
What to verify: Confirm whether the source process is expected to access the target process in that environment, and verify that the access aligns with the host role, user role, and maintenance window. When the target is a security tool or authentication process, treat any mismatch as a priority investigation item.
Common mistake: Teams often alert on the event name alone and miss the more important question of whether the source, target, and access rights form a credible attack path. A low-volume but unusual access pattern into a protected process is often more valuable than a noisy burst of routine administrative activity.
Practitioner takeaway: The event becomes actionable when it connects an unusual source process to a sensitive target process under an access pattern that can plausibly expose secrets or alter execution, so always judge it by context and not by the log line in isolation.