In our experience, we see many Windows environments in which the local Administrator password is the same for many machines. We refer to this as Wide-Spread Local Administrator Re-use. This type of configuration is extremely advantageous to an attacker. Once the attacker has the local Administrator password for one computer, they can usually pivot to other computers in the environment with ease and begin retrieving other user credentials and potentially sensitive information on the systems. In some cases, only the Administrator hash is needed to pivot with that account.
We typically start with a non-privileged user when performing pivot engagements and attempt to escalate privileges to that of a Domain Administrator. On a recent engagement, a lot of the normal escalation techniques didn’t work out. Beau Bullock (@dafthack) hopped on to aid me (as he so often does) and we put our heads together on this.
One of the escalation methods that I had already tried was password spraying. For those that don’t know, the concept of this method is that you try a few common passwords against a large set of users. The advantages that this technique has over brute-force login attempts is that you are less likely to lockout accounts and are very likely to find a valid password for at least one user.
During this engagement, the network was small and only one valid set of credentials was found. The user did not have special privileges anywhere but they were able to access an internal SharePoint-type server that our user could not access.
We browsed around the SharePoint server and were able to find a document that detailed how new user-machines should be setup. In this document, it told what the local Administrator password should be for every new workstation. It did not talk about changing it. Re-read that and give it a moment to digest. As you can imagine, we were thrilled!
Almost immediately, we tried the password on our machine. Sadly, however, it did not work. It had to be valid somewhere though…and we needed a way to check. Metasploit contains modules that allow for you to do this. The modules require a session to be established on your internal computer first. We could have established a session but we wanted an easier way. Thinking back to the password spraying attack, it hit us; that command could just be modified to test for wide-spread local admin use.
The following is a typical password spraying command:
@FOR /F %p in (pass.txt) DO @FOR /F %n in (users.txt) DO @net use \\LOGONSERVER\IPC$ /user:domain\%n %p 1>NUL 2>&1 && @echo [*] %n:%p && @net use /delete \\LOGONSERVER\IPC$ > NUL
Effectively, it takes a password out of the pass.txt file and pairs it up with each user in the user.txt file. It then attempts to authenticate each user:pass combo against the domain’s LOGONSERVER by issuing a net use command as that user.
How do we modify this for testing for wide-spread local admin? Simple. First, we need to get a list of systems in the environment. The following command can be used for this task:
net view /domain > systems.txt
Next, we need to modify our loop a bit. For this check, we assume that we have a valid set of credentials. We need to iterate over the systems rather than users and passwords. We modified the password spraying command to be as follows:
@FOR /F %s in (systems.txt) DO @net use \\%s\C$ /.\Administrator AdminPass 1>NUL 2>&1 && @echo %s>>admin_access.txt && @net use /delete \\%s\C$ > NUL
The concept of the command is the same as before but attempts to access the C$ share on each machine rather than the IPC$ share on the domain’s logon server. Anywhere that this command succeeds, we know that the Administrator credential is valid. The list of systems on which the account is valid are output to a file named admin_access.txt. You could then start grabbing up credentials off each of those machines using one of many methods. In our case, this showed us that the credential we found was valid for almost 200 machines on the network and we were quickly on our way to DA.
In conclusion, Wide-Spread Local Administrator accounts continue to be a common problem in many networks. There are existing methods to test for this once you have a valid set of credentials. Here, we have described an easy way that you can do this by using built-in tools on the Windows command shell.