By Sean M. Houle, CISSP, Louisville VA HTM
We often see warnings to change default passwords, but there are dangerous defaults beyond passwords. We are going to look at a few security issues that may exist in the configurations of your Windows systems. Our lab environment starts out with a fresh installation of Windows Server 2022.
I chose Windows Server because the setup process is just a little different than the desktop OS. The last step of the installation greets us with an old friend, the built in Administrator account. This will be the only account active when the installation is complete. We configure a password and then we log into the desktop of the built in Administrator account. Since the only account that exists on the system right now is the default administrator, we can keep ourselves from being locked out by creating a second admin account named “MyNewAdmin” and set a password for it.
This is where we will start to explore the danger in the defaults. We create a folder on the computer where we store all our very important documents. We attempt to map our drive using the credentials of our new “MyNewAdmin” account, but oops we’ve used the wrong password, 10 times. That’s when we realize we’ve been typing the wrong password put in the correct password and we successfully map the drive. Wait, 10 times, shouldn’t the account have locked out after that many bad password attempts? If we look at the Account lockout policies within the local security policy, we see that the default setting of “0” indicates that accounts will never lockout (Figure 1). We changed that to a setting of five invalid logon attempts before lockout. We reattempt five bad logons and see a message stating that the account locked out. We attempt with the correct password and are unable to logon or map the drive.
Excellent work, we have mitigated our first default configuration vulnerability. Now let’s verify that the same setting works for the default administrator account that we set the password for during installation.
This time we will simulate activity of a malicious actor to test our configuration. Instead of just typing in a bad password five times, we will use a wordlist to attempt many logons in quick succession. We pipe the contents of the wordlist rockyou.txt into the password section of our net use command (Figure 2). We let it run for several minutes resulting in 9,928 invalid login attempts (Figure 3), but we are missing the message stating that the account is locked it simply keeps repeating that the password is incorrect. Let’s investigate further. We check the account properties in computer management (Figure 4) and breathe a sigh of relief because it states that the account is locked out. If we try the correct password it will fail because the account is locked out right? Wrong, we instead get a message stating that the command was successful, and we can navigate the contents of the shared folder (Figure 5). This is documented behavior of the built in Administrator account to prevent this account from being locked out either on accident or through an invalid password-based denial of service attack. In the case of stand-alone systems, there has primarily been only one way to mitigate this potential security issue. The account cannot be deleted, so the only option is to disable this account after setting a very strong password in case the account is re-enabled at some point. This was going to be my one and only remediation suggestion until Microsoft announced in KB5020282 that systems with the October 11, 2022 cumulative update will have a new option in the Account Lockout Policy section of Local Security Policy to Allow Administrator Account Lockout (Figure 6). If enabled, this setting will enforce the account lockout policy on the built-in Administrator account.
What’s in a name? Well not much if we’re talking about the built-in administrator account. A common practice is to change the name of the built in Administrator account so that malicious actors won’t have a known username to attack. This can be dangerous however because the real identity of Windows user accounts exist in what is known as the SID, in the case of the default administrator the SID always ends with a RID of 500 (figure 6). Even if the name is changed the account with RID 500 cannot be locked out without the mitigations in place described above. If you don’t see the name “Administrator” in the list of users in computer management it has been renamed and should be identified by examining the SIDs of the existing accounts, remember the account cannot be deleted.
System hardening is an ongoing task and taking steps to examine the current configuration of Windows Servers is worth the effort. Account lockout combined with strong passwords can significantly slow down the efforts of a malicious actor and help keep your systems safe as part of defense in depth strategy.
– Sean M. Houle, CISSP, works in the Louisville VA HTM department.
