How Neglected Subdomain Records Turn Prestigious University Websites into Porn Hubs

Overview

In a disturbing twist of digital housekeeping, some of the world's most respected universities—including UC Berkeley, Columbia, and Washington University in St. Louis—have had their official domains serve explicit pornography and malicious content. This happens not because their main sites were hacked, but because scammers exploited forgotten DNS records left behind after subdomains were decommissioned. Researcher Alex Shakhov discovered that hundreds of subdomains across at least 34 universities have been hijacked by a group known as Hazy Hawk. The attackers seize on CNAME records that were never removed, redirecting old subdomains to their own servers. This tutorial explains the vulnerability, how it works, and most importantly, how you can prevent it on your own domains.

Prerequisites

Before diving into the technical details, you should have a basic understanding of the Domain Name System (DNS), especially record types like A, CNAME, and NS. Familiarity with using command-line tools such as dig or nslookup will help. You'll also need access to your domain's DNS management console (e.g., through your registrar or hosting provider) and permission to modify records. No advanced programming skills are required, but a working knowledge of web hosting and subdomain management is beneficial.

Step-by-Step Instructions: Preventing and Remediating Subdomain Hijacking

Step 1: Audit Your Existing Subdomains

The first line of defense is knowing what subdomains exist under your main domain. Use dig or an online tool like SecurityTrails to enumerate subdomains. For a quick manual check, try:

dig +short any yourdomain.com

This lists all common DNS records. However, it may not reveal all subdomains. For a thorough audit, use an Active Directory or zone transfer (if allowed) or a subdomain brute‐forcing tool like subfinder. Create a spreadsheet of every subdomain, its purpose, and the date it was last used.

Step 2: Identify Stale CNAME Records

Once you have your subdomain list, check each one's DNS record type. Pay special attention to CNAME records, which point a subdomain to another domain (a canonical name). If a subdomain was set up for a third‐party service (e.g., app.youruniversity.edu -> serviceprovider.com), and that service is no longer used, the CNAME record might remain. Use dig for each subdomain:

dig +short subdomain.yourdomain.com CNAME

If the output shows a domain that you no longer control or that no longer resolves, that subdomain is vulnerable. The attacker simply registers the target domain (if expired) and sets it up to serve their content.

Step 3: Remove or Update Vulnerable Records

For every stale CNAME record, you have two options: delete it entirely, or change it to point to a place you control (e.g., a landing page on your own server). The safest approach is deletion. In your DNS console, remove the CNAME record. If the subdomain itself is no longer needed, consider deleting the entire subdomain entry. For subdomains that still serve a purpose but use a third‐party provider, verify that the provider's domain is still valid and controlled by them. If the provider has gone out of business, migrate the subdomain to a new service immediately.

Step 4: Monitor for New Hijacks

Attackers like Hazy Hawk constantly scan for abandoned records. Set up automated monitoring with tools like dnstwist or use a commercial DNS audit service. Schedule weekly scans of all your subdomains, looking for unexpected changes. You can also enable DNS logging to track queries for old subdomains—sudden spikes often indicate probing by attackers.

Step 5: Implement a Subdomain Governance Policy

Prevent future occurrences by instituting a formal policy. When a new subdomain is created, assign an owner and a review date. Use a ticketing system to track decommission requests and ensure DNS records are removed promptly. Train your IT team on the risks of DNS litter.

Common Mistakes

• Forgetting about test/development subdomains: Developers often spin up subdomains for staging or testing and never clean up. Attackers love these because they are rarely monitored.
• Assuming third‐party services will last forever: Even large vendors can pivot or go bankrupt. Always have a fallback plan for CNAME records pointing to external services.
• Relying solely on DNS expiration dates: A CNAME record itself doesn't expire; the target domain does. Check the target's registration status regularly.
• Ignoring subdomain wildcards: A wildcard record (*.yourdomain.com) can magnify the risk—if one subdomain is hijacked, the wildcard might redirect many more.
• Not verifying after deletion: Removing a record from your console does not guarantee propagation. Use a public DNS checker to confirm the record is gone globally.

Summary

The scandal of top university websites serving porn is a stark lesson in digital hygiene. Attackers exploit simple oversight: abandoned CNAME records that point to defunct domains. By auditing your subdomains, removing stale records, and implementing ongoing monitoring, you can prevent your own domains from becoming vectors for malicious content. A little housekeeping goes a long way in maintaining your organization's reputation and security.