The Subdomain Enumeration Saga

Management wanted to know all assets under megacorp.example. We found 847 subdomains and one spectacular security oversight.

The Mandate

At 09:47 on a Tuesday, the email arrived from Director Henderson, Subject: "Asset Inventory Request - URGENT - Compliance Deadline." The body text was three paragraphs of corporate speak that translated to: "List everything under megacorp.example by Friday for the auditors."

I documented the timestamp. This would be educational.

The domain megacorp.example had been accumulating subdomains since 2019. Developers created them. Marketing campaigns spawned them. Contractors left them running after projects ended. Nobody tracked them. Until compliance needed a spreadsheet.

According to the request, this was "simple DNS enumeration." According to reality, this was archaeology.

The Archaeological Expedition

I assembled the toolkit: subfinder, amass, dnsenum, and a custom bash one-liner I'd been refining since the TTY asked "can't we just check DNS?" three months ago.

The TTY watched with growing concern as I launched the first scan.

TTY: "How many subdomains do you think there are?"

OPERATOR: "Management expects twenty, maybe thirty. Reality expects more."

Subfinder ran first. Passive reconnaissance, pulling from certificate transparency logs, search engines, APIs. Clean. Professional. Produced 127 results in forty seconds.

The TTY looked relieved.

OPERATOR: "We're not done."

Amass came next. Active and passive enumeration, DNS zone transfers (optimistically attempted), brute forcing with wordlists. The TTY discovered that wordlists have... opinions about what constitutes a reasonable subdomain name.

TTY: "Why is 'test-api-backup-old-final-FINAL-v2' in the wordlist?"

OPERATOR: "Because developers. Also, check the results."

test-api-backup-old-final-FINAL-v2.megacorp.example existed. Naturally.

Dnsenum added another layer, methodically walking the DNS infrastructure like a systematic audit. The subdomain count climbed: 200. 350. 500.

TTY: "How is this possible?"

OPERATOR: "Six years of developer enthusiasm and zero decommissioning process. Now watch this."

I deployed the custom bash one-liner. A beautiful monstrosity combining dig, awk, parallel processing, and what the TTY later described as "forbidden shell scripting techniques."

for prefix in $(cat /usr/share/wordlists/subdomains.txt); do dig +short $prefix.megacorp.example @192.0.2.53 | grep -v '^$' && echo "$prefix.megacorp.example"; done | parallel -j 50 'host {} 2>/dev/null | grep -v "not found"' | awk '{print $1}' | sort -u

The TTY stared at the screen as results streamed past.

TTY: "Is that... legal?"

OPERATOR: "It's DNS queries. Very enthusiastic DNS queries."

The final count: 847 subdomains.

The Discovery

I began categorizing. Production systems: 47. Development environments: 213. Staging servers: 89. Systems categorized as "unknown purpose": 498.

That last category required investigation.

The TTY suggested we "just check them all manually."

"I'll handle the automation," I said. "You document findings."

I wrote a quick script to probe each subdomain for HTTP/HTTPS services, check response codes, identify technologies. Standard reconnaissance. Entirely against fictional infrastructure. Purely educational.

The results were... revealing.

• old-wordpress-backup.megacorp.example: WordPress 3.8 (deprecated in 2014)
• jenkins-temp.megacorp.example: Jenkins with default credentials
• prototype-db.megacorp.example: MongoDB with no authentication
• test-api.megacorp.example: RESTful API, no authentication, complete access to user data

The TTY read the results.

TTY: "That last one seems concerning."

OPERATOR: "Concerning. Also classic."

I probed test-api.megacorp.example further. Clean API design. Good documentation at /api/docs. Beautiful architecture. Zero authentication on any endpoint. GET /api/users returned everything. POST /api/admin/settings worked perfectly.

TTY: "Should we... tell someone?"

OPERATOR: "We're creating the asset inventory for exactly this purpose. Management wanted to know what assets exist. We're documenting thoroughly."

The Report

I compiled the findings into a spreadsheet. Management requested simple DNS records. I provided a comprehensive security assessment.

Tab 1: Summary

• Total subdomains: 847
• Active HTTP services: 312
• Security concerns: 47 (critical: 12, high: 35)

Tab 2: Critical Findings
Each entry included subdomain, service type, vulnerability description, business impact, and remediation steps. I was particularly detailed about test-api.megacorp.example.

Tab 3: Complete Subdomain List
All 847 entries, alphabetically sorted, with IP addresses and service fingerprints.

Tab 4: Recommended Actions
A prioritized decommissioning schedule for 498 systems of "unknown purpose."

I sent the report at 16:45 on Tuesday. Three days early. With appendices.

Director Henderson replied seventeen minutes later: "This is more comprehensive than expected. Can we schedule a meeting?"

The meeting revealed that management expected a simple list. They received a security audit. The compliance team was thrilled. The development team was less thrilled. test-api.megacorp.example was decommissioned by Thursday.

The TTY learned about subdomain enumeration, passive reconnaissance, and why test environments need authentication.

I learned that management's "simple requests" are opportunities for strategic over-compliance.

The Operator's Notes

The asset inventory is now documented, maintained, and scheduled for quarterly review. The TTY suggested we "automate the whole thing." We did. The script runs weekly. Management receives reports they didn't know they needed.

test-api.megacorp.example served its final purpose: teaching the development team about proper decommissioning procedures and authentication requirements. The Jenkins instance is next.

847 subdomains discovered. 63 already decommissioned. Coffee consumed: significant. The art of thoroughness: documented for posterity.

Such is compliance.