Listen to this Post
Introduction:
In the perpetual cat-and-mouse game of cybersecurity, Red Teams constantly innovate to bypass modern security controls. The direct invocation of system calls (syscalls) from malicious code has emerged as a premier technique to evade Endpoint Detection and Response (EDR) solutions, which often monitor higher-level API calls. By combining this with Beacon Object Files (BOFs)—small, post-exploitation payloads for Cobalt Strike—attackers achieve a new level of stealth and efficiency.
Learning Objectives:
- Understand the methodology for converting standard BOFs to utilize direct syscalls.
- Learn to set up and use the InlineWhispers3 framework for syscall management.
- Implement API-to-syscall swaps in a practical BOF example to evade EDR hooks.
- Identify key OPSEC considerations when employing these techniques.
- Analyze Blue Team mitigations and detection strategies for this tradecraft.
You Should Know:
1. Converting BOFs to the TrustedSec Format
Before integrating syscalls, BOFs often need to be converted into a compatible format. The TrustedSec BOF format is a common standard that simplifies the integration of advanced features like direct syscall invocation.
Verified Command/Tutorial:
Clone the SafeHarbor BOF conversion tool repository git clone https://github.com/covertswarm/SafeHarbor-BOF-Conversion-Example cd SafeHarbor-BOF-Conversion-Example Review the source code differences, particularly the change from 'go' to 'datap' for data parsing and the inclusion of the InlineWhispers3 header. cat src/example.c | grep -A 5 -B 5 "datap"
Step-by-Step Guide: The primary change when converting a BOF is in how it handles input arguments. The standard `go` function, which uses BeaconDataParse, is often replaced with a function using the `datap` parser from the TrustedSec BOF template. This involves modifying the function signature and argument parsing logic to align with the new template, ensuring compatibility with the syscall invocation framework.
2. Setting Up InlineWhispers3 for Syscall Management
InlineWhispers3 is a crucial tool that simplifies the implementation of direct syscalls by providing a macro-based system to manage the assembly stubs needed for each syscall. Using the correct repository is vital to avoid build issues.
Verified Command/Code Snippet:
// In your BOF's header file, include the InlineWhispers3 header include "path/to/InlineWhispers3/InlineWhispers3.h" // Use the provided macros to define your syscall stubs. // For example, to define NtAllocateVirtualMemory: DEFINE_SYSCALL(NtAllocateVirtualMemory, 0x18);
Step-by-Step Guide:
- Clone the official InlineWhispers3 repository: `git clone https://github.com/ShorSec/InlineWhispers3`.
- Include the `InlineWhispers3.h` header in your BOF’s source code.
- Use the `DEFINE_SYSCALL` macro for each Windows API function you wish to call directly. The macro requires the function name and its corresponding syscall number (e.g., `0x18` for `NtAllocateVirtualMemory` on a specific Windows 10 build).
- During compilation, the tool will automatically inline the necessary assembly code to invoke the syscall directly.
3. Performing API-to-Syscall Swaps in BOF Code
The core of the evasion technique is replacing standard Windows API calls (like NtAllocateVirtualMemory) with their direct syscall equivalents, bypassing any userland hooks placed by EDRs.
Verified Code Snippet (Before and After):
// BEFORE: Using the standard, potentially hooked, API call. NTSTATUS status = NtAllocateVirtualMemory(GetCurrentProcess(), &baseAddress, 0, ®ionSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); // AFTER: Using the direct syscall stub defined by InlineWhispers3. NTSTATUS status = SYSCALL_NtAllocateVirtualMemory(GetCurrentProcess(), &baseAddress, 0, ®ionSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
Step-by-Step Guide: Identify all Windows Native API calls (functions from ntdll.dll) in your BOF source code. For each one, replace the standard call with the corresponding `SYSCALL_` prefixed function generated by the InlineWhispers3 macro. This replacement forces the CPU to transition to kernel mode via the `syscall` instruction without executing the potentially monitored code in ntdll.dll.
4. OPSEC: Avoiding Common Detection Pitfalls
While powerful, direct syscalls are not a silver bullet. Operational security (OPSEC) is critical to avoid detection by advanced EDRs and security analysts.
Verified Commands/Mitigations:
Syscall Number Randomization: Some EDRs detect static syscall numbers. Use tools to dynamically resolve syscall numbers at runtime based on the OS version.
Indirect Syscall Return: Instead of returning directly to userland, some techniques return to a different, clean location to break call stack analysis.
Monitor for `syscall` Instructions from Non-ntdll Memory: Blue Teams can hunt for processes where the `syscall` instruction is executed from memory regions outside of a legitimate `ntdll.dll` module. This is a strong indicator of this technique.
5. Blue Team Mitigations: Hunting for Syscall BOFs
Defenders must adapt their detection capabilities to identify the use of direct syscalls from malicious payloads like BOFs.
Verified EDR Query (Pseudocode – Elastic EQL example):
sequence by process.pid [process where process.name : "beacon.exe" or process.pe.original_file_name : "beacon.exe"] [library where dll.name : "ntdll.dll" and event.action : "load"] [process where syscall.name != null and not library.path : "C:\Windows\System32\ntdll.dll"]
Step-by-Step Guide: This detection logic looks for a sequence of events: first, a Cobalt Strike Beacon process is identified; second, `ntdll.dll` is loaded (a normal event); and third, a system call is observed that did not originate from the legitimate `ntdll.dll` on disk. This discrepancy is a key signature of direct syscall invocation from a BOF or similar shellcode. Defenders should implement such analytics in their EDR or SIEM platforms.
What Undercode Say:
- Syscalls are a Tactical Advantage, Not an Invincibility Cloak. They effectively bypass userland hooks, a primary defense of many EDRs, but they are not undetectable. The focus should be on raising the cost of detection for the Blue Team.
- The Real Skill is in the OPSEC Wrapper. The implementation of the technique is just as important as the technique itself. Poor OPSEC, like using hardcoded syscall numbers or ignoring call stack artifacts, will lead to swift detection.
The analysis from the field indicates that while frameworks like InlineWhispers3 have democratized the use of direct syscalls, their effective use requires a deep understanding of both Windows internals and defensive telemetry. For Red Teams, this is a necessary evolution in the face of sophisticated EDR. For Blue Teams, it underscores the critical need to move beyond simple API hooking and develop detection logic based on lower-level kernel telemetry and behavioral anomalies, such as syscalls originating from unexpected memory regions. The arms race is escalating from the application layer down to the system call interface.
Prediction:
The widespread adoption of direct syscall techniques will force EDR vendors to rapidly enhance their kernel-mode drivers and ETW (Event Tracing for Windows) integrations for deeper introspection. We predict a shift towards behavioral detection models that analyze the context and sequence of syscalls, rather than just their origin. Furthermore, expect a rise in counter-techniques from EDRs, such as kernel-level syscall hooking (where possible) and the use of Machine Learning to identify malicious syscall patterns that deviate from normal OS behavior, making static BOFs less effective over time and pushing attackers toward more dynamic, AI-powered evasion methods.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Ibai Castells – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
