Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
General Security Discussions
Protecting processes from injection via SetWindowsHookEx() ?
Message
<blockquote data-quote="Deleted member 65228" data-source="post: 730963"><p><strong>Method 1:</strong></p><p>1. NtQuerySystemInformation -> find PID of target process</p><p>2. NtOpenProcess -> open a handle to the target process</p><p>3. EAT scanning -> locate the address of the routines you want to re-patch in the target process within your own process (for your own virtual address space)</p><p>4. NtProtectVirtualMemory -> change the memory access protection at the target address within the address space of the target process remotely</p><p>5. NtWriteVirtualMemory -> remotely patch the memory at the address in the address space of the target process</p><p>6. NtProtectVirtualMemory -> re-protect the memory back to the original memory access protection remotely</p><p></p><p>Make sure the address is right though. E.g. x86 address of LdrLoadDll for WOW64 process, not an x64 address for the x64 processes.</p><p></p><p><strong>Method 2:</strong></p><p>1. NtQuerySystemInformation -> find PID of target process</p><p>2. NtOpenProcess -> open a handle to the target process</p><p>3. NtAllocateVirtualMemory -> allocate memory for your code-cave buffer</p><p>4. NtWriteVirtualMemory -> write to the code-cave buffer</p><p>5. NtCreateThreadEx -> get a new thread to start executing at the address of the allocated memory (now containing your injected code)</p><p></p><p><strong>Method 3:</strong></p><p>Same as Method 2 but targeting threads of the target process and relying on NtQueueApcThread/NtQueueApcThreadEx (Asynchronous Procedure Calls instead of Remote Thread Creation). By the way, NtQueueApcThread is just a wrapper for NtQueueApcThreadEx internally in the Windows Kernel.</p><p></p><p>Method 4:</p><p>Same as Method 3 except instead of using NtQueueApcThread/NtQueueApcThreadEx, you hijack the EIP/RIP of the targeted thread via NtSetContextThread. </p><p></p><p><strong>Method 5:</strong></p><p>1. RCE (target csrss.exe for Windows 7 or lsass.exe for Windows 8+) and steal an open handle for the targeted process</p><p>2. Now do either Method 1 or Method 2 using the stolen handle</p><p></p><p>You can use code-cave as a "file-less" injection method (no DLL required) and within the injected code you could then remove the third-party memory patches on routines like LdrLoadDll. Alternatively, go for method 1 and do it remotely 100%.</p><p></p><p>Patching LdrLoadDll will stop traditional DLL injection via LoadLibraryA/W and remote thread creation or APC but it won't block the actual remote thread creation or APC operation which leaves the process still vulnerable to shell-code/code-cave injection... Only way to stop remote thread creation/APC via local patching would be patching a routine like LdrInitializeThunk and KiUserApcDispatcher, both of those ideas are not practical realistically and will cause problems. </p><p></p><p>Anyway, if you really wanted to you could manually map your DLL through a file-less loader (e.g. code-cave) and thus the LdrLoadDll code execution flow redirection would never be triggered for your API monitoring module in the first place.</p></blockquote><p></p>
[QUOTE="Deleted member 65228, post: 730963"] [B]Method 1:[/B] 1. NtQuerySystemInformation -> find PID of target process 2. NtOpenProcess -> open a handle to the target process 3. EAT scanning -> locate the address of the routines you want to re-patch in the target process within your own process (for your own virtual address space) 4. NtProtectVirtualMemory -> change the memory access protection at the target address within the address space of the target process remotely 5. NtWriteVirtualMemory -> remotely patch the memory at the address in the address space of the target process 6. NtProtectVirtualMemory -> re-protect the memory back to the original memory access protection remotely Make sure the address is right though. E.g. x86 address of LdrLoadDll for WOW64 process, not an x64 address for the x64 processes. [B]Method 2:[/B] 1. NtQuerySystemInformation -> find PID of target process 2. NtOpenProcess -> open a handle to the target process 3. NtAllocateVirtualMemory -> allocate memory for your code-cave buffer 4. NtWriteVirtualMemory -> write to the code-cave buffer 5. NtCreateThreadEx -> get a new thread to start executing at the address of the allocated memory (now containing your injected code) [B]Method 3:[/B] Same as Method 2 but targeting threads of the target process and relying on NtQueueApcThread/NtQueueApcThreadEx (Asynchronous Procedure Calls instead of Remote Thread Creation). By the way, NtQueueApcThread is just a wrapper for NtQueueApcThreadEx internally in the Windows Kernel. Method 4: Same as Method 3 except instead of using NtQueueApcThread/NtQueueApcThreadEx, you hijack the EIP/RIP of the targeted thread via NtSetContextThread. [B]Method 5:[/B] 1. RCE (target csrss.exe for Windows 7 or lsass.exe for Windows 8+) and steal an open handle for the targeted process 2. Now do either Method 1 or Method 2 using the stolen handle You can use code-cave as a "file-less" injection method (no DLL required) and within the injected code you could then remove the third-party memory patches on routines like LdrLoadDll. Alternatively, go for method 1 and do it remotely 100%. Patching LdrLoadDll will stop traditional DLL injection via LoadLibraryA/W and remote thread creation or APC but it won't block the actual remote thread creation or APC operation which leaves the process still vulnerable to shell-code/code-cave injection... Only way to stop remote thread creation/APC via local patching would be patching a routine like LdrInitializeThunk and KiUserApcDispatcher, both of those ideas are not practical realistically and will cause problems. Anyway, if you really wanted to you could manually map your DLL through a file-less loader (e.g. code-cave) and thus the LdrLoadDll code execution flow redirection would never be triggered for your API monitoring module in the first place. [/QUOTE]
Insert quotes…
Verification
Post reply
Top