# 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.](https://www.linkedin.com/in/zeeshanm0x0/) 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`](http://wv.target.com)

The target I mentioned above, e.g., [v.target.com](http://wv.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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748177261655/98b25510-e6a6-43cf-8d6c-697d2d40e2e2.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748177222880/1b409efa-9195-48f0-bdad-86498d53d8f0.png align="center")

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:

```plaintext
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:

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

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748177108322/b15eef3c-f48a-4184-920d-7b8c400def55.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748177013768/d1f976f7-5542-4e35-92c0-b364a5223897.png align="center")

Now i quickly reset the password and got the notification

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748176951509/d337fcf3-03b2-4828-99b3-ec163328854c.png align="center")

After that i quickly login and it redirected me the dashboard

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748177178960/805202ca-e080-447c-9fe5-59d82905dbf1.png align="center")

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`](http://qre.redacted.com) and [`identity.redacted.com`](http://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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748176751434/c471df75-08c8-4869-94a8-e5c8b6669520.png align="center")

### Remote Code Execution (RCE)

On that day, I shared the above vulnerability with [Zeeshan M](https://www.linkedin.com/in/zeeshanm0x0/). 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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748175788151/2f2fe758-d679-41a4-9d1e-e31968fbe0bf.png align="center")

Zeeshan then logged in using the `support` account on [`login.redacted.com`](http://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`](http://qre.redacted.com).

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748175684586/0c3c7bb7-a67a-42b5-b7b3-2ca8ae207d13.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748175650144/c6e53703-0ad0-4957-b577-a58b952a26f8.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748175611044/0310c6e0-d530-42fd-a16b-fe2a11cca4fd.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748175565122/71a6e14c-47b0-4525-ad15-5505b82d25f1.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1748175520634/b34ff155-b433-41f6-9f20-92f66c260888.png align="center")

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.