I've been using some of those tricks on websec.fr for a long time now, but it seems that there haven't really been documented publicly, and since I've discussed a couple of them during Agarri's amazing Burp training last week, there is no point in keeping them super duper secret anymore. Most of them all likely already deployed on your favourite darknet market anyway.

Detecting Burp users

Detecting the web interface

Burp will by default open a web interface on its proxy listening address, so requesting http://localhost:8080/favicon.ico and checking that it has a675f036bd20cd86921fad84c29a8d04 as md5 indicates that Burp is used, with its default settings.

You can also try to resolve http://burp.

Detecting the TLS man-in-the-middle

Since someone was crazy enough to implement TLS in pure javascript, trying to establish a TLS session in the browser to your website by using raw sockets and checking that the Issuer is PortSwigger instead of your usual provider will give the MitM away.

One can also give at try at Clouflares mitmengine as well.

TLS ciphers support

Java doesn't play nice with modern TLS settings: if you try to browse dustri.org with Burp, you'll get Received fatal alert: no_application_protocol.

JA3

Salesforce is doing some interesting work around TLS fingerprinting, like JARM and JA3. Burp usually has a JA3 of 53d67b2a806147a7d1d5df74b54dd049.

Infinitely chunked responses

This isn't really Burp-specific, but having a /admin webpage sending an infinite amount of chunks will keep Burp busy, since it doesn't have a timeout, and tries by default to wait until everything is received before processing it. By default, web browsers are not waiting for the end of the request, so you can implement a redirection in javascript, they'll follow it, while Burp won't.

Detecting the Burp browser extension recording

Burp is shipping with its own web browser, and allows to record complex flows in it via an extensions, that can be detected by enumerating the EventListener since it's adding some for contextmenu, paste, keydown, click, scroll, …

Brotli compression

Burp Pro doesn't support Brotli, while every modern browser does, so just always serve content compressed with it even if the browser doesn't advertise to support it.

Edit: support for brotli was added in Burp 2023.10.

Or, if you want to be more sneaky, check if the client is using a modern user-agent, without advertising br in its Accept-Encoding header.

User-agent of the embedded browser

The web browser embedded by Burp is Chromium, with the current user-agent as of today: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36, but it doesn't spoof the navigator.platform, leading to a detectable disparity if the user isn't running on Windows.

If the user is running on Windows, SEC-CH-UA: "Chromium";v="89", ";Not A Brand";v="99" will give Burp away, since nobody is running Chromium instead of Google Chrome on this platform.

Hackvector

Add some hackvector tags in your webpage, and check if they were processed.

Breaking stuff in Burp

Breaking the crawler

Internally, the crawler uses CSV, as in "cheese separated values", which is like "Comma separated values", but with 🧀 instead of a ,.

Launching the crawler on a page with the following content will result in 2.html being added to the sitemap, as well as something like 🧀.html, instead of 2.html and %F0%9F%A7%80.html:

<a href="🧀">one</a>
<a href="2.html">

Confusing Burp's active scan

This is quite lame, but you can randomly:

• delay the answer of your web server for 20 seconds to confuse the SQLI scanner.
• query every .burpcollaborator.net url that you see in your logs, via tor/proxies, with a random delay, random content and with random repetitions. You can also blackhole the resolution of those urls on your servers a the DNS level.
• reply to dirbuster-like requests (in resources/PayloadStrings/). Bonus if you're not only throwing 200, but also real-looking content.
• add the scanner's expected result into a comment in web pages. You can find them by spending a bit of time reversing Burp's slightly obfuscated .jar file. For example:
  • Parts of /etc/passwd/win.ini/boot.ini/WEB-INF/(meta|web).xml//etc/hosts/… for LFI
  • 5929 to template injections
  • 111111 for shell injections
  • Parts of the output of id for template/shell injection
  • alert("XSS") for, well, XSS
• ask shodan.io for all the Burp Collaborators on the internet and drop them server-side.

Breaking the decoding

I wrote about this in 2018, and it's still unfixed.

Breaking the Intruder

Since Burp's Intruder uses § as marker for data to replace, we can use this to detect tampering. Even better, since it seems that there is a bug in Burp making it replace § with Â (aka chr(0xc2)), we can precisely detect if the tampering is due to Burp or not:

<?php
if (isset($_POST['x'])) {                                                        
  if ($_POST['x'] !== '§') {                                                     
    if ($_POST['x'] == chr(0xc2))                                                
      echo "Burp detected";                                                         
    else                                                                         
      echo "Tampering detected";                                                         
  }                                                                              
} else {                                                                         
  echo '<form method="post" enctype="text/plain"><input name="x" value="§"></form>';
} 

This means that the Intruder is unable to sent the §, so feel free to add this character to madatory signed blobs everywhere. It might be possible to use the grep extractors to extract and correctly insert § characters to bypass this.