Who is accountable when a hijacked subdomain is used for phishing or malware?

Why This Matters for Security Teams

A hijacked subdomain is not just a DNS cleanup issue. Once attackers use it for phishing or malware, the exposure quickly becomes an identity, trust, and lifecycle failure. That makes accountability broader than the security team that detected the abuse. It usually spans the service owner, infrastructure or platform teams, and the governance function responsible for decommissioning controls and certificate or DNS hygiene. NIST’s NIST Cybersecurity Framework 2.0 treats this as a governance and protection problem, not only an incident response task.

The hard part is that subdomains often outlive the applications behind them. Forgotten SaaS records, expired campaigns, abandoned cloud resources, and stale CNAME targets can all leave a valid trust boundary in place after the asset is gone. Attackers exploit that gap because users, mail filters, and even some browser controls still recognize the brand’s domain. Current guidance suggests that ownership must include retirement responsibilities, not just provisioning authority. In practice, many security teams encounter hijacked subdomains only after phishing complaints or malware telemetry have already established abuse at scale, rather than through intentional lifecycle review.

How It Works in Practice

Accountability becomes clearer when the organisation treats subdomain ownership as a lifecycle control with named handoffs. The operational chain usually looks like this: the business team requests the subdomain, the platform or DNS team provisions it, the application or campaign team uses it, and the same or a different team must explicitly retire it. If any step is informal, the trust boundary can remain live after the backend service, cloud bucket, or third-party target has been removed. That is why the most effective programs tie DNS records, certificate inventory, and application ownership together.

For teams managing high-change environments, the right question is not only “who owns DNS?” but “who can prove the target still exists?” A practical control set includes:

• Verified inventory of subdomains, certificate issuances, and backend endpoints
• Mandatory decommission workflow with approval before DNS records are left dangling
• Periodic checks for parked, orphaned, or pointed-to-nothing records
• Explicit escalation paths when a business unit no longer needs a hostname

Attackers often exploit abandoned infrastructure faster than teams expect. Research from NHI Management Group’s Shai Hulud npm malware campaign and DeepSeek breach coverage shows how quickly exposed trust boundaries and secrets become attacker footholds. These controls tend to break down when DNS, cloud, and application ownership are split across different vendors or time zones because no single team can confirm closure end to end.

Common Variations and Edge Cases

Tighter subdomain governance often increases operational overhead, requiring organisations to balance fast campaign delivery against the cost of lifecycle review. That tradeoff is real, especially in marketing, M&A, lab environments, and developer sandboxes where hostnames are created and discarded quickly. Best practice is evolving, but there is no universal standard for this yet: some teams require central approval for every record, while others rely on delegated ownership with automated expiry checks.

There are also edge cases where accountability is shared in unusual ways. A business unit may own the content, a cloud team may own the DNS zone, and a vendor may own the underlying service. If the subdomain points to a retired third-party endpoint, blame alone is less useful than proving which party owned the validation step. A governance function should still be accountable for ensuring the control existed, even if an operations team made the final change.

The safest pattern is to treat any subdomain with a public trust signal as a managed asset until it is explicitly retired, removed, and verified. That includes test hostnames, temporary redirects, and old campaign landing pages. If the organisation cannot prove that a hostname is still backed by an intended service, it should be considered an orphaned trust boundary.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• Who is accountable when stolen tokens are used after a device code phishing incident?
• Who should be accountable when an agent makes a high-risk decision?
• Who is accountable when a production model drifts below approved thresholds?