This write-up is about something more subtle — and arguably more dangerous.

During a recent assessment, I discovered a vulnerability where a low-privileged user could force a workspace owner to lose their privileges entirely, without ever logging in as them. The owner didn’t get hacked in the traditional sense — instead, the application reassigned identity in a way that caused forced privilege de-escalation and effective account takeover.

This post walks through how it happened, why it worked, and what developers can learn from it.

Application overview

The target application is a multi-tenant SaaS platform. Each customer has one or more workspaces, and users inside those workspaces are assigned roles:

• Owner (super-admin level)

• Manager

• Member

The owner has full control — user management, configuration, and critical workspace actions. Manager and Member have minimal privileges.

I was authenticated as a member-level user, testing normal account functionality with proper authorization from the client.

The starting point: profile updates

Like most modern SaaS platforms, the application allowed users to update basic profile information such as:

• Display name

• Preferred language

While updating my profile, I intercepted the request using Burp Suite. The request was sent to:

PUT /api/users/me

The request body looked harmless:

{
  "displayName": "Member-1",
  "userSystemLanguage": "en-US"
}

The response returned my full user object, including some personally identifiable information (PII). While reviewing it, something stood out.

A small detail that mattered

Inside the response, I noticed two properties:

• email

• primaryemail

Both were set to my registered email address.

This raised a simple question:

What happens if I try to set these fields myself?

The frontend UI never exposed email changes here — but the backend clearly accepted and returned them. That meant the server was likely trusting client-supplied values.

The experiment

I modified the same request and added the following fields:

{
  "displayName": "Member-1",
  "userSystemLanguage": "en-US",
  "email": "john.doe@redacted.com",
  "primaryemail": "john.doe@redacted.com"
}

john.doe@redacted.com belonged to the workspace owner — the highest-privileged user in that tenant.

I sent the request.

The backend accepted it.

No validation error.
No ownership check.
No email verification flow.

The response came back successfully, showing my account now associated with the owner’s email address.

What happened next

After refreshing the application, my session broke and I started seeing server errors.

At the same time, the workspace owner logged back into their account.

What they saw was alarming:

• Their owner privileges were gone

• Their account had been demoted to a lower role (member)

• They could no longer manage their own workspace

In simple terms:

My low-privileged account absorbed the owner’s email identity, and the system responded by de-escalating the real owner’s privileges.

This was not just account takeover.

This was forced privilege de-escalation through identity rebinding.

Why this works (root cause)

This issue exists at the intersection of identity, authorization, and business logic.

The backend made several critical assumptions:

1. Email fields were treated as editable profile data
   Instead of protected identity attributes.

2. No uniqueness enforcement
   The system did not block assigning an email already associated with another user.

3. No email ownership verification
   No confirmation link, no challenge, no secondary approval.

4. Implicit trust in client input
   If the client sent primaryemail, the server accepted it.

Once the system allowed email rebinding, the rest of the failure cascaded naturally — identity collision, role confusion, and privilege loss.

Why this is critical

This vulnerability allows:

• Forced owner privilege de-escalation

• Effective reverse account takeover without authentication

• Workspace lockout of legitimate administrators

From a risk perspective, this is catastrophic in a SaaS environment. A single low-privileged user can disrupt or seize control of an entire tenant.

Lessons learned

This bug wasn’t about missing authentication or weak crypto. It was about trust boundaries.

If a field defines who a user is, it must never be treated like what a user prefers.

From a testing perspective, this reinforces a key mindset:

Always test what the backend accepts — not just what the UI exposes.

Responsible disclosure

This issue was responsibly disclosed to the client, validated by their engineering team, and fixed. No real user data was harmed.

Final thoughts

Modern applications are complex systems where identity, authorization, and state management intersect. Bugs like this don’t look dangerous at first glance — but their impact can be devastating.

Sometimes, breaking security isn’t about breaking in.

It’s about changing who the system thinks you are.

Requirements

For GOAD installation on ESXI you need to download the following tools

1. create an ubuntu machine on ESXI server

2. ovftool —> install it on the ubuntu machine

3. pywinrm and ansible —> install it on the ubuntu machine

4. winrm —> install it on the ubuntu machine

5. winrm-fs —> install it on the ubuntu machine

6. winrm-elevated —> install it on the ubuntu machine

7. GOAD repository

STEP 1

Vagrant installation on Ubuntu Machine

1. mkdir tools

2. cd tools

3. wgethttps://releases.hashicorp.com/vagrant/2.3.7/vagrant_2.3.7-1_amd64.deb

4. dpkg -i vagrant_2.3.7-1_amd64.deb

STEP 2

install vagrant vmware esxi plugins

1. vagrant plugin install vagrant-vmware-esxi

2. vagrant plugin install vagrant-reload

3. vagrant plugin install vagrant-vmware-desktop

4. vagrant plugin install winrm

5. vagrant plugin install winrm-fs

6. vagrant plugin install winrm-elevated

install Ansible and pywinrm

1. pip3 install --include-deps ansible

2. pip3 install ansible-core

3. pip3 install ansible-core==2.12.3

4. pip3 install pywinrm

STEP 3

Download the Goad repository from the Github and configure some initial files for vmware_esxi compatibility

git clonehttps://github.com/Orange-Cyberdefense/GOAD

in this directory GOAD/ansible install the “requirements.yml” file using the following command —> ansible-galaxy install -r ansible/requirements.yml

STEP 4

In the main directory of the “GOAD” remove the previous goad.sh file and use the provided goad.sh file and replace the old file with this new one provided file.

Create a directory called “vmware_esxi” in this directory → “/GOAD/ad/GOAD-Light/providers”

Now we have the directory called “/GOAD/ad/GOAD-Light/providers/vmware_esxi”

STEP 5

Now go back to the main GOAD directory and run the goad.sh

Now run the goad.sh using the follwing command:

bashgoad.sh-t check -l GOAD-LIGHT -p vmware_esxi -m local

→ 2 file will be generated they will be Vagrantfile and inventory

→ Replace these two files with these Vagrantfile & inventory in the "/GOAD/ad/GOAD-Light/providers/vmware_esxi" directory.

Note: if you want to change the ips of DC01, DC02, SRV02 you have to change the ips inside the inventory file too. This will be used with ansible-playbook while installing the vulnerable AD-set.

STEP 6

Install the OVFTOOL in the ubuntu machine

Since our ESXI version is 8.0.2 we will download the latest version of ovftool which is “v4.6.2” from “https://developer.vmware.com/web/tool/4.6.2/ovf-tool/”

download-Link with the wget command :

wgethttps://vdc-download.vmware.com/vmwb-repository/dcr-public/8a93ce23-4f88-4ae8-b067-ae174291e98f/c609234d-59f2-4758-a113-0ec5bbe4b120/VMware-ovftool-4.6.2-22220919-lin.x86_64.zip

Unzip the ovftool file by the follwing command

unzip VMware-ovftool-4.6.2-22220919-lin.x86_64.zip

echo $PATH

cd ovftool

pwd

export PATH=/home/management/tools/ovftool:/home/management/.local/bin:/usr/local/sbin:/usr/local/bin:/ usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

STEP 7

Configuring the IP addresses automatically assigned by the vagrant in the provisioning files

Go to the following directory and configure the IP addresses → “/GOAD/ad/GOAD-Light/providers/vmware_esxi”

edit the files as in the screenshots

STEP 8

DEPLOYING WINDOWS ACTIVE DIRECTORY MACHINES ON ESXI sever

Go to the following directory “ad/GOAD-Light/providers/vmware_esxi/” Then run the follwing command: vagrant up

check the adapters of the machines deployed using the vagrant up command

POC of the network adapter of the ubuntu machine

Ubuntu Machine is on the same network as the DCO1 Adapters

POC: we don't need to change the adapters in order for the provisioning to work properly both of the adapters should be on the same network like in the following screenshots

This is the network scheme of all the machines

Important Note: Goad provisioning file considering Ethernet0 as the domain adapter and Ethernet1 as the NAT adapter. We will configure the domain adapter IP addresses in the inventory and the Vagrant file before provisioning.

DCO1

Ethernet adapter Ethernet0: IPv4 Address. . . . . . . . . . . : 172.70.0.70

Ethernet adapter Ethernet1: IPv4 Address. . . . . . . . . . . : 172.70.0.71

DC02

Ethernet adapter Ethernet0: IPv4 Address. . . . . . . . . . . : 172.70.0.74

Ethernet adapter Ethernet1: IPv4 Address. . . . . . . . . . . : 172.70.0.75

SRV02

Ethernet adapter Ethernet0: IPv4 Address. . . . . . . . . . . : 172.70.0.68

Ethernet adapter Ethernet1: IPv4 Address. . . . . . . . . . . : 172.70.0.69

STEP 9

Start the provisioning using the ansible

Go to the following directory “/GOAD/ansible”

Run the following command before provisioning:

export ANSIBLE_COMMAND="ansible-playbook -i ../ad/GOAD-Light/data/inventory -i ../ad/GOAD-Light/ providers/vmware_esxi/inventory"

Run the following command to run the provisioning: ../scripts/provisionning.sh

Special Thanks to my friend Syed Asadullah for the help especially in networking part he has done a great job.

I wanted to write a short blog on OSINTLEAK, which is a very powerful OSINT platform. Unlike Dehashed, it has a larger database of leak contents, making it very useful for bug hunters, penetration testers, and red teamers. It offers numerous amazing search filters that allow you to find your desired results.

The pricing is very affordable, and it provides better and more results. I have personally used osintleak.com for bug hunting and penetration testing projects, and I can say it was very helpful for me. It's a great and affordable investment, and I liked it better than dehashed.com. This is not a promotional blog post; I just wanted to share my experience with you all.

The first menu is about the type of filter you want to search for. You can search with a username, email, URL, phone number, IP address, first name, last name, credit card number, credit card name, and others.

The second option is the database option. You can select any specific database or choose all, which means it will search all three leaked databases for your queries.

The third option is the date option. It will search based on the provided date, and by default, it's set from 2001 to 2024.

The fourth option is the country filter. You can select all countries for better results.

The fifth and sixth options are the interesting search filters. The first quick search will search for the exact word you enter, and the similar option is a very interesting one which will search for the word you entered and find similar results. The best example is for the URL section. If you type "tesla," it will search all the subdomains of xxx.tesla.xxx and other similar results, including usernames and passwords.

In conclusion, OSINTLEAK stands out as a valuable asset for individuals and teams engaged in cybersecurity endeavors. Its comprehensive database, powerful search filters, and affordability make it a go-to choice for bug hunters, penetration testers, and red teamers alike. As you delve into the realm of OSINT exploration, remember to utilize these tools responsibly and ethically, respecting privacy and legal boundaries. With OSINTLEAK at your fingertips, the possibilities for uncovering valuable insights and fortifying digital defenses are boundless. Happy hunting!

So, a few months back I and Haseeb were hunting on a private program and the program is a services-based company that has paid services only. So the program had very limited assets in scope and most of them were redirected back to the main domain then we used the main domain and checked every functionality we tried every possible way to manipulate the payment method to get the subscription free of cost and we were able to get the services free of cost by providing negative value but due to bad luck someone had reported this before us and it was marked as duplicate. So getting duplicate motivated us to dig deeper instead of de-motivating and this time we were confident enough that we could get critical vulnerability.

By changing our hunting methodology we focused on this program in the opposite way we collected their in-scope assets and then saved them in a txt file as url.txt and ran "x-officers.py" script to quickly collect js files and then search for custom words in those js files luckily we found a dev portal which was "29dev-api-x.target.com" note 29 is not the exact number 😛 after visiting the URL it prompts us with a login page and after checking their js files we found a registration API and we successfully registered an account via the API with defined parameters. After a successful login, we had access to their developer portal but it had very few functions not very useful according to my experience I felt that there would be an admin panel with lots of working functions so the next step was to find the admin panel. I love FFUF since it's very handy in terms of fuzzing so we found "qa-admin-api.target.com" with a status code of 301 which was redirecting back to the login panel with curl.

But as we were authenticated inside "29dev-api-x.target.com" our session was valid for the admin panel too because of the Authorization header which contained our JWT by the way we found multiple JWT issues but I won't cover that in this article. But we faced another issue "Access Denied" there were several menu none was working because we were not an admin our account was from the developer portal, not an admin account. In the incognito window, we opened the admin panel which prompts us with a login panel and we started to analyze the js files I was hoping for registration API and we could find any mentioned API.

On the authenticated admin panel window I opened chrome's developer tools and in the application tab I was checking the cookies section was had some rubbish and useless parameters and their values not useful but after checking the Local Storage section I found the GEM there were some parameters like "currentuser" and "current_user_role" now the fun parts begin, as it's visible in the below screenshot that the "currentuser" parameter has my account's details and the "current_user_role" has the value of "IsAdmin:false" means my role was not admin role by changing the "IsAdmin:false" to "IsAdmin:true" and refreshing the page I was able to use the admin panel so I escalated my privileges to admin then we browsed all the pages and options and then found the subscription section and we were able to enable paid services for our account on "target.com" and to delete other user's subscription and do other malicious things. Wink Wink

Another method

I guess some of you might think that why we didn't try to register an account on the admin panel with the previously found API URL you are right after performing the above trick we tried to register an account on the admin panel with the same API path and parameters and by adding another parameter "admin" to true.

HTTP request and API URL

Developer portal:

POST /api/user/register HTTP/1.1

Host: 29dev-api-x.target.com

user-agent**:** Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36

Content-Type: application/json

{"username":"test1337","email":"qjimyhwekglh@mymail.com","fname":"george","lname":"frankmiller","password":"Test@123$"}

Admin Panel:

POST /api/user/register HTTP/1.1

Host: qa-admin-api.target.com

user-agent**:** Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36

Content-Type: application/json

{"username":"test2","email":"email@email.com","fname":"george","lname":"frankmiller","password":"Test@123$", "admin":"true"}

FFUF command:

ffuf -u https://FUZZ.target.com/ -w /usr/share/wordlists/SecLists/Discovery/DNS/dns-Jhaddix.txt

Takeaways & recommendations

1: Use the application as a normal person and observe all the functionalities.

2: If you get any subscription section do a test for price manipulation with every possible method.

3: Don't get de-motivated if your submission gets duplicated or if you don't find any vulnerability it's a part of this game.

4: Always try at least two different methodologies for hunting your target program.

5: Analyze JS files you never know what's in there so keep your eyes on every JS file.

6: Always test for parameters like admin or role or priv and give admin as value most of the time it works and you can register an admin account.

7: Check for parameters like "isadmin" or other similar things and changing their value to the opposite of that value.

8: Link of X-Officers.py

If you want to learn or sharpen your Active Directory penetration testing skills then this course is a gem for you. Before CRTP I did PNPT certification by TCM-Security and I'm a PNPT certified PNPT cleared my concept of Active Directory pen-testing mostly attacking the AD environment from Linux but CRTP is more focused on pen-testing AD with Windows Powershell which is a bit boring in the starting but when you start using Powershell it gets interesting.

The course content of CRTP is a complete guide to pentest an AD environment it includes everything you need to perform in your AD pentest. Before attempting the CRTP exam I studied the course contents and did some labs and got a good grip on using PowerShell and PowerShell scripts for enumerating the AD environment like Powerview, powerup and others so I got an internal Pentesting project including their Active Directory environment and I used all of the techniques I learned from CRTP course indeed I can say it was really helpful the pen-testing project was like the CRTP labs I became a Domain Admin in 2 days of pentest most of the techniques and methodologies explained in CRTP are based on the real-world environment it not just like any other CTF type exam. The exam was really hard and realistic and I enjoyed a lot solving the exam machines I'm a fan of the exam machines they were great and challenging and you will find most of the explained topics in the exam machine so I would like to suggest that don't skip any topic in the course all are important and necessary to watch if you skip any of them you might miss the important part and on the exam day you may face some issues regarding the attacks. So Long story short The course material is enough to learn and practice but if you want to learn more and practice AD pentest and different attacks or exploiting misconfigurations on the AD environment then try tryhackme's Active Directory modules as well besides this.

I do appreciate Altered security and Nikhil Mittal for this amazing course and I do highly recommend CRTP if you want to learn Active Directory pen-testing. Their course contents and labs plus exam labs are based on real-world environments, not just CTF-type machines.

I'm not gonna bore you with a long story of this pentest project. Last month I was working on a Pen-testing project and I found multiple critical & high vulnerabilities and I'll cover the interesting findings only. I won't share the name of the application let's assume it's redacted.com it has multiple subdomains but my focus was on the main domain. So, on the main domain, it has a login portal and from there users and admins can login to their dashboard. It was a grey box Pen-testing I tried to login as an admin with the admin credential and it was a successful login but it asked for the OTP since 2fa is enabled just for the admin, not for normal users. So, upon successful login it asks for OTP in the new HTTP request it asked only for userID and the parameter was OTPUserId=5 digit numbers by replacing this userId I was able to login to another user account and it wasn't validating the LoginOTP parameter. Later I found that without authentication just by sending a post request to that endpoint with the parameter "OTPUserId" and "LoginOTP" I was able to login just by providing anyone's userid.

Note: later I found that the same HTTP request plus parameter was already in their javascript file as an attacker without having any credentials I was able to login into anyone's account.

As you can see in the above Screenshot just by providing userid I was able to login into anyone's account. The first part is finished here.

Admin account creation with normal user

So in the first part, you can see that an attacker was able to login into anyone's account without a username and password just by typing random userID. So after authentication into any user's account, I was able to navigate to the admin panel by just visiting https://redacted.com/admin/dashboard from there most of the admin functionalities were accessible and the interesting one was the "User Management" section I was able to create users with custom roles either admin or normal user and I created an admin account just for the testing purpose it was working I was admin without credential I was able to create an admin account and then take over the whole admin panel.

Things to remember

By reading their Js code I was able to login into anyone's account without credentials and then I found that "/admin/dashboard" was accessible for authenticated users but doesn't check if the user is an admin or a normal user and then from "User Management" section I was able to create admin account.

./exit