Introduction

Last year, I received an invitation to a private bug bounty program on the HackerOne platform. Since I had some free time, I decided to give it a shot. This is the story of how I leveraged an out-of-scope domain to earn a $1250 bounty.

Understanding Out-of-Scope Domains

Note: In this write-up, “out-of-scope” refers to out-of-scope domains, not vulnerabilities.

Bug bounty programs define out-of-scope domains for multiple reasons, such as:

  • The security team is aware of vulnerabilities in these domains and is working on fixing them before including them in scope.
  • The bounty program has a limited budget and cannot cover all domains.
  • The domains are intended for end-users, and any security testing could negatively impact them.

However, out-of-scope domains can still be used for escalation in in-scope attacks. Many bug bounty reports have demonstrated successful exploits by chaining vulnerabilities from out-of-scope to in-scope domains. Some programs even accept RCE reports on out-of-scope domains (e.g., Mail.ru’s bug bounty program).

Reconnaissance and Discovery

During my recon, I discovered a subdomain running AnswerHub. Coincidentally, I had previously found a stored XSS vulnerability in AnswerHub. Since I had already documented this issue in my past reports, I won’t go into full details here. You can read about similar findings in my previous write-ups:

Finding an Out-of-Scope Subdomain

After checking the bug bounty rules, I used Sublist3r to enumerate subdomains. I found:

answers.target.com

This subdomain was running AnswerHub and was vulnerable to the stored XSS I had previously discovered. However, it was not listed as an in-scope domain in the program rules.

I decided not to report it immediately but instead, continued searching for in-scope vulnerabilities that could be combined with this issue.

Exploiting Same-Origin Policy (SOP) Misconfiguration

I then shifted focus to an Angular app hosted on:

developer.market.target.com

I was testing JavaScript tricks when I discovered something interesting in the browser console:

>> document.domain
>> "target.com"

Understanding the Security Issue

The source code of developer.market.target.com included the following script:

document.domain = "target.com";

This overrides the default Same-Origin Policy (SOP), allowing subdomains under target.com to interact with each other.

This meant that if I could execute JavaScript on answers.target.com, I could manipulate developer.market.target.com, which was in-scope!

Bypassing X-Frame-Options

To exploit this, I needed to embed developer.market.target.com inside an <iframe>. However, it had the X-Frame-Options: DENY header, preventing framing.

After further testing, I discovered that the /support/ path did not enforce X-Frame-Options—meaning I could frame it!

The Proof of Concept (PoC)

I created a malicious XML file and uploaded it to answers.target.com.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>PoC</title>
        <script type="text/javascript">
             document.domain = 'target.com';
             function exploit() {
             var i = document.getElementById("my_frame");
             var exp = i.contentWindow.document.getElementsByClassName('ng-binding')[3].innerText;
             alert(exp);
             }
        </script>   
    </head>
  <iframe src="https://developer.market.target.com/support/" id="my_frame" onload="exploit();"></iframe>
    </body>
</html>

Exploit Validation

After uploading the PoC file to answers.target.com, I confirmed that it executed JavaScript on developer.market.target.com—an in-scope domain.

    wp

Steps to Reproduce:

  1. Go to https://answers.target.com, open any question, and click “Reply.”
  2. Upload poc.xml as an attachment and intercept the request.
  3. Modify Content-Type from text/plain to text/xml and forward the request.
  4. Visit the attachment URL. The exploit executes, displaying an alert box containing your username.

Reporting and Bounty

I submitted the PoC report to the bug bounty program. The security team responded quickly and awarded me $1250 for what was essentially an XSS attack!

    wp

Remediation

The security team fixed the issue by:

  • Applying a strict X-Frame-Options header across all subdomains.
  • Updating their CSP (Content Security Policy).
  • Patching the AnswerHub vulnerability so XML files could no longer be executed.

Conclusion

This case highlights how out-of-scope domains can still be useful in bug bounty programs. By thinking outside the box, you can:

  • Chain vulnerabilities across domains.
  • Bypass security policies using JavaScript tricks.
  • Leverage misconfigurations for greater impact.

I hope you enjoyed this write-up and learned something valuable!

If you found this interesting, feel free to retweet and follow me on Twitter @Abdulahhusam.