I’ve been pentesting a while now and many times it’s the same thing over and over. Not all gigs can be awesome, sometimes lather, rinse, repeat is the name of the game. Find an exploit (MS08-067, jmx-console, weak passwords) get on the box, get the local admin hash and domain cached credentials pass them around, get meterpreter shells on a bunch of windows systems and then go through them to find “the one” that has an admin token for you to create and escalate an account. Account escalation, is of course, not the end goal, it just helps you to move more freely around the network to go after the real goods, usually data in the database servers.
Even with resource scripts and post exploit modules, going through 100′s of shells can be time consuming and tedious. I know if I see a server in the list, that’s a much better target. Servers tend to mean better tokens, local hashes and domain cached credentials. However, most of the time we get on a workstation and go from there.
Last week I started thinking, how great it would be if I could know which system(s) had a DA/EA account logged in, or a process running. This would be way better/faster than our current method. So I figured with a local administrator account I could probably pull it off. I hit up Google for a few windows commands and parsed the output and incredibly I had a working PoC. (In bash of course…so it’s not pretty)
I told my boy purehate about it and we discussed another issue we always run into with the smb_login module for Metasploit. smb_login is awesome, as it is a quick way of letting us know if an account we obtain (normally domain cached credential) is legitimate. The main issue we sometimes have is the smb_login module does not actually check if that account has the ability to log in remotely. If the account cannot log in remotely (RDP/SMB) its really no good to us, well less good.
This post will show you how to verify if an account has remote log in capabilities and if a domain admin account can be leveraged from the systems on the network. We are working on a metasploit module, but currently the functionality only exists in smbexec (v1.2.2).
smbexec has two new options:
- Remote Login Validation
- Check Systems for Domain Admin
Before we get started with smbexec, lets use the smb_login module from metasploit. I am going to feed it a user list (users.lst) that contains a pair of credentials. Both of the accounts are valid accounts for my network, but only one of them can actually log into systems remotely. The credentials are emilam:P@ssW0rd and jbravo:P@ssW0rd.
As you can see, metasploit says they are both valid logins.
However if we try to RDP to the host with the first credential pair we are not able to actually log into the system, so there isn’t truly a “SUCCESSFUL LOGIN”, just a verification that the credentials are valid.
Since its extremely important for us on a pentest to know which systems we actually have remote log in capabilities, we coded up a very simple check. Basically all we are doing is issuing a command via smbclient that will echo back the connection status. If the response has the connection information then we know we can remotely log into the system.
Lets try the exact same check with smbexec. We will use the same credentials and host to ensure we are comparing apples to apples. Below you can see the proper responses as they relate to the remote log in capabilities for the accounts and the provided system. smbexec will automatically store the information pertaining to a successful login in a text file to ensure everything is well documented.
If you look closely at the screenshot above, you will see we answered ‘N’ to a question about a DA/EA check. Let’s run it again and answer ‘y’ to that question.
Holy crap! Look at that, not only did it tell me I could log into the system remotely, but it checked and found Domain Admin processes running on the system. Now I know exactly what system I’m going after!
If you prefer to only run a check for DA/EA you can select that option from the menu and the remote log in notifications are no longer returned or logged.
The true power of smbexec is a samba tool called winexe. Winexe is the Linux equivalent to psexec, they are virtually identical. Essentially I am using winexe to pass command to the Windows systems which are executed and I parse the results returned.
In order to check for DA/EA smbexec does the following:
- On the first system in the list, it issue commands to find the members of the domain and enterprise admins group, parse out the names and place them in a file
- For every system in the host list it executes two command to ascertain logged in user accounts and the task list of processes running on the system and parse those into a file.
- Finally it simply compare the lists for a match
Here are a few caveats:
- You must have a valid set of local admin credentials (minimum)
- Port 139 or 445 must be open and allow log in (default)
- winexe must not be blocked on the target system (usually not since its a legitimate tool)
- Your credential list must be TAB separated (plaintext or hash)
Armed with this information, you can now go after ONLY the systems you know have a DA/EA process running on them. This approach should help pen testers stay below the radar during their testing. I know this will save me hours on a pen test and am looking forward to using it on my next gig.