Skip to content

16: Chapter 9 | Summary

VirtualAllocEx edited this page Aug 15, 2023 · 3 revisions

Summary

In this workshop we took a closer look at syscalls, direct syscalls and indirect sycalls. In detail, we covered the following topics

  • We learned the necessary basics of the Windows NT architecture to better understand what syscalls are in general and why they are needed in operating systems like Windows 10, which has a user-mode and kernel-mode architecture.
  • We learned about the user-mode API hooking defence mechanism, which is often used by EDRs to intercept the code execution flow associated with different types of APIs.
  • We learned about the concept of direct syscalls, how they can be used from a red team perspective, and their limitations.
  • We built a Win32 API loader that was used as a reference loader for further loader development.
  • We went down a level and made the transition from a Win32 API loader to a native API (NTAPI) loader.
  • We went again one level lower and made the transition from NTAPIs to direct sycalls and built a direct syscall loader based on hardcoded SSNs.
  • Finally, we made the transition from direct syscalls to indirect syscalls and built an indirect syscall loader based on hardcoded SSNs.

Limitations

In general, building a shellcode loader that uses indirect syscalls could definitely help to bypass EDRs in the context of shellcode execution. However, if your shellcode loader "only" uses indirect syscalls, there are some limitations.

  • Using indirect syscalls puts ntdll.dll on top of the stack, and the stack looks much more legitimate compared to a direct syscall dropper. However, this does not help in the case of an EDR that analyzes the entire call stack. So spoofing the whole call stack would be necessary.

  • Indirect syscalls have no impact at all on solving problems with unlegitimate RWX regions or unbacked memory regions. I think the module stomping technique can help solve this problem.

  • Also, indirect syscalls can help avoid EDR hooks in the context of your shellcode loader, but in the case of the implemented shellcode itself, e.g. Meterpreter shellcode does not use direct sycalls or indirect syscalls, this will not help. Therefore, it may help or make sense to additionally implement user mode unhooking, as this will also have a positive impact on the shellcode execution itself.