IAM: A Bug Hunter's Field Manual

0x00 IAM For Bug Bounty Programs

This is your briefing. No fluff. Just the attack vectors and methodologies for dismantling flawed IAM systems.

0x01 Core Directives: AuthN vs. AuthZ

First, a critical distinction. Do not confuse them.

• Authentication (AuthN): The challenge. Prove your identity. This is the front door lock. Passwords, MFA tokens, API keys, JWTs. Breaking AuthN means you can forge a key and become anyone.

• Authorization (AuthZ): The permissions. What can you do now that you're inside? This is the map of what doors your key can open. User vs. Admin. Read vs. Write. Accessing your own data vs. everyone's data. Most high-severity IAM vulns live here. It's where lazy developers assume the front door is enough. We exploit that assumption.

Thanks for reading ToxSec - Bug Bounty and AI Security! Subscribe for free to receive new posts and support my work.

0x02 The Hit List

This is your target list. Focus your reconnaissance and exploitation efforts here.

Broken Access Control

This is the top-tier objective. It manifests when the server fails to enforce restrictions, allowing you to access unauthorized data or execute privileged functions.

• Vertical Privilege Escalation (VPE): A standard user executing admin functions. Your mission is to find endpoints (/api/admin/deleteUser) or GraphQL mutations (mutation { deleteUser(id:"123") }) that lack a role check.

  • Tactic: Establish two accounts, User and Admin. Map the Admin's capabilities. Replay every privileged request using the User's session token. Automate this with tools like Burp's Autorize. A 200 OK on an admin function is a critical finding.

• Horizontal Privilege Escalation / IDOR: A user accessing the data of another user at the same privilege level. This is the most common IAM failure.

  • Tactic: Establish two standard accounts, User A and User B. As User A, perform every possible action (view profile, post message, download invoice). Capture these requests. In Repeater, replace every instance of User A's ID with User B's ID. Check URL paths, request bodies, and headers. If you see User B's data, you've found an IDOR.

Flawed Authentication Mechanisms

A direct assault on the front door. Compromising the mechanism itself leads to account takeover.

• JWT Misconfigurations: JWTs are a frequent source of failure. Use jwt.io to decode them.

  • alg:none attack: Modify the token's header to {"alg":"none"} and remove the signature. Some poorly configured servers will accept this, allowing arbitrary user impersonation.

# Simple Python PoC for alg:none
import base64

# Original header: {"alg": "HS256", "typ": "JWT"}
# Original payload: {"user": "test", "exp": 1672531199}

# 1. Base64url encode the new header and desired payload
header = base64.urlsafe_b64encode(b'{"alg":"none","typ":"JWT"}').rstrip(b'=')
payload = base64.urlsafe_b64encode(b'{"user":"admin","iat":1516239022}').rstrip(b'=')

# 2. Concatenate with a period, leave signature empty
unsigned_token = header + b'.' + payload + b'.'

print(unsigned_token.decode())
# eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4iLCJpYXQiOjE1MTYyMzkwMjJ9.

• • Secret Key Cracking: If the signature algorithm is symmetric (HS256), capture a token and run hashcat against it with a common wordlist. Developers often use weak secrets (secret, password, 12345). A cracked secret means you can forge tokens for any user, including admins.

# Hashcat command for cracking a JWT HS256 secret
# -m 16500 specifies JWT mode. rockyou.txt is a common password list.
hashcat -m 16500 -a 0 your_captured_token.txt /path/to/rockyou.txt

• OAuth 2.0 Implementation Flaws: OAuth's complexity is a breeding ground for bugs.

  • Redirect URI Manipulation: Test for weak validation in the redirect_uri parameter. Can you use subdomains, path traversal, or different schemes to leak authorization codes to a domain you control? https://example.com/auth?redirect_uri=https://evil.com https://example.com/auth?redirect_uri=https://example.com.evil.com

Session Management Vulnerabilities

Exploiting how the application handles a session after login.

• Session Token Analysis: Is the token (session_id, etc.) sufficiently random and unpredictable? Does it expire correctly? Crucially, does it invalidate on the server-side after logout, or can it be replayed?

• Session Fixation: Can you force a victim to use a session ID you already know? Provide a user with a link to the target site that includes a specific session token (

https://example.com/?session_id=YOUR_TOKEN

• ). If the user logs in and the application doesn't assign a new token, their authenticated session is now tied to your token. You now have their session.

0x03: Field Operations - Toolkit & Methodology

Random clicking is for amateurs. Professionals operate with a clear doctrine and a trusted set of tools.

Field Mandates

These are non-negotiable rules of engagement.

• The Two-Account Rule: All IAM testing requires a minimum of two parallel accounts. A single account makes finding horizontal privilege escalation impossible. A third, higher-privilege account is ideal for VPE testing.

• Proxy Everything: Your intercepting proxy (Burp Suite, Caido) is your central nervous system for the operation. Every request must be logged, inspected, and understood. Do not trust the client-side UI. Trust the traffic.

The Arsenal

Master your tools. Know their function and how to deploy them effectively.

• Repeater: This is your primary weapon for manual testing. It's where you'll spend most of your time, methodically changing IDs, parameters, and headers to probe for authorization weaknesses.

• Autorize (Burp Extension): Feed it your low-privilege session cookie, then browse the application as a high-privilege user. Autorize mirrors the requests with the low-privilege session and flags any that bypass access controls.

• Logger++ / Flow: Your comprehensive mission log. It provides a complete, searchable history of all traffic. When you identify a user ID, search for it across the entire log to find every endpoint that uses it.

Standard Operating Procedure (SOP)

Follow the process.

1. Recon & Mapping: Identify roles and privileges. What makes an admin different from a user? What data is considered private? Build a threat model based on the application's functionality.

2. Authenticate & Enumerate: Log in as your primary test user. Methodically navigate every feature and function. Capture and document every request.

3. Falsify & Replay: Isolate individual requests in Repeater. Systematically swap identifiers (user IDs, session tokens, tenant IDs) with those of your second account. Analyze the server's response for data leakage.

4. Hunt for Hidden Endpoints: The UI doesn't show everything. Use content discovery tools (dirsearch, gobuster) to find unlinked directories like /admin/ or /debug/. Analyze JavaScript files for API endpoints. Test every discovered endpoint for access control flaws.

# Example dirsearch command
dirsearch -u [https://target-app.com](https://target-app.com) -e php,html,js,bak,txt -w /path/to/wordlist.txt

0x04: Advanced Tactics & Asymmetric Warfare

The basics will find common bugs. Elite hunters look deeper, exploiting subtle flaws in logic and timing that automated tools miss.

Race Conditions

Exploit the tiny gap between a system checking a condition and acting on it. This is common in features involving limits or states (e.g., spending funds, using a coupon, voting).

• Tactic: Identify a function with a limited resource. Using Burp's Turbo Intruder or a custom script, send numerous identical requests to that function in parallel. The goal is to have the requests execute before the system can update its state. Can you use a one-time discount code twice? Can you exceed your API rate limit? Can you add yourself to a team twice, getting elevated privileges?

# Simple Python race condition PoC using threading
import requests
import threading

TARGET_URL = "[https://target-app.com/api/use_coupon](https://target-app.com/api/use_coupon)"
HEADERS = {"Authorization": "Bearer YOUR_TOKEN"}
DATA = {"coupon_code": "ONETIME25"}

def send_request():
    try:
        response = requests.post(TARGET_URL, headers=HEADERS, json=DATA)
        print(f"Status: {response.status_code}, Response: {response.text}")
    except requests.RequestException as e:
        print(f"Error: {e}")

threads = []
for i in range(20): # Send 20 requests at once
    thread = threading.Thread(target=send_request)
    threads.append(thread)
    thread.start()

for thread in threads:
    thread.join()

Multi-Step Process Exploitation

Complex, multi-step processes like password resets, email verifications, or OAuth flows are ripe for logic flaws. The vulnerability often lies in a failure to validate that all steps were completed by the same user.

• Tactic: Initiate a process as User A (e.g., request a password reset). Intercept the final step of the process (e.g., submitting the new password with the reset token). Can you substitute User A's ID with User B's ID in that final request? If the server only validates the token and not the user ID associated with it, you may be able to change User B's password.

Parameter & Verb Tampering

Sometimes access control is implemented imperfectly, keyed to specific parameters or HTTP methods.

• HTTP Parameter Pollution (HPP): If a request uses a parameter like user_id=attacker_id, try submitting it as user_id=attacker_id&user_id=victim_id. Depending on the backend parsing technology, the application might process only the last parameter, applying the action to the victim while using the attacker's session for the initial authorization check.

• Verb Tampering: If a POST request to /api/users/123/delete is blocked for your role, try sending a PUT, PATCH, or even GET request to the same endpoint. Frameworks can have different authorization controls for different HTTP methods, and you might find a less-secure route to the same function.

# Using curl to test for verb tampering
# Original forbidden request:
# curl -X POST [https://target-app.com/api/users/123/delete](https://target-app.com/api/users/123/delete) -H "Authorization: Bearer YOUR_TOKEN"

# Test with PUT instead
curl -X PUT [https://target-app.com/api/users/123/delete](https://target-app.com/api/users/123/delete) -H "Authorization: Bearer YOUR_TOKEN"

Exploiting Team/Organization Features

Applications with multi-user "organization" or "team" features introduce a massive attack surface for IAM. Focus on invitation and role-change logic.

• Tactic: As a low-privilege user in an organization, try to modify your role via a direct request ("role":"admin"). Can you re-accept an old, expired invitation? When you are removed from a team, are your session tokens immediately invalidated, or can you continue to access resources for a period?

Click the button below to keep getting high quality content from ToxSec.com

Subscribe now

0x05: Debrief - Reporting for Maximum Impact

A critical finding is useless if the security team can't understand or reproduce it. Your report is a weapon. Wield it with precision.

The Title is Half the Battle

Be clear and impactful.

• Weak Title: "IDOR"

• Strong Title: "Account Takeover via IDOR in Email Change Functionality"

• Weak Title: "Privilege Escalation"

• Strong Title: "Any Standard User Can Achieve Full Admin Privileges by Modifying API Request to /api/v2/setRole"

The Anatomy of a Flawless Report

Structure your report for immediate triage.

1. Summary: A brief, one-paragraph overview of the vulnerability, the attack vector, and the ultimate impact.

2. Steps to Reproduce (StR): This is the most important section. Provide a numbered list. Be ruthlessly clear and simple. Assume the reader has minimal knowledge of the application.

   • Example: "1. Log in as low-privilege User A. 2. Navigate to your profile settings page. 3. Intercept the POST /api/updateProfile request and send it to Repeater. 4. In the JSON body, change the user_id from User A's ID to User B's ID. 5. Forward the request. Observe that you receive a 200 OK and have successfully modified User B's profile."

3. Proof-of-Concept: Include the full HTTP request and response pairs. Redact sensitive data but leave enough for the team to verify the finding. Screenshots or short videos are highly effective.

4. Impact Statement: Clearly articulate the business risk. Don't make them guess. Spell it out: "This vulnerability allows any user to take over any other user's account by changing their email address without authorization. This could lead to theft of sensitive user data, financial loss, and reputational damage."

Hunting for IAM vulnerabilities requires a methodical and patient mindset. It's less about firing off a fancy exploit and more about understanding the application's logic and systematically breaking it. Master these techniques, and you'll be finding the kinds of critical bugs that build a reputation and earn serious bounties. Now go get to it.

Want to read more? Check out ToxSec’s article on how LLM’s are getting involved in CTFs!