Skip to content
  • Home
  • OWASP Top 10
  • Bug bounty hunting
  • About
  • Contact
  • How to support
Account takeover: From zero to System Admin

Account takeover: From zero to System Admin

April 22, 2021 by thehackerish

Hello ethical hackers! Today I share with you an account takeover I achieved during a recent penetration testing of a web application. For those who don’t know know what an account takeover is, there is a dedicated section for that. From there, I will explain how I enumerated all the endpoints. Then, I will walk you through the steps I took to gain access to the highest privilege account. It is going to be a fun and rewarding episode, so stay with me until the end!

Account takeover definition

Account takeover happens when an attacker, with low or no privileges, can take control of another account without authorization. For example, you can find customer account takeover in e-commerce platforms or any other service which manages user accounts.

Is account takeover a vulnerability?

I see account takeover qualified as a vulnerability. However, I don’t think this should be the case. In fact, I tend to describe it as a result of one or more vulnerabilities. Just like a data breach can be the result of a SQL injection vulnerability.

Account takeover scenarios

Based on the distinction we have just set between vulnerability and its outcome, many vulnerabilities can lead to account takeover. For example, you might have an open redirect vulnerability which leaks the user token upon login. In this scenario, an attacker can take over the victim’s account by simply clicking on a malicious link. There are many reports demonstrating account takeover on HackerOne’s Hacktivity, so make sure to check them out.

In the remaining of this episode, the scenario involves unauthenticated endpoints which, once combined, result in a full account takeover without user interaction.

Account takeover and JavaScript enumeration

The developers wanted to know what a public user could achieve with no prior access. I didn’t have login credentials as it was a black-box penetration testing assignment. In such use cases, I dive right into JavaScript files, hoping to find API endpoints, hard-coded secrets, or even juicy comments. I like to use Chrome’s Dev Tool because it lists JavaScript files, beautifies them and looks for specific keywords across the entire code base. Besides, I can make breakpoints and track events to analyze how the application works from a Client-side perspective.

Since this application had a separate front-end, I collected all the API endpoints. It is a tedious task, but it’s rewarding in the long run. I found many endpoints, but the most interesting ones were the user sign up feature, password resetting based on the user identifier and account listing based on the user email. You will see why shortly!

Before account takeover

Before I found how to achieve account takeover, I first tested the endpoints I collected earlier. During application mapping, there was a registration form which returned an error. I thought maybe it’s broken and I moved on. However, I now understand what’s happening.

The debug interface

It turns out that the application sends a confirmation email to the user. However, the mail server was down. Besides, the sign up requires approval from an employee. How did I know that? Well, I found a debugging portal on another port on the server which disclosed all the operations, including the back-end responses. One of them contained a mail server connection error, and another one returned the ID of the newly created user, which means that it has been successfully created, but not yet active.

Bypassing the approval step

If you recall, I mentioned earlier that I found a password reset API endpoint that uses the account ID. Guess what, I have the new user ID. So I quickly send the request. To my surprise, the response is positive and I can now log in as the new user without approval from an internal employee! As a bonus, I have a limited admin role, which is not as powerful as the System Admin, but it’s a good start to hunt for the ultimate account takeover. Sadly, the user identifiers were long and random, also known as UUIDs. Therefore, I needed a way to enumerate them.

Information disclosure to the rescue

When I logged in with the new user, I captured the traffic while doing the usual application mapping, and one endpoint caught my attention. It queries the back-end for an email and retrieves data which includes the user ID, among other Personally Identifiable Information (PII). This endpoint matched the one I found during JavaScript enumeration. So now I need prior knowledge of the victim email to achieve account takeover, or do I?

Inspecting the debugging portal reveals exhaustive details about this specific feature, including the SQL query, which happened to be using the LIKE operator in the WHERE statement. The SQL query resembled something along the line of select email from user where email LIKE ?. Although there is no SQL injection, I can still use the percent character %, which returned the entire users from the database! A massive information disclosure!

System admin account takeover without interaction

We now have all the ingredients to get that System Admin account. Matter of fact, I didn’t know there is one until I dumped the entire database with that information disclosure vulnerability. I now have the System admin ID, which I use to reset the password, therefore achieving full account takeover of the System Admin user.

In terms of the impact, I essentially got full access to the application as the highest role possible, without any interaction from the victim.

Conclusion

Hopefully, you learned a trick or two on how to achieve account takeover during a web application penetration testing using a black-box approach.

Account takeover is one of the biggest security flaws. Depending on the level of access, attackers can compromise the entire web application or even the whole infrastructure. If you are a developer, I hope you learned why you must always implement authentication and access control on privileged endpoints. Besides, I recommend you request a penetration testing early in the development life cycle. That way, you will avoid any design flaws or business logic errors that will become expensive to patch later.

Learn more

If you are new to hacking and want to learn the basics, start with the Ultimate guide to OWASP Top 10 and apply your knowledge on the lab which supports it. If you enjoy learning with videos, I invite you to watch the OWASP Top 10 Youtube playlist.

Post navigation

Previous Post:

OSCP Certification: All you need to know

Next Post:

Jira vulnerabilities and how they are exploited in the wild

Get my FREE Udemy course

Hack like a white hat hacker - A practical introduction

Is pentesting the right job for you? MyFREE Udemy course will help you answer it through a practical pentest mission example.

Enroll for FREE

Overcome your struggles and become a successful bug bounty hunter!

Master bug bounty hunting through Anna's journey, uncovering the mindset, tactics, and skills needed to thrive and succeed in the game

Read it NOW

Categories

  • burp suite
  • Hacking
    • bug bounty
    • Penetration testing
    • red team
  • OWASP
    • OWASP juice shop
    • OWASP Top 10
      • OWASP Top 10 training
      • OWASP Top 10 vulnerabilities
    • OWASP WebGoat
    • OWASP ZAP
  • Secure coding
  • Uncategorized

Overcome your struggles and become a successful bug bounty hunter!

Get you Free hacking lab VM

free-hacking-lab-vm
free-hacking-lab-vm
© 2025 thehackerish | Built using WordPress and SuperbThemes