Sessiondump Meterpreter Extension

Mimikatz is awesome right, so is WCE. But both have one fatal flaw, even though you can execute them in memory {link} - you still have to have the binaries, remember the command to execute it in memory, and ultimately transfer the entire binary over so that metasploit can do its thing.

Then along came SessionDump. I only noticed this because someone was tweeting congratulations to someone on writing it:

No blog post or huge Vegas lights talk on it at DefCon or Blackhat. Just posted online in a corner of the Internet:

http://www.hsc.fr/ressources/outils/sessiondump/

Before we get started lets be clear about one thing. Sessiondump while awesome doesn't do everything that Mimikatz does. However, it does do the feature of mimikatz that I do use the most, the logged on user hash dumping as well as the wdigest clear text password dumping. It does this as a Meterpreter extension that operates using reflective DLL injection. Does that solve our minor issues we had with mimikatz, as of right now, only partially. This code was simply posted online, not in a pull request or submitted to Metasploit in any way. So you still have to have the binary + code. What about the remembering, surely it makes it so I can just tab complete my way to passwords right? Yup, it does, but until/if it is in the Metasploit trunk you will still have to remember how to get it installed (which we will go over in a bit). The final question is yes it does still transfer a complete DLL over to the host same as any of the other extensions (not to disk mind you, just memory),.

Without further ado lets go ahead and get the file and do a bunch of extracting. 

And finally placing everything in it's correct place, which was nice of the author to make easy by making the archive the same as the Metasploit directory structure:

Cool, everything should be good to go. Lets use this thing. I'm using psexec to get a shell but any way you get a windows native meterpreter fine, with one caveat, and its the same as with any of the other aforementioned tools. You need to be Admin (past UAC, w/ SeDebug privilege) or NT\AUTHORITY SYSTEM.  After that it's cake, load the extension:

 

Here is the available commands:

And run getHashes:

or getwDigestPasswords:

Thats is, you free passwords, YAY...

Possible issues you may run into:

1) If you are on a x64 box and meterpreter isn't running in a x64 process it will fail saying that it doesn't have the correct version offsets, here is how you can check:

x64 system and Meterpreter is x86/win32. Lets find a good process to migrate into and kick it from there. Winlogon isn't the greatest choices since if meterpreter decides to crash it during migration then the system will go down, whereas a service running as SYSTEM will probably just restart if something fails.

2) If by any chance you are running it against a system the author hasn't gotten the offsets for. I don't' have a screenshot for this one because he covers all the languages I have CMs for, but the author was awesome enough to include a few python scripts that can help you generate the correct offsets. I'll show you by running it on my lsass and widgets.dll files even though he already has this data included in the CSV file that comes with session dump.

Thats all for now folks, may the shells be with you.

Finding Admin Access

You've got shell, and a set of credentials but you're coming up empty on what you can do with those credentials. This is especially problematic when you can't get past UAC as you are either in a AlwaysNotify situation or not a local admin.

(I'm not trying to pull some some "insert magic here" on the assumption of credentials just at the time of this writing I have only just started working (created a blank file) on a post module to do this as your current user, so until then, you need credentials)

Enter the auxiliary module:  auxiliary/admin/smb/check_dir_file

First we set up a route as aux modules don't have a "SESSION" parameter:

Use the module and set our credentials:

Next, set ADMIN$ as we can't guarantee C$ is the primary drive, but ADMIN$ will definitely be the WINDOWS directory. Our RHOSTS is our target range

A simple 'run' and away it goes:

So we can see that our lowly user that doesn't have any chance of bypassing the UAC on his current system can pivot to these other systems (172.16.10.10, and 172.16.10.150) quite easily.

=============================================================================

The rest of this has nothing to do about admin access, just some tricks to do it better

=============================================================================

As many of you know I'm not a huge fan of sending packets I don't need to so instead of just spraying a range (which I doubt would be seen, but why take the chance?)

[Update: While computer_browser_discovery does lookup all the hosts and sends -more- packets than check_dir_file would, those extra packets are sent at DNS resolvers not into empty space that can be detected by network sensors]

Enter computer_browser_discovery:

This module does the equivalent of 'net view' to get a list of computers on the domain. You can change the LTYPE to "SQL" to just get MSSQL boxes but we're going for everything:

As you can see WIN7X86 (the box we are on came up with 0.0.0.0) expected. and the .150 address didn't show up at all as it's not on the domain. So the benefits is that it's quieter on the wire and you probably will find hosts that aren't in your immediate IP range. (Not the case here simply because I don't have a big enough test network). The disadvantages are as with the .150 address you may miss hosts.

Next we add the found host's IP addresses to a text file (targethosts.txt)

[because at the time of this writing the computer_browser_discovery module doesn't add the hosts to the MSF database]

Then use the smb_version module which does a couple things, it verifies that the hosts are there and alive, adds them to the MSF database, and what version of Windows (or samba) they are running:

(We still have our route set up so this is module is going through our low privilege user still)

And now we have info in the DB for better targeting:

Then back in our check_dir_file module we just use the hosts -R to have the database automatically set RHOSTS to the hosts in the database that match your search or alternatively use services -p 445 -R to add all the hosts that you've found port 445 open (everything smb_version finds will be shown in services)

One more way you can get hosts is doing reverse lookups of ranges. You can just hit a range you know of, or guess ranges based on the computer_browser_discovery results. You can do this with resolve_ip module (this can be pretty slow on ranges that don't have many hosts):

I used the range this blog is hosted on 1) because for some reason my stupid VM wasn't resolving internal stuff 2) To demonstrate that you can use the module to resolve anything, not just internal ranges.

So to wrap up, we have a ton of ways to find hosts that don't involve traditional scanning (smb_version is the only thing that comes close). And we've located two hosts that we have the ability to administer. One oddly enough being the domain controller, so don't ever discount the access you already have. Tunnel vision is the pentesters worst enemy.

BypassUAC got a facelift

Dave Kennedy and Kevin Mitnick submitted the "bypassuac" post module to Metasploit a while back (last DerbyCon?). Which is awesome and they did some fantastic work, but I had a few complaints as probably anyone did who used the module on a somewhat modern network.

"Old" module (post/windows/escalate/bypassuac):

I decided to give it a bit of a face lift:

"New" local exploit module (exploit/windows/local/bypassuac):

All of the credit for the availability of this module goes to @egyp7 though, without his epic addition of local exploits to Metasploit the majority of the updates to this module wouldn't be possible.

Anywho, on to the new features:

1) You can set any windows payload you want to use now:

and yes it supports EXE::Custom.

2) It lets you know if it will be able to bypass the current setting of UAC or not:

Even when you're going overkill with it:

(ASK module if UAC is disabled will just elevate without any kind of user prompt)

And of course it works as expected if UAC needs bypassing:

One thing I have yet to update is a simple check to make sure you are an admin that can actually bypass UAC. If you aren't, then you'll be leaving this lovely calling card behind for the user:

Mounting SMB shares over Meterpreter

Ok, this is pretty straight forward no magic:

Got a shell, doesn't have to be SYSTEM

Add a route to the internal range or directly to the host you want over the session you want

Mosy on over  to the Socks4a module. And in another terminal we need to make sure our proxychains.conf file in /etc/ or where ever you store your conf is correct. 

It defaults to 9050 on 127.0.01 for Tor, that's pretty easy to cope with and no reason to mess with it if you actually use it for Tor for other things.

Run the socks proxy with the Tor-like settings. (Remember to shutdown Tor first)

And the rest is gravy. The % (percent sign if blog software mangles it) is a delimiter that smbclient and other samba tools recognize between user and password (so it doesn't prompt you for it).

And just to love it working:

yay files.. Yes I know I didn't use smbmount but it works the same as well as rpcclient.

A side note here is if you are using the pth-tools from:

https://code.google.com/p/passing-the-hash/

You can use hashes instead of passwords for stuff like this. But who are we kidding? Who doesn't get clear text passwords anymore ;-)

Raising Zombies in Windows: Part 1 - Passwords

With the use of Mimikatz and WCE, clear text passwords are much more common. What isn't always there is the user. They take lunches, go home at a reasonable time and generally aren't really appreciative of our (pentester/red teamer)'s schedule.

A straight forward way, and provided by Microsoft to create a process as a user (whereby having their token readily available is using 'runas.exe':

w00t, we the user is present, we can migrate our meterepreter session into that notepad and we're good right? Problem there is you have to interactively input the password, so without a real cmd.exe or RDP session of your own, (VNC payload would work), you're generally SOL.

There are a ton of posted ways around this, most involve make a wrapper script to input the password for you such as this one:

(this was pretty unique as it actually sent the keys to the key buffer instead of directly to STDIN)

Another way if you don't mind dropping / creating a custom bin, AutoIT makes this REALLY simple:

This could be 2 lines if you really wanted it to be but I like to make things a bit more universal. You could also execute this directly in memory with meterepreter's execute command with the "-m" argument after you've built the AutoIT script into a EXE.

But what go through all that trouble? Railgun can do this just as easily. Drop to IRB or create a script that does the following:

a = client.railgun.kernel32.GetStartupInfoW(56)["lpStartupInfo"]

client.railgun.advapi32.CreateProcessWithLogonW("USER","DOMAIN","PASSWORD","LOGON_WITH_PROFILE","notepad.exe",nil,0,nil,nil,a,32)

This will create a notepad.exe process with the defined user. But we can go a bit more stealthy, since we really only need their account token we can just user LogonUser:

client.railgun.advapi32.LogonUserA("USER","DOMAIN","PASSWORD","LOGON32_LOGON_INTERACTIVE","LOGON32_PROVIDER_DEFAULT",4)

 

List the tokens available with Incognito, your new user will be there, steal it and you're done. You now have the ability to user that account/domain token on any of the hosts you've compromised on the network, not just the ones they happen to have left themselves logged in. This gets really fun on servers where the admin hasn't logged in but you wanna grab all of their IE saved passwords ;-)