]> Windows Protected Folders: Network shares 🌐:aligrant.com

Windows Protected Folders: Network shares

Alastair Grant | Monday 8 June 2020

Windows 10's Windows Defender security program comes with a feature called "Protected Folders".  This is a type of ransomware protection that disallows write-access to selected folders.  The idea is simple, when a malicious program tries to write over your documents with an encrypted version, it gets rejected by the operating system; an effective first-line of defence (note, due to exploits and escalation vulnerabilities do not rely on this as your only protection).

Personally, I don't keep many documents on my computer, but centrally on a server.  I wondered whether this feature could be used to protect network locations in the same way.

The UI will accept UNC paths (e.g. \\myserver\share), but it does require a share name on the path and not just the server, which means you have to list every share on the remote host individually.  I then suspected it might be a simple match, so adding a fully qualified name wouldn't protect against a netbios name (\\myserver.mylan is different from \\myserver).

To test this I created a simple exe that writes a file into a directory of my choice.  I then added a fully qualified UNC path (e.g. \\myserver.mylan\share) into the protected folders list and tried out a few scenarios.

Blocking FQDN

Test Example Outcome
Write to share via FQDN \\myserver.mylan\share Blocked
Write to share via hostname only \\myserver\share Allowed
Write to share via CNAME FQDN \\alias.mylan\share Allowed
Write to share via CNAME only \\alias\share Allowed
Write to share via CNAME and different FQDN \\alias.external\share Allowed
Write to share via IPv4 address \\192.168.0.1\share Allowed
Write to share via IPv6 address \\fd00-1--1.ipv6-literal.net\share Allowed
Write to share via a HOSTS file entry \\entry\share Allowed

My suspicion was correct, it is an exact match on the path.  I was hoping Windows Defender would at least be smart enough to know the difference between a FQDN and a host that is in the DNS prefix list for the client, but sadly not.

Blocking IP address

The only other test I though worthy was to block it by IP address, although my hopes weren't high as when it comes to IPv6, you can see in the example above UNC really struggles to handle it.  I added both the IPv4 and IPv6 destinations to the block list (\\192.168.0.1\share\\fd00-1--1.ipv6-literal.net\share) and removed the previous entry.

Test Example Outcome
Write to share via FQDN \\myserver.mylan\share Allowed
Write to share via hostname only \\myserver\share Allowed
Write to share via CNAME FQDN \\alias.mylan\share Allowed
Write to share via CNAME only \\alias\share Allowed
Write to share via CNAME and different FQDN \\alias.external\share Allowed
Write to share via IPv4 address \\192.168.0.1\share Blocked
Write to share via IPv6 address \\fd00-1--1.ipv6-literal.net\share Blocked
Write to share via a HOSTS file entry \\entry\share Allowed

No real surprises here.

Conclusion

Whilst Protected Folders might be useful for local directories, and it's entirely possible to add remote ones, it's fairly useless at remote protection and actually brings a false sense of security.

We can see by the tests above, it would be trivial for an application to access the remote server directly by IP address or add an entry into the local hosts file (requires Administrative privileges) to circumvent a folder being added via UNC path.

Instead I recommend taking the appropriate precautions on any remote file shares.  Such as read-only snapshots and regular disconnected backups (with multiple versions being retained).

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.