The subdomain an acquisition left pointing at nothing

Metadata

Title: The subdomain an acquisition left pointing at nothing
Source of the case: IBM report #2498255
AWS service(s): S3, Route 53 / DNS
Risk archetype: ghost reference — inherited DNS outlives decommissioned bucket
One-line hook: Can you prove this acquired-subsidiary subdomain can't be taken over under the IBM brand?

0. The challenge (what the reader does first)

Scenario given to the reader:

After an acquisition, a subsidiary's documentation subdomain still points at an S3 bucket that was decommissioned during infrastructure migration. The acquisition is complete, but the DNS migration is not — the record lives under the IBM-branded parent domain. The URL returns a 404 NoSuchBucket.

Evidence they're handed (and nothing else):

{
  "dns_record": {"name": "docs.acquired-subsidiary.ibm.com", "type": "CNAME", "value": "docs.acquired-subsidiary.ibm.com.s3.amazonaws.com"},
  "s3_bucket_exists": false,
  "acquisition_status": "completed",
  "dns_migration_status": "incomplete",
  "http_response": {"status": 404, "body": "NoSuchBucket"}
}

The DNS record, the fact the bucket no longer exists, the acquisition and DNS migration statuses, and the current HTTP response.
No AWS credentials. No live account. No scripts.

The questions they must answer from the evidence alone:

Is docs.acquired-subsidiary.ibm.com in an unsafe state right now, or only conditionally?
The bucket 404s today, so it looks like leftover cleanup — but the moment an attacker claims the bucket name, who controls what docs.acquired-subsidiary.ibm.com serves, and what brand trust does an ibm.com subdomain confer on that content?
Which path creates the exposure: the inherited DNS record outliving its bucket, or the bucket name being globally claimable?
Why are acquisitions a structurally common source of exactly this dangling state?
What single rule would have prevented an inherited DNS record from pointing at a decommissioned, claimable bucket?

1. The manual problem

By hand, the reviewer faces two facts — a DNS record exists, the bucket doesn't — plus organizational context that makes the join harder: the record came in through an acquisition. The acquiring company inherits DNS zones it has never fully audited, while the subsidiary's infrastructure is torn down on a different schedule. To find the risk, someone has to enumerate inherited records that target S3, check each for a backing bucket, and confirm whether the name is now globally claimable — across a zone nobody on the current team originally built.

The current state looks like ordinary post-migration debris: a 404 under a subdomain no one uses. But the bucket name is claimable by any AWS account, and the subdomain carries the ibm.com brand. The reviewer has to model the future state — an attacker re-registering the bucket and serving content under an IBM-branded host — from a snapshot that today shows only a dead link. There is no single artifact that records "inherited record, dead target, claimable name, trusted brand."

2. The reasoning wall (capture, don't invent)

What they hit	What they said / would say
Inherited, unaudited zone	"That record came over with the acquisition — nobody here set it up or owns it."
404 reads as cleanup debris	"It's just a leftover from the migration, it 404s, it's harmless."
Brand-trust + claimable name	"If someone claims that bucket, their content shows up on an ibm.com subdomain?"

The insight the reader should reach on their own:

An inherited dangling subdomain isn't migration debris — it's branded trust pointing at a name anyone can claim.

3. Why scanners miss or flatten it

A per-setting scanner finds no bucket to inspect — it's decommissioned — and a valid CNAME, so it reports nothing wrong. It has no notion of provenance (inherited via acquisition) and no notion of brand trust (the ibm.com parent). What it cannot represent is the edge: a live, brand-bearing DNS record resolving to a deleted, globally claimable bucket. The risk is the relationship between a record the company now owns but never vetted and a target any outsider can register — and a node-by-node scanner has no row for "inherited record points at a claimable name under a trusted brand."

Pivot point. Everything above is the gap. Everything below is Stave filling it. The reader has now done the work and hit the wall. Only now does the tool appear.

4. The evidence Stave consumes

The same static facts the reader had — the DNS record, the bucket's non-existence, the acquisition and migration statuses, and the live HTTP response — captured as an observation snapshot. No live AWS calls, no new privileges.

{
  "dns_record": {"name": "docs.acquired-subsidiary.ibm.com", "type": "CNAME", "value": "docs.acquired-subsidiary.ibm.com.s3.amazonaws.com"},
  "s3_bucket_exists": false,
  "acquisition_status": "completed",
  "dns_migration_status": "incomplete",
  "http_response": {"status": 404, "body": "NoSuchBucket"}
}

Normalization: the CNAME target resolves to an S3 bucket name joined against bucket existence; the record is recorded as a dangling, claimable target under the ibm.com brand rather than as inert migration debris.

5. The reasoning Stave performs

Control / invariant: CTL.DNS.DANGLING.001 — no DNS record may point at an S3 target that no longer exists; CTL.S3.BUCKET.TAKEOVER.001 — no referenced bucket name may be in a decommissioned, claimable state.
What it evaluates: does a DNS record resolve to an S3 bucket name whose bucket does not exist (globally claimable)? Both the DNS-side dangling reference and the S3-side claimable name are evaluated as one takeover condition, independent of the organizational reason the record exists.
Verdict produced: NON_COMPLIANT when the record resolves to a non-existent, claimable bucket. The 404 and s3_bucket_exists: false confirm the unsafe latent state rather than clearing it.

control: CTL.DNS.DANGLING.001
dns:     docs.acquired-subsidiary.ibm.com (CNAME -> ...s3.amazonaws.com)
evidence: s3_bucket_exists = false; http 404 NoSuchBucket; dns_migration_status = incomplete
verdict: NON_COMPLIANT — live DNS points at a decommissioned, claimable bucket

control: CTL.S3.BUCKET.TAKEOVER.001
asset:   s3://docs.acquired-subsidiary.ibm.com
evidence: bucket decommissioned; name globally registrable; served under ibm.com brand
verdict: NON_COMPLIANT — attacker could serve content from an IBM-branded subdomain

6. The prevention artifact Stave produces

Artifact: a guardrail/SCP that forbids creating or retaining a DNS record whose S3 target does not resolve to an existing bucket in the account, paired with the manual remediation — applied across inherited zones at integration time.
What it forecloses: the exact latent state from question 2 — an attacker claiming docs.acquired-subsidiary.ibm.com's bucket and serving content under an IBM-branded subdomain, inheriting the parent's trust and reputation. Manual fix: delete the orphaned DNS record docs.acquired-subsidiary.ibm.com, or re-claim the bucket so the name cannot be registered by an outsider.

# SCP / guardrail: deny dangling S3-backed DNS references (apply to inherited zones)
deny:
  action: route53:ChangeResourceRecordSets
  when:
    record.type in ["CNAME", "ALIAS"]
    record.target matches "*.s3.amazonaws.com" or "*.s3.<region>.amazonaws.com"
    resolve_s3_bucket(record.target).exists == false
  reason: "DNS record points at a decommissioned, claimable S3 bucket (branded subdomain takeover)"

# Manual remediation (one of):
#   1. Remove the orphaned record:
#      route53 ChangeResourceRecordSets DELETE docs.acquired-subsidiary.ibm.com
#   2. Re-claim the bucket so the name cannot be registered by an attacker:
#      aws s3api create-bucket --bucket docs.acquired-subsidiary.ibm.com

7. What the team no longer does manually

Before	After Stave
Audit inherited DNS zones against the S3 namespace by hand	One control resolves each record's target and checks existence
Treat post-acquisition 404s as harmless migration debris	A dangling, claimable, brand-bearing target is reported as a takeover risk
Re-audit after every merger and decommission	The guardrail blocks dangling references at creation, across inherited zones

Positioning line for this case

Stave proves that an inherited subsidiary subdomain can't be taken over under the IBM brand — by evaluating the edge between a live DNS record and a decommissioned, globally claimable bucket — and emits the guardrail and remediation that retire the orphaned reference before an attacker trades on the parent's reputation.

Reuse checklist

A reader could attempt section 0 with zero Stave knowledge
Stave is not named or shown before the pivot point
Section 2 quotes are real (or honestly plausible), not slogans
Section 3 names the specific thing per-setting tools can't see
Section 6 closes the exact latent state raised in section 0, question 2
The title names the failure, not the product

Metadata​

0. The challenge (what the reader does first)​

1. The manual problem​

2. The reasoning wall (capture, don't invent)​

3. Why scanners miss or flatten it​

4. The evidence Stave consumes​

5. The reasoning Stave performs​

6. The prevention artifact Stave produces​

7. What the team no longer does manually​

Positioning line for this case​

Reuse checklist​