Windows Protected Folders: Network shares
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).