TamperingSyscalls

TamperingSyscalls 

a proof of concept of 2 various techniques I have discovered and published a the code for. I will look to briefly describe these techniques.

The former is a syscall retrieval technique I originally discovered in June 2022 while stepping through a user-land application under a debugger in the presence of an EDR. I observed that the EDR would provide us with the correct SSN for that function in the RAX register (as it should). Thus if we set a hardware break-point before the syscall instruction, we could retrieve the SSN and use it for direct syscalls. I wrote a proof of concept for this but never bothered to utilize it as direct syscalls never did interest me.

EDRs must hook before or on the instruction that reveals the SSN (system service number). They almost always will return after determining if the nature of the call is malicious or not. They achieve this by inspecting the arguments in the registers and the stack. If the parameters passed to the function are determined to be malicious: they will terminate the application; else, they will restore the stack and registers and retrieve the SSN and restore execute the instruction after the hook.

.

 

Applying a hardware break-point on the syscall address on execution, allows us to throw an exception when we attempt to execute it. We can setup an exception handler which will namely obtain a copy of the CONTEXT, the state of various registers and other bits of information, when an exception is thrown.  As we put the break-point ON the syscall address, this means the RAX register is ours for reading and it will contain the SSN number.

This is the first technique I present which allows us to dynamically retrieve syscall numbers. Namely, there are a few NT functions we cannot retrieve as they are used to place the hardware break-point. 

The second technique I present is the ability to modify the arguments actually being used. As we have the break-point on the syscall instruction and full control over the registers and stack (as we are in our exception handler), we can modify them in order to point them to malicious instructions (subverting the user-land hooks). This will appear to be a legitimate syscall as it is! I will be interested to see what and if various detection's may come forth from this. 

There is also the opportunity to feed the EDR fake telemetry given that we can change the arguments of what is actually being called. We can pass in non-malicious arguments, hit our breakpoint, flow into the exception handler and replace them as discussed earlier.

 
I look forward to seeing what comes of this, as this is only the beginning.