If you are on the blue team, you’re most likely aware of the powershell script „NetCease„. It’s a handy tool to harden the default permissions for net session enumeration over smb in such a way that normal domain user rights are no longer sufficient to query for users who have a session open with a fileserver. It essentially modifies a registry setting which contains an ACL in binary format. Details on the NetCease script page.
The scripts effect can easily be verified by manually running „netsess.exe“ against a target system. A successfully hardened box should no longer return session information, unless queried by a user with admin rights on the target.
Since we use bloodhound in both our red teaming and blue teaming engagements extensively, i wanted to gain better understanding on how this hardening method is effecting the session collection procedure. Does NetCease have any effect on session collection at all? According to several sites [1] [2] it should – but we have not yet seen any impact at our customers environments, and what worried me even more, in our own prod and lab environments i was completely unable to reproduce the hardening method’s promised effects.
As you can see below, we gained session information in bloodhound for server SRV007CM, altough netsess.exe failed to retrieve this information.
So where is this data coming from? The domain controller maybe? Let’s harden this one too:
Still, no dice. Bloodhound again knows i’m having sessions open – picture omitted, as it’s the same result as above….
Time for an in-depth investigation!
Bloodhound’s session collection methods – in depth
There are two relevant methods in bloodhound’s ingestor: Session and LoggedOn. The ingestor, when started without optional parameters, or with the specific parameter „Session„, does a smb session enumeration by default, similar to the method used in netsess.exe. When run with the optional parameter „LoggedOn„, or „All,“ it runs two additional collection methods. One is calling an API named „NetWkstaUserEnum“, but it requires administrative rights on the target. It also tries to connect to the target via remote registry, this is where it gets interesting. But step by step.
METHOD ONE: SESSION COLLECTION
When we harden a box with netcease, this is how wireshark sees the traffic. You will notice WERR_ACCESS_DENIED for a call from netsess.exe and „Unknown DOS error“ for a call from bloodhound.
In a non-hardenend environment, trying to enumerate sessions with netsess.exe and bloodhound the result looks like this:
In this case netsess.exe reveals this information:
And the data captured with the ingestor then looks like this:
This needs a little explanation. We have queried the server SRV007CM for session information, but bloodhound shows us results for two users on two clients (PC002, PC006NB2), while the server in question doesn’t even show up in the results. Any interactive sesssions (RDP) on the server are not shown. Why is that? The answer is that „HasSession“ is probably just an ill chosen naming convention if you look at it from a protocol perspective. The users in the picture have SMB sessions to the server, but what bloodhound means with „HasSession“ is an actual logon (like interactive or RDP) to a machine. A better name would be „IsLoggedOn“ or something like that.
Regardless of the name: what we see in the GUI is correct – these users are logged on to their workstation, and we have no information what is going on actually on the remote server, because this is not something we can query with net session enumeration.
All of this was quite confusing to me first, but hopefully this clears it up for you too.
METHOD TWO: LOGGED ON ENUMERATION
As mentioned above, there are two additional methods in the ingestor, which have to be triggered manually (via „LoggedOn“ or „All“ parameter). Let’s ignore NetWkstaUserEnum for now, it requires admin rights on the target, and focus on the remote registry method. What it does is, it tries to connect to the remote registry service of the target, and enumerate HKEY_USERS. Based on the sub-keys it finds, it deduces who is logged on to this box. Contrary to what’s documented on the bloodhound website, this does not require admin rights, in fact it seems to work by default for any user in the domain. Let’s verify this in our lab:
Wireshark shows remote registry traffic going on, let’s try this manually from an unprivileged user, opening regedit.exe and connecting to the remote system:
Success! We were able to query logged on user information on the remote system.
The finding that this works out of the box with default permissions for any user in the domain was quite amusing even for the bloodhound slack community:
Anyway, all of this now explains the question in the introduction paragraph nicely – why does bloodhound show countless session data, although net cease hardening is in place? The answer is simply that it runs an additional data collection method which completely ignores net session enumeration, but is based on remote registry calls, which (at least to my findings), work out of the box for any user in the domain.
TO SUMMARIZE
- The net cease hardening script is still working and blocks reconnaissance at the SMB session level
- It’s usefulness is drastically reduced by the fact that remote registry reconnaissance can gather the relevant information with standard permissions
- Do not forget to run logged on session collection manually, as it is not included in the default parameter set
- Do not confuse „logged on“ and „net session“ when looking at the technical details. Bloodhound transforms both data sets into valid „HasSession“ relations, but the source of the data is from two very different things