Have you ever scrolled through your Burp Suite history, feeling like you're just looking at noise? I almost did. In ethical hacking, the biggest finds are often right there, hidden in plain sight. This is the story of how a single, overlooked line in a Burp Suite log led to a critical privilege escalation and a $2000 bounty.

Let me show you why your HTTP history is a goldmine.

The Discovery: Spotting the Anomaly

The initial security research was focused on a standard admin dashboard. The goal was to test access controls for a common bug bounty target. The /users page was reviewed, which listed everyone: Users, Admins, and Partners.

Everything appeared normal. As an admin, changing user roles was a standard function. The web interface showed the usual three options: User, Administrator, and Partner.

But then, something small was noticed. While actions were performed in the browser, Burp Suite was running in the background. A specific response was caught that looked like this:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "user": "test_admin",
  "email": "admin@example.com",
  "role": "111e4567-e89b-12d3-a456-426614174000"
}

Did you see it? The "role" wasn't a name like "Admin." It was a UUID. This was the first clue. In that moment, a simple question was asked: What if this identifier can be controlled?

The Investigation: Connecting the Dots

This is where Burp Suite's search function became essential. That UUID from the response was copied, and a search was run through all the captured traffic.

And there it was. A different request, likely made by the application itself when loading the page, was found:

GET /api/internal/role/list HTTP/1.1
Host: target.com

Its response was the key:

{
  "roles": [
    {"name": "User", "id": "222e4567-e89b-12d3-a456-426614174111"},
    {"name": "Administrator", "id": "111e4567-e89b-12d3-a456-426614174000"},
    {"name": "Partner", "id": "333e4567-e89b-12d3-a456-426614174222"},
    {"name": "Internal_Employee", "id": "444e4567-e89b-12d3-a456-426614174333"}
  ]
}

Four roles. The interface only showed three. The fourth UUID (444e4567...) was for "Internal_Employee". This hidden role was not meant to be selected by a standard admin.

The core access control flaw was now visible: the backend knew about a powerful internal role, but the frontend didn't show it. The system trusted the role UUID from the user without verifying if they were allowed to assign it.

The Exploitation: Testing the Hypothesis

The hypothesis was simple: What if the hidden Internal_Employee UUID was submitted in a role-change request?

A legitimate admin action was intercepted in Burp Suite Repeater. The request to change a user's role looked like this:

POST /api/user/role/update HTTP/1.1
Host: target.com
Content-Type: application/json
Authorization: Bearer <valid_admin_token>

{
  "user_id": "target_user",
  "role_id": "111e4567-e89b-12d3-a456-426614174000"
}

The role_id For a standard Administrator, was then swapped with the hidden Internal_Employee UUID.

{
  "user_id": "target_user",
  "role_id": "444e4567-e89b-12d3-a456-426614174333"
}

The ENTER key was pressed.

The server responded: HTTP/1.1 200 OK. The IDOR was confirmed.

The application did not check if the submitted role_id was one that the current admin was authorized to assign. This Insecure Direct Object Reference (IDOR) allowed a jump from a regular admin role to an internal system role.

The Impact: From Admin to Internal

The impact of this privilege escalation was immediate and significant. After reassigning the role, a refresh of the admin dashboard was performed.

  • New management sections appeared that were not visible before.
  • Sensitive internal employee records could now be viewed and edited.
  • System configuration panels were unlocked.

The access was no longer that of a platform administrator, but of an internal system operator. The ability to simulate threats had revealed a critical flaw in the access control matrix.

The vulnerability could be summarized as: Broken authorization on an endpoint that allowed assignment of any role UUID, leading to vertical privilege escalation.

The Report & Reward: The Professional Finish

The finding was documented clearly for the bug bounty program:

  1. The flaw: IDOR in the role assignment endpoint.
  2. The prerequisite: A standard administrator account.
  3. The steps: From finding the hidden UUID to escalating privileges.
  4. The impact: Full access to internal employee data and system controls.

A CVSS v3.1 score of 8.8 (High) was suggested, highlighting the High impact on Confidentiality, Integrity, and Availability.

The ethical disclosure was submitted. The triager agreed with the severity.

The reward: A $2,000 bounty.

Your Turn: The Key Takeaways

The path from admin to internal access was paved by one habit: looking deeper into the logs.

  1. Treat every ID as a potential lever. Whether it's a UUID, a number, or a string, ask: "What happens if I change this?"
  2. Map hidden application data. Use Burp Suite to find API responses that reveal more than the UI shows.
  3. Test the trust boundary. Systems often trust data from "authorized" users too much. Your job is to test that trust.

This wasn't about complex attacks. It was about noticing a small inconsistency — a role as a UUID — and following the thread.

What would you have called this finding? An IDOR? A Broken Access Control? Both are correct. In the end, the impact is what matters most.