Hacking In-Scope Targets via Out-of-Scope Domains
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.
Steps to Reproduce:
- Go to
https://answers.target.com
, open any question, and click “Reply.” - Upload
poc.xml
as an attachment and intercept the request. - Modify
Content-Type
fromtext/plain
totext/xml
and forward the request. - 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!
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.