18 Popular Code Packages Hacked, Rigged to Steal Crypto

At least 18 popular JavaScript code packages that are collectively downloaded more than two billion times each week were briefly compromised with malicious software today, after a developer involved in maintaining the projects was phished. The attack appears to have been quickly contained and was narrowly focused on stealing cryptocurrency. But experts warn that a similar attack with a slightly more nefarious payload could lead to a disruptive malware outbreak that is far more difficult to detect and restrain.

Aikido is a security firm in Belgium that monitors new code updates to major open-source code repositories, scanning any code updates for suspicious and malicious code. In a blog post published today, Aikido said its systems found malicious code had been added to at least 18 widely-used code libraries available on NPM (short for) “Node Package Manager,” which acts as a central hub for JavaScript development and the latest updates to widely-used JavaScript components.

JavaScript is a powerful web-based scripting language used by countless websites to build a more interactive experience with users, such as entering data into a form. But there’s no need for each website developer to build a program from scratch for entering data into a form when they can just reuse already existing packages of code at NPM that are specifically designed for that purpose.

Unfortunately, if cybercriminals manage to phish NPM credentials from developers, they can introduce malicious code that allows attackers to fundamentally control what people see in their web browser when they visit a website that uses one of the affected code libraries.

According to Aikido, the attackers injected a piece of code that silently intercepts cryptocurrency activity in the browser, “manipulates wallet interactions, and rewrites payment destinations so that funds and approvals are redirected to attacker-controlled accounts without any obvious signs to the user.”

“This malware is essentially a browser-based interceptor that hijacks both network traffic and application APIs,” Aikido researcher Charlie Eriksen wrote. “What makes it dangerous is that it operates at multiple layers: Altering content shown on websites, tampering with API calls, and manipulating what users’ apps believe they are signing. Even if the interface looks correct, the underlying transaction can be redirected in the background.”

Aikido said it used the social network Bsky to notify the affected developer, Josh Junon, who quickly replied that he was aware of having just been phished. The phishing email that Junon fell for was part of a larger campaign that spoofed NPM and told recipients they were required to update their two-factor authentication (2FA) credentials. The phishing site mimicked NPM’s login page, and intercepted Junon’s credentials and 2FA token. Once logged in, the phishers then changed the email address on file for Junon’s NPM account, temporarily locking him out.

Junon also issued a mea culpa on HackerNews, telling the community’s coder-heavy readership, “Hi, yep I got pwned.”

“It looks and feels a bit like a targeted attack,” Junon wrote. “Sorry everyone, very embarrassing.”

Philippe Caturegli, “chief hacking officer” at the security consultancy Seralys, observed that the attackers appear to have registered their spoofed website — npmjs[.]help — just two days before sending the phishing email. The spoofed website used services from dnsexit[.]com, a “dynamic DNS” company that also offers “100% free” domain names that can instantly be pointed at any IP address controlled by the user.

Caturegli said it’s remarkable that the attackers in this case were not more ambitious or malicious with their code modifications.

“The crazy part is they compromised billions of websites and apps just to target a couple of cryptocurrency things,” he said. “This was a supply chain attack, and it could easily have been something much worse than crypto harvesting.”

Akito’s Eriksen agreed, saying countless websites dodged a bullet because this incident was handled in a matter of hours. As an example of how these supply-chain attacks can escalate quickly, Eriksen pointed to another compromise of an NPM developer in late August that added malware to “nx,” an open-source code development toolkit with as many as six million weekly downloads.

In the nx compromise, the attackers introduced code that scoured the user’s device for authentication tokens from programmer destinations like GitHub and NPM, as well as SSH and API keys. But instead of sending those stolen credentials to a central server controlled by the attackers, the malicious code created a new public repository in the victim’s GitHub account, and published the stolen data there for all the world to see and download.

Eriksen said coding platforms like GitHub and NPM should be doing more to ensure that any new code commits for broadly-used packages require a higher level of attestation that confirms the code in question was in fact submitted by the person who owns the account, and not just by that person’s account.

“More popular packages should require attestation that it came through trusted provenance and not just randomly from some location on the Internet,” Eriksen said. “Where does the package get uploaded from, by GitHub in response to a new pull request into the main branch, or somewhere else? In this case, they didn’t compromise the target’s GitHub account. They didn’t touch that. They just uploaded a modified version that didn’t come where it’s expected to come from.”

Eriksen said code repository compromises can be devastating for developers, many of whom end up abandoning their projects entirely after such an incident.

“It’s unfortunate because one thing we’ve seen is people have their projects get compromised and they say, ‘You know what, I don’t have the energy for this and I’m just going to deprecate the whole package,'” Eriksen said.

Kevin Beaumont, a frequently quoted security expert who writes about security incidents at the blog doublepulsar.com, has been following this story closely today in frequent updates to his account on Mastodon. Beaumont said the incident is a reminder that much of the planet still depends on code that is ultimately maintained by an exceedingly small number of people who are mostly overburdened and under-resourced.

“For about the past 15 years every business has been developing apps by pulling in 178 interconnected libraries written by 24 people in a shed in Skegness,” Beaumont wrote on Mastodon. “For about the past 2 years orgs have been buying AI vibe coding tools, where some exec screams ‘make online shop’ into a computer and 389 libraries are added and an app is farted out. The output = if you want to own the world’s companies, just phish one guy in Skegness.”

Aikido recently launched a product that aims to help development teams ensure that every code library used is checked for malware before it can be used or installed. Nicholas Weaver, a researcher with the International Computer Science Institute, a nonprofit in Berkeley, Calif., said Aikido’s new offering exists because many organizations are still one successful phishing attack away from a supply-chain nightmare.

Weaver said these types of supply-chain compromises will continue as long as people responsible for maintaining widely-used code continue to rely on phishable forms of 2FA.

“NPM should only support phish-proof authentication,” Weaver said, referring to physical security keys that are phish-proof — meaning that even if phishers manage to steal your username and password, they still can’t log in to your account without also possessing that physical key.

“All critical infrastructure needs to use phish-proof 2FA, and given the dependencies in modern software, archives such as NPM are absolutely critical infrastructure,” Weaver said. “That NPM does not require that all contributor accounts use security keys or similar 2FA methods should be considered negligence.”

DOGE Denizen Marko Elez Leaked API Key for xAI

Marko Elez, a 25-year-old employee at Elon Musk’s Department of Government Efficiency (DOGE), has been granted access to sensitive databases at the U.S. Social Security Administration, the Treasury and Justice departments, and the Department of Homeland Security. So it should fill all Americans with a deep sense of confidence to learn that Mr. Elez over the weekend inadvertently published a private key that allowed anyone to interact directly with more than four dozen large language models (LLMs) developed by Musk’s artificial intelligence company xAI.

On July 13, Mr. Elez committed a code script to GitHub called “agent.py” that included a private application programming interface (API) key for xAI. The inclusion of the private key was first flagged by GitGuardian, a company that specializes in detecting and remediating exposed secrets in public and proprietary environments. GitGuardian’s systems constantly scan GitHub and other code repositories for exposed API keys, and fire off automated alerts to affected users.

Philippe Caturegli, “chief hacking officer” at the security consultancy Seralys, said the exposed API key allowed access to at least 52 different LLMs used by xAI. The most recent LLM in the list was called “grok-4-0709” and was created on July 9, 2025.

Grok, the generative AI chatbot developed by xAI and integrated into Twitter/X, relies on these and other LLMs (a query to Grok before publication shows Grok currently uses Grok-3, which was launched in Feburary 2025). Earlier today, xAI announced that the Department of Defense will begin using Grok as part of a contract worth up to $200 million. The contract award came less than a week after Grok began spewing antisemitic rants and invoking Adolf Hitler.

Mr. Elez did not respond to a request for comment. The code repository containing the private xAI key was removed shortly after Caturegli notified Elez via email. However, Caturegli said the exposed API key still works and has not yet been revoked.

“If a developer can’t keep an API key private, it raises questions about how they’re handling far more sensitive government information behind closed doors,” Caturegli told KrebsOnSecurity.

Prior to joining DOGE, Marko Elez worked for a number of Musk’s companies. His DOGE career began at the Department of the Treasury, and a legal battle over DOGE’s access to Treasury databases showed Elez was sending unencrypted personal information in violation of the agency’s policies.

While still at Treasury, Elez resigned after The Wall Street Journal linked him to social media posts that advocated racism and eugenics. When Vice President J.D. Vance lobbied for Elez to be rehired, President Trump agreed and Musk reinstated him.

Since his re-hiring as a DOGE employee, Elez has been granted access to databases at one federal agency after another. TechCrunch reported in February 2025 that he was working at the Social Security Administration. In March, Business Insider found Elez was part of a DOGE detachment assigned to the Department of Labor.

In April, The New York Times reported that Elez held positions at the U.S. Customs and Border Protection and the Immigration and Customs Enforcement (ICE) bureaus, as well as the Department of Homeland Security. The Washington Post later reported that Elez, while serving as a DOGE advisor at the Department of Justice, had gained access to the Executive Office for Immigration Review’s Courts and Appeals System (EACS).

Elez is not the first DOGE worker to publish internal API keys for xAI: In May, KrebsOnSecurity detailed how another DOGE employee leaked a private xAI key on GitHub for two months, exposing LLMs that were custom made for working with internal data from Musk’s companies, including SpaceX, Tesla and Twitter/X.

Caturegli said it’s difficult to trust someone with access to confidential government systems when they can’t even manage the basics of operational security.

“One leak is a mistake,” he said. “But when the same type of sensitive key gets exposed again and again, it’s not just bad luck, it’s a sign of deeper negligence and a broken security culture.”

xAI Dev Leaks API Key for Private SpaceX, Tesla LLMs

An employee at Elon Musk’s artificial intelligence company xAI leaked a private key on GitHub that for the past two months could have allowed anyone to query private xAI large language models (LLMs) which appear to have been custom made for working with internal data from Musk’s companies, including SpaceX, Tesla and Twitter/X, KrebsOnSecurity has learned.

Philippe Caturegli, “chief hacking officer” at the security consultancy Seralys, was the first to publicize the leak of credentials for an x.ai application programming interface (API) exposed in the GitHub code repository of a technical staff member at xAI.

Caturegli’s post on LinkedIn caught the attention of researchers at GitGuardian, a company that specializes in detecting and remediating exposed secrets in public and proprietary environments. GitGuardian’s systems constantly scan GitHub and other code repositories for exposed API keys, and fire off automated alerts to affected users.

GitGuardian’s Eric Fourrier told KrebsOnSecurity the exposed API key had access to several unreleased models of Grok, the AI chatbot developed by xAI. In total, GitGuardian found the key had access to at least 60 fine-tuned and private LLMs.

“The credentials can be used to access the X.ai API with the identity of the user,” GitGuardian wrote in an email explaining their findings to xAI. “The associated account not only has access to public Grok models (grok-2-1212, etc) but also to what appears to be unreleased (grok-2.5V), development (research-grok-2p5v-1018), and private models (tweet-rejector, grok-spacex-2024-11-04).”

Fourrier found GitGuardian had alerted the xAI employee about the exposed API key nearly two months ago — on March 2. But as of April 30, when GitGuardian directly alerted xAI’s security team to the exposure, the key was still valid and usable. xAI told GitGuardian to report the matter through its bug bounty program at HackerOne, but just a few hours later the repository containing the API key was removed from GitHub.

“It looks like some of these internal LLMs were fine-tuned on SpaceX data, and some were fine-tuned with Tesla data,” Fourrier said. “I definitely don’t think a Grok model that’s fine-tuned on SpaceX data is intended to be exposed publicly.”

xAI did not respond to a request for comment. Nor did the 28-year-old xAI technical staff member whose key was exposed.

Carole Winqwist, chief marketing officer at GitGuardian, said giving potentially hostile users free access to private LLMs is a recipe for disaster.

“If you’re an attacker and you have direct access to the model and the back end interface for things like Grok, it’s definitely something you can use for further attacking,” she said. “An attacker could it use for prompt injection, to tweak the (LLM) model to serve their purposes, or try to implant code into the supply chain.”

The inadvertent exposure of internal LLMs for xAI comes as Musk’s so-called Department of Government Efficiency (DOGE) has been feeding sensitive government records into artificial intelligence tools. In February, The Washington Post reported DOGE officials were feeding data from across the Education Department into AI tools to probe the agency’s programs and spending.

The Post said DOGE plans to replicate this process across many departments and agencies, accessing the back-end software at different parts of the government and then using AI technology to extract and sift through information about spending on employees and programs.

“Feeding sensitive data into AI software puts it into the possession of a system’s operator, increasing the chances it will be leaked or swept up in cyberattacks,” Post reporters wrote.

Wired reported in March that DOGE has deployed a proprietary chatbot called GSAi to 1,500 federal workers at the General Services Administration, part of an effort to automate tasks previously done by humans as DOGE continues its purge of the federal workforce.

A Reuters report last month said Trump administration officials told some U.S. government employees that DOGE is using AI to surveil at least one federal agency’s communications for hostility to President Trump and his agenda. Reuters wrote that the DOGE team has heavily deployed Musk’s Grok AI chatbot as part of their work slashing the federal government, although Reuters said it could not establish exactly how Grok was being used.

Caturegli said while there is no indication that federal government or user data could be accessed through the exposed x.ai API key, these private models are likely trained on proprietary data and may unintentionally expose details related to internal development efforts at xAI, Twitter, or SpaceX.

“The fact that this key was publicly exposed for two months and granted access to internal models is concerning,” Caturegli said. “This kind of long-lived credential exposure highlights weak key management and insufficient internal monitoring, raising questions about safeguards around developer access and broader operational security.”

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