由 NCC Group Plc 以开源形式发布 - http://www.nccgroup.trust/
由 Richard Turnbull 开发，richard [dot] turnbull [at] nccgroup [dot] com
http://www.github.com/nccgroup/Berserko
根据 AGPL 发布，更多信息请参阅 LICENSE。
Berserko 的后续开发将在 https://github.com/rteatea/Berserko 进行。
Berserko 是一个 Burp 扩展，用于增加对 Kerberos 认证的支持。当 NTLM 认证不受支持时（Burp 已能处理 NTLM），这对于在 Windows 域中进行测试非常有用。Berserko 不要求运行 Burp 的机器加入域（甚至不要求它运行 Windows）。
目前我们所知的唯一能通过 Burp 测试 Kerberos 应用程序的现有方案是经由 Fiddler 进行代理链，并按照 这些说明 配置认证。但 Fiddler 仅支持 Windows，而且链路代理会增加复杂性并降低性能，因此能在 Burp 内部直接具备 Kerberos 能力是很好的。
从 Releases 标签页或 berserko\releases 文件夹获取最新的 Berserko jar 文件
转到 Burp 中的 Extender 标签页，选择 Add，确保 Extension type 选择的是 Java，然后指向该 jar 文件。一切顺利的话，Berserko 标签页应会添加到 Burp 界面中。
Burp 的 Berserko 标签页上有多种控件。
Do Kerberos authentication 复选框是一个总开关。在启用之前，Berserko 不会做任何事。
Restore defaults 按钮会将 Berserko 恢复为默认配置（即不包含任何域详细信息或用户凭据）。
Clear Kerberos state 按钮会清除客户端上的所有 Kerberos 票据和其他状态。你可能需要用到此功能的唯一原因是：服务端的 Kerberos 配置发生了变化，而你想从一个全新的状态开始。
Write tickets to log 按钮会将你当前 Kerberos 票据的信息写入 Berserko 的日志流——这对调试/故障排查很有用。要查看日志，请转到 Burp 的 Extender 标签页，选择 Berserko，然后查看下方的 Output 标签页。此处使用 Save to file 选项可能更合理，因为票据数据很容易填满 GUI 中的日志缓冲区。
某些控件带有帮助按钮，点击后会弹出更多信息。
使用本节中的控件指定 Domain DNS Name 和 KDC Host。这些文本框无法直接编辑；你必须使用 'Change' 按钮来修改它们。
Domain DNS Name 应为你希望进行认证的域的 DNS 名称（准确地说，这实际上是 Kerberos realm）。它的格式应类似于 mydomain.acme.local，而不应是域的 NETBIOS 名称（例如 MYDOMAIN）。
KDC Host 应为 Kerberos KDC（Key Distribution Center，密钥分发中心）的主机名（或 IP 地址）。在 Windows 域中，KDC 就是域控制器。
提供 Domain DNS Name 后，你可以使用 Auto 按钮尝试自动定位 KDC。它会通过向 Kerberos 服务发送 DNS SRV 查询来实现这一点。如果你的某个 DNS 服务器是正确域的域控制器，这应该能成功；否则不会。❗在较新版本的 Burp 中，此功能无法使用，因为所需的 DNS 库并未随附带的 JRE 一起提供。你可以按照本 README 顶部所述，在完整的 JRE 下启动来解决此问题。❗
输入 Domain DNS Name 和 KDC Host 后，使用 Test domain settings 按钮测试连接。一切顺利的话，你会得到 Successfully contacted Kerberos service 响应。
有关如何获取这些域设置正确值的更多信息，请参阅 此文件。
使用本节中的控件指定域帐户的 Username 和 Password。这些文本框无法直接编辑；你必须使用 'Change' 按钮来修改它们。
Username 应为纯用户名，例如 bob。不应是 MYDOMAIN\bob 或 [email protected] 或类似格式。
提供凭据后，你可以使用 Test credentials 按钮。它将尝试为指定用户获取 Kerberos 票证授予票证（TGT）。如果成功，你会得到 TGT successfully acquired 响应。如果不成功，请注意这是一次域身份验证尝试，因此要小心不要导致帐户被锁定。
除非勾选 Save password in Burp config? 复选框，否则密码不会保存到 Berserko 配置中以备下次使用。不过其他所有设置都会被保存。
有些应用程序会在服务端使用 Kerberos 委派，将客户端身份转发到其他服务器（但从客户端很难判断是否使用了此功能）。
Berserko 确实支持这一点，但有一个问题。委派仅在用户拥有 forwardable（可转发）TGT（票证授予票证）时才有效。遗憾的是，Kerberos 的 Java 实现没有提供以编程方式指定应获取可转发票据的方法。这只能通过在 krb5.conf 配置文件中添加相应的条目来实现。
因此，要让委派生效，必须让 Berserko 指向合适的 krb5.conf 文件。这里有两种可行的方法。
最简单也推荐的方法是使用 Create krb5.conf file 按钮。这会在你选择的位置为你创建一个合适的文件。你可以把它放在临时目录、项目目录或任何地方。但同一个文件可以无限期重复使用，因此把它放在更持久的位置可能更合适。Change 按钮允许你选择使用不同的文件。
如果你感兴趣的话，被创建的 krb5.conf 文件非常简单，内容如下：
[libdefaults]
forwardable = true
或者，你可以使用 Change 按钮指向系统上现有的 krb5.conf 文件。你之所以想这样做，唯一原因可能是该文件中还有其他重要的 Kerberos 设置，你希望 Berserko 能读取到（理论上应该可以正常工作，但尚未在实践中测试过）。请注意，此文件在 Linux 上的默认位置是 /etc/krb5.conf——其他操作系统则不太可能有此文件。如果你要指向现有的 krb5.conf 文件，请确保编辑它以启用转发——在 [libdefaults] 部分添加 forwardable = true（或为每个 realm 单独添加）。但要小心。让 Berserko 为你创建文件在 99% 的情况下是更好的选择。
如果你想知道委派配置是否成功，请使用 Check current config 按钮。它会告知 krb5.conf 文件是否已定位，以及 forwardable 设置是否正确。还要注意，当你使用 Test credentials 按钮时，Berserko 会告诉你是否成功获取了可转发的 TGT。
最好确保在开始使用某个应用程序之前拥有可转发的票据。IIS 似乎会在服务端以某种方式缓存用户的认证状态，导致从不可转发票据切换到可转发票据无法生效。
本节中的设置控制 Berserko 是“被动地”尝试 Kerberos 认证（即等待服务器返回 401 响应，然后在请求中添加 Kerberos 认证头后重新发送），还是“主动地”尝试（即在发出请求时添加 Kerberos 认证头）。
主动认证的优势是只需要一次 HTTP 往返，而被动认证需要两次。主动认证的缺点是 Kerberos 认证头可能会被发送到并不期望收到它们的主机。此外，在使用被动策略时，Berserko 能更好地诊断认证错误。
Proactive Kerberos authentication, only after initial 401 received 选项是这两种方法的混合体：Berserko 会对某个主机的第一个请求进行被动认证，但之后则采用主动方式。
在本节中，你可以定义哪些主机被认为处于 Kerberos 认证的作用范围内。
默认情况下，All hosts in this Kerberos domain in scope for Kerberos 复选框会被勾选。这意味着 Berserko 只会对主机名以域 DNS 名称结尾的 Web 服务器尝试 Kerberos 认证。在许多情况下，这已经足够了。不过，也有可能存在启用了 Kerberos 的 Web 应用程序，其主机名并不采用这种形式（前提是管理员已设置合适的服务主体名称）。为了考虑到这种情况，你可以使用右侧的列表框将“其他”主机添加到作用范围内。请注意，可以使用通配符（* 匹配零个或多个字符，? 匹配除点号外的任意单个字符）。
或者，你也可以勾选 All hosts in scope for Kerberos authentication 复选框。显然，这样做的好处是你无需手动指定作用范围。此配置的潜在缺点在于，它可能导致 Berserko 向 KDC 发送 Kerberos 请求，以获取不在域中的主机的服务票据。这可能会引起性能问题，也可能会引发隐私问题（如果你不希望这些信息泄露给 KDC）。在使用 Proactive Kerberos authentication 策略时，这可能尤其成问题，因为 Berserko 会尝试为经过 Burp 的每个请求添加 Kerberos 认证头。不建议将这两种选项组合使用；如果选择了这种组合，Berserko 会发出警告（但不会真正阻止）。
如果既未选择 All hosts in this Kerberos domain in scope for Kerberos，也未选择 All hosts in scope for Kerberos authentication，则作用范围内只有添加到列表框中的主机。
如果选择了 Plain hostnames considered part of domain 选项，则意味着“纯主机名”（即仅由单个组件组成的主机名）将被视为域的一部分（因此如果选择了 All hosts in this Kerberos domain in scope for Kerberos，它们会自动处于作用范围内）。你可能想要禁用此选项的主要原因是：你的机器加入的域与使用 Berserko 进行认证的域不同（在这种情况下，纯主机名很可能指的是你所加入域中的主机）。
如果选择了 Do not perform Kerberos authentication to servers which support NTLM 选项，则将指示 Berserko 不要对除 Kerberos 外还支持 NTLM 的主机（即同时返回 WWW-Authenticate: NTLM 和 WWW-Authenticate: Negotiate 头的主机）尝试 Kerberos 认证。
可以在此处将 Alert Level 和 Logging Level 配置为 NONE、NORMAL 或 VERBOSE。
Alert Level 控制发送到 Burp 的 Alerts 标签页的信息量。
Logging Level 控制发送到 Berserko 标准输出的信息量（可在 Extender 标签页上查看）。请注意，将 Logging Level 提高到 VERBOSE 会提供更多关于可能发生的错误或异常的信息。
如果你的环境中使用了 Kerberos 域信任，可以在此处找到一些指导。
默认情况下，Berserko 通过 UDP（端口 88）与 KDC 进行所有 Kerberos 交互。如果你想改用 TCP，也是可以的。最常见的原因可能是使用了针对 TCP 端口 88 的 SSH 端口转发。只需在 krb5.conf 文件中添加 udp_preference_limit = 1，使其如下所示：
[libdefaults]
forwardable = true
udp_preference_limit = 1
可以通过在 krb5.conf 文件中加入 [berserko_spn_hints] 部分（见上文），为特定主机配置要使用的 SPN。语法如下所示。
[berserko_spn_hints]
[email protected]
server2.bar.org=app.domain2.local
等号左侧是目标服务器，右侧是要使用的 SPN。SPN 的 realm 可以按需指定（如果不指定，Berserko 会照常尝试确定正确的 realm）。这里不要包含 SPN 的 HTTP/ 部分。
Berserko 不兼容 v2020.5.1 之前的 Burp v2。 对 Burp v1 没有问题。
这是因为早期 Burp 2 版本附带的 OpenJDK 版本未包含 Berserko 所使用的部分 Kerberos 功能。尝试使用 Berserko 时，这会导致 java.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSContext 错误。
显而易见的解决方法是升级到 v2020.5.1 或更高版本。另外，如果你使用完整版本的 Java 运行时环境（即不是 Burp 自带的那一个）启动，Berserko 应该可以配合任何 Burp v2 版本使用。
假设你的 PATH 中有 java：
java -jar burpsuite_pro.jar
请参阅 Burp 关于从命令行启动的文档。