Posts

Detecting Indirect Syscalls from Userland, A Naive Approach.

-
Image
Our goal is to detect indirect syscalls. Indirect syscalls have taken the red teaming community by storm due to the newfound ability of EDRs to detect direct syscalls. To understand how to catch them, we must first understand a bit about them. For example (have a look at SysWhispers for a pratical implmentation) mov r10, rcx mov rcx, <SSN> syscall ret Various individuals utilized instrumentation callbacks, as documented in these two blog posts.  Instrumentation callbacks are a post-op syscall hook that allows a user to execute a specified function before the kernel returns execution to the userland process. There's a great article on CodeProject which discusses this. The premise for these detections identifies where the syscall instruction comes from; if it is not NTDLL/win32u (the only 2 DLLs where syscall instructions should originate), then it is most likely a direct syscall. Indirect syscalls sought to resolve this by just going to the syscall, and what this means is onc
Post a Comment
Read more

Hardware Breakpoints for Malware

-
Our task is to trivially hook functions and diver the code flow as needed, and finally remove the hook once it is no longer need... Check out my article for Vx-Underground: Black Mass Volume 1 ; I discuss various aspects and use cases of hardware breakpoints; including userland evasion techniques (TamperingSyscalls2) . You can find the associated code under my Github with C and C++ implementations.
Post a Comment
Read more

D-Generating EDR Internals, Part 1

-
Recently,  @JonasLyk  released  D-Generate , a polyglot that utilises DTrace to provide users with introspection into the system calls made by: the entire system, a specific application specified by the PID or image file name. It would help if the reader got set up with the  instructions and  downloaded the  associated symbols  necessary. Furthermore, if possible, the reader should set up a virtual machine without any security solutions to observe unbiased behaviour (a critical step to determine whether the observed behaviour is that of the security product or the windows kernel). Another possible step alternatively is to modify a clone of our current boot configuration entry. bcdedit /copy {current} /d "Local Debug" bcdedit /set {bd8e4076-eec8-11ec-9dec-uniqueid} dtrace on (Ensure "Local Debug" is selected on reboot) A few reasons for the express approval of such a tool include but are not limited to: It is trivial to enable DTrace with a simple  bcdedit /set dtrac
Post a Comment
Read more

Fixing our Call Stack

-
 In response to a valid caveat pointed out by  Chetan  ( here and here ) in regards to TamperingSyscall 's, he previously pointed out that some EDRs may check the origin of various problematic NT API function calls; if they originated from an unbacked RX (Read/Executable) region, the function call would be marked as malicious and potentially killed. Thus this short blog post will look to detail how it is possible to use an "indirect syscall" (if that is the correct terminology).  In the previous posts, we detail the basic application and usage of TamperingSyscalls. When making function calls in Windows using the Win32 API, more often than not, they will eventually call a function in ntdll.dll. As such, kernel32.VirtualAlloc will call kernelbase.VirtualAlloc, which in turn calls ntdll.NtAllocateVirtualMemory. In TamperingSyscalls, we call ntdll.NtAllocateVirtualMemory directly, a possible IoC.  It is pretty effortless to have the function call originate from the Win32 coun
Post a Comment
Read more