Calling Syscalls Directly from Visual Studio to Bypass AVs/EDRs
Last updated
Last updated
AVs/EDR solutions usually hook userland Windows APIs in order to decide if the code that is being executed is malicious or not. It's possible to bypass hooked functions by writing your own functions that call syscalls directly.
For a more detailed explanation of the above, read a great research done by @Cn33liz from @Outflank: https://outflank.nl/blog/2019/06/19/red-team-tactics-combining-direct-system-calls-and-srdi-to-bypass-av-edr/ - now you know what inspired me to do this lab.
With this lab, I wanted to follow along what Cn33liz did and go through the process of incorporating and compiling ASM code from the Visual Studio and simply invoking one syscall to see how it's all done by myself. In this case, I will be playing with NtCreateFile syscall as this will be enough to prove the concept.
Also, see my previous labs about API hooking/unhooking: Windows API Hooking, Bypassing Cylance and other AVs/EDRs by Unhooking Windows APIs
Add a new file to the project, say syscalls.asm - make sure the main cpp file has a different name as the project will not compile:
Navigate to project's Build Customizations:
Enable masm:
Configure the syscalls.asm file to be part of the project and compiled using Microsoft Macro Assembler:
In the syscalls.asm, let's define a procedure SysNtCreateFile with a syscall number 55 that is reserved for NtCreateFile in Windows 10:
The way we can find the procedure's prologue (mov r10, rcx, etc..) is by disassembling the function NtCreateFile (assuming it's not hooked. If hooked, just do the same for, say NtWriteFile) using WinDbg found in ntdll.dll module or within Visual Studio by resolving the function's address and viewing its disassembly there:
Disassembling the address of the NtCreateFile in ntdll - note the highlighted instructions and we can skip the test / jne instructions at this point as they are irrelevant for this exercise:
Once we have the SysNtCreateFile procedure defined in assembly, we need to define the C function prototype that will call that assembly procedure. The NtCreateFile prototype per MSDN is:
Once we have the prototype, we can compile the code and check if the SysNtCreateFile function can now be found in the process memory by entering the function's name in Visual Studio disassembly panel:
The above indicates that assembly instructions were compiled into the binary successfully and once executed, they will issue a syscall 0x55 that is normally called by NtCreateFile from within ntdll.
Before testing SysNtCreateFile, we need to initialize some structures and variables (like the name of the file name to be opened, access requirements, etc.) required by the NtCreateFile:
Once the variables and structures are initialized, we are ready to invoke the SysNtCreateFile:
If we go into debug mode, we can see that all the arguments required by the SysNtCreateFile are being pushed on to the stack - as seen on the right disassembler panel where the break point on SysNtCreateFile is set:
If we continue debugging, the debugger eventually steps in to our assembly code that defines the SysNtCreateFile procedure and issues the syscall for NtCreateFile. Once the syscall finishes executing, a handle to the opened file c:\temp\test.txt is returned to the variable fileHandle:
What this all means is that if an AV/EDR product had hooked NtCreateFile API call, and was blocking any access to the file c:\temp\test.txt as part of the hooked routine, we would have bypassed that restriction since we did not call the NtCreateFile API, but called its syscall directly instead by invoking SysNtCreateFile - the AV/EDR would not have intercepted our attempt to open the file and we would have opened it successfully.
