Focusing on x64, this is not completely applicable to x86/WOW64

The instruction that makes the transition between userland and kernel land. To pull these off, the CPU registers need to be aligned for the respective call, then a syscall instruction is made, then a return instruction is done.

Always follow this template.

4C 8B D1                      mov     r10, rcx
B8 ?? ?? ?? ??                mov     eax, ??
0F 05                         syscall
C3                            retn

Funny enough, syscall stubs are literal nt functions. Nt Functions are the syscall stub format, but with the ?? filled in with the respective syscall ID.

Why syscalls?

It is the lowest level in the userland that we can go for many of the APIs that our malware will use. Beyond this is the kernel, which requires loading a driver. By using syscalls we avoid ALL userland hooks.

Direct, Static

Done via syswhispers, a tool that provides the syscall stubs for the operating system it is run on. I do not like hard coding multiple syscalls for a specific operating system, so I do not know much else about this technique.

Direct, Dynamic

Dinvoke

Will read and map ntdll from disk into memory to read the Nt functions. Recall nt functions are literally syscall stub format; dinvoke will read and map the nt function that you need into memory, and then create a delegate as a function pointer.

• Pros:
  • Clears the mapped ntdll is cleared
  • Works on WOW64
• Cons:
  • To map ntdll into memory, it (dynamically) utilizes potentially hooked API calls.
  • The mapped syscall is in a manually mapped memory page; may be caught by memory scanner, and when the syscall is utilized, the kernel will callback to that address rather than ntdll

SharpHellsgate

Create a memory stream that reads the ntdll in memory. Read the Nt functions in memory and checks their instructions to find out the syscall id (recall how nt functions follow the template). Then it utilizes the RWX space made by .NET JIT compilation to hide the manually mapped syscall in.

• Pros:
  • Does not use potentially hooked API calls to grab IDs
  • Utilizes a high entropy memory space to hide the syscall within the noise
• Cons:
  • If Nt functions are hooked, the syscall stub format will be changed (due to the hook adding extra instructions), so the
  • The mapped syscall will call back to the JIT space rather than ntdll.
  • Not WOW64/x86 compatible

Indirect, Dynamic

My ElephantSe4l modifcation + Netero1010

Uses the elephantse4l technique; the order of Nt functions in memory corresponds to their syscall id. E.g NtSomethingFake is the 24th nt function located in memory, from lowest to highest address order, and will have a syscall id of 24. Using this method of syscall id grabbing, create a jump stub; this stub is not a fully syscall stub, rather, it aligns the CPU using the syscall id and then jumps to an arbitrary syscall instruction in ntdll. This spoofs the callback, making it look like a random ntfunction was called in ntdll. This jump stub is written in JIT space as is hellsgate, to blend in with the noise

The jump stub looks like this

	0x4C, 0x8B, 0xD1,               			                      // mov r10, rcx
	0xB8, 0x18, 0x00, 0x00, 0x00,    	              	          // mov eax, syscall number
	0x49, 0xBB, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // movabs r11,syscall address
	0x41, 0xFF, 0xE3 				       	                            // jmp r11

• Pros:
  • Does not use potentially hooked API calls to grab IDs
  • Utilizes a high entropy memory space to hide the jump stub within the noise
  • Jumps to arbitrary ntdll syscall instructions, making the callback look legit (and we can spoof which ntfunction it calls back to)
• Cons:
  • Not WOW64/x86 compatible