Microsoft has baked into the upcoming Fall Creators Update of Windows 10 an interesting little feature called Controlled Folder Access, which allows you to set restrictions on which executables can make changes in certain directories. In the recent Insider Preview builds of Server 2016, Controlled Folder Access has been present, so it’s probably safe to assume the next iteration of Windows will also include this. This addition appears to be in response to recent highly-publicized ransomware attacks.
Plenty of security companies offer products that provide control over which applications are allowed to execute in which directories. Carbon Black, Trend Micro, McAfee, and many others have application control solutions that allow you to create and manage policies to keep your network safe while allowing your end-users to do their work. Make no mistake, this feature in Windows is not quite as sophisticated, but it can provide a fairly useful service for individual users if configured wisely.
So, you ready to rumble and enable it? …hold that thought!
If not implemented properly, this feature has the potential to prevent remote management such as software deployment and inventory collection, aka PDQ Deploy and PDQ Inventory.
Game plan
Setting up Controlled Folder Access is like preparing the setup for a brand new Active Directory domain. You wouldn’t dive directly into Group Policy and start implementing willy-nilly without a game plan, right? You walk the fine line between giving users secure but unusable machines, or usable machines with gaping security holes. One must think before one jumps.For PDQ Deploy and PDQ Inventory in particular, please also read Windows Firewall Ports and Exceptions for information on what to exclude from Controlled Folder Access.
An important thing to keep in mind is the lack of centralized management. PowerShell cmdlets and Group Policy objects exist to manage Controlled Folder Access, but they’ll only help so far.
If something goes wrong, you may very well have to visit each machine to repair the damage done.
What exactly can go wrong?
In my exploration and testing, I learned several neat ways to completely cut off access or destroy a machine. In one spectacular instance I witnessed many executables, including core Windows components like explorer.exe, being blocked from making any changes anywhere on the C: drive.
Windows does have a list of what they’re calling “friendly apps” that are automatically allowed by Controlled Folders to execute anywhere. But, it’s entirely possible that they weren’t anticipating anyone attempting to do something quite as ham-fisted as enabling protection for an entire drive, thus blocking friendly apps. Word to the wise, keep an exit strategy on hand when testing.
To make things worse, it was impossible to undo using Windows Defender Security Center, PowerShell, or even Group Policy. You know something’s wrong when Group Policy is denied access to make changes…
Disclaimer: My exploration and testing of this feature was done on the Insider Preview builds of Windows 10. I attribute some unexpected behavior to the fact that it is in beta and hold out hope that the final release will be more stable..
What are the default protected folders?
Controlled Folder Access is off by default. After enabling it, the list of default protected folders appears to be fairly innocuous. System folders, as well as current logged on and public user directories are protected. This, however, cannot be changed, even by PowerShell or group policy.
You are able to browse to a directory to add additional directories to the list of protected folders or browse to an executable to add it as an exception. In an extreme case, this feature will allow you to protect the entire C: drive – which, as I explained earlier, is a terrible idea. Doing this is an excellent way to render the machine unusable with only a few clicks.
This should go without saying, but do not enable this for the entire C: drive unless you’re interested in reinstalling Windows.
See controlled folder access in action
Below is one of the small tests I performed that you can follow:
Identify a folder you would like to test. We will use the shared folder named SharedFiles.
Save a file to C:\SharedFiles.Using Krita I created this beautiful stick figure masterpiece.
Turn on Controlled Folder Access. Windows Defender Security Center > Virus & Threat Protection > Virus & Threat Protection Settings > Controlled Folder Access.
Add C:\SharedFiles to the list of Protected folders.
Click Protected Folders > Add a protected folder.
Create a second file and save to the newly protected folder, C:\SharedFiles.Krita can no longer write to the directory when I attempt to save changes.
Windows Defender Security Center also pops up a helpful notification, alerting me to the unauthorized changes it blocked on my behalf.
Identify the path to Krita’s installation file.
If you, like me, don’t know the exact path of every application that needs to be whitelisted, Windows Defender Security Center luckily logs an informational event in the event viewer each time it blocks an executable from making changes to a directory. You’ll find these logs by navigating to Applications and Services > Microsoft > Windows > Windows Defender > Operational > Event ID 1123.
Add Krita as an allowed app.
Now that we’ve got the path to our application, we can add it to the whitelist:
Observe Krita now behaves as expected.
Because this was only a simple test, any production applications might require more research or more applications added to the whitelist.
Wrapping up
The downside to using the Windows Defender Security Center GUI to manage applications, is the fact that it forces you to browse for a single executable. This would be where PowerShell and Group Policy could prove useful. Scripting or automating management of Controlled Folder Access sounds significantly less cumbersome than browsing to each file on each machine
