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
Microsoft Defender
Application Control on Windows 10 Home
Message
<blockquote data-quote="Andy Ful" data-source="post: 911371" data-attributes="member: 32260"><p><span style="font-size: 18px"><strong>Windows Defender BabySitter for Windows Home - part 2.</strong></span></p><p><span style="font-size: 15px"><strong>(post updated in October 2021)</strong></span></p><p></p><p>I am thinking about changing the BabySitter model of protecting EXE files. In the older version, the protection comes from SmartScreen and from Microsoft ISG (non-system drives). Now I am inclined to use the WD ASR prevalence rule "<span style="color: rgb(41, 105, 176)">Block executable files from running unless they meet a prevalence, age, or trusted list criteria</span>", instead. So, EXE files (also COM and SCR) will be globally whitelisted in WDAC and globally protected by this ASR rule.</p><p></p><p><strong>Here is what the current WD BabySitter can do:</strong></p><ol> <li data-xf-list-type="ol"><span style="color: rgb(0, 168, 133)"><strong>The protection schema is based on </strong></span><strong><span style="color: rgb(0, 168, 133)">WD ASR rules and WD Application Control</span></strong> (WDAC). The WD ASR exceptions are independent of WDAC whitelisting.</li> <li data-xf-list-type="ol"><span style="color: rgb(0, 168, 133)"><strong>All files accepted by Microsoft ISG are allowed to run</strong></span>. This is true both for WD ASR rules and WDAC restrictions.</li> <li data-xf-list-type="ol"><span style="color: rgb(0, 168, 133)"><strong>The EXE, COM, and SCR files on all disks are protected by the WD ASR prevalence rule</strong></span>. These executables are totally whitelisted in WDAC.</li> <li data-xf-list-type="ol">The binary libraries (DLL, OCX) are restricted by WDAC on the non-system disks except for whitelisted locations. On the system disk, the binary libraries have only standard WD protection. One can apply additional WD ASR rules for additional protection on the system disk.</li> <li data-xf-list-type="ol"><span style="color: rgb(0, 168, 133)"><strong>The scripts (Windows Script Host, PowerShell) and MSI files </strong></span><strong><span style="color: rgb(0, 168, 133)">are restricted</span> <span style="color: rgb(0, 168, 133)"><strong>by WDAC</strong></span> <span style="color: rgb(0, 168, 133)">on all disks </span></strong>except for whitelisted <s>locations</s>. files (by hash). One can add some other script restrictions via WD ASR rules.</li> <li data-xf-list-type="ol">The WDAC restrictions for PowerShell follow from applying the Constrained Language Mode. Similar restrictions are applied for Windows Script Host. So, <span style="color: rgb(0, 168, 133)"><strong>scripts can be still run but advanced functions are disabled</strong></span>.</li> <li data-xf-list-type="ol">The restrictions can be turned OFF/ON without logging off the user account.</li> <li data-xf-list-type="ol">If the user wants to protect the "Desktop, Documents, Downloads, Pictures, Videos" user folders against DLL hijacking, then these folders have to be<strong> moved</strong> to the non-system disk (right-click >> Properties >> Location >> Move ...).</li> <li data-xf-list-type="ol">Some protection for BAT, JAR, CHM, ... files can be done in a similar way as in SysHardener (no whitelisting).</li> </ol><p>Points 4 and 9 can prevent most DLL hijacking methods. From my tests, it follows that ASR rules and SmartScreen do not prevent such attacks (especially via USB drives or archives).</p><p>In the current version, the WD BabySitter is a kind of smart-default-deny that uses WD features introduced in Windows 10. I made the AutoIt program which can extend the necessary WDAC configuration features (like whitelisting) to Windows Home. It can create the WDAC policy files identical to those created by PowerShell on Windows Pro. For now, I test it without GUI - the tests will be continued for about one year.<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /><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></p><p>Post edited.</p><p>Normally, the ASR prevalence rule for EXE, COM, and SCR files can overlap with WDAC default-deny restrictions. In BabySitter, these files are whitelisted globally in WDAC (by file rule) to avoid overlapping.</p><p>Additionally, I use the WDAC path rule to whitelist all Portable Executable files on the system disk, so also DLL and OCX files are allowed on the system disk (but restricted on other disks). This is crucial to avoid problems when installing/updating/uninstalling/running applications.</p><p><strong>Still, the installations/updates made via MSI installers are inconvenient (require turning off the script/MSI protection or whitelisting by hash).</strong></p></blockquote><p></p>
[QUOTE="Andy Ful, post: 911371, member: 32260"] [SIZE=5][B]Windows Defender BabySitter for Windows Home - part 2.[/B][/SIZE] [SIZE=4][B](post updated in October 2021)[/B][/SIZE] I am thinking about changing the BabySitter model of protecting EXE files. In the older version, the protection comes from SmartScreen and from Microsoft ISG (non-system drives). Now I am inclined to use the WD ASR prevalence rule "[COLOR=rgb(41, 105, 176)]Block executable files from running unless they meet a prevalence, age, or trusted list criteria[/COLOR]", instead. So, EXE files (also COM and SCR) will be globally whitelisted in WDAC and globally protected by this ASR rule. [B]Here is what the current WD BabySitter can do:[/B] [LIST=1] [*][COLOR=rgb(0, 168, 133)][B]The protection schema is based on [/B][/COLOR][B][COLOR=rgb(0, 168, 133)]WD ASR rules and WD Application Control[/COLOR][/B] (WDAC). The WD ASR exceptions are independent of WDAC whitelisting. [*][COLOR=rgb(0, 168, 133)][B]All files accepted by Microsoft ISG are allowed to run[/B][/COLOR]. This is true both for WD ASR rules and WDAC restrictions. [*][COLOR=rgb(0, 168, 133)][B]The EXE, COM, and SCR files on all disks are protected by the WD ASR prevalence rule[/B][/COLOR]. These executables are totally whitelisted in WDAC. [*]The binary libraries (DLL, OCX) are restricted by WDAC on the non-system disks except for whitelisted locations. On the system disk, the binary libraries have only standard WD protection. One can apply additional WD ASR rules for additional protection on the system disk. [*][COLOR=rgb(0, 168, 133)][B]The scripts (Windows Script Host, PowerShell) and MSI files [/B][/COLOR][B][COLOR=rgb(0, 168, 133)]are restricted[/COLOR] [COLOR=rgb(0, 168, 133)][B]by WDAC[/B][/COLOR] [COLOR=rgb(0, 168, 133)]on all disks [/COLOR][/B]except for whitelisted [S]locations[/S]. files (by hash). One can add some other script restrictions via WD ASR rules. [*]The WDAC restrictions for PowerShell follow from applying the Constrained Language Mode. Similar restrictions are applied for Windows Script Host. So, [COLOR=rgb(0, 168, 133)][B]scripts can be still run but advanced functions are disabled[/B][/COLOR]. [*]The restrictions can be turned OFF/ON without logging off the user account. [*]If the user wants to protect the "Desktop, Documents, Downloads, Pictures, Videos" user folders against DLL hijacking, then these folders have to be[B] moved[/B] to the non-system disk (right-click >> Properties >> Location >> Move ...). [*]Some protection for BAT, JAR, CHM, ... files can be done in a similar way as in SysHardener (no whitelisting). [/LIST] Points 4 and 9 can prevent most DLL hijacking methods. From my tests, it follows that ASR rules and SmartScreen do not prevent such attacks (especially via USB drives or archives). In the current version, the WD BabySitter is a kind of smart-default-deny that uses WD features introduced in Windows 10. I made the AutoIt program which can extend the necessary WDAC configuration features (like whitelisting) to Windows Home. It can create the WDAC policy files identical to those created by PowerShell on Windows Pro. For now, I test it without GUI - the tests will be continued for about one year.:)(y) Post edited. Normally, the ASR prevalence rule for EXE, COM, and SCR files can overlap with WDAC default-deny restrictions. In BabySitter, these files are whitelisted globally in WDAC (by file rule) to avoid overlapping. Additionally, I use the WDAC path rule to whitelist all Portable Executable files on the system disk, so also DLL and OCX files are allowed on the system disk (but restricted on other disks). This is crucial to avoid problems when installing/updating/uninstalling/running applications. [B]Still, the installations/updates made via MSI installers are inconvenient (require turning off the script/MSI protection or whitelisting by hash).[/B] [/QUOTE]
Insert quotes…
Verification
Post reply
Top
