The proliferation of new top-level domains (TLDs) has exacerbated a well-known security weakness: Many organizations set up their internal Microsoft authentication systems years ago using domain names in TLDs that didn’t exist at the time. Meaning, they are continuously sending their Windows usernames and passwords to domain names they do not control and which are freely available for anyone to register. Here’s a look at one security researcher’s efforts to map and shrink the size of this insidious problem.
At issue is a well-known security and privacy threat called “namespace collision,” a situation where domain names intended to be used exclusively on an internal company network end up overlapping with domains that can resolve normally on the open Internet.
Windows computers on a private corporate network validate other things on that network using a Microsoft innovation called Active Directory, which is the umbrella term for a broad range of identity-related services in Windows environments. A core part of the way these things find each other involves a Windows feature called “DNS name devolution,” a kind of network shorthand that makes it easier to find other computers or servers without having to specify a full, legitimate domain name for those resources.
Consider the hypothetical private network internalnetwork.example.com: When an employee on this network wishes to access a shared drive called “drive1,” there’s no need to type “drive1.internalnetwork.example.com” into Windows Explorer; entering “\\drive1\” alone will suffice, and Windows takes care of the rest.
But problems can arise when an organization has built their Active Directory network on top of a domain they don’t own or control. While that may sound like a bonkers way to design a corporate authentication system, keep in mind that many organizations built their networks long before the introduction of hundreds of new top-level domains (TLDs), like .network, .inc, and .llc.
For example, a company in 2005 builds their Microsoft Active Directory service around the domain company.llc, perhaps reasoning that since .llc wasn’t even a routable TLD, the domain would simply fail to resolve if the organization’s Windows computers were ever used outside of its local network.
Alas, in 2018, the .llc TLD was born and began selling domains. From then on, anyone who registered company.llc would be able to passively intercept that organization’s Microsoft Windows credentials, or actively modify those connections in some way — such as redirecting them somewhere malicious.
Philippe Caturegli, founder of the security consultancy Seralys, is one of several researchers seeking to chart the size of the namespace collision problem. As a professional penetration tester, Caturegli has long exploited these collisions to attack specific targets that were paying to have their cyber defenses probed. But over the past year, Caturegli has been gradually mapping this vulnerability across the Internet by looking for clues that appear in self-signed security certificates (e.g. SSL/TLS certs).
Caturegli has been scanning the open Internet for self-signed certificates referencing domains in a variety of TLDs likely to appeal to businesses, including .ad, .associates, .center, .cloud, .consulting, .dev, .digital, .domains, .email, .global, .gmbh, .group, .holdings, .host, .inc, .institute, .international, .it, .llc, .ltd, .management, .ms, .name, .network, .security, .services, .site, .srl, .support, .systems, .tech, .university, .win and .zone, among others.
Seralys found certificates referencing more than 9,000 distinct domains across those TLDs. Their analysis determined many TLDs had far more exposed domains than others, and that about 20 percent of the domains they found ending .ad, .cloud and .group remain unregistered.
“The scale of the issue seems bigger than I initially anticipated,” Caturegli said in an interview with KrebsOnSecurity. “And while doing my research, I have also identified government entities (foreign and domestic), critical infrastructures, etc. that have such misconfigured assets.”
REAL-TIME CRIME
Some of the above-listed TLDs are not new and correspond to country-code TLDs, like .it for Italy, and .ad, the country-code TLD for the tiny nation of Andorra. Caturegli said many organizations no doubt viewed a domain ending in .ad as a convenient shorthand for an internal Active Directory setup, while being unaware or unworried that someone could actually register such a domain and intercept all of their Windows credentials and any unencrypted traffic.
When Caturegli discovered an encryption certificate being actively used for the domain memrtcc.ad, the domain was still available for registration. He then learned the .ad registry requires prospective customers to show a valid trademark for a domain before it can be registered.
Undeterred, Caturegli found a domain registrar that would sell him the domain for $160, and handle the trademark registration for another $500 (on subsequent .ad registrations, he located a company in Andorra that could process the trademark application for half that amount).
Caturegli said that immediately after setting up a DNS server for memrtcc.ad, he began receiving a flood of communications from hundreds of Microsoft Windows computers trying to authenticate to the domain. Each request contained a username and a hashed Windows password, and upon searching the usernames online Caturegli concluded they all belonged to police officers in Memphis, Tenn.
“It looks like all of the police cars there have a laptop in the cars, and they’re all attached to this memrtcc.ad domain that I now own,” Caturegli said, noting wryly that “memrtcc” stands for “Memphis Real-Time Crime Center.”
Caturegli said setting up an email server record for memrtcc.ad caused him to begin receiving automated messages from the police department’s IT help desk, including trouble tickets regarding the city’s Okta authentication system.
Mike Barlow, information security manager for the City of Memphis, confirmed the Memphis Police’s systems were sharing their Microsoft Windows credentials with the domain, and that the city was working with Caturegli to have the domain transferred to them.
“We are working with the Memphis Police Department to at least somewhat mitigate the issue in the meantime,” Barlow said.
Domain administrators have long been encouraged to use .local for internal domain names, because this TLD is reserved for use by local networks and cannot be routed over the open Internet. However, Caturegli said many organizations seem to have missed that memo and gotten things backwards — setting up their internal Active Directory structure around the perfectly routable domain local.ad.
Caturegli said he knows this because he “defensively” registered local.ad, which he said is currently used by multiple large organizations for Active Directory setups — including a European mobile phone provider, and the City of Newcastle in the United Kingdom.
ONE WPAD TO RULE THEM ALL
Caturegli said he has now defensively registered a number of domains ending in .ad, such as internal.ad and schema.ad. But perhaps the most dangerous domain in his stable is wpad.ad. WPAD stands for Web Proxy Auto-Discovery Protocol, which is an ancient, on-by-default feature built into every version of Microsoft Windows that was designed to make it simpler for Windows computers to automatically find and download any proxy settings required by the local network.
Trouble is, any organization that chose a .ad domain they don’t own for their Active Directory setup will have a whole bunch of Microsoft systems constantly trying to reach out to wpad.ad if those machines have proxy automated detection enabled.
Security researchers have been beating up on WPAD for more than two decades now, warning time and again how it can be abused for nefarious ends. At this year’s DEF CON security conference in Las Vegas, for example, a researcher showed what happened after they registered the domain wpad.dk: Immediately after switching on the domain, they received a flood of WPAD requests from Microsoft Windows systems in Denmark that had namespace collisions in their Active Directory environments.
Image: Defcon.org.
For his part, Caturegli set up a server on wpad.ad to resolve and record the Internet address of any Windows systems trying to reach Microsoft Sharepoint servers, and saw that over one week it received more than 140,000 hits from hosts around the world attempting to connect.
The fundamental problem with WPAD is the same with Active Directory: Both are technologies originally designed to be used in closed, static, trusted office environments, and neither was built with today’s mobile devices or workforce in mind.
Probably one big reason organizations with potential namespace collision problems don’t fix them is that rebuilding one’s Active Directory infrastructure around a new domain name can be incredibly disruptive, costly, and risky, while the potential threat is considered comparatively low.
But Caturegli said ransomware gangs and other cybercrime groups could siphon huge volumes of Microsoft Windows credentials from quite a few companies with just a small up-front investment.
“It’s an easy way to gain that initial access without even having to launch an actual attack,” he said. “You just wait for the misconfigured workstation to connect to you and send you their credentials.”
If we ever learn that cybercrime groups are using namespace collisions to launch ransomware attacks, nobody can say they weren’t warned. Mike O’Connor, an early domain name investor who registered a number of choice domains such as bar.com, place.com and television.com, warned loudly and often back in 2013 that then-pending plans to add more than 1,000 new TLDs would massively expand the number of namespace collisions.
Mr. O’Connor’s most famous domain is corp.com, because for several decades he watched in horror as hundreds of thousands of Microsoft PCs continuously blasted his domain with credentials from organizations that had set up their Active Directory environment around the domain corp.com.
It turned out that Microsoft had actually used corp.com as an example of how one might set up Active Directory in some editions of Windows NT. Worse, some of the traffic going to corp.com was coming from Microsoft’s internal networks, indicating some part of Microsoft’s own internal infrastructure was misconfigured. When O’Connor said he was ready to sell corp.com to the highest bidder in 2020, Microsoft agreed to buy the domain for an undisclosed amount.
“I kind of imagine this problem to be something like a town [that] knowingly built a water supply out of lead pipes, or vendors of those projects who knew but didn’t tell their customers,” O’Connor told KrebsOnSecurity. “This is not an inadvertent thing like Y2K where everybody was surprised by what happened. People knew and didn’t care.”
Cool. I remember when I discovered someone registered localhost.com years ago. I wondered if errant traffic went there
Hi Brian,
Very interesting piece, thanks. I never fail to be amazed how many cracks there are in the systems we depend upon to keep our data safe. I very much appreciate you highlighting this as a step to put pressure on the responsible parties to enact proper fixes.
Re “…over one week it received more than 140,000 hits from Sharepoint hosts around the world…”
Were these unique site hits (140k different sites), or many repeated from a smaller number of sites?
Regards,
RW
Thanks. I had to adjust some wordage in there to make it more accurate. These were Windows systems seeking out Sharepoint servers.
The solution to much of this is simple: Make companies pay $10,000 plus any demonstrable additional costs per customer from misconfigurations, leaving databases open on the web, etc.
That would get attention from the suits who constantly demand everything but pay for little from IT. It would also draw attention to employees who do not know their trade.
Additionally, this should apply to firms using contractors, making contractors their agents and the company responsible for their contractors activities and failures.
Yup. Like the .corp shenanigans back int he day, luckily Microsoft ended up purchasing the domain:
https://opensourcesecurity.io/2020/02/24/episode-184-its-dns-its-always-dns/
Episode 184 – It’s DNS. It’s always DNS
Josh and Kurt talk about the sale of the corp.com domain. Is it going to be the end of the world, or a non event? We disagree on what should happen with it. Josh hopes an evildoer buys it, Kurt hopes for Microsoft. We also briefly discuss the CIA owning Crypto AG.
The easy solution to this problem is to set up the hosts file on the client devices. I.e. test.example.com is resolved in /etc/hosts (Linux, I forget where it lives in Windows) as being 127.0.0.1, while example.com is resolved by DNS. It’s a pain to do across an enterprise, but it will work. Or if you are going to another device on the local network, you would add it’s local address to the hosts file. If the printer is at 192.168.0.128, or 10.0.0.17, then you would use printer.example.com in the hosts file, or whatever you wanted, with those addresses defined.
@ Catwisper, Brian, ALL,
Local names can be a real problem in many places, especially when URL’s are “autogenerated” by editing software and the like.
Back at the end of last century I was working for a then very well known company that provided academia, science, enginering, and similar domains with citation databases and search engines.
Well for various reasons it was decided to make a static web presentation to be put on a CD and given away at shows and in response to sales enquires etc.
Well the person originally tasked with the job did not get to finish it as their position changed. The “wrap” got handed to an internal software developer who also built the internal support systems.
Their machine was called by a girls name and nobody thought any more about it.
The problem was that all the URL’s the software autogenerated used the short form of the name not the fully qualified form.
So it tested fine on everyone’s machines within the company, and it got signed off and a lot of CD’s were made.
It was only a day after the first few thousand CD’s had been handed out at a show that messages came in about “adult content not suitable for work” came in…
It turns out that the girls name had been registered by an “adult entertainment” organisation and the way DNS resolved for most people was to that site…
The fix was carried out by the owner of the adult sight, I later found out he thought it was hysterically funny…
So yes “Domain Names” have their problems for the unwary, and you generally only find out there is a lack in your knowledge when you get bitten…
You said “…by the owner of the adult sight…”
Grammatical/syntactical errors aren’t usually funny, but this one is. A “sight” is something you look at, including something remarkable you might stare at, as in “That was quite a sight!”
On the other hand, a place you go to, like a website… or “site”… is what you meant. Or maybe in this case you meant both!
.local is a bad choice for an internal network domain because most clients will treat it specially due to it’s use in Multicast-DNS resolution:
https://www.rfc-editor.org/rfc/rfc6762.html
“This document specifies that the DNS top-level domain “.local.” is a special domain with special semantics, namely that any fully qualified name ending in “.local.” is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addresses in the FE80::/10 prefix, which are link-local and meaningful only on the link where they originate.”
It’s on IANA’s list of Special-Use Domain Names:
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain
They absolutely cared. They cared not to care
I hear that lie repeatee as people nclose their eyes and cover their ears with their hands very frequently when I try to share them that Life is The Most Important Truth and that the Truth of the Importance of Life itself is the cure and prevention of all needless and preventable suffering and death. I mean geewiz. If the very people who are themselves claiming to represent life’s truthful interests choose to lie and not to care about that Most Important information, then why should those tasked with even less care about this?
Excuse me…but do you come with subtitles? Cuz I can’t figure out what your jibber-jabber is all about.
See: https://magnitude.research.icann.org for more top level domain collisions happening in the wild.
Has anyone made an opening up “Andorra’s Box” pun yet? Thanks for illustrating that it’s been this wide open for years. Hopefully it can still be closed in time to protect Hope.
ICANN’s Name Collision Report;
https://www.icann.org/en/system/files/files/ncap-study-2-report-05apr24-en.pdf
and Analysis;
https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-124-01-05-2024-en.pdf
You mention .local as preferred alternative. But that is a problem in itself, as it is reserved for mDNS and should not be used for standard DNS. We’ve been bitten by that when we introduced some Linux computers in our network.
local.arpa or home.arpa is the preferred local address. .arpa is reserved for reverse lookups, and will not be used for any other purpose…
Home.ARPA has been allocated to handle local domains and should be used instead of .local or any other domain that is not publicly registered. See RFC 8375 https://www.rfc-editor.org/rfc/rfc8375.txt
https://www.theregister.com/2024/08/08/dot_internal_ratified/
new update to the standards.
.internal is also reserved for that purpose. that TLD stays off the public DNS forever
“… and neither was built with today’s mobile devices or workforce in mind.”
Kind of like the whole security thing.
SoftwareEngineer July 23, 2024
“It seems to work well, and it’s good we have more top level domains.”
What’s not to love.
Active directory was actually an inferior rip-off of Novell Directory Services; a typical M$ “innovation.”
imho.
Assuming you want to use a public certificate authority, you should use a domain you own for internal DNS. Otherwise, use a TLD that is standardized for private use. That does not include .local, which is used for multicast DNS.
Examples:
.internal for private-use applications
(https://en.wikipedia.org/wiki/.internal)
.home.arpa for non-unique use in residential home networks
(https://datatracker.ietf.org/doc/html/rfc8375.html)
Not sure what rock you are living under if you think Active Directory was a Microsoft ” innovation”. Microsoft AD was a Johnny-come-lately to the directory/X.500 standards. It was basically a clone of Novell Netware, Banyan Vines and Sun’s YP/NIS all of which preceded Microsoft AD by a decade or 2 (in the case of Vines). At best it was iterative, although the fact it was embedded into the world’s most popular desktop O/S is what gave it the leg up to the dominate postion it has today.
Al Gore should have thought about this when he invented the internet.
Yawn. Gee. Mickysoft created problems for itself. Whoop Dee Doo.
“Microsoft authentication systems” – there’s the problem.
When I registered my (now defunct) AD more than 20 years ago, there was advice to own the domain, else why would I have done it as everything was new to me then. Thanks for pointing out that I was not wasting all that money I spent on annual fees!
The large Aerospace company I used to work for required all internal domain names to be purchased and I always kind of wondered why. Now many decades later it seems obvious, when the Domain name was no longer being used and we did not renew the Domain name a Chinese company purchased the name probably hoping they could capture some information.
Domain Registrar ICANN ID:
420
Domain Registrar Name:
HiChina Zhicheng Technology Limited
tooltip
[Total Count:
20,878,998
Buy in
$896 USD]
Domain Registrar Website:
http://www.net.cn
Create Date:
2017-06-22
Updated Date:
2017-09-09
Expiry Date:
2018-06-22
Query Time:
2018-02-23 02:41:36
I’ve owned a domain for about 30 years that could be considered a joke domain name (no, I’m not going to say it here), that admins would occasionally use for their Active Directory domain name.
And I used to run into this all the time, back when I paid attention. Organizations setting up their active directory would choose my domain name as their active directory domain for funsies, and it would leak out all sorts of things at me. I got constant DNS queries for assorted active directory services, authentication requests, IIS traffic and emails for password updates. These differ from the relentless scam hits I would get; they were legit requests from domains set up by idiots.
I’m probably still getting them; it’s just been ages since I’ve checked.
contosi.com or contosi.ad should be “fun.”
O’Connor seemed knowledgeable until he said:
> This is not an inadvertent thing like Y2K where everybody was surprised by what happened. People knew and didn’t care
The Y2K problem was well-understood, with warning flags raised 20+ years before. People absolutely knew what problems would occur — and exactly when they would happen. The only “surprise” was how many waited until the brink of disaster was glaring in their headlights.
If anything, the TLD conflicts would be more inadvertent or surprising, since a small fraction of professionals could understand the risk, let alone justify spending money to fix something that “isn’t causing a problem now”.
20 years ago a large defense contractor (now mercifully defunct) had a name like “Foo Bar Systems”. The external domain was “foobar.com”, but they brilliantly chose “fbs.com” for their internal domain … then three doctors formed a practice and used the first letter of each of their last names for the name of their practice: “FBS” and registered “fbs.com”. Their IT consultant eventually contacted the defense contractor and told them we were leaking their DNS traffic onto the internet for the internal domain. So the firewall was configured to block outbound DNS requests for “*.fbs.com” because it is too painful to rename an Active Directory Server. What if a national adversary had registered this name rather than some random doctors?
Home.ARPA has been allocated to handle local domains and should be used instead of .local or any other domain that is not publicly registered. See RFC 8375 https://www.rfc-editor.org/rfc/rfc8375.txt
This post really resonates with me, especially as someone who has witnessed the impact of security oversights in companies. I have friends who have business and I don’t think all aspect of a business is taken into consideration. The namespace collision issue is a stark reminder of how quickly the digital landscape evolves, leaving many vulnerable. The issue at the Memphis Police Department hits home because they dispatchers and officers collect all sorts of information and that type of information can be damaging in the wrong hands. Thank God for Caturegli’s his discovery shades light on s problem I think a lot of people just don’t think about until you hear about a massive breach in systems. Things like this should be a wake up call to everyone to prioritize security especially when someone else’s sensitive information is in your possession. I would probably give this post a 8/10 because it puts things in prospective.
As someone who is fairly new to the backend of computing. The programs and roots of everything this is pretty scary and eye opening. I remember the big Y2k debacle. Its sad that people KNOW this and still don’t care to set things up correctly.
A bit of ancient history: Back in the early 1980’s, Digital Equipment Corporation, aka DEC, introduced the LPS40 – a “print server,” what we today call a network-attached printer. Impressive for its time – Postscript at 40 pages a minute. Quite expensive.
The LPS40 was intended to be used on an Ethernet for workgroup printing. However, its communication actually used DECnet, which support wide-area networks, such as they were at the time. The DECnet of the day had a flat namespace: A single name that was global to a whole DECnet – like the DECnet that connected all of DEC’s sites and machines. So each LPS40 had to be assigned a name. The installation guide had a step in which you chose your name and told your LPS40 to use it. For “obvious reasons,” the examples used LPS40 as the name.
So … many random DEC sites configured their nice new printers with the name LPS40. The first happened to be a manufacturing plant somewhere in the South, maybe North Carolina. They “won” – their network address was propagated to everyone in the equivalent of a /etc/hosts file. (DECnet in those days had nothing like DNS.) Any new LPS40’s formed no outgoing connections, so didn’t get that file – so had no way to report that the name LPS40 was already taken. But anyone printing to LPS40 actually sent their data off to North Carolina.
While the printer software was designed to work on an Ethernet, it usually worked quite well even talking to the manufacturing plant! The guys there used to look at the random stuff they received to try to figure out where it came from and who to contact about it, which led to some amusing messages as the first test files printed to a new LPS40 were often things like ASCII pictures of nudes. Meanwhile, the guys who’d installed the new LPS40 were trying to figure out why nothing the printed ever appeared….
This whole DNS crap is a real mess! Even M$ (20.70.246.20) can’t figure how to use their protocols. Let’s forget it and just use straight ipv6 addresses instead; we’ll adapt and come to recognize familiar ones in the long run. 🙂