System Calls

Create By : Sher
What are windows APIs?

Syscalls are windows internals components that provide a way for windows programmer to interact or
develop the programs related to windows system . These programs can be used in ways such as
accessing specific services , reading or writing to a file, creating a new process in userland, or allocating
memory to programs , use cryptographic functions in your programs.

But syscalls are intermediatory when someone uses the windows API using win32. These syscalls are
also called native API for windows. The majority of syscalls are not officially documented by Microsoft ,
Thus we relies on other third party documentation. generally All syscalls returns NTSTATUS value
indicate its success or error, but It is important to note that while some NtAPIs return NTSTATUS , they
are not necessarily syscalls. e.g. : NtAllocateVirtualMemory() is syscalls that is actually runs under the
hood when we access the functions likes VirtualAlloc() or VirtualAllocEx() From WINAPI.

Here ntdll.dll File from windows plays important role, how? most of the native syscalls, which are called
are from ntdll.dll file. This syscalls have more advantages over standard WINAPI functions. This syscalls
functions from ntdll.dll provide more customizability over the parameter passed and arguments that
those functions will be accepting , Thus provide a ways for evading host-based security solutions.
Types of System Call

Device
Management

File Information
Management Management

Process Communication
Control

Types of system call

virtualAlloc() virtualAlloc() NtAllocateVirtualMemory()
Kernel32.dll Kernelbase32.dll ntdll.dll

Syscall

NtAllocateVirtualMemory()
Kernel Stuff
Function code
Introduction to System Call

User Programs

User Interface

System Calls

Program
I/O File System Comms
Control

Error
Resource Auditing Security
Management

Hardware
What is Windows System call?

A Windows syscall is made by some functions in the NTDLL library as a way to request a service

▪
from the kernel.

▪ The Windows syscall is the last step from user-mode to kernel-mode.

▪ In Windows, syscalls are not intended to ever be used by programmers.

Windows syscalls utilize a special system service number (SSN), which is placed in the eax
register. ○ SSNs are also known as syscall number or syscall ID .

References :
Github
j00ru
System Service Number (SSN)

Every Syscalls has special unique number given to it called SSN , this SSN number is used by
kernel to distinguish syscalls from other syscall .
For example, the NtAllocateVirtualMemory() syscall will have an SSN of 24 whereas
NtProtectVirtualMemory() will have an SSN of 80, these numbers are what the kernel uses to
differentiate NtAllocateVirtualMemory() from NtProtectVirtualMemory() .
What is a system call?

Technically speaking, a system call at the assembler level is an instruction that, after executing
code in Windows user mode in the context of the respective Windows API, enables the
temporary transition (transition CPU switch) from user mode to kernel mode.
The system call thus forms the interface between a process in user mode and the task to be
executed in the Windows kernel.
Why do you need system calls at all in an operating system that is divided into user mode
and kernel mode? Here are a few examples :

• Access to hardware such as scanners and printers

• Network connections for sending and receiving data packets
• Reading and writing files
The following example is intended to explain a little how system calls work under Windows
OS. The user wants to save text or code written in Notepad to the hard drive of the
device. To do this, the usermode process notepad.exe requires temporary access to the file
system and various device drivers. However, since both components are located in the
Windows kernel, access from user mode is not easily possible. To solve this problem, system
calls are used in Windows. These are programmatic instructions that enable a temporary
transition from user mode to kernel mode for a specific task in an application, e.g.
notepad.exe.
Each system call can be found via its own Syscall ID and is assigned to a specific native API
under Windows. However, the Syscall ID may vary from Windows version to Windows
version..
 Hooked Native API

NtCreateFile()
Ntdll.dll
Windows API Windows API
Notepad.exe
CreateFileW() CreateFileW()
Kernel32.dll Kernelbase32.dll

user mode (Ring 3)

Execute
System Call
kernel mode (Ring 0)

Execute
KiSystemCall64

System Service Descriptor Table (SSDT)

Execute
Compare or search for respective execute
NtCreateFile()
function code of NtCreateFile()
Function Code

The Figure shows the transition from user mode to kernel mode in the context of saving a file within notepad.exe
Protection Rings
What is a system call?

Technically speaking, a system call at the assembler level is an instruction that, after executing
code in Windows user mode in the context of the respective Windows API, enables the
temporary transition (transition CPU switch) from user mode to kernel mode.
The system call thus forms the interface between a process in user mode and the task to be
executed in the Windows kernel.
Why do you need system calls at all in an operating system that is divided into user mode
and kernel mode? Here are a few examples :
• Access to hardware such as scanners and printers
• Network connections for sending and receiving data packets
• Reading and writing files
What is a system call?

Technically speaking, a system call at the assembler level is an instruction that, after executing
code in Windows user mode in the context of the respective Windows API, enables the
temporary transition (transition CPU switch) from user mode to kernel mode.
The system call thus forms the interface between a process in user mode and the task to be
executed in the Windows kernel.
Why do you need system calls at all in an operating system that is divided into user mode
and kernel mode? Here are a few examples :
• Access to hardware such as scanners and printers
• Network connections for sending and receiving data packets
• Reading and writing files
The above figure shows the technical principle of System Calls using the above example
with Notepad. So that the saving process can be carried out in the context of the user mode
process notepad.exe, the first step is to access the Kernel32.dll and call the Windows API
WriteFile(). In the second step, Kernel32.dll accesses Kernelbase.dll in the context of the
same Windows API. In the third step, the Windows API WriteFile() accesses the native API
NtCreateFile() via Ntdll.dll. The Native API contains the technical instructions for initiating
the system call (System Call ID) and, after execution, enables the temporary transition
(Transition - CPU Switch) from user mode (Ring 3) to kernel mode (Ring 0).
The System Service Dispatcher aka KiSystemCall / KiSystemCall64 is then called in the
Windows kernel, which is responsible for querying the respective function code in the
System Service Descriptor Table (SSDT) ​based on the executed System Call ID (index
number in the EAX register). After the function code for the affected system call has been
identified through collaboration between the System Service Dispatcher and the SSDT, the
task is executed in the Windows kernel.
Working of a System Call

User Mode

Get System Call Return from System Call

User Process Executing

Kernel Mode

Execute System Call

When the process is under execution process executes under user mode, but when the process
requires some OS resources to complete the task, the process makes a system call.
System calls in OS are executed in kernel mode on a priority basis.
On completion of the system call, the control is passed to process in user mode.
The process continues the execution in user mode.
Types of System Call

1. Process Control: It handles the system calls for process creation, deletion, etc. Examples
of process control system calls are: Load, Execute, Abort, and Wait for Signal events for
process.

2. File Management: File manipulation events like Creating, Deleting, Reading Writing etc.
are being classified under file management system calls.

3. Device Management: Device Management system calls are being used to request the
device, release the device, and logically attach and detach the device.

4. Information Maintenance: This type of system call is used to maintain the information
about the system like time and date.

5. In order to have inter-process communications like send or receive the message, create
or Communications: delete the communication connections, to transfer status
information etc. communication system calls are used.
 Types of System Call Windows Linux

- CreateProcess() - fork()
- ExitProcess() - exit()
Process Control - WaitForSingleObject() - wait()
- CreateProcess() / ShellExecute() - exe()
- GetCurrentProcessID() - getpid()
- CreateFile() - open()
- ReadFile() - read()
- WriteFile() - write()
File Management
- CloseHandle() - close()
- SetFilePointer() - lseek()
- DeleteFile() - unlink()
- MoveFile() - rename()
- VirtualAlloc() / VirtualFree() - brk() / sbrk()
- SetConsoleMode() - ioctl()
Device Management - ReadConsole() - read()
- WriteConsole() - write()
- MapViewOfFile() - mmap()
- GetTokenInformation() - getgid()
- GetSystemTime() - time()
- SetTimer() / SetWaitableTimer() - alarm()
Information Maintenance - Sleep() - sleep()
- GetUserName() / - getuid()
LookUpAccountName()
 Types of System Call Windows Linux
- CreatePipe() - pipe()
Communication
- CreateFileMapping() - shmget()
- CreatePipe() - pipe()
- CreateFileMapping() - shmget()
- WSASocketA() - socket()
- bind() - bind()
Communication Calls
- listen() - listen()
- WSAAccept() - accept()
- WSAConnect() - connect()
- WSASend() / WSARecv() - send() / recv()
- CreateDirectory() - mkdir()
- RemoveDirectory() - rmdir()
- SetCurrentDirectory() - chdir
* Directory Management - GetFileAttributesEx() - stat()
- GetInformationByHandle() - fstat()
- CreateHardLink() - link()
- CreateSymbolicLink() - symlink()
- SetFileAttributes() / SetSecurityInfo() - chmod()
* Security and access control - SetSecurityInfo() - chown()
The following example is intended to explain a little how system calls work under Windows
OS. The user wants to save text or code written in Notepad to the hard drive of the
device. To do this, the usermode process notepad.exe requires temporary access to the file
system and various device drivers. However, since both components are located in the
Windows kernel, access from user mode is not easily possible. To solve this problem, system
calls are used in Windows. These are programmatic instructions that enable a temporary
transition from user mode to kernel mode for a specific task in an application, e.g.
notepad.exe.
Each system call can be found via its own Syscall ID and is assigned to a specific native API
under Windows. However, the Syscall ID may vary from Windows version to Windows
version..
What is a Direct System Call?

This is a technique that allows an attacker (Red Team) to execute malicious code, e.g. shellcode,
in the context of APIs under Windows in such a way that the respective system call is not
obtained via Ntdll.dll, but directly as an assembly instruction is implemented in the .text region
of the malware, for example . Hence the name Direct System Calls.
Compared to the previous illustration in the System Calls chapter, the following illustration
shows the principle of direct system calls under Windows in a simplified manner. It can be seen
that the user mode process Malware.exe does not obtain the system call for the native API
NtCreateFile() via Ntdll.dll as normally intended, but instead has implemented the instructions
necessary for the system call.
 Windows API Windows API Hooked Native API

Malware.exe CreateFileW() CreateFileW() NtCreateFile()

Kernel32.dll Kernelbase32.dll Ntdll.dll
Execute
System Call
User mode (Ring 3)

Kernel mode (Ring 0)

Execute
KiSystemCall64

System Service Descriptor Table (SSDT)

Execute
Compare or search for respective execute
NtCreateFile()
function code of NtCreateFile()
Function Code

The Figure shows the transition from windows user mode to kernel mode in the context of
executing malware with implemented direct system calls .
Why Direct System Calls?

To protect against malware, both antivirus products (AV) and endpoint detection and response
(EDR) products rely on different defense mechanisms. In order to be able to dynamically examine
potentially harmful code in the context of Windows APIs, most EDRs today implement the
principle of user mode API hooking. To put it simply, this is a technique in which code that is
executed in the context of a Windows API, e.g. VirtualAlloc() or the associated native API
NtAllocateVirtualMemory(), is intentionally redirected by the EDR into the EDR's own
"Hooking.dll". The following types of hooking can be distinguished under Windows:

• Inline API hooking

• Import Address Table (IAT) hooking

• SSDT Hooking (Windows Kernel)

In the time before the introduction of Kernel Patch Protection (KPP) aka Patch Guard, it was
possible for antivirus products to implement their hooks in the Windows kernel, for example using
SSDT hooking. Microsoft prevented this with Patch Guard for reasons of operating system
stability. Most of the EDRs I analyzed rely primarily on inline API hooking. Technically speaking, an
inline hook is a 5-byte assembly instruction (also called jump or trampoline) that causes a redirect
to the "Hooking.dll" of the EDR before the system call is executed in the context of the respective
native API is done. The redirection from the "Hooking.dll" back to the system call in the Ntdll.dll
only occurs if the executed code analyzed by the "Hooking.dll" was classified as not
harmful. Otherwise, the execution of the corresponding system call will be prevented by the
Endpoint Protection (EPP) component of an EPP/EDR combination. The following figure shows a
simplified view of how usermode API hooking works using EDR.
 Hooked Native API

NtCreateFile()
Ntdll.dll
Windows API Windows API
Notepad.exe
CreateFileW() CreateFileW() EDR
Kernel32.dll Kernelbase32.dll
Hooking.dll

User mode (Ring 3)

Execute
Kernel mode (Ring 0) System Call

Execute
KiSystemCall64

Execute System Service Descriptor Table (SSDT)

NtCreateFile() Compare or search for respective execute

Function Code function code of NtCreateFile()

The Figure shows the principle of EDR user mode API-Hooking on a high level
Indirect Syscalls

The indirect syscall technique is more or less an evolution of the direct syscall technique. Compared
to direct syscalls, indirect syscalls can solve the following EDR evasion problems

Firstly, the execution of the syscall command takes place within the memory of the ntdll.dll and is
therefore legitimate for the EDR.
On the other hand, the execution of the return statement takes place within the memory of the
ntdll.dll and points from the memory of the ntdll.dll to the memory of the indirect syscall assembly.

Compared to the direct syscall POC, simplified, only a part of the stub from the Native API is
implemented and executed directly in the indirect syscall assembly itself, while the syscall
statement and return are executed in the ntdll.dll memory. The following diagram should help you
to understand the concept of indirect syscalls, bearing in mind that it is a simplified representation.
Insights :
Various experiments with different EDRs have shown that direct syscalls can still work, but are also
increasingly detected depending on the EDR. Based on IOCs in the context of direct syscalls,
indirect syscalls can be a useful solution, as they solve the following problems in comparison
• Firstly, the execution of the syscall command takes place within the memory of the ntdll.dll and is
therefore legitimate for the EDR.
• On the other hand, the execution of the return statement takes place within the memory of
ntdll.dll and points from the memory of ntdll.dll to the memory of the indirect syscall assembly.
This behaviour is at least more legitimate than the behavior with direct syscalls, but can still lead to
IOCs depending on the EDR, e.g. if the EDR also checks the call stack.

Indirect syscalls are an improvement over direct syscalls, but have their limitations, and also have
certain IOCs that are now used by EDR vendors to generate detection rules. For example, with
indirect syscalls it is possible to spoof the return address, which places the memory address of the
subsequent return at the top of the call stack and bypass the EDR's return check. However, if an
EDR is using ETW, it can additionally check the call stack itself for improper behavior. Indirect
syscalls alone are no longer sufficient for EDR evasion in case of an EDR also uses ETW, and you
need to take a closer look at call stack spoofing
 Windows API Hooked Native API
Windows API

Malware.exe CreateFileW() NtCreateFile()

CreateFileW()
Kernel32.dll Ntdll.dll
Kernelbase32.dll
Mov r10, rcx
syscall
Mov eax, SSN
return
Jmp to syscall
address in ntdll.dll
User mode (Ring 3)

Kernel mode (Ring 0)

Execute
KiSystemCall64

System Service Descriptor Table (SSDT)

Execute
Compare or search for respective execute
NtCreateFile()
function code of NtCreateFile()
Function Code

The Figure shows the transition from windows user mode to kernel mode in the context of
executing malware with implemented indirect system calls .
Direct VS Indirect Syscalls

1. Implementation method :
- Direct syscalls : Implement the syscall instruction directly in assembly code or shellcode
within the program's memory space.
- Indirect syscalls : Use a more sophisticated technique that executes critical operations like
the syscall and return statements within the memory of ntdll.dll.

2. Memory location of execution :

- Direct syscalls : Execute the syscall from the memory area of the malware or shellcode
loader (.text region).
- Indirect syscalls : Execute the syscall from within the legitimate ntdll.dll memory space.
3. Detection evasion :
- Direct syscalls : May be detected by advanced EDRs that can determine if the return
statement is executed outside ntdll.dll memory.
- Indirect syscalls : More difficult to detect as they mimic standard Windows behavior by
executing within ntdll.dll memory.

4. System compliance :
- Direct syscalls : Less compliant with standard Windows behavior.
- Indirect syscalls : More closely align with normal Windows operating behavior, making
them more sophisticated in terms of system compliance.

5. Implementation complexity :
- Direct syscalls : Generally simpler to implement, often using tools like SysWhispers or
custom assembly code.
- Indirect syscalls : More complex to implement, requiring techniques to execute
within ntdll.dll memory.
 References

Github Redops
GitHub
Youtube
StackOverFlow
Github
FluxSec
Hadess
SysDig
iRed.team
GcCyberMonks

RedOps Alice

t.me/ch4mr0sh