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
Guides - Privacy & Security Tips
Windows processes which are significantly important
Message
<blockquote data-quote="Visa" data-source="post: 644852" data-attributes="member: 62849"><p>Ty! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>As an addition to the info posted about lsass.exe, if you can gain code execution within that Windows process you can actually use it as an advantage to bypass AV self-defense mechanisms, or alternatively bypass anti-cheat mechanisms. In theory at least.</p><p></p><p>There is something called "handle hijacking", similar to the situation with csrss.exe (which no longer works so well since csrss.exe is now a protected process therefore you cannot open a handle to it even with debugging rights from user-mode). If you can inject code into lsass.exe you can use handle hijacking to get access to an open handle for an AV process, or any protected process, and as long as it has sufficient rights to do what you need to do then you can use that hijacked handle to terminate/inject/suspend.</p><p></p><p>Bear in mind that you would still need administrator rights and SeDebugPrivilege (aka. debugging rights) since lsass.exe is running under the SYSTEM account. Some AVs might even try to lower the access rights which can be obtained through handle hijacking within lsass.exe so it cannot be used to do much damage although I am not entirely sure.</p><p></p><p>It can be quite a complex topic... I am not an expert on handle hijacking tbh. I didn't even know you could do that with lsass.exe when I made this thread haha</p><p></p><p>---</p><p>[SPOILER="Theory idea"]</p><p>You might even be able to abuse code execution within lsass.exe to spawn other processes under SYSTEM, potentially. I haven't tested this idea but I will do soon for sure... My idea is that you would allocate some memory within lsass.exe (e.g. NtAllocateVirtualMemory) and then write to that allocated memory to store a loader function (e.g. NtWriteVirtualMemory), and then create a remote thread for lsass.exe to start via NtCreateThreadEx - make the newly created remote thread be responsible for executing the loader code you had put inside the process! Then the loader code steal the access tokens from lsass.exe (token for SYSTEM) or steal it from another windows process running under SYSTEM like winlogon.exe, and then create a new process which has the same tokens which you stole. If it works right, then the new process will also be under SYSTEM due to having the stolen SYSTEM token. It definitely used to work on older versions of Windows like Windows 2000/XP without needing to inject into windows process, and it still works on newer versions as Windows as long as you do it within a genuine service (as opposed to a process), but I've never tested it while executing from a genuine process under SYSTEM (since lsass.exe is a genuine process which is just running under the NT Authority account, it would've been started by an existent service to be running under SYSTEM instead of just spawning under it for sure, or I think at least). I'll probably go through ReactOS a bit to learn a bit on the spawning start-up of lsass.exe on older OS like Vista and 7 soon and see if that provides any more insight for me to report back on, but this is just a theory idea for me to test soon. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>But I recon MS probably patched that old method even for if you are executing the code within lsass.exe. But I will test it for sure soon <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p>[/SPOILER]</p></blockquote><p></p>
[QUOTE="Visa, post: 644852, member: 62849"] Ty! :) As an addition to the info posted about lsass.exe, if you can gain code execution within that Windows process you can actually use it as an advantage to bypass AV self-defense mechanisms, or alternatively bypass anti-cheat mechanisms. In theory at least. There is something called "handle hijacking", similar to the situation with csrss.exe (which no longer works so well since csrss.exe is now a protected process therefore you cannot open a handle to it even with debugging rights from user-mode). If you can inject code into lsass.exe you can use handle hijacking to get access to an open handle for an AV process, or any protected process, and as long as it has sufficient rights to do what you need to do then you can use that hijacked handle to terminate/inject/suspend. Bear in mind that you would still need administrator rights and SeDebugPrivilege (aka. debugging rights) since lsass.exe is running under the SYSTEM account. Some AVs might even try to lower the access rights which can be obtained through handle hijacking within lsass.exe so it cannot be used to do much damage although I am not entirely sure. It can be quite a complex topic... I am not an expert on handle hijacking tbh. I didn't even know you could do that with lsass.exe when I made this thread haha --- [SPOILER="Theory idea"] You might even be able to abuse code execution within lsass.exe to spawn other processes under SYSTEM, potentially. I haven't tested this idea but I will do soon for sure... My idea is that you would allocate some memory within lsass.exe (e.g. NtAllocateVirtualMemory) and then write to that allocated memory to store a loader function (e.g. NtWriteVirtualMemory), and then create a remote thread for lsass.exe to start via NtCreateThreadEx - make the newly created remote thread be responsible for executing the loader code you had put inside the process! Then the loader code steal the access tokens from lsass.exe (token for SYSTEM) or steal it from another windows process running under SYSTEM like winlogon.exe, and then create a new process which has the same tokens which you stole. If it works right, then the new process will also be under SYSTEM due to having the stolen SYSTEM token. It definitely used to work on older versions of Windows like Windows 2000/XP without needing to inject into windows process, and it still works on newer versions as Windows as long as you do it within a genuine service (as opposed to a process), but I've never tested it while executing from a genuine process under SYSTEM (since lsass.exe is a genuine process which is just running under the NT Authority account, it would've been started by an existent service to be running under SYSTEM instead of just spawning under it for sure, or I think at least). I'll probably go through ReactOS a bit to learn a bit on the spawning start-up of lsass.exe on older OS like Vista and 7 soon and see if that provides any more insight for me to report back on, but this is just a theory idea for me to test soon. :) But I recon MS probably patched that old method even for if you are executing the code within lsass.exe. But I will test it for sure soon :) [/SPOILER] [/QUOTE]
Insert quotes…
Verification
Post reply
Top