Full Account Takeover Leading to RCE Remote Code Execution

Introduction

Hey fellow hackers,
My name is Waqas, and I am currently working as a cybersecurity enthusiast, Last year, my friend Zeeshan M. and I worked on a project called redacted. The company is a service-based company where we had to test their domains, subdomains, and acquisitions, which were included within the scope..

Scope:

The scope is an External Blackbox, where we are able to pull multiple domains and subdomains using Google dorks and Crunchbase.

Interesting Functionality

One of the functionalities I found particularly interesting was the Single Sign-On (SSO) across subdomains, also known as Shared Cookie Authentication. This means that once a user logs in on one subdomain, the session remains valid across all other subdomains. This is achieved by setting a shared authentication cookie for the main domain.

Full Account Takeover via Reset Password Functionality

During the assessment, we stumbled upon a subdomain, for example: v.target.com

The target I mentioned above, e.g., v.target.com, has two major functionalities: Login/Single Sign-On and Forget Password functionality.

Well in the start I was looking for the SQL injection on their login pages and Forget password functionality. However, during the first two days, I wasn’t able to identify any interesting vulnerabilities. I always focus on finding vulnerabilities that can be chained together to achieve a critical impact.

The interesting part about the Forgot Password functionality was that it required a valid username. If the username had security features enabled, the user was given two options: either to receive a password reset link or to proceed with answering security questions

By guessing common usernames, I was able to identify valid ones in most cases. Usernames like admin, support, and root were found to be working, The username we identified as support is now blurred because, on the second day, that account was deactivated

Now clicking on continue button it lead to page where we have two options

At that point, I attempted an SQL injection, but it was unsuccessful.

we captured the following POST request that is sent when verifying security questions:

POST /Login/********/VerifySecurityQuestions HTTP/1.1
Host: v.redacted.com
Cookie: ai_user=...; ASP.NET_SessionId=...; TS0179559a=...; <other session tokens>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0
Content-Type: application/json; charset=utf-8
X-Requested-With: XMLHttpRequest
Referer: https://v.redacted.com/login/********/ForgotPassword
Origin: https://v.redacted.com
Connection: keep-alive

{
  "Questions": "1,445:3,4545:2,5454:",
  "UName": "support"
}

Let's first understand the JSON format. For the first answer, the value will be 445; for the third question, it will be 44545; and for the second security question, the value is 5454

Now, after every colon (:) symbol, I tried SQL Injection again, but it was still unsuccessful.

Now, after removing the data for the question, the JSON format looks like this:

{
  "Questions": "",
  "UName": "support"
}

When i forward the request, It redirected me to a page where I was given the option to reset the password.

Now i quickly reset the password and got the notification

After that i quickly login and it redirected me the dashboard

As mentioned earlier in the blog post, Single Sign-On (SSO) across subdomains was enabled, which allowed me to gain access to other subdomains as well, such as q.redacted.com and identity.redacted.com. Interestingly, I was also able to take over their Zendesk account. From there, I conducted further enumeration and was able to find credentials belonging to their employees. We had very limited time, so unfortunately, I missed taking a screenshot.

Remote Code Execution (RCE)

On that day, I shared the above vulnerability with Zeeshan M. The next day, I took a day off from the office, and when I woke up, I received a message: "Hey buddy, got the RCE as well—we can take over the other domains too." Zeeshan also managed to take over the SMTP server as well.

Zeeshan then logged in using the support account on login.redacted.com. During further enumeration, he discovered a subdomain when he clicked on Quality Rule Engine. It opened in a new tab with the subdomain name q.redacted.com.

When we clicked on the Add Measure functionality, we were presented with a file upload option along with multiple input parameters.

As we knew the backend was ASPX, we uploaded an ASPX shell, and in the response, we received the full path to the shell.

Through further enumeration, we discovered that impersonation was enabled. However, we were restricted from performing any further exploitation.

As shown in the image above, virtual hosting is enabled, and we could potentially take over other domains. However, we were restricted and limited by time. Somehow, I was later able to find different subdomains with the same code functionality, where I also discovered remote code execution vulnerabilities.

Key points

Understand the Flow of the Application

• Analyze how the application functions and how different components interact.

Look for Vulnerabilities That Can Be Chained

• Focus on identifying bug classes that can be chained together.

• For example, a SQL Injection vulnerability—depending on the context—could potentially be escalated and chained to achieve Remote Code Execution (RCE).

Final Thoughts

Pen testing isn't just about running tools or guessing payloads—it's about understanding the application inside out.
By taking the time to analyze how components interact and focusing on vulnerabilities that can be chained, you're more likely to uncover critical issues that automated scans might miss.

✅ Don’t just pray and spray—be strategic.
✅ Understand the flow, identify chaining opportunities, and think like an attacker with a plan.

Remember:
Rome wasn’t built in a day.
Deep understanding, persistence, and context-driven testing are what truly lead to impactful findings.