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: 770191"><p>Me and you both hahahaha</p><p></p><p>I know the opt-in registry setting once enabled and the changes are made after the reboot will cause the Windows kernel to protect lsass.exe. Essentially, it will be set as a protected process (either normal protected process or protected process light) and this is tracked in opaque kernel-mode structures.</p><p></p><p>When you try to open a handle to lsass.exe, eventually you'll reach undocumented and non-exported kernel routines which continue this handle opening operation. They'll see lsass.exe is identified as a protected process and block the operation, passing back an error code that lets the original caller know that the access was denied.</p><p></p><p>The ASR rule though? No idea how it protects lsass.exe yet. When I look into that rule soon, I can try and debunk how it works... I guess trying is better than nothing. I doubt there will be any official or public documentation which explains the internals of it, so you pretty much have to go down reverse-engineer galore.</p></blockquote><p></p>
[QUOTE="Eddie Morra, post: 770191"] Me and you both hahahaha I know the opt-in registry setting once enabled and the changes are made after the reboot will cause the Windows kernel to protect lsass.exe. Essentially, it will be set as a protected process (either normal protected process or protected process light) and this is tracked in opaque kernel-mode structures. When you try to open a handle to lsass.exe, eventually you'll reach undocumented and non-exported kernel routines which continue this handle opening operation. They'll see lsass.exe is identified as a protected process and block the operation, passing back an error code that lets the original caller know that the access was denied. The ASR rule though? No idea how it protects lsass.exe yet. When I look into that rule soon, I can try and debunk how it works... I guess trying is better than nothing. I doubt there will be any official or public documentation which explains the internals of it, so you pretty much have to go down reverse-engineer galore. [/QUOTE]
Insert quotes…
Verification
Post reply
Top