An indirect function call is a programming call that reaches a target function through a pointer, reference, table entry, or similar indirection rather than naming the function directly. It is used in languages and binaries that support dynamic dispatch, callbacks, or jump tables, and it can expand the attack surface when control of the target address or table entry is compromised.
How indirect function calls work
An indirect function call resolves the callee at runtime instead of embedding a fixed function name or address in the call site. That indirection is what enables callbacks, virtual dispatch, plug-in patterns, and jump tables, but it also means the call target is only as trustworthy as the pointer, table entry, or dispatch state that selects it.
Because the destination is data-driven, the security question is not just “what does the function do?” but “who can influence the target selection?” If an attacker can alter a function pointer, vtable entry, dispatch table, or other control structure, the call can be redirected into unintended code paths.
Why indirect calls matter in security analysis
Indirect calls are important because they blur the line between code and data. A direct call is comparatively easy to reason about, while an indirect call depends on runtime state that may come from memory, object layout, ABI conventions, or dynamic linking. That makes them a common place to look for control-flow integrity issues, corruption bugs, and exploitation primitives in native software.
They also expand the attack surface in binaries that accept untrusted input, parse complex formats, or manipulate object graphs. If a memory-safety bug, logic flaw, or deserialization issue lets an adversary overwrite a pointer or dispatch entry, the indirect call can become a reliable pivot from corruption to execution.
For broader control and verification context, teams often map this kind of risk to NIST SP 800-53 Rev 5 Security and Privacy Controls when they need formal guidance on access control, integrity, and secure software controls.
Common failure modes and exploitation paths
The main failure modes are pointer corruption, stale references, table hijacking, and unintended type confusion. An attacker does not need to replace the entire program flow, only to influence the value that an indirect call uses when selecting its target.
That is why indirect calls often show up in exploit chains after an initial memory corruption. Once control data is altered, the next dispatch may transfer execution into attacker-chosen code gadgets, error handlers, or other reachable functions that were never intended for that context.
From a threat-hunting perspective, the broader execution pattern is similar to other adversary techniques that abuse legitimate program behavior. The MITRE ATT&CK Enterprise Matrix is useful for understanding how control-flow abuse can support privilege escalation, execution, and post-compromise movement.
How to reduce exposure and verify control-flow integrity
Security hardening starts with minimizing writable control data, using memory-safe languages where practical, and enabling compiler and platform protections that reduce the chance of pointer overwrite or code-reuse abuse. Indirect calls also deserve extra scrutiny in code review because they frequently hide behind abstractions that look harmless at the source level.
Static analysis, fuzzing, sanitizers, and runtime integrity checks help reveal whether a dispatch path can be reached with malformed state. In mature environments, reviewers also trace ownership of function pointers, callback registration, and table mutation so that only trusted components can alter call targets.
For teams building software with these risks in mind, OWASP SAMM helps embed secure design and verification practices into the development lifecycle, while SLSA strengthens provenance for the components that implement or consume dynamic dispatch paths.
Detection, review, and defensive coding patterns
Detection focuses on abnormal control transfer, corrupted object state, and suspicious runtime behavior around callback registration or dispatch tables. If a post-exploitation review finds an unexpected indirect branch, the next question is whether the target was ever supposed to be mutable, reachable, or derived from untrusted state.
Defensive coding patterns include validating pointers before use, reducing mutable shared state, constraining callback registration, and keeping dispatch tables read-only after initialization where possible. When the codebase is large, the safest approach is to treat indirect calls as a sensitive boundary, not a neutral abstraction.
Operational controls such as hardened baselines and secure build settings can reinforce those measures. The CIS Benchmarks are often used to lock down platform settings that make memory corruption and code execution harder to convert into a working exploit.
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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-16 — Memory Protection | Indirect calls rely on protected control data and pointer integrity. |
| SI-7 — Software, Firmware, and Information Integrity | Integrity controls help detect tampering that can redirect indirect call targets. | |
| Recommendation — Use SI-16 to protect control data and reduce hijackable indirect branches. Apply SI-7 to detect tampering that could alter dispatch targets or control structures. | ||
| MITRE ATT&CK | T1055 — Process Injection | Control-flow abuse often appears in exploitation and post-compromise execution chains. |
| Recommendation — Map suspicious control-transfer anomalies to T1055 and investigate execution redirection. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Logging supports detection of anomalous execution paths and exploit attempts involving indirect calls. |
| Recommendation — Centralize and review logs for abnormal control-flow and exploit indicators. | ||
Related resources from NHI Mgmt Group
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 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org