A Proactive Guide to Preventing Subdomain Hijacking on University Websites

Introduction

In recent findings, security researcher Alex Shakhov revealed that hundreds of subdomains belonging to prestigious universities—including berkeley.edu, columbia.edu, and washu.edu—have been hijacked to serve explicit pornographic content and malicious scam pages. The root cause? Shoddy record-keeping by site administrators. When subdomains are decommissioned, their corresponding CNAME records are often left dangling, allowing scammers (tracked as the Hazy Hawk group) to re-register those records and redirect unsuspecting visitors to harmful sites. This guide provides a step-by-step process to audit, secure, and maintain your university’s DNS records to prevent such hijacking.

What You Need

• Access to your university’s DNS management console (e.g., via your registrar or hosting provider)
• A list of all active and historical subdomains (preferably from a domain inventory tool)
• Basic familiarity with DNS record types (A, CNAME, NS) and zone files
• A tool for DNS scanning (e.g., dig, nslookup, or a commercial solution like Detectify)
• Permissions to modify DNS records (admin-level access)
• Optional: A security information and event management (SIEM) system for monitoring

Step-by-Step Instructions

Step 1: Conduct a Comprehensive DNS Audit

Begin by pulling a full dump of all DNS records associated with your university’s primary domain (e.g., university.edu). Use tools like dig axfr (if zone transfers are allowed) or a third-party scanner to list every subdomain. Pay special attention to CNAME records—these are the ones most often exploited. Note any subdomains that are no longer in use, such as old project sites, temporary experiments, or test environments. Create a spreadsheet with columns for subdomain name, record type, target, and status (active/inactive).

Step 2: Identify Orphaned CNAME Records

Cross-reference your list with the current infrastructure. For each CNAME record, verify whether the target domain is still under your control or still exists. For example, a record like provost.washu.edu that pointed to a decommissioned service may still be present. These are orphaned records. Use nslookup or dig to see where they currently resolve. If they resolve to a third-party domain you don’t own, they’ve likely been hijacked. Flag all such records for immediate removal or remediation.

Step 3: Remove or Update Dangling CNAME Records

For each orphaned CNAME record, decide its fate. If the subdomain is no longer needed, delete the CNAME record entirely from your DNS zone. If you plan to reuse the subdomain in the future, either update the CNAME to point to a placeholder (e.g., a parked page) or replace it with an A record pointing to a server under your control. Do not leave any CNAME record pointing to an external domain you do not own. This is the critical clerical error that scammers exploit.

Step 4: Implement a Subdomain Lifecycle Policy

Create a written policy that governs the creation and decommissioning of subdomains. This policy should require that whenever a subdomain is decommissioned, the responsible administrator must delete the corresponding DNS record(s) within 24 hours. Use a ticket system to track these actions. Enforce this policy with regular audits (e.g., quarterly). This prevents the accumulation of stale records that become hijacking targets.

Step 5: Strengthen DNS Security with DNSSEC

Deploy DNSSEC (Domain Name System Security Extensions) to authenticate DNS responses. While this does not directly prevent hijacking of CNAME records (which are part of your own zone), it adds a layer of integrity checking that can help detect if an adversary attempts to poison your DNS cache. More importantly, ensure that all DNS records are signed and that the signatures are valid. This step raises the bar for attackers.

Step 6: Monitor for Unauthorized Changes

Set up continuous monitoring of your DNS records using tools that alert on new or modified CNAME or A records. Many security information and event management (SIEM) systems can integrate with DNS logs. Alternatively, use a free service like DNS Spy or Detectify. Configure alerts for any subdomain that points to an external domain not in your whitelist. This allows you to catch hijacking attempts in real time.

Step 7: Conduct Regular Penetration Tests

At least once a year, hire or use a DNS vulnerability scanner to simulate the tactics used by Hazy Hawk. The scanner should look for subdomain takeovers, open resolvers, and zone transfer vulnerabilities. Document and fix any issues found. Remember the researcher’s findings: even top universities like Columbia and Berkeley were vulnerable. Regular testing keeps your defenses sharp.

Step 8: Educate Site Administrators

Train everyone who has the ability to create or modify subdomains on the risks of dangling CNAME records. Provide a one-page checklist that includes: always delete records when decommissioning, never point a CNAME to an external domain without a contract, and report any orphaned records immediately. Use real-world examples from the original article to illustrate the consequences.

Tips for Long-Term Success

• Automate where possible: Use scripts to periodically list all CNAME records and cross-check against a known-good inventory. Manual audits are error-prone.
• Use a domain registry with auto‑expiration notices: Some providers alert you when a subdomain’s target domain is about to expire—this can prevent hijacking before it happens.
• Implement a strict subdomain naming policy: Avoid using generic names like “test” or “dev” that are easy targets for enumeration.
• Backup your DNS zone files: If a hijacking occurs, you can quickly restore a clean version.
• Stay informed: Follow security researchers and threat intelligence feeds for new subdomain hijacking techniques. The Hazy Hawk group is one of many.
• Remember the human factor: A single administrator who forgets to delete a CNAME record can compromise an entire domain. Foster a culture of security awareness.

By following these eight steps, your university can eliminate the shoddy housekeeping that makes subdomain hijacking possible. The cost of prevention is far lower than the reputational damage of serving explicit content or scam pages from your official domain.