HELLO HACKERS!

I'm back after a long break — and I returned with a high-severity bug found in a private HackerOne program that can lock out every Owner and Admin in an organization, paving the way for a complete org takeover.

Without wasting any time… let's dive in!

About the Target:

The target is a well-known property-management platform used worldwide for real estate and rental management. To preserve confidentiality, I'll refer to the service in this write-up as Target.com

When you create an organization on Target.com, the initial owner is automatically assigned a role called Administrator. This Administrator has full access to everything within the organization. The owner can add additional owners and grant them the Administrator role, or invite regular users and assign them default or custom roles with varying permissions.

Now, let's break down how I exploited a flaw in this system to destroy the org.

HACKING TIME:

My methodology starts with creating an account and exploring the main domain and its functions — without using Burp Suite or any tools at first. I focus on understanding the application properly.

After that, I split the platform into SECTIONS, and each SECTION into FUNCTIONS. I test each function one by one until I fully understand how it works and find any potential vulnerabilities.

Digging into the Roles section

After running some initial tests, I decided to focus more on the Roles section to understand how it worked in detail. While exploring it, I noticed something interesting right away — every role in the system could be edited, deleted, or even replicated by creating a new custom role.

However, there was one exception: the Administrator role. It couldn't be edited or deleted, and there was a clear label next to it saying "Non-Editable."

Looks interesting, right?

From there I had an idea: what if I tried to modify the Administrator role? To test it, the organization owner invited a second user (the attacker) and gave him only the permission to Edit Roles — so the attacker's access was limited to the Roles section.

When the attacker opened the Roles page, the Administrator role still appeared as non-editable in the UI, so they couldn't change it directly there.

I sent a GET request that returns all role objects to obtain the internal ID for the Administrator role and discovered its ID was 1.

Next, I edited any other default or custom role through the UI, removing all permissions from that role while intercepting the outgoing request. The intercepted request looked like this:

PUT /manager/api/userRoles/{Role-Id}/menu

I modified the request by replacing {Role-Id} with 1 (the Administrator role ID) and then forwarded the request.

When I returned to the Roles section, I found that the Administrator role had indeed been changed: all permissions had been removed and its label had switched from Non-Editable to Edited.

After that, I switched back to the Owner account — and to my surprise, it had been automatically logged out. When trying to log in again, the owner couldn't access the account at all.

At this point, all Owners and Admins across the entire organization were completely locked out, unable to log back in or regain access in any way. In other words, this single request effectively caused a total lockout of the organization, leading to Org Takeover scenario.

I reported the vulnerability through the private program, and the team classified it as High severity, rewarding me with a $$$$ bounty for the finding.

I hope you found my story useful! If anyone has any additions or suggestions, here are my social media accounts — I'd really appreciate it if you reached out.

LinkedIn => https://www.linkedin.com/in/ahmed-esmail-844401298/

Facebook => https://www.facebook.com/profile.php?id=100024307756910