How Cyberseer Detect Burp Suite
using Darktrace

Burp Suite is a graphical tool for testing Web application security and vulnerabilities that can be used for penetration testing. It’s a framework which allows an adversary not only to carry out reconnaissance but also gives them the ability to intercept and manipulate traffic from a victim, meaning it can be used for a Man-in-The-Middle (MiTM) style of attack.

It comes with a heap of built-in functions and is included in the Kali Operating System. It should also be noted that not all usage of Burp Suite is a bad thing, for example, it can be legitimately used by web developers in order to test the robustness of web applications. This article covers how Cyberseer implements models to detect the potential use of this framework on the network.

Testing Burp Suite

The usage of Burp Suite can leave some key indicators of compromise (IOCs) within the network traffic. In the following scenario, we’re going to take a look and see what happens when the intercept function is used against a victim’s computer. This is a common use case for Burp Suite as it offers the attacker the ability to view, edit and choose which web requests are forwarded to the destination.

It’s possible to demonstrate its power by showing what happens when we use the intercept function on a sample login page over HTTP. In this example, the victim’s PC is configured to use our machine as a proxy server, so when the victim attempts to authenticate their credentials are passed through in headers ‘user’ and ‘pwd’ and we can see this in the clear. 

The introduction of HTTPS makes it a little harder, in the example above a warning was displayed on the victim’s PC similar to below. This would have required them to click through to proceed past the warning.

The introduction of HTTP Strict Transport Security (HSTS) will cause this method of intercepting traffic over HTTPS to fail. HSTS allows websites to force HTTPS connections and also dictates none of the traffic ever be sent in clear text.

When modern browsers detect a self-signed certificate on a website that uses HSTS they will close the connection because it is deemed to be insecure and can be a sign that a MiTM attack is occurring. It is a common misconception that all HTTPS sites are secure, however, the major players such as Google, Facebook etc will all enforce HSTS. Read more about HSTS here

Identifying Burp Suite in a network traffic flow:

When we analyse relevant network traffic, we can see the following Burp Suite related IOCs.

Proxy headers
Burp Suite on our attacker’s machine is acting as a proxy server which means when the victim makes an HTTP connection a proxy request is placed in the HTTP headers:

1556870587.8471 CiolERuBKC2hvIx00 172.17.255.11 58776 192.168.110.101 8080 — — spclient.wg.spotify.com 1 [PROXY-CONNECTION -> keep-alive] spclient.wg.spotify.com:443 0 [HOST,PROXY-CONNECTION,USER-AGENT] Spotify/1.1.0 OSX/OS X 10.14.2 [x86 8] 1.0 Connection established CONNECT 200 0

In this scenario the device does not usually connect through a proxy server meaning this is abnormal activity; this can be verified by looking at the historical logs for the device.

Using the included proxy destination (192.168.110.101) it is possible to verify if this is normal behaviour for the environment by seeing what other devices connect to this device on the proxy port (8080). This can be achieved using the Advanced Search function in Darktrace with the following query:

@fields.dest_ip:192.168.110.101 AND @fields.dest_port:8080

A ‘scoring’ of the source IP addresses connecting to this device around this timeframe shows us which device connected the most. While there was a connection from another device the percentage figure shows us that this device makes up the majority of the connections.

Using this information we’re able to further refine the search, limiting it to that source IP address we are presented with the following graph:

The graph above is set to show the week’s view and the spike shows us that these types of connections are not normal for the device - so we need to dig deeper into why this is occurring.

Attempts to proxy HTTPS

We mentioned earlier about Burp Suite using self-signed certificates, we can see that as well. Burp Suite is developed by PortSwigger, so looking for the default certificate included in Burp Suite we can see the following:

03/05 08:03:06x5091556870586.5859 CJF1f24MkvKZd9pp00 172.17.255.11 58775 192.168.110.101 8080 — — 1163420158 1794140158 FATGIu3olCPvv4Ss00 emailAddress=mail@portswigger.net,CN=PortSwigger,OU=PortSwigger,O=PortSwigger,L=London,ST=London,C=GB rsa sha1WithRSAEncryption 1024 rsaEncryption emailAddress=mail@portswigger.net,CN=PortSwigger,OU=PortSwigger,O=PortSwigger,L=London,ST=London,C=GB 65537 3 00 true

Furthermore, we can also see the untrusted certificate warning that is presented back to the client:

03/05 07:59:27notice1556870367.3719 CN71ua4450TyTbhG00 172.17.255.11 58356 192.168.110.101 8080 tcp — SSL::Invalid_Server_Cert dt-534–01–172.31.10.3 192.168.110.101 SSL certificate validation failed with (self signed certificate) 172.17.255.11 emailAddress=mail@portswigger.net,CN=PortSwigger,OU=PortSwigger,O=PortSwigger,L=London,ST=London,C=GB 8080 950

As Burp Suite is also acting as a proxy server for HTTPS, we can see that Darktrace has identified that the attacker’s machine is now acting as a server:

03/05 07:59:31notice1556870371.5329 CWqx9SspmubsLeP00 172.17.255.11 58354 192.168.110.101 8080 tcp — ProtocolDetector::Server_Found dt-534–01–172.31.10.3 192.168.110.101 192.168.110.101: SSL server on port 8080/tcp 192.168.110.101 SSL 8080 950

From an analyst’s perspective, this would immediately raise suspicions as to why a device has started serving other devices.

Unusual events

The Darktrace technology is constantly assessing device traffic to determine if a device is acting outside of its normal pattern of behaviour. All of the IOCs above clearly show that this device is deviating from its typical network behaviour.

Machine learning-based anomaly analytics interprets this, tracks it and incorporates it into a mathematic model. When we look at the relevant timeframe in the device’s graph, the system identified the above as unusual activity for this device as it was observed making a large volume of connections over a short period:

And the solution?

Cyberseer’s Forensic Analysts build custom models to detect this type of activity and push them out across our customer base. Analysts can combine factual and unusual components into models. The unusualness of a connection is determined through the machine learning process.

Darktrace constantly assesses connections to determine if the activity is anomalous for the device and devices similar to it. This is made available to an analyst in the form of a score for how unusual the connection is. In our initial investigation steps, we used 2 queries to determine what was normal behaviour for the device.

We could have also achieved the same results, in a single step if we looked for the unusualness score. This reduces the amount of manual triage required; it means the model can filter out normal connections (ie, a lower score of unusualness) which reduces the possibility for false positive breaches where the connections are legitimate.

For the example used in the post, Cyberseer analysts built a model with the following components:

• Anomalous Connections over a strength of 50%.
• Common Proxy Ports (3128, 8080, 8443).
• PortSwigger Signed Certificates.
• When a destination is first observed with “PROXY-CONNECTION” in the packet header.
• The first time “ProtocolDetector::Server_Found” is observed.

With this combination, Cyberseer were able to re-test using a different device and Darktrace placed a high-priority model at the top of the threat tray.

Given the nature of Burp Suite and that it has very few reasons to be legitimately used in an organisation, analysts can quickly report the activity to the customer so that they can investigate the source of the activity and understand why Burp Suite is being used within the environment.