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
Hiding malware in Windows – The basics of code injection
Message
<blockquote data-quote="Eddie Morra" data-source="post: 770160"><p>A better method would be to not create or manually hijack an existing thread in the targeted process at all. </p><p></p><p>I can tell you right now that most vendors who have behavioural protections are going to be relying on USER-MODE hooking for routines like NtCreateThreadEx (NTDLL), NtQueueApcThread (NTDLL), NtQueueApcThreadEx (NTDLL), etc.</p><p></p><p>1. NtAllocateVirtualMemory to allocate memory for your shell-code.</p><p>2. NtWriteVirtualMemory to write your shellcode to the allocated memory.</p><p>3. Now patch a routine under the virtual memory of the target process which you KNOW is going to be called sooner or later to redirect to the shell-code you allocated.</p><p>3. After your shell-code is executed, return back to the original address where you redirected from after cleaning up and removing the patch on the innocent routine.</p><p></p><p>This way, you get your shell-code in the target process, but it automatically hijacks a thread for you and redirects to your injected code. No need to create a new thread remotely, hijack an existing thread by changing the context or queuing an APC (if the thread is alertable), etc.</p><p></p><p>If you use direct system calls for those NtAllocateVirtualMemory and NtWriteVirtualMemory calls, then everything becomes more complicated, because on traditional systems... AV solutions aren't going to be able to do anything about it. The best they are going to be able to do without hardware-assisted virtualization is user-mode hooking for those routines (most AVs with behavioural protections are patching both of those routines btw), but a direct system call will bypass those hooks. And thus without hardware-assisted virtualization, since traditional systems are on Windows x64, they aren't going to be able to intercept those virtual memory operations from kernel-level to even know about what you did.</p><p></p><p>However, if you're doing things like creating a remote thread, that can be caught from a kernel-level via a documented and officially supported technique... kernel-mode callbacks!</p><p></p><p>One more note, it may be obvious if you are opening a handle to a process like explorer.exe, because such can be identified from a kernel-level as well. Most AVs are using ObRegisterCallbacks for self-protection purposes, but it can be used to watch out for which processes are trying to access other processes (for whatever reason).</p><p></p><p>Obviously I am not condoning malware development, but good people view this place who clearly have an interest in these topics, so if I don't share these tips... who will?</p></blockquote><p></p>
[QUOTE="Eddie Morra, post: 770160"] A better method would be to not create or manually hijack an existing thread in the targeted process at all. I can tell you right now that most vendors who have behavioural protections are going to be relying on USER-MODE hooking for routines like NtCreateThreadEx (NTDLL), NtQueueApcThread (NTDLL), NtQueueApcThreadEx (NTDLL), etc. 1. NtAllocateVirtualMemory to allocate memory for your shell-code. 2. NtWriteVirtualMemory to write your shellcode to the allocated memory. 3. Now patch a routine under the virtual memory of the target process which you KNOW is going to be called sooner or later to redirect to the shell-code you allocated. 3. After your shell-code is executed, return back to the original address where you redirected from after cleaning up and removing the patch on the innocent routine. This way, you get your shell-code in the target process, but it automatically hijacks a thread for you and redirects to your injected code. No need to create a new thread remotely, hijack an existing thread by changing the context or queuing an APC (if the thread is alertable), etc. If you use direct system calls for those NtAllocateVirtualMemory and NtWriteVirtualMemory calls, then everything becomes more complicated, because on traditional systems... AV solutions aren't going to be able to do anything about it. The best they are going to be able to do without hardware-assisted virtualization is user-mode hooking for those routines (most AVs with behavioural protections are patching both of those routines btw), but a direct system call will bypass those hooks. And thus without hardware-assisted virtualization, since traditional systems are on Windows x64, they aren't going to be able to intercept those virtual memory operations from kernel-level to even know about what you did. However, if you're doing things like creating a remote thread, that can be caught from a kernel-level via a documented and officially supported technique... kernel-mode callbacks! One more note, it may be obvious if you are opening a handle to a process like explorer.exe, because such can be identified from a kernel-level as well. Most AVs are using ObRegisterCallbacks for self-protection purposes, but it can be used to watch out for which processes are trying to access other processes (for whatever reason). Obviously I am not condoning malware development, but good people view this place who clearly have an interest in these topics, so if I don't share these tips... who will? [/QUOTE]
Insert quotes…
Verification
Post reply
Top