Indirect Syscall

Expanded Definition

An indirect syscall is a Windows attack technique that attempts to reach kernel services without using the most obvious user-mode function path. Instead of calling a monitored API entry point directly, the code routes execution through an alternate path so that security tools depending on user-mode hooks may see less of the activity. In practice, this is less a formal feature than an evasion pattern used by threat actors, especially when they want to reduce visibility around memory allocation, process injection, or handle manipulation. The term is used mainly in offensive security and malware analysis, not as a standardized architecture concept, and definitions vary across vendors and write-ups. For a governance lens, NHI Management Group treats it as a detection-evasion technique that challenges endpoint telemetry rather than a legitimate kernel interface design. For broader control framing, the NIST Cybersecurity Framework 2.0 is useful because it emphasizes detection, monitoring, and response capabilities around adversarial activity.

The most common misapplication is treating every low-level syscall path as malicious, which occurs when teams confuse normal software behavior with deliberate hook evasion.

Examples and Use Cases

Implementing detection for indirect syscalls rigorously often introduces telemetry noise and analysis overhead, requiring organisations to weigh visibility gains against the cost of deeper endpoint inspection.

• Malware uses an indirect syscall to perform memory allocation before injecting a payload into another process.
• A loader routes execution around a user-mode hook so endpoint detection products have less context on the originating call chain.
• Post-exploitation tooling uses alternate syscall paths to reduce the likelihood of script, API, or hook-based monitoring seeing the action.
• Security researchers reproduce the technique in a lab to validate whether an EDR still captures kernel-relevant events even when user-mode interception is bypassed.
• Analysts compare direct calls, indirect calls, and unhooked libraries to understand whether an alert is caused by evasion or by a legitimate application pattern, using references such as MITRE ATT&CK for adjacent tradecraft context and CISA malware guidance for defensive response workflows.

Because usage is still evolving, defenders should avoid assuming one implementation pattern. Some threats rely on a bespoke syscall stub, while others borrow living-off-the-land components and alter execution flow only briefly. That distinction matters for memory forensics, because the observable symptom may be the bypass attempt rather than the syscall itself.

Why It Matters for Security Teams

Indirect syscalls matter because they reveal a gap between what endpoint tooling expects to see and what an attacker can actually execute. If a monitoring stack is overly dependent on user-mode hooks, attackers may be able to bypass detection while still performing high-risk actions in memory. This is especially relevant to teams defending against credential theft, ransomware staging, and post-exploitation automation, where quiet allocation and injection often precede the most damaging stage of an incident. The operational response usually involves layered telemetry, kernel-aware controls, and validation that detection does not stop at API interception. Where identity, NHI, or agentic AI surfaces exist, the same concern extends to agents or service identities that execute tools with elevated reach, because abuse can hide behind apparently normal process activity. Security teams should also align response logic with NIST Cybersecurity Framework 2.0 functions for detection and response, rather than relying on a single inspection point. Organisations typically encounter the full impact only after an intrusion has already progressed past initial access, at which point indirect syscall analysis becomes operationally unavoidable to determine how the execution was concealed.

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?