Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Introducing Burplay, A Burp Extension for Detecting Privilege Escalations

The seventh entry on the most recent OWASP Top 10 release (from 2013, due to the 2017 release candidate being rejected!) is "Missing Function Level Access Control", which is essentially what leads to Privilege Escalation issues. This common vulnerability related to the question: "Am I Vulnerable to Forced Access?" in the following way:

"The best way to find out if an application has failed to properly restrict function level access is to verify every application function […]".

The word "every" is indeed originally in bold and there is a good reason behind it. Very often, applications implement function-level access control for most, but not every, application function. This can be especially true of larger applications that might still rely on legacy code to perform certain functions. Testing all possible cases during a web application penetration test is often quite time-consuming, can easily become overwhelming and of course be subject to human error.

In this blog post I would like to introduce a tool, which I have discovered to be extremely helpful in identifying privilege escalation issues.

Let's start with the basics. If you are reading this blog post there is a good chance you already know about vertical and horizontal privilege escalation, which is effectively a lapse in user separation. However, for the sake of completeness, let me quickly explain what they are.

Vertical Privilege Escalation

Vertical privilege escalation is a kind of flaw that allows a lower privileged user to access and/or modify data which should only be accessible to higher privileged users.

It often happens that the application UI presents different options to different user roles, but the application does not enforce authorisation at the server side on the application function level. For instance, a regular user does not see the UI element pointing to "http://app/admin/user_list" URL, however, when they type this URL directly into the browser's address bar or use other tools to send such a request, the application erroneously responds with unauthorised content.

Horizontal Privilege Escalation

Horizontal privilege escalation is a similar issue. Instead of two user roles there are two users with the same role and permissions. When this issue is present, users can cross-access private data of other users with the same level of permissions. Similar to vertical escalation, it may happen that "User1" (from "Company A") is presented with a list of documents, which should only be available to users of "Company A". That list is available at http://app/documents/list?companyId=A URL and each element on the list points to a URL of http://app/documents?docId=NNN.

Obviously, "User2" of "Company B" is presented with a different list of documents while navigating to the URL through the UI (http://app/documents/list?companyId=B). However, what happens when User2 (of "Company B") requests the following URLs directly:

  • http://app/documents/list?companyId=A, or
  • http://app/documents?docId=NNN, where NNN is an ID of a document belonging to Company A?

If the application successfully responds with the requested content, there is an Insecure Direct Object Reference issue, which is a specific example of privilege escalation.

Testing for Privilege Escalation

Testing for privilege escalation usually requires a manual approach as the vulnerability tends to be context dependant. It is difficult to program testing software to recognise what is expected to be available only to one user role or user, but not to the other.

One of Burp's tools is particularly useful when it comes to discovering horizontal escalation - Burp Intruder allows you to enumerate different resources with a great control over how that is done. When it comes to vertical privilege escalation, the number of requests which should be sent to the application is directly proportional to the number of tested URLs and user roles. More precisely, it is at least a multiplication of these numbers. Comprehensive testing should cover all these requests, as more often than not, the authorisation within the web application is properly implemented for almost all application functions, but not all of them.

Moreover, if all privileged application functions have been tested as some non-privileged role, it is still sensible to go through all of them again as other non-privileged roles. For instance, if there are 3 roles in the application: Admin, Editor, Viewer, and all of the Admin's application functions have been tested with the Viewer's session, it's still advisable to go through all of them as the Editor user. This kind of testing can easily become quite cumbersome when there is no specialised tool at hand. This is where Burplay comes in.


Burplay is a Burp extension, which allows for replaying any number of requests while applying different modifications to them.

Currently Burplay supports adding, modifying or deleting:

  • Cookies
  • Request headers
  • GET parameters
  • POST parameters

In addition, sessions can be defined, so you can easily replay requests as a particular user.

For instance, if the application uses a session cookie to track users' sessions, you can:

  1. Log in to the application as a high-privileged user in a browser proxied by Burp and browse through all URLs which should be covered by the test.


  1. In Burp Proxy's History or Target Site Map, choose all interesting requests and "Send to Replay"


They will then show up in the "Replay" tab:


  1. Log into the application as a low-privileged user


  1. Define a Burplay session based on the cookie issued by the application for the low-privileged user

The session can be defined by selecting a cookie name and value in any request or response view within Burp:


5. "Apply" the newly defined session as a modification in the Replay tab:


  1. Start the test by clicking the "REPLAY!" button.


On the right-hand side of Burplay's UI, there are tabs showing all replays and the original set of requests and responses. Currently, manual inspection of replay tabs is the only method of identifying an issue.


Privilege escalations are hard hitting issues that should be tested for comprehensively. Burplay helps in identifying all the vulnerable areas within an application, saving a great deal of time but also potential oversights due to manual testing efforts.

There are plans to introduce some automatic comparison of responses in future versions of Burplay, so stay tuned!

Get Burplay from:


Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More