nccgroup/berserkoBurp Suite extension to perform Kerberos authentication
Released as open source by NCC Group Plc - http://www.nccgroup.trust/
Developed by Richard Turnbull, richard [dot] turnbull [at] nccgroup [dot] com
http://www.github.com/nccgroup/Berserko
Released under AGPL, see LICENSE for more information
Further development of Berserko will take place at https://github.com/rteatea/Berserko
Berserko is a Burp extension to add support for performing Kerberos authentication. This is useful for testing in a Windows domain when NTLM authentication is not supported (Burp already handles NTLM). Berserko does not require that the machine running Burp be domain-joined (or even that it is running Windows).
The only existing solution that we are currently aware of for testing Kerberos applications using Burp is to chain through Fiddler, with authentication set up according to these instructions. But Fiddler is Windows-only, and chaining proxies adds complexity and hinders performance, so it's nice to have Kerberos capability within Burp itself.
Get the latest Berserko jar file from the Releases tab, or from the berserko\releases folder
Go to the Extender tab in Burp, select Add, make sure Java is selected as the Extension type, and then point it at the jar file. All being well, the Berserko tab should be added to the Burp UI.
There are various controls on the Berserko tab in Burp.
The Do Kerberos authentication checkbox is a master switch. Until it is enabled, Berserko won't do anything at all.
The Restore defaults button will return Berserko to the default configuration (in which no domain details or user credentials are present).
The Clear Kerberos state button will clear out all Kerberos tickets and other state on the client. The only reason you might need to use this would be if changes had been made to the Kerberos configuration on the server side and you wanted to start from a fresh state.
The Write tickets to log button will write information about your current Kerberos tickets to Berserko's log stream - this can be useful for debugging/troubleshooting. To see the logs go to Burp's Extender tab, select Berserko and look at the Output tab below. It might make sense to use the Save to file option here, because the ticket data can easily fill the log buffer in the GUI.
Some controls have a help button that will pop up more information.
Specify the Domain DNS Name and the KDC Host using the controls in this section. The textboxes can't be edited directly; you have to use the 'Change' button to modify them.
The Domain DNS Name should be the DNS name of the domain you wish to authenticate against (to be precise, this is actually the Kerberos realm). This should be something like mydomain.acme.local. It should not be the NETBIOS name of the domain (which would be something like MYDOMAIN).
The KDC Host should be the hostname (or IP address) of a Kerberos KDC (Key Distribution Center). In a Windows domain, a KDC is simply a domain controller.
Having supplied the Domain DNS Name, you can use the Auto button to try to automatically locate a KDC. It does this by sending a DNS SRV query for the Kerberos service. If one of your DNS servers is a domain controller for the correct domain, this should work. If not, it won't. ❗This functionality won't work in recent versions of Burp, as the required DNS libraries are not being shipped as part of the bundled JRE. You can get round this by launching under a full JRE as described at the top of this README.❗
When the Domain DNS Name and KDC Host have been entered, use the Test domain settings button to test connectivity. All being well, you will get a Successfully contacted Kerberos service response.
See this file for lots more information about obtaining the correct values for these Domain Settings.
Specify the Username and Password for a domain account using the controls in this section. The textboxes can't be edited directly; you have to use the 'Change' button to modify them.
The Username should just be the plain username. This should be something like bob. It should not be MYDOMAIN\bob or [email protected] or similar.
Having supplied the credentials, you can use the Test credentials button. This will attempt to acquire a Kerberos ticket-granting ticket for the specified user. If successful, you will get a TGT successfully acquired response. If not successful, note that this is a domain authentication attempt, so be careful not to lock out your account.
The password will not be saved in the Berserko config for next time unless the Save password in Burp config? checkbox is ticked. All other settings will be saved though.
Some applications use Kerberos delegation on the server side to forward the client's identity to other servers (but there isn't an easy way to determine from the client side if this is in use).
Berserko does support this, but there is a catch. Delegation only works if the user has a forwardable TGT (ticket-granting ticket). The Java implementation of Kerberos sadly doesn't provide a way to programmatically specify that a forwardable ticket should be acquired. This can only be done by adding an appropriate entry to the krb5.conf configuration file.
So, for delegation to work, Berserko has to be pointed at a suitable krb5.conf file, and there are two possible approaches here.
The easiest thing to do, and the recommended approach is to use the Create krb5.conf file button. This will create a suitable file for you at a location of your choice. You can put it in a temporary directory, or your project directory, or wherever. But the same file can be reused indefinitely, so it might make sense to put it somewhere more permanent. The Change button lets you select a different file to be used.
If you're interested, the krb5.conf file which is created is very simple, and will have the following contents:
