Leak AtomLdr | A DLL Loader With Advanced Evasive Features

[235]

Features:

• CRT library independent.
  
• The final DLL file, can run the payload by loading the DLL (executing its entry point), or by executing the exported 
  Code:

  "Atom"
   function via the command line.
  
• DLL unhooking from \KnwonDlls\ directory, with no RWX sections.
  
• The encrypted payload is saved in the resource section and retrieved via custom code.
  
• AES256-CBC Payload encryption using custom no table/data-dependent branches using ctaes; this is one of the best custom AES implementations I’ve encountered.
  
• Aes Key & Iv Encryption.
  
• Indirect syscalls, utilizing HellHall with ROP gadgets (for the unhooking part).
  
• Payload injection using APC calls - alertable thread.
  
• Payload execution using APC - alertable thread.
  
• Api hashing using two different implementations of the 
  Code:

  CRC32
   string hashing algorithm.
  
• The total Size is 17kb + payload size (multiple of 16).
  

How Does The Unhooking Part WorkAtomLdr’s unhooking method looks like the following

 
the program Unhooking from the \KnwonDlls\ directory is not a new method to bypass user-land hooks. However, this loader tries to avoid allocating RWX memory when doing so. This was obligatory to do in KnownDllUnhook for example, where RWX permissions were needed to replace the text section of the hooked modules, and at the same time allow execution of functions within these text sections.
This was changed in this loader, where it suspends the running threads, in an attempt to block any function from being called from within the targetted text sections, thus eliminating the need of having them marked as RWX sections before unhooking, making RW permissions a possible choice.
This approach, however, created another problem; when unhooking, 

Code:

NtProtectVirtualMemory

 syscall and others were using the syscall instruction inside of ntdll.dll module, as an indirect-syscall approach. Still, as mentioned above, the unhooked modules will be marked as RW sections, making it impossible to perform indirect syscalls, because the syscall instruction that we were jumping to, can’t be executed now, so we had to jump to another executable place, this is where 

Code:

win32u.dll

 was used. 

Code:

win32u.dll

 contains some syscalls that are GUI-related functions, making it suitable to jump to instead of ntdll.dll. win32u.dll is loaded (statically), but not included in the unhooking routine, which is done to insure that win32u.dll can still execute the syscall instruction we are jumping to.The suspended threads after that are resumed.
It is worth mentioning that this approach may not be that efficient, and can be unstable, that is due to the thread suspension trick used. However, it has been tested with multiple processes with positive results, in the meantime, if you encountered any problems, feel free to open an issue.

 
Based on

• ctaes
  
• WriteProcessMemoryAPC
  
• VX-API
  

[spoiler]

Hidden Content

You must register or login to view this content.

[132]

wheres the loader

[10]

Features:

• CRT library independent.
  
• The final DLL file, can run the payload by loading the DLL (executing its entry point), or by executing the exported 
  Code:

  "Atom"
   function via the command line.
  
• DLL unhooking from \KnwonDlls\ directory, with no RWX sections.
  
• The encrypted payload is saved in the resource section and retrieved via custom code.
  
• AES256-CBC Payload encryption using custom no table/data-dependent branches using ctaes; this is one of the best custom AES implementations I’ve encountered.
  
• Aes Key & Iv Encryption.
  
• Indirect syscalls, utilizing HellHall with ROP gadgets (for the unhooking part).
  
• Payload injection using APC calls - alertable thread.
  
• Payload execution using APC - alertable thread.
  
• Api hashing using two different implementations of the 
  Code:

  CRC32
   string hashing algorithm.
  
• The total Size is 17kb + payload size (multiple of 16).
  

How Does The Unhooking Part WorkAtomLdr’s unhooking method looks like the following

 
the program Unhooking from the \KnwonDlls\ directory is not a new method to bypass user-land hooks. However, this loader tries to avoid allocating RWX memory when doing so. This was obligatory to do in KnownDllUnhook for example, where RWX permissions were needed to replace the text section of the hooked modules, and at the same time allow execution of functions within these text sections.
This was changed in this loader, where it suspends the running threads, in an attempt to block any function from being called from within the targetted text sections, thus eliminating the need of having them marked as RWX sections before unhooking, making RW permissions a possible choice.
This approach, however, created another problem; when unhooking, 

Code:

NtProtectVirtualMemory

 syscall and others were using the syscall instruction inside of ntdll.dll module, as an indirect-syscall approach. Still, as mentioned above, the unhooked modules will be marked as RW sections, making it impossible to perform indirect syscalls, because the syscall instruction that we were jumping to, can’t be executed now, so we had to jump to another executable place, this is where 

Code:

win32u.dll

 was used. 

Code:

win32u.dll

 contains some syscalls that are GUI-related functions, making it suitable to jump to instead of ntdll.dll. win32u.dll is loaded (statically), but not included in the unhooking routine, which is done to insure that win32u.dll can still execute the syscall instruction we are jumping to.The suspended threads after that are resumed.
It is worth mentioning that this approach may not be that efficient, and can be unstable, that is due to the thread suspension trick used. However, it has been tested with multiple processes with positive results, in the meantime, if you encountered any problems, feel free to open an issue.

 
Based on

• ctaes
  
• WriteProcessMemoryAPC
  
• VX-API
  

[spoiler]

cool

[24]

thank

[167]

Features:

• CRT library independent.
  
• The final DLL file, can run the payload by loading the DLL (executing its entry point), or by executing the exported 
  Code:

  "Atom"
   function via the command line.
  
• DLL unhooking from \KnwonDlls\ directory, with no RWX sections.
  
• The encrypted payload is saved in the resource section and retrieved via custom code.
  
• AES256-CBC Payload encryption using custom no table/data-dependent branches using ctaes; this is one of the best custom AES implementations I’ve encountered.
  
• Aes Key & Iv Encryption.
  
• Indirect syscalls, utilizing HellHall with ROP gadgets (for the unhooking part).
  
• Payload injection using APC calls - alertable thread.
  
• Payload execution using APC - alertable thread.
  
• Api hashing using two different implementations of the 
  Code:

  CRC32
   string hashing algorithm.
  
• The total Size is 17kb + payload size (multiple of 16).
  

How Does The Unhooking Part WorkAtomLdr’s unhooking method looks like the following

 
the program Unhooking from the \KnwonDlls\ directory is not a new method to bypass user-land hooks. However, this loader tries to avoid allocating RWX memory when doing so. This was obligatory to do in KnownDllUnhook for example, where RWX permissions were needed to replace the text section of the hooked modules, and at the same time allow execution of functions within these text sections.
This was changed in this loader, where it suspends the running threads, in an attempt to block any function from being called from within the targetted text sections, thus eliminating the need of having them marked as RWX sections before unhooking, making RW permissions a possible choice.
This approach, however, created another problem; when unhooking, 

Code:

NtProtectVirtualMemory

 syscall and others were using the syscall instruction inside of ntdll.dll module, as an indirect-syscall approach. Still, as mentioned above, the unhooked modules will be marked as RW sections, making it impossible to perform indirect syscalls, because the syscall instruction that we were jumping to, can’t be executed now, so we had to jump to another executable place, this is where 

Code:

win32u.dll

 was used. 

Code:

win32u.dll

 contains some syscalls that are GUI-related functions, making it suitable to jump to instead of ntdll.dll. win32u.dll is loaded (statically), but not included in the unhooking routine, which is done to insure that win32u.dll can still execute the syscall instruction we are jumping to.The suspended threads after that are resumed.
It is worth mentioning that this approach may not be that efficient, and can be unstable, that is due to the thread suspension trick used. However, it has been tested with multiple processes with positive results, in the meantime, if you encountered any problems, feel free to open an issue.

 
Based on

• ctaes
  
• WriteProcessMemoryAPC
  
• VX-API
  

[spoiler]

thanks a lot brother

[101]

kudos for it

[101]

kudos for it