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
Software
Operating Systems
Windows 10
OS Archive
Use Windows 10 build-in (anti)execution options
Message
<blockquote data-quote="Andy Ful" data-source="post: 754791" data-attributes="member: 32260"><p>Understand. My point is that some updates use this key also as standard user (no admin rights) - the Windows OneDrive is an example. That is also common for most updates for applications that are installed in the Userspace, because they do not need admin rights to update.</p><p>I am still considering such protection, because the malware can often use the Run key in HKCU hive to get persistence. But maybe the better solution will be installing one of the simple realtime tools that can notify about modifying the Run key?</p><p></p><p>Yes, that could be an advantage over blocking those folders by the WD Ransomware protection. The installations in the Userspace will not be a problem (mostly), except OneDrive and other installers that cannot be run as administrator.</p><p>I have to think it over, because the<strong><span style="color: rgb(184, 49, 47)"> Start Folders</span></strong> are already well protected in Hard_Configurator via SRP. In the Recommended SRP settings those restrictions are higher than ACL deny execute. I did not see the malware in the wild that could bypass that protection and execute the payload as standard user, even when the payload was copied <span style="color: rgb(184, 49, 47)"><strong>there</strong></span>.</p><p></p><p>You have the special setup that does not allow elevation of unsigned executables, so you cannot use directly the "Run As SmartScreen" option (RunAsSmartscreen executable is not digitally signed and requires elevation). That is OK, for the users which know the limitations of Windows SmartScreen. Your setup is still <span style="color: rgb(0, 168, 133)"><strong>default-deny for files running as standard user</strong></span> (SRP 'Default Security Level' = Disallowed or Basic User) and additionally <span style="color: rgb(41, 105, 176)"><strong>restricted on the elevation of unsigned programs</strong></span>.</p><p><span style="color: rgb(41, 105, 176)"><strong>The second</strong></span> will trigger only when something could bypass<strong><span style="color: rgb(0, 168, 133)"> the</span></strong><span style="color: rgb(0, 168, 133)"><strong> first</strong></span>.</p><p></p><p>The mitigation 'Disabling child processes in PowerShell' + Constrained Language mode (applied by SRP) is a pretty good protection. Anyway, I think that you can disable PowerShell executables via Hard_Configurator (<Block Sponsors>). Windows Updates use directly System.Management.Automation.dll to retrieve PowerShell functions. System scheduled tasks and other processes will bypass this protection when running with admin or higher rights.</p><p>.</p><p>Regards</p></blockquote><p></p>
[QUOTE="Andy Ful, post: 754791, member: 32260"] Understand. My point is that some updates use this key also as standard user (no admin rights) - the Windows OneDrive is an example. That is also common for most updates for applications that are installed in the Userspace, because they do not need admin rights to update. I am still considering such protection, because the malware can often use the Run key in HKCU hive to get persistence. But maybe the better solution will be installing one of the simple realtime tools that can notify about modifying the Run key? Yes, that could be an advantage over blocking those folders by the WD Ransomware protection. The installations in the Userspace will not be a problem (mostly), except OneDrive and other installers that cannot be run as administrator. I have to think it over, because the[B][COLOR=rgb(184, 49, 47)] Start Folders[/COLOR][/B] are already well protected in Hard_Configurator via SRP. In the Recommended SRP settings those restrictions are higher than ACL deny execute. I did not see the malware in the wild that could bypass that protection and execute the payload as standard user, even when the payload was copied [COLOR=rgb(184, 49, 47)][B]there[/B][/COLOR]. You have the special setup that does not allow elevation of unsigned executables, so you cannot use directly the "Run As SmartScreen" option (RunAsSmartscreen executable is not digitally signed and requires elevation). That is OK, for the users which know the limitations of Windows SmartScreen. Your setup is still [COLOR=rgb(0, 168, 133)][B]default-deny for files running as standard user[/B][/COLOR] (SRP 'Default Security Level' = Disallowed or Basic User) and additionally [COLOR=rgb(41, 105, 176)][B]restricted on the elevation of unsigned programs[/B][/COLOR]. [COLOR=rgb(41, 105, 176)][B]The second[/B][/COLOR] will trigger only when something could bypass[B][COLOR=rgb(0, 168, 133)] the[/COLOR][/B][COLOR=rgb(0, 168, 133)][B] first[/B][/COLOR]. The mitigation 'Disabling child processes in PowerShell' + Constrained Language mode (applied by SRP) is a pretty good protection. Anyway, I think that you can disable PowerShell executables via Hard_Configurator (<Block Sponsors>). Windows Updates use directly System.Management.Automation.dll to retrieve PowerShell functions. System scheduled tasks and other processes will bypass this protection when running with admin or higher rights. . Regards [/QUOTE]
Insert quotes…
Verification
Post reply
Top