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: 897583" data-attributes="member: 32260"><p><span style="font-size: 18px"><strong>Windows Defender BabySitter for Windows Home.</strong></span></p><p></p><p><span style="font-size: 15px">It is my little project on joining WD with a simple WDAC policy. WDAC can restrict PE Executables (EXE, SCR, DLL, OCX, etc.) and non-PE files (Windows Script Host and PowerShell, or MSI files).</span></p><p><span style="font-size: 15px"></span></p><p><span style="font-size: 15px">Here is what WD BabySitter can do:</span></p><ol> <li data-xf-list-type="ol">The whole system drive (usually c<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite110" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> is whitelisted in WDAC for PE Executables, but all other drives (also flash drives) are restricted by WDAC.</li> <li data-xf-list-type="ol">WDAC restricts non-PE files on all drives (also on system drive). The restrictions for PowerShell follows from applying the Constrained Language Mode. Similar restrictions are applied for Windows Script Host. So, scripts can be run but advanced functions are disabled.</li> <li data-xf-list-type="ol">The restrictions for non-PE files can be turned OFF separately from PE Executables.</li> <li data-xf-list-type="ol">Turning OFF/ON the restrictions for PE Executables and non-PE files do not require to log off the account.</li> <li data-xf-list-type="ol">If the user wants to protect the "Desktop, Documents, Pictures, Videos" user folders, then these folders have to be<strong><span style="color: rgb(184, 49, 47)"> moved</span></strong> to a non-system drive (right-click >> Properties >> Location >> Move ...).</li> <li data-xf-list-type="ol">It is possible to whitelist PE Executables in the predefined folders (Games, Programs), but the user cannot whitelist anything by himself.</li> <li data-xf-list-type="ol">All files (also non-PE files) accepted by Microsoft ISG are allowed to run (requires WD).</li> <li data-xf-list-type="ol">If the Portable Executable is not accepted by ISG but has been checked by SmartScreen Application Reputation, then it is allowed to run. One can use RunBySmartScreen for files without MOTW. This does not work for non-PE files.</li> <li data-xf-list-type="ol">Some protection for BAT, JAR, CHM, ... files can be done in the similar way as in SysHardener (no whitelisting).</li> <li data-xf-list-type="ol">It is probably also possible to block some LOLBins (via WDAC or Image File Execution Options).</li> </ol><p>In theory, the Microsoft ISG feature looks good. But in fact, it is very restrictive and different from SmartScreen. All applications have to be installed on system drive or in whitelisted folders (Games or Programs) on other drives. The installations/updates based on the standalone EXE installers can be done safely and without problems (also from the protected folders).</p><p>The software installations/updates based on MSI installers can be performed without problems only for very popular applications accepted by ISG, but otherwise, they will require turning OFF temporarily the protection for non-PE files.</p><p></p><p>Some info about Microsoft ISG:</p><p>"<em>The Microsoft Intelligent Security Graph relies on the same vast security intelligence and machine learning analytics which power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having known good, known bad, or unknown reputation. When an unevaluated file is run on a system with WDAC enabled with the Microsoft Intelligent Security Graph authorization option specified, WDAC queries the file's reputation by sending its hash and signing information to the cloud. If the Microsoft Intelligent Security Graph determines that the file has a known good reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file. Every time the file tries to execute, if there are no explicit deny rules present for the file, it will be allowed to run based on its positive reputation. Conversely, a file that has unknown or known bad reputation will still be allowed to run in the presence of a rule that explicitly allows the file.</em></p><p><em></em></p><p><em>Additionally, an application installer which is determined to have known good reputation will pass along that positive reputation to any files that it writes. This way, all the files needed to install and run an app are granted positive reputation data.</em>"</p></blockquote><p></p>
[QUOTE="Andy Ful, post: 897583, member: 32260"] [SIZE=5][B]Windows Defender BabySitter for Windows Home.[/B][/SIZE] [SIZE=4]It is my little project on joining WD with a simple WDAC policy. WDAC can restrict PE Executables (EXE, SCR, DLL, OCX, etc.) and non-PE files (Windows Script Host and PowerShell, or MSI files). Here is what WD BabySitter can do:[/SIZE] [LIST=1] [*]The whole system drive (usually c;) is whitelisted in WDAC for PE Executables, but all other drives (also flash drives) are restricted by WDAC. [*]WDAC restricts non-PE files on all drives (also on system drive). The restrictions for PowerShell follows from applying the Constrained Language Mode. Similar restrictions are applied for Windows Script Host. So, scripts can be run but advanced functions are disabled. [*]The restrictions for non-PE files can be turned OFF separately from PE Executables. [*]Turning OFF/ON the restrictions for PE Executables and non-PE files do not require to log off the account. [*]If the user wants to protect the "Desktop, Documents, Pictures, Videos" user folders, then these folders have to be[B][COLOR=rgb(184, 49, 47)] moved[/COLOR][/B] to a non-system drive (right-click >> Properties >> Location >> Move ...). [*]It is possible to whitelist PE Executables in the predefined folders (Games, Programs), but the user cannot whitelist anything by himself. [*]All files (also non-PE files) accepted by Microsoft ISG are allowed to run (requires WD). [*]If the Portable Executable is not accepted by ISG but has been checked by SmartScreen Application Reputation, then it is allowed to run. One can use RunBySmartScreen for files without MOTW. This does not work for non-PE files. [*]Some protection for BAT, JAR, CHM, ... files can be done in the similar way as in SysHardener (no whitelisting). [*]It is probably also possible to block some LOLBins (via WDAC or Image File Execution Options). [/LIST] In theory, the Microsoft ISG feature looks good. But in fact, it is very restrictive and different from SmartScreen. All applications have to be installed on system drive or in whitelisted folders (Games or Programs) on other drives. The installations/updates based on the standalone EXE installers can be done safely and without problems (also from the protected folders). The software installations/updates based on MSI installers can be performed without problems only for very popular applications accepted by ISG, but otherwise, they will require turning OFF temporarily the protection for non-PE files. Some info about Microsoft ISG: "[I]The Microsoft Intelligent Security Graph relies on the same vast security intelligence and machine learning analytics which power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having known good, known bad, or unknown reputation. When an unevaluated file is run on a system with WDAC enabled with the Microsoft Intelligent Security Graph authorization option specified, WDAC queries the file's reputation by sending its hash and signing information to the cloud. If the Microsoft Intelligent Security Graph determines that the file has a known good reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file. Every time the file tries to execute, if there are no explicit deny rules present for the file, it will be allowed to run based on its positive reputation. Conversely, a file that has unknown or known bad reputation will still be allowed to run in the presence of a rule that explicitly allows the file. Additionally, an application installer which is determined to have known good reputation will pass along that positive reputation to any files that it writes. This way, all the files needed to install and run an app are granted positive reputation data.[/I]" [/QUOTE]
Insert quotes…
Verification
Post reply
Top
