Attackers use Asynchronous Procedure Call to queue malicious code in a running thread so it executes indirectly inside another process. This can hide execution from simple process-creation monitoring and help with injection or evasion. Defenders should watch for unusual thread manipulation, remote memory writes, and code execution in processes that should not be hosting untrusted payloads.
How APCs turn code execution into indirect execution
asynchronous procedure call, or APCs, let one thread schedule work for another thread to run when that thread enters an alertable state. Attackers abuse that design by queueing malicious code into a live thread so execution happens indirectly inside a target process, rather than as a new process launch. That makes the activity blend into normal thread behaviour and can weaken simple process-creation detections.
The technique is useful because it shifts attention away from the obvious parent-child process chain and into lower-level execution flow. In practice, the attacker still needs a way to reach a thread, write or place code that the target can execute, and trigger the thread at the right moment. That is why APC use is often discussed alongside remote memory writes, thread injection, and other process-hollowing style tradecraft.
Because the payload runs in the context of another process, defenders should think in terms of execution provenance, not just process names. A benign-looking process can become the host for untrusted code, which means visibility tools need to correlate thread activity, memory changes, and subsequent behaviour inside the process rather than relying only on creation events.
What makes APC abuse attractive to attackers
APC-based execution is attractive when the goal is stealth, blending, or bypassing controls that key heavily off new process creation. It can support injection, code staging, or evasion when the attacker wants malicious logic to run inside a process that appears legitimate. In that sense, the value is not that APCs are inherently malicious, but that they provide an execution path that is easy to miss if monitoring is too narrow.
Attackers also like APCs because they fit into a broader set of trusted-execution abuses, where the operating system is used to deliver code into a context that defenders are less likely to question. The technique is especially relevant when combined with thread manipulation, memory allocation, and careful timing, because those supporting actions help the malicious APC land and execute cleanly.
For defenders, the important point is that the risk is not limited to one API or one event type. A successful APC technique usually implies a sequence of suspicious actions that should be evaluated together, not as isolated alerts.
What defenders should look for in APC-based injection
Detection works best when you treat APC use as a pattern of correlated behaviour. Unusual thread manipulation, remote memory writes, and code execution inside processes that should not host untrusted payloads are the core signals in the direct answer, and they remain the most practical triage points. Suspicious APC activity often becomes clearer when paired with unexpected memory permissions, odd thread state changes, or execution inside a process with no normal reason to run injected code.
Context matters more than the API call alone. Some software legitimately uses APCs, so the control challenge is separating expected asynchronous work from abnormal queuing into a process that is now being used as an execution vessel. That means baselining normal thread behaviour for key applications and looking for deviations in where code lands, which process hosts it, and whether the resulting execution path matches the software’s normal function.
Teams should also watch for cases where the host process is trusted but its memory or threads are not. A process can look normal at the service or application layer while still being used as a covert execution container, which is why telemetry from endpoint monitoring, memory inspection, and process lineage all matter.
Risk and Threat Considerations
APC abuse matters because it can convert a routine execution mechanism into a stealthy injection path. The main risk is reduced visibility: if defenders depend too heavily on process creation alerts, malicious code can run inside an existing process with fewer obvious indicators.
Failure mechanism: The attacker queues code into an alertable thread, combines that with memory manipulation or injection, and causes the payload to execute inside a legitimate process context. That weakens simple detection logic and can help the attacker blend into trusted process activity.
Impact: Successful abuse can enable covert execution, evasion of coarse monitoring, and follow-on actions inside a process that the organisation would normally trust.
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 | APC abuse is a process-injection technique that executes code in another process. |
| T1055.004 — Asynchronous Procedure Call | This sub-technique directly names the APC execution method described in the question. | |
| T1055.012 — Process Hollowing | APC abuse often appears in broader process-injection tradecraft alongside hollowing and related evasion. | |
| Recommendation — Map APC injection activity to T1055 and hunt for injected execution in the target process. Track APC queuing, alertable-thread execution, and suspicious cross-process code execution. Correlate APC activity with hollowing indicators and investigate abnormal memory state changes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | APC misuse is best surfaced by endpoint and process telemetry correlated across events. |
| Recommendation — Centralise and review endpoint telemetry for thread, memory, and process-injection indicators. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | APC injection is a monitoring problem that requires detecting abnormal execution and memory behaviour. |
| Recommendation — Monitor for unusual thread manipulation, remote memory writes, and unexpected in-process execution. | ||
Practitioner Guidance
What to prioritise: Correlate APC-related thread events with remote memory writes, unusual module or shellcode placement, and post-execution behaviour in the host process. If those signals line up, treat the alert as a likely injection or evasion attempt rather than as an isolated thread anomaly.
What good looks like: Your detections should answer three questions quickly: which thread was targeted, what code or memory region became executable, and whether that process should ever be hosting untrusted payloads. If you cannot answer all three, the investigation is too shallow for this technique.
Practitioner takeaway: APC abuse is hard to spot only when monitoring stops at process creation; the real defence is to track thread-level execution context and memory provenance together.
Related resources from NHI Mgmt Group
- Guide: MITRE ATT&CK Guide for Defenders
- How do attackers turn a supply-chain incident into wider NHI compromise?
- How do attackers operationalise stolen OAuth tokens at scale?
- Why do attackers often check model availability before trying to generate content?
- How do attackers turn stolen npm secrets into broader compromise?