MasterCard DNS Error Went Unnoticed for Years

The payment card giant MasterCard just fixed a glaring error in its domain name server settings that could have allowed anyone to intercept or divert Internet traffic for the company by registering an unused domain name. The misconfiguration persisted for nearly five years until a security researcher spent $300 to register the domain and prevent it from being grabbed by cybercriminals.

From June 30, 2020 until January 14, 2025, one of the core Internet servers that MasterCard uses to direct traffic for portions of the mastercard.com network was misnamed. MasterCard.com relies on five shared Domain Name System (DNS) servers at the Internet infrastructure provider Akamai [DNS acts as a kind of Internet phone book, by translating website names to numeric Internet addresses that are easier for computers to manage].

All of the Akamai DNS server names that MasterCard uses are supposed to end in “akam.net” but one of them was misconfigured to rely on the domain “akam.ne.”

This tiny but potentially critical typo was discovered recently by Philippe Caturegli, founder of the security consultancy Seralys. Caturegli said he guessed that nobody had yet registered the domain akam.ne, which is under the purview of the top-level domain authority for the West Africa nation of Niger.

Caturegli said it took $300 and nearly three months of waiting to secure the domain with the registry in Niger. After enabling a DNS server on akam.ne, he noticed hundreds of thousands of DNS requests hitting his server each day from locations around the globe. Apparently, MasterCard wasn’t the only organization that had fat-fingered a DNS entry to include “akam.ne,” but they were by far the largest.

Had he enabled an email server on his new domain akam.ne, Caturegli likely would have received wayward emails directed toward mastercard.com or other affected domains. If he’d abused his access, he probably could have obtained website encryption certificates (SSL/TLS certs) that were authorized to accept and relay web traffic for affected websites. He may even have been able to passively receive Microsoft Windows authentication credentials from employee computers at affected companies.

But the researcher said he didn’t attempt to do any of that. Instead, he alerted MasterCard that the domain was theirs if they wanted it, copying this author on his notifications. A few hours later, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations.

“We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote. “This typo has now been corrected.”

Meanwhile, Caturegli received a request submitted through Bugcrowd, a program that offers financial rewards and recognition to security researchers who find flaws and work privately with the affected vendor to fix them. The message suggested his public disclosure of the MasterCard DNS error via a post on LinkedIn (after he’d secured the akam.ne domain) was not aligned with ethical security practices, and passed on a request from MasterCard to have the post removed.

Caturegli said while he does have an account on Bugcrowd, he has never submitted anything through the Bugcrowd program, and that he reported this issue directly to MasterCard.

“I did not disclose this issue through Bugcrowd,” Caturegli wrote in reply. “Before making any public disclosure, I ensured that the affected domain was registered to prevent exploitation, mitigating any risk to MasterCard or its customers. This action, which we took at our own expense, demonstrates our commitment to ethical security practices and responsible disclosure.”

Most organizations have at least two authoritative domain name servers, but some handle so many DNS requests that they need to spread the load over additional DNS server domains. In MasterCard’s case, that number is five, so it stands to reason that if an attacker managed to seize control over just one of those domains they would only be able to see about one-fifth of the overall DNS requests coming in.

But Caturegli said the reality is that many Internet users are relying at least to some degree on public traffic forwarders or DNS resolvers like Cloudflare and Google.

“So all we need is for one of these resolvers to query our name server and cache the result,” Caturegli said. By setting their DNS server records with a long TTL or “Time To Live” — a setting that can adjust the lifespan of data packets on a network — an attacker’s poisoned instructions for the target domain can be propagated by large cloud providers.

“With a long TTL, we may reroute a LOT more than just 1/5 of the traffic,” he said.

The researcher said he’d hoped that the credit card giant might thank him, or at least offer to cover the cost of buying the domain.

“We obviously disagree with this assessment,” Caturegli wrote in a follow-up post on LinkedIn regarding MasterCard’s public statement. “But we’ll let you judge— here are some of the DNS lookups we recorded before reporting the issue.”

As the screenshot above shows, the misconfigured DNS server Caturegli found involved the MasterCard subdomain az.mastercard.com. It is not clear exactly how this subdomain is used by MasterCard, however their naming conventions suggest the domains correspond to production servers at Microsoft’s Azure cloud service. Caturegli said the domains all resolve to Internet addresses at Microsoft.

“Don’t be like Mastercard,” Caturegli concluded in his LinkedIn post. “Don’t dismiss risk, and don’t let your marketing team handle security disclosures.”

One final note: The domain akam.ne has been registered previously — in December 2016 by someone using the email address um-i-delo@yandex.ru. The Russian search giant Yandex reports this user account belongs to an “Ivan I.” from Moscow. Passive DNS records from DomainTools.com show that between 2016 and 2018 the domain was connected to an Internet server in Germany, and that the domain was left to expire in 2018.

This is interesting given a comment on Caturegli’s LinkedIn post from an ex-Cloudflare employee who linked to a report he co-authored on a similar typo domain apparently registered in 2017 for organizations that may have mistyped their AWS DNS server as “awsdns-06.ne” instead of “awsdns-06.net.” DomainTools reports that this typo domain also was registered to a Yandex user (playlotto@yandex.ru), and was hosted at the same German ISP — Team Internet (AS61969).

Local Networks Go Global When Domain Names Collide

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.

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.”