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.

EXE::Custom in Metasploit's Java Exploits

Let me say first off that this isn't the most elegant of ways to accomplish it. It is in the "it works for me" stage.

A quick primer on EXE::Custom: This is a setting just like RHOST in Metasploit wherever an EXE is built for Windows payloads. Such as PSEXEC, BypassUAC, etc. It tells Metasploit to ignore all of your payload settings and just use the EXE you have specified. Now this does come at a bit of a cost. If you don't have a handler set up to catch whatever is in your EXE and you have bogus information in your payload settings for your module, Metasploit won't be able to magically determine what you want it to do. So make sure that you either have the payload settings correct (even though it won't use them for the exploit) or set the option "DisablePayloadHandler" to true and start your own handler somewhere else.

With that said, the Java Signed Applet attack is one of the most widely used, one problem in the Metasploit module version is that you have no external control (such as EXE::Custom) for the binary that is dropped if you are using a Windows native payload. (I do highly recommend trying out Java Meterpreter, but that it for another post)

Here is the hack that gets me by until a more elegant solution is thought up by smarter people than I:

We are going to use the Java Rhino exploit, and this story starts with an undetectable.exe sitting in /tmp/ - How you bypass the AV you are up against is up to you. The first thing we need to do is make a core library change. Yes, this is as scary as it sounds and you should document any time you do so you can revert as needed.

In your MSF directory open up lib/msf/util/exe.rb - should look something like this:

Scroll down or search for "self.to_jar" - should look something like this:

Now add "exe = File.read('/path/to/your/evil.exe') as demonstrated below:

Cool. We've made our change, now we have to pull down a jar generated with our evil bin, and the Rhino exploit. We can do that by spinning up Metasploit with our newly editing core library. Load up the Rhino exploit via "use exploit/multi/browser/java_rhino".

One trip up that I messed up even just creating this blog post (and a constant headache in the #Metasploit channel on Freenode) is forgetting to set the TARGET variable in Java exploits. The default payload type being Java. Since we are using a native windows binary we need to specify Windows by setting TARGET 1.

Run the exploit with any settings, since we'll be just pulling out what we need. Then pull down the exploit JAR file with wget:

(Most java exploits are set to answer ANY .jar extension request with the payload.)

The HTML to load the JAR is pretty straight forward, but if you've never seen it before here it is:

Thats it. A very blank page with an exploit in it. We can do better than that:

Obviously you can do whatever you want with the HTML, mirror a site or what have you. Notice that I've also changed the name of the JAR. (You can't change the class unless you start making changes to the exploit directly and I wanted to keep this as generically applicable as possible)

Move the Applet.jar to SuperMario.jar and start up a Web server (for demo using Python's awesome SimpleHTTPServer, but apache will serve as well)

Don't forget to start up a handler for our now-external exploit:

Victim views the site:

And WA-LA! we haz shell:

Yay… Game over..

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:

Setting SYSTEM's proxy settings with Metasploit

One of the great things about the reverse_http(s) payloads is that it is proxy aware. However one of the pitfalls to this is that SYSTEM doesn't have proxy settings, nor do users who have never logged into a system (unless profile loading is triggered). The problem here arrises when you are trying to do anything as SYSTEM, also the PSEXEC only has the option of getting you a SYSTEM shell (so you're done for right out of the door)

Now, there is a stub in Metasploit that I have been unable to complete due to my lack of knowledge in the shell code world. The stub allows you to create payloads that have static proxies, which basically invalidates the need for the following. Until then here is a few ways to set / read the proxy settings for SYSTEM or any other user for that matter.

(Its here if you want to take a whack at it: external/source/shellcode/windows/x86/src/block/block_reverse_https_proxy.asm )

One of the ways @carnal0wnage and I demoed @DerbyCon was using the bitsadmin binary. Windows7/Vista/2008 come with version 2.0+ which has this great ability to run the following:

bitsadmin /util /setieproxy localsystem MANUAL_PROXY 192.168.1.55:3128 ";"

(2000,XP,2003 you could upload a copy of bitsadmin that was new enough and that would still work)

That command sets the proxy settings for the SYSTEM account. I was able to jump through hoops and do this remotely by using the windows/exec payload via psexec, then reverse_http(s) would work.

But I wanted a better way to do this. I watched the execution of bitsadmin to see what it was doing and all it was actually doing is setting a registry key. Awesome, I can do that.

Enter enum_proxy:

And...

If you've noticed that RHOST option, Metasploit has the ability to do remote registry calls as well (this module will attempt to start the RemoteRegistry service if the user has the privilege to do so):

Output from it finding a disabled RemoteRegistry:

msf post(enum_proxy) > run

[-] Unable to contact remote registry service on 172.16.10.217
[*] Attempting to start service remotely...
[*] Proxy Counter = 9
[*] Setting: WPAD and AutoConfigure script
[*] AutoConfigURL: http://anotherproxyserver/pac.pac
[*] Post module execution completed

"Awesome but you promised setting the proxy settings", well right now all I can give you is a cloner ;-)

Enter clone_proxy_settings module:

And thats it. Still working on an actual "set_proxy" module, but this should do for now, and a lot less to type.

As of this post both are currently pull requests:

https://github.com/rapid7/metasploit-framework/pull/942

https://github.com/rapid7/metasploit-framework/pull/943