Detecting Burp Suite – Part 2 of 3: Callback Exposure


This is part two of a three part series on detecting traffic generated by the security tool Burp Suite. These methods are by no means exhaustive, but are simple tricks that can be used for detecting some of the malicious traffic on your web server.

The first article dealt with information leaked by Burp Suite whenever traffic is replayed in the browser. You can read more on that here: This article is going to deal with a callback that can be used to expose Burp setup with default settings.

Callback Exposure

As discussed in part 1, you are running a local web service whenever you are running Burp. This web service by default is running on port 8080, but that can be changed. However, it’s always running on the intranet DNS name burp (i.e. http://burp/).

After going through the requests and files that are running on the web server, I came across proxy.pac. This is a JavaScript file that has a function defined in it: http://burp/proxy.pac

Because this JS file is in a static location, we can include this on any page that we want. This is similar to how someone would define a callback to steal information from an external website. Without having any sort of protection, you can force a browser to include the file as JavaScript.

I wasn’t sure if Burp would actually parse out the JavaScript and I wanted to make sure that it would catch spider traffic. I created two files to test this:


<a href="burp2.html"></a>


<title>Burp Callback Detection</title>
<script src="http://burp/proxy.pac"></script>


<div id="container"></div>


// A function defined within proxy.pac
var burpDetected = FindProxyForURL("", "")

// Check if we detected the function or not
if(burpDetected) {
    // Log to the browser that we've detected Burp
    console.log("Burp Suite detected: " + burpDetected);
    // Create a new image and append it to the document
    var img = new Image(1,1);
    img.src = "http://[website]/log.php?c=burp+detected";


*Just as a note, it’s not really safe to include the JavaScript file and call the function directly. You do get the benefit of seeing the return to ensure that it is indeed Burp Suite, but it’s risky.

After telling Burp to target burp1.html, it loaded burp2.html and parsed out the JavaScript creating the image. This pinged log.php, letting my server know that the function exists and that the traffic from this user is most likely being generated by Burp.

Practical Usage

As stated at the end of part 1, this is not complete detection and there may be easier ways to detect Burp traffic. I would say this method is a pretty good way to catch a vast majority of people scanning your website using Burp. It may not be smart to outright block people based on whether or not a function exists in the browser’s memory, but it could be used to flag the traffic as potentially malicious.

Part 2 of 3

This is part two of a three part series:

  • Part 1: Info Leak
  • Part 2: Callback Exposure
  • Part 3: Traffic Heuristics and Honeypots