exploiting-broken-link-hijacking

name	exploiting-broken-link-hijacking
description	Discover and exploit broken link hijacking vulnerabilities by identifying references to expired domains, decommissioned cloud resources, and dead external services that can be claimed by an attacker.
domain	cybersecurity
subdomain	web-application-security
tags	["broken-link-hijacking","blh","subdomain-takeover","dead-link","expired-domain","supply-chain","external-resource"]
version	1.0
author	mahipal
license	Apache-2.0
nist_csf	["PR.PS-01","ID.RA-01","PR.DS-10","DE.CM-01"]

Exploiting Broken Link Hijacking

When to Use

• When auditing web applications for references to expired or unclaimed external resources
• During supply chain security assessments of third-party script and resource dependencies
• When testing for subdomain takeover opportunities via dangling CNAME records
• During bug bounty hunting for broken link hijacking vulnerabilities
• When assessing the security of external resource dependencies in production applications

How to CONFIRM a Hit (avoid false negatives)

• Positive signal: the broken/dead reference points to a resource you can actually claim (expired domain registrable, deleted S3 bucket recreatable, unclaimed GitHub Pages/social handle) AND, once claimed, your content is served where the target loads it — confirm with a benign canary.
• A 404/000 on a linked resource is a candidate, not a confirmed hijack — the domain or namespace must be genuinely available to register/claim.
• Do NOT conclude "vulnerable" until you have:
  • Confirmed the referenced domain/namespace is registrable (whois "no match"/available) or the cloud resource is recreatable, not merely returning an error while still owned.
  • Matched the service-specific fingerprint for takeover-style links (NoSuchBucket, GitHub Pages, Heroku "No such app", Azure container missing) instead of trusting status code alone.
  • Identified the resource type and its impact: a hijackable <script src> = full XSS on every page that loads it; a dead image/CSS = lower impact — confirm which sink it is.
  • Checked historical references (Wayback) and JS/CSS includes, not just visible anchor links, since the highest-impact dead refs are often in source/headers.
  • Where impactful, performed the canary claim and verified the target actually fetches your hosted marker, then cleaned up.

Prerequisites

• Web crawler or spider for discovering all external links (Burp Suite Spider, Scrapy)
• DNS lookup tools for checking CNAME records and domain availability
• Domain registrar access for claiming expired domains (as proof of concept)
• Understanding of CDN and cloud service provisioning (S3, Azure Blob, GitHub Pages)
• blc (broken-link-checker) or similar tool for automated link validation
• Knowledge of services vulnerable to subdomain takeover (can-i-take-over-xyz)