An indirect syscall is a way of reaching kernel functionality without using a visibly hooked user-mode function entry point. Malware uses it to reduce the chance that endpoint products will intercept the call, making memory allocation, injection, and similar actions harder to detect.
How indirect syscalls work
An indirect syscall is a kernel invocation path that avoids a visibly hooked user-mode function entry point. Instead of calling the ordinary API stub in the usual way, the process reaches the syscall interface by another route, which can reduce the chance that user-mode monitoring will see the transition point that many products instrument.
This matters because the technique does not change what the system call does, it changes how the request gets to the kernel. That distinction is important in intrusion analysis: defenders may see the outcome, such as memory allocation or injection activity, without seeing the expected user-mode API call that would normally be easiest to intercept.
Why attackers use it
Indirect syscalls are attractive when an operator wants to bypass hooks placed in user space. They are commonly associated with EDR evasion, especially where the defender depends on API interception, inline patching, or similar user-mode inspection points to observe suspicious activity.
The technique is most useful during actions that would otherwise stand out, including process injection, remote memory operations, and staged payload execution. It is part of a wider set of tradecraft that tries to reduce telemetry and complicate the link between observed behaviour and the code path that caused it.
For a broader view of that defensive problem, see EDR Evasion and Defence Guide, which covers unhooking, syscalls, ETW tampering, and the common ways sensors get blinded.
Detection and defensive interpretation
Because the normal user-mode call chain may be bypassed, defenders should not rely on a single API hook as proof that an action did not occur. The better question is whether the endpoint still exposes the surrounding behavioural signals, such as unusual memory permissions, suspicious thread creation, injection patterns, or kernel-observable effects that do not match the expected application behaviour.
Indirect syscalls are therefore best treated as an evasion indicator, not a standalone verdict. In practice, the same host may still reveal process ancestry anomalies, access patterns to sensitive processes, or telemetry gaps that show the monitoring layer was intentionally avoided or weakened.
That defensive logic fits well with the broader endpoint-control model described in the NIST SP 800-53 Rev 5 Security and Privacy Controls and the adversary-technique mapping in the MITRE ATT&CK Enterprise Matrix.
Defensive hardening and response
Indirect syscalls are most effective when defenders depend too heavily on user-mode interception alone. Hardening therefore means combining endpoint telemetry, tamper resistance, kernel-aware controls, and validation that security tooling is still seeing the behaviours it is supposed to see.
Response should focus on whether the technique was used as part of a broader compromise path. If indirect syscalls supported injection or memory manipulation, analysts should review the affected process tree, related network activity, and any persistence or privilege escalation that followed. The operational goal is not just to spot the bypass, but to understand what the bypass enabled.
Where the issue is specifically about protecting security tooling and seeing through blinded sensors, the concepts in EDR Evasion and Defence Guide are directly relevant because it ties syscall abuse to the surrounding evasion patterns defenders need to detect.
Risk and Threat Considerations
Indirect syscalls matter because they are a visibility problem as much as a technical execution trick. They can let malware perform sensitive actions while sidestepping the monitoring point that defenders expect to inspect, which creates a gap between what happened and what telemetry records.
Failure mechanism: The attacker routes kernel-bound activity through a path that avoids or undermines user-mode hooks, reducing the chance that endpoint tools will observe the call at the place they normally instrument.
Impact: Memory allocation, code injection, and related hostile actions can proceed with less friction, which can delay detection and make compromise analysis harder after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Indirect syscalls often support injection and evasive process manipulation. |
| Recommendation — Map syscall-bypass activity to process-injection techniques and hunt for anomalous memory and thread behaviour. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | The term is about defeating endpoint visibility and monitoring hooks. |
| SI-7 — Software, Firmware, and Information Integrity | The technique is used to evade or weaken security tooling and its integrity assumptions. | |
| Recommendation — Validate that monitoring still captures suspicious memory and execution behaviour across telemetry layers. Apply integrity checks to endpoint tooling and investigate signs of tampering or hook removal. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Not materially applicable to indirect syscalls. |
| Recommendation — Omit. | ||
Practitioner Guidance
What to watch for: Treat indirect syscalls as a signal that endpoint visibility may be incomplete, especially when the same host also shows injection behaviour, anomalous memory activity, or evidence of tamper resistance being bypassed. The key judgement is whether the endpoint still produces enough trustworthy telemetry to support detection and response.
Practitioner takeaway: A robust detection strategy should assume that user-mode hooks can be bypassed and should validate security outcomes from multiple telemetry layers, not a single interception point.
Related resources from NHI Mgmt Group
- How should security teams reduce indirect prompt injection risk in AI systems?
- When does indirect prompt injection become a business risk rather than a technical curiosity?
- Why do indirect prompt injections matter for IAM and NHI governance?
- Why is indirect prompt injection harder to defend than XSS?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org