For my first fully independent research topic I chose to look at the registry key created when an object is shared.

This all started with a job we were investigating recently where the indicators we were given did not turn up any good evidence, as such we started looking wider across the system. I stumbled across the LanmanServer\Shares key and realised that an exfiltration method could involve a shared folder. While this ended up having no relevance to the job we were looking at, I decided to learn something new. Especially as the answers don’t appear to be at the other end of Google!

Methodology

I tested this on the versions of Windows I had available to me, these were Windows XP SP3, Windows 7 SP1 and Windows 8.1. I have the technical release of Windows 10 too, but I’m not going to base any research on an O/S that can change any number of times before release.

I don’t have a copy of Vista sadly(?), however as Vista appears to take the worst parts of XP and 7, the results wont be wildly different. If you are dealing with a Vista case you will need to carry out your own testing I’m afraid. In fairness though, you should validate all of my results for yourself before putting them into a report. I am just hoping to save you some time 🙂

I created shares on the root of C: calling them share## (## = incrementing number). I then manually shared each folder using all of the methods I could think of! Including “simple” sharing mode in XP, Powershell in 7 & 8 and command line in all.

I tried to test every combination of share available, after a while the results became largely predictable.

Finally, the only tool I used outside of a vanilla Windows build was MJRegWatcher, this simple tool has proven to be extremely useful when I am researching changes to the registry! It monitors changes and then prompts you to accept them giving you a copy of the key that changed. You can manually select a key or hive and it accepts wildcards…. it’s freakin awesome! (I know, I know, I need to get out more!)

Location

Before we look at the results, the key in question is located

SYSTEM\currentcontrolset\services\lanmanserver\shares

The sub-key of Security handles Share user permissions, which I will not be covering in this post.

Format of Data

The data field is broken down into the following areas

CSCFlags

The CSCFlags deal with caching and breaks down into the following:

While discussing the options for caching, I am not going to discuss the effects of offline folders or how each caching option differs from the last, this information is already well documented on the web.

CSCFlag=0 is the default setting for shares on all versions of Windows tested. With this setting is up to the user to manually specify which folders will be cached.

CSCFlag=16 This is option 3 on the screen shot below “All files and programs that users open from the shared folder are automatically available offline” with the “optimize for performance” unticked.

Command line for this would be “net share <name>:<path> /cache:documents

CSCFlag=32 This is option 3 again however this time with the “Optimize performance” checked.

Command line for this would be “net share <name>:<path> /cache:programs

CSCFlag=48 This setting has offline caching disabled.

Command line for this would be “net share <name>:<path> /cache:none

CSCFlag=2048 This setting is only on Win 7 & 8 and is the default setting until you disable “Simple file sharing” or use the “advanced” sharing option. It also appears to be the default setting for the “Homegroup”

CSCFlag=768 This setting was only seen on shared Print devices.

The command line option also has a “/cache:BranchCache” option, however that caused an error or simply set the share to default options. Branchcache refers to WAN technologies and may simply be because for this experiment all of the machines were isolated.

Why do I care about the Cache settings?

What better way to avoid exfiltration evidence than using offline files? The attacker sets the folder to cache all documents and copies all of the IP data to that folder. Once it is opened all you will see is folder caching. Also if the folder is set up to allow caching and an insider takes a copy of the offline files, did they steal them or did you give them access? Honestly I am asking 😉

MaxUses

The MaxUses field deals with how many concurrent connections can connect to the share. By default this is set to “4294967295”.

In XP this can be limited to a maximum of 10 users or below, if you attempt to set >11 it will default to 10. Only if you change the radio button to “maximum allowed” will it let you have more than 10.

In 7 & 8 this has been increased to 20, however the restrictions work the same here as in XP, you can have 20 users and less or 4.3 billion users (32 binary bits set to 1, converted into base10).

Path

Nothing too shocking here, this will relate to the full path of the shared folder you are using. The only time this looks odd is for a printer. I set my test machine up with one of the first printers in the list and got the following in the key:

“Path=Brother Color Type3 Class Driver,LocalsplOnly”

Permissions

The permissions field will tell you how the share was created*

*sometimes

I will explain in a moment. First lets look at the options:

Permissions=0 is the only permission you will see from Windows (GUI) based shares in XP regardless of settings. In 7 & 8 you will see this for all simple/wizard created shares.

However, you will also see this if the cache option is changed regardless of where the share was created from. This is a real shame as it makes the Permissions field unreliable in showing how a share was created.

Powershell also sets the permission to zero, which is a real shame, in fact using Powershell to create shares looks identical to creating one through the GUI (in respect to this specific registry key. I have not tested for other Powershell artefacts).

Permissions=9 field is set if the share is created in Win 7/8 from the “advanced” sharing option. With the caveat; if you set caching this will set to zero.

Permissions=63 field is set if the share was created via the command line. Both net.exe and net1.exe create the exact same results. Once again caching changes this setting to zero.

Why do I care about this?

If you know your attacker prefers to use GUI or command line to exfiltrate data, this can show which way the share was created, as previously shown it’s not a guarantee, but if you see a suspicious share with a permissions value of 63, then it probably just became a whole lot more suspicious!

Remark

The remark field is present whenever the share Permissions field is set to zero. It is only present in the 63 and 9 shares when /remark:<remark> is set or a remark typed into the remarks window.

Kind of odd I know, I assume this is a legacy feature. From what I have surmised the Permissions=0 is the legacy setting.

Type

The Type field was driving me nuts, I could only get it to either be 0 or 1 for folders and printers respectively. I was sure there must be more settings, and as I was researching Powershell I came across this list . I haven’t had the chance to test all of these, but providing disk drive is synonymous with folder, then I see no reason to instantly dis-trust it.

[Source]

CATimeout

Windows 8 brings in a new field; CATimeout. I couldn’t get this to display anything except zero, so I did some research online instead. I came across an MSDN page which had the following description:

[Source]

“In case of a failover, the number of seconds the client will wait before failing the operation.”

I am going to assume this is for domain environments, as I cannot see a setting for failover/time out. Not overly exciting from a forensics standpoint, but could be useful to admins.

Conclusion

We have looked at all of the fields in the data portion of the lanmanserver\shares key. I am happy that I have learned something from carrying out this research, I only hope that it helps someone in a job one day. At least now I know when I look at a shared folder I have options to see how it was created. Previously that would have to be via pre-fetch or shellbags. Now I can combine those with this data and hopefully the stars will align!

As always, feedback is appreciated, especially if you disagree with any of my findings. The average time of day for my research was between 2300-0200 (same as writing this blog post).