Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Burp v1.7.24+ NTLM Issues

Jared | Last updated: Aug 08, 2017 01:53PM UTC

A large number of our app testing consultants at SecureWorks have noted that NTLM authentication stopped working once we upgraded past Burp v1.7.23. We have had to downgrade versions to get things working smoothly with NTLM, and I wanted to be sure to let you know that something in this functionality isn't working...Unfortunately I don't have much for details beyond that, but would be happy to run a packet trace and try to narrow it down if a diff of the code doesn't reveal the issue on your end. Please feel free to reach out for any questions if needed. Thanks! -Jared

PortSwigger Agent | Last updated: Aug 08, 2017 01:57PM UTC

There was an NTLM issue in 1.7.24 and 1.7.25. We believe this is fixed in 1.7.26. If you're still having issues with 1.7.26, please let us know - with as much additional information as you can.

Burp User | Last updated: Nov 07, 2017 09:42PM UTC

NTLM auth still fails to work correctly in burpsuite_pro_v1.7.27. Tested this on multiple operating systems including Linux, Mac OS, and Windows. This bug should be addressed as many enterprise apps use this type of auth.

PortSwigger Agent | Last updated: Nov 08, 2017 09:00AM UTC

Hi Anonymous, Can you provide some more detail about your configuration, including a screenshot of User options > Connections > Platform Authentication. What exactly is failing to work? The server refusing to accept your credentials? If you have access to the server logs, please check them for any clues. Many Burp users are successfully using NTLM authentication. Hopefully we can fix your issue by refining your configuration. Please let us know if you need any further assistance.

Burp User | Last updated: Nov 08, 2017 03:32PM UTC

In burpsuite_pro_v1.7.23, the following options are specified for platform auth for the target site: Destination host, type (NTLMv2), username, password, domain. It is possible to view and audit the site with this version of burp as a proxy and configuration. However, in the Burp alerts tab, the warning "No NTLM challenge received from ..." is periodically displayed while navigating the site with the proxy. This warning is strange, as the initial auth prompt from the site is for NTLM. Despite the warning, this version works. In burpsuite_pro_v1.7.27, the same configuration options are used for platform authentication for the same site. The site fails to render correctly in the browser (it shows a blank page instead). However, viewing the source in the browser for the page or issuing the request in Burp Repeater shows that page behind auth did load, but it is not being correctly rendered in the browser while using burp as a proxy for this version of Burp.

PortSwigger Agent | Last updated: Nov 08, 2017 03:37PM UTC

Hi, Thanks for the detailed description. It sounds like Burp can successfully perform NTLM authentication in at least some cases. Perhaps your page is blank because a key subresource has failed to load. Can you try accessing the site in Chrome with developer tools enabled? Using the network tab might pin down which load is failing. What server software is the application using? This is helpful to know so we can attempt a similar setup ourselves. The "No NTLM challenge received" warning can usually be safely ignored. Burp raises it if NTLM authentication is configured, but the server doesn't request it. This quite often happens if the application only needs NTLM authentication for some paths. Please let us know if you need any further assistance.

Burp User | Last updated: Oct 23, 2018 02:18PM UTC

Sorry to reply to an old thread but I was just looking at an application with a similar problem, where using Burp with NTLM platform authentication enabled caused a blank page to be shown in the browser, even though the HTML had been sent. I looked a bit deeper and it seems that a JavaScript file was failing to load. Disabling NTLM auth, re-requesting the page, then re-enabling NTLM auth allowed me to use the site as normal. I compared the responses and it looked like, when the page was blank, a 'Transfer-Encoding: chunked' header was being added to the JavaScript response. This makes no sense to me, and it's not clear whether it is a server issue (I don't have access to the server), or an issue within Burp itself. I found another help post which suggested that burp always removes 'Transfer-Encoding' headers, so perhaps this is failing sometimes with NTLM auth? I managed to workaround it by adding a match and replace rule to remove the header from all responses but I thought I'd point it out anyway in case a fix can be found or if someone else has the same problem. I was using Burp 1.7.37 if that helps.

Rose, PortSwigger Agent | Last updated: Oct 23, 2018 02:28PM UTC

Dhruvesh, do you have an upstream proxy configured in Burp that requires NTLM authentication?

Burp User | Last updated: Jul 25, 2019 03:02PM UTC