Our Blog

Guest vs Null session on Windows

Reading time ~9 min

If you have been doing internal assessments on Active Directory infrastructure you may have heard the following words: “Null session”, “Guest session” and “Anonymous session”. These words describe techniques that can be used on Windows servers to connect to resources and obtain information about a computer or Active Directory objects such as users or SMB shares you have access on. Even if these techniques are well known I realised that people, including myself, didn’t understand them completely. This got me wanting to better understand it, hence this blogpost :)!

In order to illustrate this blogpost I will be using the Game Of Active Directory project developed by the awesome Mayfly. This lab aims at offering a working Active Directory network with multiple domains and vulnerabilities to test. Also, Mayfly wrote some writeups to explain which vulnerability he added and how to exploit them. So if you ever need a vulnerable Active Directory network, take a look at this project ;)!

0/ Guest vs Anonymous vs Null session

To begin with, let’s clarify one thing. There are only two techniques that can be used:

  • Guest authentication which relies on guest accounts
  • Null session also known as anonymous authentication which, within Active Directory, relies on a built-in group.

Now let’s fire up Wireshark and have some fun ;)!

I/ Guest authentication

Guest authentication is an authentication method that relies on guest accounts. These special accounts are used to give access to a Windows computer (local guest account) or to domain resources (domain guest account) to users who do not have valid credentials but still need to access a computer. As mentioned there are two type of guest accounts:

  • Domain guest account
  • Local guest account

When connecting to a resource (let’s say a SMB share) you will have to specify the username and the password of the account you want to authenticate with. For example with NetExec:

poetry run netexec smb 192.168.56.11 -u daenarys.targaryen -p 'BurnThemAll!' --shares

One could say that if you don’t have any credentials you cannot authenticate to the SMB service and thus cannot list available shares but that’s not true if the guest account of the domain is enabled. You can run the following Netexec command to try list shares using a guest account:

poetry run netexec smb 192.168.56.11 -u "someaccountthatdoesntexist" -p "" --shares

And it will work:

Question is, why? If we take a look at a packet capture, we can see that Netexec authenticates twice when running the previous command:

The first authentication is used by Netexec to determine whether or not SMB signing and SMBv1 are supported. As you can see, no credentials are submitted and we get an error STATUS_ACCESS_DENIED:

The second authentication is the authentication of the someaccountthatdoesntexist account which doesn’t exist within the Active Directory domain. Even if the user doesn’t exist we authenticate and connect to the svcctl named pipe which is used by Netexec to determine whether or not the account is local admin:

But the account doesn’t exist so what is the magic trick? Taking a look at the packet received right after sending our NTLMSSP_AUTH packet we can see the following fields:

When we connected as a user that doesn’t exist, the server was aware of it so it implicitly falls back to the guest account of the domain. Since this is a valid domain account we were granted access to the resources exposed on the domain without having any credentials! Is accessing SMB shares the worst we can do? Nope! Using this account you can for example launch coercion attacks using, for example, printerbug:

Now let’s disable the domain guest account to prevent guest authentication:

And run the following command once again:

poetry run netexec smb 192.168.56.11 -u "someaccountthatdoesntexist" -p "" --shares

As you can see it still works? Know why? Because on the BRAAVOS server, the local guest account is still enabled:

Disabling this account will prevent us from authenticating as a guest and thus prevent us from accessing the SMB shares:


Side note, you may have seen that the guest users have READ/WRITE access on the “all” share:

That’s because on the GOAD lab, the “all” share is configured to be accessible with READ/WRITE using the following rule which affects the “Everyone” group:

And since I have been wondering what’s the difference between the “Everyone” group and the “Authenticated Users” group, here is the response: the “Authenticated users” group includes users that authenticated via a valid username and password while the “Everyone” contains both the authenticated users and the guest user.


Now that we have disabled both the domain guest account and the local guest accounts, can we consider that we are safe ? Not entirely.

II/ Null session / anonymous authentication

Null session, also known as anonymous authentication, is a special kind of authentication during which the user doesn’t submit any credentials. When a user connects via a null session, he connects as a member of the “Anonymous Logon” group and inherits all ACL’s assigned to this group. You can launch a null session authentication using the following commands with Netexec:

poetry run netexec smb 192.168.56.11 -u '' -p '' --users
poetry run netexec smb 192.168.56.11 --users

These are the same and will allow you to list domain users, if successful:

But why does it work? In older versions of Windows, null sessions were used for various network operations in order to establish connections to servers without providing credentials. At some point Microsoft dropped the null session capability for security purposes but, for backward compatibility, they created a group which allows its members to authenticate via a null session. This group is called “Pre-Windows 2000 Compatible Access” and is a built-in group in Active Directory:

The thing is, this group has got special permissions over the domain which we can list here:

These permissions allow a member of the “Pre-Windows 2000 Compatible Access” to remotely call the SAMR named pipe in order to list domain users, their descriptions, their badpwd number, and even the password policy.

This is the reason why we can launch the following commands and get results from a null session authentication:

poetry run netexec smb 192.168.56.11 --users
poetry run netexec smb 192.168.56.11 --pass-pol

But interestingly enough, if we take a look at the members of the “Pre-Windows 2000 Compatible Access” on WINTERFELL we will see that it doesn’t contain the “Anonymous Logon” group:

Wait, did you expect Mayfly to blindly add the “Anonymous Logon” group to the “Pre-Windows 2000 Compatibility Access” group ? Nah this guy knows more than enough on what he is doing, instead he simply added the necessary permissions to the “Anonymous Logon” group directly:

And that is why we can call the remote SAMR named pipe!

III/ Final words

Final words:

  • Disable all guest accounts whether it is the domain guest account or the local guest accounts
  • Check the permissions of the “Anonymous Logon” group on your domain and restrict them as much as you can

This will protect your domain against all we have seen during this blog ;)!

Happy hacking!

This is a cross-post blog from https://blog.whiteflag.io/blog/null-vs-guest-vs-anonymous-sessions/.