Picture a cyberattack and most people imagine something out of a movie a hooded figure typing furiously, alarms blaring, a firewall finally giving way after some heroic push. That's not really how it goes, most of the time. Attackers rarely bother breaking down the front door. Why would they, when there's a side door standing wide open one the company itself forgot even existed?
That side door is usually a subdomain. Not the main website. Not the app everyone logs into every day. Something smaller and older, a leftover from a campaign that wrapped up two years ago, or a test environment somebody spun up once and never tore down. It's still sitting there. Still resolving. Still technically part of the company's domain. Nobody's looked at it in a long while, and that's kind of the whole problem in one sentence.
I want to walk through why this happens, how attackers actually take advantage of it, and probably more useful what a company can actually do about it before it turns into a headline.
So What Is a Subdomain, and Why Do They Multiply Like This?
At its simplest, a subdomain is a prefix stuck onto a company's main domain: blog.company.com, app.company.com, staging.company.com. Each one can point somewhere completely different a different server, a different vendor, a different platform entirely. That's kind of the whole point of subdomains. They let one company run a dozen different services under a single trusted name.
Here's where it gets messy, though. Take a fairly ordinary mid-sized company. Marketing needs a landing page for a product launch, so someone spins up a subdomain through a third-party site builder done in twenty minutes, nobody thinks twice about it. Engineering wants somewhere to test a new feature before it ships, so a couple more subdomains appear. Sales needs one to hook into the CRM. IT sets one up for the VPN. And somewhere in the mix, there's a subdomain left over from a partnership that ended three years ago, quietly pointing at a vendor's servers that may or may not even exist anymore. None of this is unusual, by the way. It's just what happens when a business runs on cloud tools and moves at a normal, everyday pace.
Setting up a subdomain takes minutes. Retiring one properly that's a different story. It means deleting a DNS record, shutting down whatever cloud resource it pointed to, updating documentation that half the time doesn't even exist to begin with. That's coordination across teams who, frankly, don't always talk to each other much. So subdomains pile up year after year, and cleanup basically never happens on its own. Plenty of companies end up with hundreds of them, sometimes thousands, and security teams often can't say with any confidence what half of them are even for anymore.
It's shadow IT, more or less, except it lives in DNS instead of some employee's personal Dropbox folder. Nobody meant to leave a hole open. It's just what gets left behind after normal business happens, and nobody's actual job is to go clean it up afterward.
The Real Danger: Subdomain Takeover
There's one risk that towers over the rest here, and security people call it subdomain takeover. Sounds like something out of a spy novel. Once you see the mechanics, though, it's almost disappointingly simple annoyingly so, honestly, given how much damage it can do.
When a company points a subdomain at some outside service cloud storage, a hosting platform, a SaaS tool, whatever it might be it usually does this with a DNS record called a CNAME. In plain terms, that record just says: anyone who comes looking for promo.company.com, send them over here, to this address, on this other company's servers.
Now say the campaign ends. The marketing team stops paying for that hosting service, or just deletes the account without giving it a second thought. The CNAME record back home, though? Still there. Still pointing at that same address. promo.company.com is technically alive it resolves fine, DNS wise except there's nobody home on the other end of it anymore.
This is the part that should make people nervous. A lot of hosting and cloud platforms let basically anyone sign up and claim a resource name, as long as it isn't already taken. So if an attacker notices promo.company.com pointing at some now empty resource on one of these platforms, they can just... claim it. Register the exact same name themselves. And that's it, really whatever they put up next is now being served from a URL ending in .company.com, a domain that looks completely trustworthy because it is, technically, the company's own domain.
This isn't some rare edge case dreamed up in a research lab somewhere. It's happened to major brands, government agencies, universities, the whole spectrum. There are entire automated tools built for nothing else but scanning the internet looking for exactly this kind of dangling record. You don't need to be some elite hacker to pull it off, either. You need patience, a couple of free tools, and a target that never got around to cleaning up after itself which, as it turns out, describes an awful lot of targets.
Why This Matters More Than It Sounds Like It Should
Somebody hears "an old subdomain got hijacked" and thinks, okay, so what? It's not the real website. Barely anyone even visits it. Why should anyone care?
Turns out there are several reasons, and they stack on top of each other in a fairly ugly way.
For one, trust gets inherited from the root domain. Browsers trust it. Email filters trust it. Users trust it, mostly without even thinking about it. A phishing link pointing to secure-login.company.com is going to fool a lot more people than one pointing to some random throwaway domain, simply because it genuinely is the company's own domain. Attackers know this. A hijacked subdomain becomes a ready-made stage for phishing pages, fake logins, or malware that looks completely above-board.
Then there's the cookie problem, which is subtler but honestly kind of worse. Depending on how a company's cookies get scoped say, set broadly across .company.com instead of locked to one specific subdomain anything under that root domain might be able to read them. So if an attacker gets control of even one obscure, long-forgotten subdomain, they might be able to grab session cookies meant for the real, main application. That can mean session hijacking. Account takeover, even, without the actual user having done anything wrong at all.
SSL certificates add another wrinkle here too. Certificate authorities generally issue certs based on proof-of-control over the DNS, and if an attacker controls a hijacked subdomain, they can often get a perfectly legitimate, browser-trusted certificate issued for it without much trouble. Visitors see the little padlock icon. Everything looks secure. It just isn't not really. They're talking to the attacker's server the whole time, with a green light telling them everything's fine.
Reputation takes a hit too, and it happens fast. If a hijacked subdomain starts serving malware or running a phishing campaign, the company's name is sitting right there in the URL bar the entire time it's happening. Most people don't stop to ask whether it was "the real site" or some forgotten corner nobody was watching anymore. The brand takes the damage either way.
And there's one more thing worth mentioning it can slide right past a lot of security tooling that would otherwise catch it. Email filters, browser protections, even some antivirus products lean on allowlists built around known, trusted domains. A subdomain riding on a trusted root domain often just walks right past defenses that would normally flag something suspicious, because as far as those tools are concerned, it's a "good" domain. Case closed, nothing to see here.
Add it all up and one overlooked DNS record can turn into a fully functional attack platform, one that looks completely legitimate to everyone except the company that's actually supposed to own it.
It's Not Just Takeover — There's More Lurking Here
Subdomain takeover gets most of the attention, understandably, since it's dramatic and pretty well documented at this point. But it's far from the only thing hiding in a sprawling subdomain footprint.
Development and staging environments are a classic one. Teams throw up subdomains like dev.company.com or staging-v2.company.com to test things before they go live, usually with the unspoken assumption that it doesn't really matter, since it's not production. Except these environments often run real or realistic data, weaker passwords, default credentials nobody bothered changing, verbose error messages that happily leak internal details about how the whole system is built. If one of these is still reachable from the open internet and a surprising number of them are it's a much easier target than the hardened production system sitting right next to it.
Then there are the internal admin panels that somehow end up public. admin.company.com, jenkins.company.com, some monitoring dashboard nobody remembers setting up sitting there, sometimes behind nothing more than a basic login screen, sometimes not even that. These tools were never meant to be internet-facing in the first place. A subdomain got created, a firewall rule got missed somewhere along the way, and now there's a piece of critical infrastructure management sitting one search query away from a total stranger.
There's the reconnaissance angle too, which people tend to underestimate. Even subdomains that aren't directly exploitable still hand attackers useful information what vendors a company uses, what tech stack sits underneath everything, internal naming conventions, hints about products that haven't even launched yet. Mapping out a company's full subdomain list is genuinely one of the first things done in almost every penetration test, and honestly, in a lot of real attacks too. Each subdomain is one more data point. Enough of those and you've got a fairly detailed picture of how a company actually runs, whether they meant to share it or not.
Wildcard certificates deserve a mention as well. Plenty of organizations use a single wildcard cert (*.company.com) to cover everything under their domain, which is convenient, sure. It also means that if that one private key ever leaks, an attacker isn't just able to impersonate one subdomain — they can impersonate any of them, all at once. All that convenience ends up concentrating a lot of risk into a single point of failure.
And finally, there's the vendor angle. Loads of subdomains point straight at services run entirely by outside companies CDNs, marketing tools, support widgets, analytics platforms, take your pick. If nobody's tracking which vendors still have live subdomain configurations, nobody's really tracking whether those vendors are keeping their own house in order either. A vulnerability on the vendor's end can quietly become an entry point into a namespace the original company assumed it still controlled.
A Story That Plays Out More Than You'd Think
It helps to walk through how this actually looks in the wild, because honestly, it's a pattern that repeats constantly, across industries, almost word for word.
Say a retail company runs a summer sale two years back. Their agency builds a landing page through a popular website builder and connects it via summer-sale.retailco.com. The campaign does well. Six weeks later it wraps up, the agency's contract ends around the same time, and nobody thinks to tell IT to pull the DNS record mostly because nobody really thinks of a marketing landing page as "infrastructure" that needs its own formal decommissioning process. It just quietly stops mattering, or seems to.
Fast forward eighteen months. Someone running routine subdomain scans across retail brands (and yes, people genuinely do this at scale, automated, across thousands of targets at once, for fun or profit or both) notices summer-sale.retailco.com still resolves, pointing at a site on that same builder platform that no longer exists. They sign up for a free account, claim that exact site name, and within a few minutes that subdomain is serving whatever they want it to serve.
Maybe they just deface it, to prove they can. Maybe they sit on it quietly, saving it for later. Or worst case, and honestly the most common one they build a convincing fake version of the retailer's customer login page, then launch a phishing run: texts and emails pointing to summer-sale.retailco.com/account-verify, a link that looks completely real because it genuinely is part of the company's actual domain. Email filters wave it right through, because the root domain checks out fine. Customers click it, because why wouldn't they trust their own retailer's domain? Credentials start flowing straight to the attacker, and nobody at the company has the faintest idea, because nobody's been watching that subdomain in well over a year.
This kind of thing isn't rare. It happens across industries constantly, and companies usually only find out once a customer complains, a researcher flags it publicly somewhere, or the abuse gets loud enough to draw attention on its own.
Why Does This Keep Happening?
Worth asking why does a problem this well-documented keep repeating itself, over and over, at companies that presumably have security teams? The answer isn't really technical. It's organizational, mostly.
Ownership tends to be scattered. Marketing creates some subdomains, engineering spins up others, individual teams handle their own projects, and there's rarely one group tasked with keeping a master list of all of it in one place. Security can't defend what it doesn't know exists, and at bigger companies it's completely normal for the security team to only have visibility into a fraction of what actually lives under their own domain.
There's also no natural moment that triggers cleanup. When an office closes, there are obvious signals everywhere keys handed back, the lease ending, furniture getting hauled out the door. A marketing campaign ending doesn't come with any equivalent signal that says go remove this DNS record now. So the subdomain just sits there. Still resolving. Still technically working. Still completely forgotten.
And then there's the gap between DNS and whatever the DNS record actually points to. Different teams manage each piece, often on entirely different platforms, and nobody really owns the full lifecycle from creation to retirement. So nobody notices when the cloud resource disappears on one side while the DNS record just keeps sitting there on the other, pointing at absolutely nothing.
What Actually Fixes This
The encouraging part is that none of this needs exotic tooling or some massive budget increase. Mostly it just takes discipline and a bit of process that a lot of companies simply haven't gotten around to building yet not because it's hard, but because it's never anyone's clear job.
Start with an actual inventory. A real, maintained list of every subdomain tied to the company's root domains, what each one points to, who's responsible for it, why it exists in the first place. A spreadsheet somebody updates once a year isn't going to cut it. This needs to be a living thing, checked regularly, not a document dusted off once during an annual audit and forgotten again immediately after.
Beyond that, ongoing monitoring matters a lot more than periodic sweeps do. There are commercial and open-source tools built specifically for subdomain enumeration, and they can run on a schedule, comparing what exists today against what existed yesterday, flagging anything new or anything that looks like it's dangling pointing somewhere that no longer resolves properly.
Retirement needs to become a real, tracked step, not something left to memory or goodwill. Whenever a project or campaign wraps up, pulling the associated DNS record should be as automatic as revoking someone's access badge or closing out a vendor contract. If it's not on a checklist somewhere, it's probably not going to happen consistently. That's just how these things tend to go.
Internal tools shouldn't be internet-facing at all, if there's any way to avoid it admin panels, dashboards, that sort of thing. Where there's genuinely no way around it, they need real authentication behind them, ideally sitting behind a VPN or some zero-trust layer, rather than leaning on an obscure subdomain name as the only real barrier. Obscurity isn't a security control, no matter how convenient it feels in the moment.
Cookie scope matters too, and it's an easy one to fix once someone actually looks at it. Rather than defaulting to broad, root-domain-wide cookies, it's worth scoping authentication tokens as narrowly as possible, so a compromised subdomain somewhere doesn't automatically hand over access to the main application.
Vendor-facing subdomains deserve periodic review as well checking that the underlying account or service is still active, still owned, still actually needed by anyone. When a vendor relationship ends, cleaning up the DNS records tied to it should be part of that offboarding, not an afterthought nobody remembers six months down the line.
And subdomain enumeration ought to be standard practice in security testing, not some optional extra tacked on at the end. Penetration tests and red team exercises should include it by default. It's a relatively cheap check, honestly, given how much risk it addresses.
None of this asks a company to rebuild its entire security program from the ground up. Mostly it just asks for an acceptance that DNS hygiene is an ongoing job not a box checked once during setup and then forgotten about forever after.
Rethinking What "Attack Surface" Really Covers
Part of the reason this stuff slips through is that a lot of organizations still think about attack surface pretty narrowly the main site, the core app, maybe the VPN and email system. But attack surface, in reality, is everything that's reachable. Everything that resolves. Everything an outsider could possibly poke at, whether or not anyone inside the company still thinks of it as important.
A dusty subdomain from a marketing push nobody remembers doesn't register as "real infrastructure" to most people inside a company. But to someone running automated scans across thousands of domains at once, it looks exactly like what it is: a trusted name attached to an open door that nobody's watching. That gap between how a company sees its own risk and how an attacker actually sizes up opportunity is basically the whole reason this attack surface stays so underdefended, year after year, at company after company.
The fix isn't complicated, even if it does require a bit of a mindset shift. Every subdomain a company creates is a small ongoing responsibility, something that needs tracking from the moment it's built all the way to the moment it's deliberately taken down. Treating DNS records with the same seriousness given to servers, credentials, and access permissions closes a lot of this gap without a whole lot of extra effort.
Final Thoughts
Subdomains are quick to create and easy to forget, and that combination is exactly what makes them such a tempting target. They borrow all the trust of the main domain while usually getting none of the scrutiny that the actual website or core product receives. An attacker doesn't need some clever zero-day exploit when a company has simply left an old DNS record pointing at nothing just sitting there, waiting for someone to notice it and claim it as their own.
The companies that handle this well aren't necessarily the ones spending the most money on security tools. They're the ones that accepted a pretty basic idea early on: every subdomain is a real asset, with a real owner, and a real lifecycle that has to end deliberately, not by accident. Whatever gets left hanging in between creation and retirement is usually exactly where the next incident quietly gets its start.