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
Inactive Support Threads
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
Security Apps
Hard_Configurator Tools
Testing Windows Hybrid Hardening (new hardening application).
Message
<blockquote data-quote="Andy Ful" data-source="post: 1055879" data-attributes="member: 32260"><p>It is normal that you cannot relate the WDAC used in WHHLight to your experience. Simply, WHHLight uses WDAC in a different way.</p><p>Your setup is based on ISG and WHHLight avoids ISG for some reasons.</p><p></p><p></p><p></p><p>It does not, because WHHLight is not a default deny, but a smart-default deny similar to ISG. You will see it when using WHHLight. Almost all applications are installed/updated in folders whitelisted by default in WHHLight. Many of them will be blocked by ISG (especially software updates).</p><p></p><p></p><p></p><p>It is not true. The holes would be important while only using the WDAC restrictions. The WHHLight settings + tools included in the package make these holes negligible at home. Allowing ISG introduces larger holes via DLL hijacking.</p><p></p><p></p><p></p><p>The attacks via DLL hijacking are pretty common nowadays and very simple, the extra restrictions are necessary. You clearly underestimate this attack vector.</p><p></p><p></p><p></p><p>It is simple. I can skip dynamic code trust verification because in WHH it is only a theoretical problem limited to Microsoft-signed .NET applications. So far, no one found any such vulnerable application. On the contrary, the ISG vulnerability is large and commonly abused in the wild (DLL hijacking). Furthermore, ISG is much more vulnerable to abusing dynamic code, because it will allow all reputable applications (not only Microsoft-signed).</p><p></p><p></p><p></p><p></p><p>The post-intrusion attacks are performed mostly via user AppData or %ProgramData% folders. WHHLight protects these locations for scripts, also when the script is executed with high privileges. But the EXE, DLL, and MSI files are allowed (user AppData and %ProgramData% are on the WDAC Whitelist). The ISG setup can help to block them.</p><p></p><p></p><p></p><p>If you will test WHHLight then there will not be any disagreement. I understand that is not easy to grasp all details without using the application.</p><p></p><p></p><p></p><p>Thank you. Your critique and my answers can help others understand how WHHLight (and WHH full version) works.<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite130" alt="(y)" title="Thumbs up (y)" loading="lazy" data-shortname="(y)" /></p><p>Let's only remember to avoid repeating the same questions & answers.<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p></blockquote><p></p>
[QUOTE="Andy Ful, post: 1055879, member: 32260"] It is normal that you cannot relate the WDAC used in WHHLight to your experience. Simply, WHHLight uses WDAC in a different way. Your setup is based on ISG and WHHLight avoids ISG for some reasons. It does not, because WHHLight is not a default deny, but a smart-default deny similar to ISG. You will see it when using WHHLight. Almost all applications are installed/updated in folders whitelisted by default in WHHLight. Many of them will be blocked by ISG (especially software updates). It is not true. The holes would be important while only using the WDAC restrictions. The WHHLight settings + tools included in the package make these holes negligible at home. Allowing ISG introduces larger holes via DLL hijacking. The attacks via DLL hijacking are pretty common nowadays and very simple, the extra restrictions are necessary. You clearly underestimate this attack vector. It is simple. I can skip dynamic code trust verification because in WHH it is only a theoretical problem limited to Microsoft-signed .NET applications. So far, no one found any such vulnerable application. On the contrary, the ISG vulnerability is large and commonly abused in the wild (DLL hijacking). Furthermore, ISG is much more vulnerable to abusing dynamic code, because it will allow all reputable applications (not only Microsoft-signed). The post-intrusion attacks are performed mostly via user AppData or %ProgramData% folders. WHHLight protects these locations for scripts, also when the script is executed with high privileges. But the EXE, DLL, and MSI files are allowed (user AppData and %ProgramData% are on the WDAC Whitelist). The ISG setup can help to block them. If you will test WHHLight then there will not be any disagreement. I understand that is not easy to grasp all details without using the application. Thank you. Your critique and my answers can help others understand how WHHLight (and WHH full version) works.(y) Let's only remember to avoid repeating the same questions & answers.:) [/QUOTE]
Insert quotes…
Verification
Post reply
Top
