Researcher’s footnote: The cautionary tale of public facing workfolders
So Windows 11 launched this week, and that means every single tech outlet on the planet scrounging to review the latest build, 22000, and beat everyone else to the punch. I myself am no different, having migrated my VmWare home lab to Microsoft Hyper-V via virtual disk imaging (Azure, you’re next!) But that’s not all I did, I also looked at some of the functionality of Microsoft’s older protocols. Windows server 2022 was launched this past year in march of 2020. Within it, the default setup contains all sorts of local-headed default configuration goodies. One such configuration deals with Work Folders.
Seeing this, I figured, “Oh this is just how they label SMB or Sharepoint or drive mounting, right?” After about 5 minutes on google, turns out I’m wrong. This technology is its own Microsoft-universal thing. It was introduced around the time of Windows Server 2012 R2 was introduced. The utility of this is between OneDrive and a Sharepoint group for the end user, where users log in to access a resource and a folder that syncs their files no matter what machine they connect to.
The idea of it is to configure a central Work Folder server your organization’s intranet site, again like a Sharepoint folder (which this is not) and have users access it within the office or over a VPN. The server uses a www subdomain structure, the default configuration suggested as “workfolders.contoso.tld”. It’s not network connected like SMB and it’s not AD group dependent like Workgroup folders.
Confused yet? I sure was. I venture to guess I’m not the only one. A quick googledork reveals a couple more mistakes within MSP’s who may not have had best practices in mind for this.
To bring home the point here, Work Folders are not:
SMB/Samba shares, NAS, Workgroups, FTP, Sharepoint resources, OneDrive shares, Azure shares, Any other network file systems.
Work Folders are:
AD integrated, Connected and shared to a windows user/resource profile, Cross machine compatible, should be set up and configured on an intranet, use an internet DNS namespace schema, supports proxy, encryption, logging, supportive of other windows proprietary protections such as Windows Information Protection.
So following best practices is the best way to utilize these folders: some basic hygiene for this includes:
Not using the default domain space, not hosting the server on the open internet (Preferably behind an IDS, Firewall and enterprise ingress/egress traffic monitoring tool), enforce user password policy and encryption policies.
My final caution goes to submitting this googledork to Offensive Security’s Exploit DB. Hopefully blue teams out there can take this and apply it to keep their intranet intra.
Overall though, don’t be dumb and host a folder like this on the public internet, that’s not what this service is for, and failing to adhere to guidelines puts anyone who uses your network at risk.