How I Found a Potential Subdomain Takeover Using Subzy and Cargo Collective

In this short writeup, I share how I hunted for a subdomain takeover vulnerability using Subzy and Cargo Collective.

This writeup is for educational purposes only and aims to help fellow bug bounty hunters understand real-world recon and verification steps.

A subdomain takeover happens when a subdomain points to a third-party service (like GitHub Pages, Heroku, or Cargo Collective) but there’s no valid content or project configured.

If the DNS record remains, attackers can claim the dangling subdomain and host malicious content under a trusted domain name.

- Subzy: for automated subdomain takeover detection

- Dig: for manual DNS verification

- A Cargo Collective test account

Walkthrough

In this case, I started with passive recon to collect potential subdomains for a large target domain.

I used various recon methods, including Shodan, online certificate search, and passive subdomain wordlists.

After gathering a good list of subdomains, I scanned them using **Subzy**, which is an open-source tool for detecting possible subdomain takeover points.

The command I used was:

subzy run --targets target_subdomains.txt --vuln --hide_fails

Subzy flagged two subdomains as potentially vulnerable to takeover — both were pointing to Cargo Collective, a popular third-party site builder that allows custom domains.

To verify the results, I manually checked the DNS records using dig and confirmed that the subdomains had CNAME records pointing to Cargo’s domain.

Next, I created a test account on Cargo Collective and tried adding these subdomains as custom domains in my project settings.

Cargo accepted both domains and showed that they were available for me to bind — but required upgrading to a paid plan to finalize the setup.

This means that the subdomains are still pointing to Cargo Collective, but there is no active project attached — leaving them dangling and at risk of takeover if an attacker decides to pay for the plan.

The entire process took about a few hours, but it helped me practice real recon, verify DNS manually, and understand how dangling third-party records can still appear safe but pose a hidden risk.

In the end, I submitted this finding to the program but it was closed as a duplicate.

Still, the experience helped me improve my recon skills, practice verifying dangling CNAME records, and document a clear PoC with supporting evidence.

✔️ Always verify subdomain takeovers with a working PoC.

✔️ Not all “Vulnerable” flags are real — many have extra protections.

✔️ Subdomain takeovers on third-party services often require a paid plan.

✔️ Duplicate reports are normal — don’t get discouraged!

I hope this case study helps other bug bounty hunters learn how to find and verify potential subdomain takeovers.

If you found this useful, feel free to connect with me on LinkedIn — let’s share knowledge and grow together!

Closing & Connect With Me

Thank you for reading my short case study — I hope it helps you understand how to hunt for potential subdomain takeovers in real bug bounty programs.

If you’d like to connect, discuss more recon techniques, or share hunting ideas, feel free to add me on LinkedIn:

👉 Connect with me on LinkedIn

https://www.linkedin.com/in/venome1x/

Let’s learn, hunt, and grow together!

#BugBounty #SubdomainTakeover #Recon #CyberSecurity