Cyber Pickpocketing

Drink!!

So I've been working on a training package that takes a bit of a different approach than what I've normally done. The training breaks down like this:

• Day 1: Local LAN based exploit (Windows)
• Day 2: Remote Web based exploit (Linux)
• Day 3: Client side exploit (Windows)
• Day 4: Local exploit (FreeBSD)
• Day 5: Network of the Seven Bells Test

Each day (save for the 5th) will focus on a single exploit, explaining it, running it on virtual machines, and spending 8 hours diving into as many detectable changes that exploit makes on a system.. and how to not make them or make them vanish.

Day 5 will be a lot like a CTF where you know all the answers. First one to get all 7 exploits completed without being detected wins.

Venue is TBD but I've been putting a lot of time into making the VMs and slides and stuff just needed to get some feedback on what you guys think.

Let me know in the comments (something more valuable then, "great idea!" or , "thats stupid" please)

Delete TrustedInstaller-only Files and Folders

Not very security related, but something I don't want to forget how to do. It was a PITA. So I had a old WINDOWS directory that I needed to get rid of. And the following commands gave me the ooomph needed to get the job done.

1) Get a SYSTEM shell so all modding of permissions will be good.

D:\> psexec /accepteula -s cmd

2) Grant Administrators FULL rights to the directory and all sub directories and files

D:\> icacls D:\Windows\* /grant Administrators:F /C /T

3) Finish the job, delete the folder and everything below it

D:\> rmdir /s /q D:\Windows\

All done. Weeeeeeeee!

If you have a better way to do this via commands or programs please let me know, always looking to learn more.

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..

Smash and Grab: Windows Dir Lists

Looking through network shares can be slow, and waiting for individual searches to finish looking through the whole “drive” is redundant. Easier to just use some Windows voodoo to get a good list to look through offline:

start /b cmd /c dir /b /s \\doesnotexist\supersecretshare$ ^> shareinfo.txt

Breaking that down:

start /b – starts a process that won’t hang up our current one, with the “b” flag meaning “background”, yay not visible to the user! (unless your process forces it back)

cmd /c – no reason to explain this one it runs something.. (since dir isn’t an executable but something that resides inside of cmd this is needed)

dir /b /s – the “s” means sub directories and pretty widely known. The one that isn’t as well known is the “b” which means “bare” format. Also known as “puts-path-on-every-line-to-make-it-easy-to-find-and-grep-stuff” mode.

The path is arbitrary, if you didn’t know you could dir list a UNC path, now ya do.

The ^> is the cool trick. If you use “start” to create a process in the background, re-routing its output to a file instead of just getting the fact that start began (the only thing start outputs), is made possible by this lowly ‘carrot’ before the greater-than.

And that's it. With big drives, come back in an hour or two and you’ll have a perfectly grep-able file waiting for you to grep through for file names and extensions to your heart’s content.

One caveat, don’t freak out if it’s been 30 minutes and the file size is still ZERO. It doesn’t write the output until the end, it write buffered in the process and then “start” pulls it back out at the end with the carrot.

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.