Category: Latest Warnings

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. O’Connor was so concerned about the problem that he offered $50,000, $25,000 and $10,000 prizes for researchers who could propose the best solutions for mitigating it.

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

More than a million domain names — including many registered by Fortune 100 firms and brand protection companies — are vulnerable to takeover by cybercriminals thanks to authentication weaknesses at a number of large web hosting providers and domain registrars, new research finds.

Image: Shutterstock.

Your Web browser knows how to find a site like example.com thanks to the global Domain Name System (DNS), which serves as a kind of phone book for the Internet by translating human-friendly website names (example.com) into numeric Internet addresses.

When someone registers a domain name, the registrar will typically provide two sets of DNS records that the customer then needs to assign to their domain. Those records are crucial because they allow Web browsers to find the Internet address of the hosting provider that is serving that domain.

But potential problems can arise when a domain’s DNS records are “lame,” meaning the authoritative name server does not have enough information about the domain and can’t resolve queries to find it. A domain can become lame in a variety of ways, such as when it is not assigned an Internet address, or because the name servers in the domain’s authoritative record are misconfigured or missing.

The reason lame domains are problematic is that a number of Web hosting and DNS providers allow users to claim control over a domain without accessing the true owner’s account at their DNS provider or registrar.

If this threat sounds familiar, that’s because it is hardly new. Back in 2019, KrebsOnSecurity wrote about thieves employing this method to seize control over thousands of domains registered at GoDaddy, and using those to send bomb threats and sextortion emails (GoDaddy says they fixed that weakness in their systems not long after that 2019 story).

In the 2019 campaign, the spammers created accounts on GoDaddy and were able to take over vulnerable domains simply by registering a free account at GoDaddy and being assigned the same DNS servers as the hijacked domain.

Three years before that, the same pervasive weakness was described in a blog post by security researcher Matthew Bryant, who showed how one could commandeer at least 120,000 domains via DNS weaknesses at some of the world’s largest hosting providers.

Incredibly, new research jointly released today by security experts at Infoblox and Eclypsium finds this same authentication weakness is still present at a number of large hosting and DNS providers.

“It’s easy to exploit, very hard to detect, and it’s entirely preventable,” said Dave Mitchell, principal threat researcher at Infoblox. “Free services make it easier [to exploit] at scale. And the bulk of these are at a handful of DNS providers.”

SITTING DUCKS

Infoblox’s report found there are multiple cybercriminal groups abusing these stolen domains as a globally dispersed “traffic distribution system,” which can be used to mask the true source or destination of web traffic and to funnel Web users to malicious or phishous websites.

Commandeering domains this way also can allow thieves to impersonate trusted brands and abuse their positive or at least neutral reputation when sending email from those domains, as we saw in 2019 with the GoDaddy attacks.

“Hijacked domains have been used directly in phishing attacks and scams, as well as large spam systems,” reads the Infoblox report, which refers to lame domains as “Sitting Ducks.” “There is evidence that some domains were used for Cobalt Strike and other malware command and control (C2). Other attacks have used hijacked domains in targeted phishing attacks by creating lookalike subdomains. A few actors have stockpiled hijacked domains for an unknown purpose.”

Eclypsium researchers estimate there are currently about one million Sitting Duck domains, and that at least 30,000 of them have been hijacked for malicious use since 2019.

“As of the time of writing, numerous DNS providers enable this through weak or nonexistent verification of domain ownership for a given account,” Eclypsium wrote.

The security firms said they found a number of compromised Sitting Duck domains were originally registered by brand protection companies that specialize in defensive domain registrations (reserving look-alike domains for top brands before those names can be grabbed by scammers) and combating trademark infringement.

For example, Infoblox found cybercriminal groups using a Sitting Duck domain called clickermediacorp[.]com, which was initially registered on behalf of CBS Interactive Inc. by the brand protection firm MarkMonitor.

Another hijacked Sitting Duck domain — anti-phishing[.]org — was registered in 2003 by the Anti-Phishing Working Group (APWG), a cybersecurity not-for-profit organization that closely tracks phishing attacks.

In many cases, the researchers discovered Sitting Duck domains that appear to have been configured to auto-renew at the registrar, but the authoritative DNS or hosting services were not renewed.

The researchers say Sitting Duck domains all possess three attributes that makes them vulnerable to takeover:

1) the domain uses or delegates authoritative DNS services to a different provider than the domain registrar;
2) the authoritative name server(s) for the domain does not have information about the Internet address the domain should point to;
3) the authoritative DNS provider is “exploitable,” i.e. an attacker can claim the domain at the provider and set up DNS records without access to the valid domain owner’s account at the domain registrar.

Image: Infoblox.

How does one know whether a DNS provider is exploitable? There is a frequently updated list published on GitHub called “Can I take over DNS,” which has been documenting exploitability by DNS provider over the past several years. The list includes examples for each of the named DNS providers.

In the case of the aforementioned Sitting Duck domain clickermediacorp[.]com, the domain was originally registered by MarkMonitor, but it appears to have been hijacked by scammers by claiming it at the web hosting firm DNSMadeEasy, which is owned by Digicert, one of the industry’s largest issuers of digital certificates (SSL/TLS certificates).

In an interview with KrebsOnSecurity, DNSMadeEasy founder and senior vice president Steve Job said the problem isn’t really his company’s to solve, noting that DNS providers who are also not domain registrars have no real way of validating whether a given customer legitimately owns the domain being claimed.

“We do shut down abusive accounts when we find them,” Job said. “But it’s my belief that the onus needs to be on the [domain registrants] themselves. If you’re going to buy something and point it somewhere you have no control over, we can’t prevent that.”

Infoblox, Eclypsium, and the DNS wiki listing at Github all say that web hosting giant Digital Ocean is among the vulnerable hosting firms. In response to questions, Digital Ocean said it was exploring options for mitigating such activity.

“The DigitalOcean DNS service is not authoritative, and we are not a domain registrar,” Digital Ocean wrote in an emailed response. “Where a domain owner has delegated authority to our DNS infrastructure with their registrar, and they have allowed their ownership of that DNS record in our infrastructure to lapse, that becomes a ‘lame delegation’ under this hijack model. We believe the root cause, ultimately, is poor management of domain name configuration by the owner, akin to leaving your keys in your unlocked car, but we acknowledge the opportunity to adjust our non-authoritative DNS service guardrails in an effort to help minimize the impact of a lapse in hygiene at the authoritative DNS level. We’re connected with the research teams to explore additional mitigation options.”

In a statement provided to KrebsOnSecurity, the hosting provider and registrar Hostinger said they were working to implement a solution to prevent lame duck attacks in the “upcoming weeks.”

“We are working on implementing an SOA-based domain verification system,” Hostinger wrote. “Custom nameservers with a Start of Authority (SOA) record will be used to verify whether the domain truly belongs to the customer. We aim to launch this user-friendly solution by the end of August. The final step is to deprecate preview domains, a functionality sometimes used by customers with malicious intents. Preview domains will be deprecated by the end of September. Legitimate users will be able to use randomly generated temporary subdomains instead.”

What did DNS providers that have struggled with this issue in the past do to address these authentication challenges? The security firms said that to claim a domain name, the best practice providers gave the account holder random name servers that required a change at the registrar before the domains could go live. They also found the best practice providers used various mechanisms to ensure that the newly assigned name server hosts did not match previous name server assignments.

[Side note: Infoblox observed that many of the hijacked domains were being hosted at Stark Industries Solutions, a sprawling hosting provider that appeared two weeks before Russia invaded Ukraine and has become the epicenter of countless cyberattacks against enemies of Russia].

Both Infoblox and Eclypsium said that without more cooperation and less finger-pointing by all stakeholders in the global DNS, attacks on sitting duck domains will continue to rise, with domain registrants and regular Internet users caught in the middle.

“Government organizations, regulators, and standards bodies should consider long-term solutions to vulnerabilities in the DNS management attack surface,” the Infoblox report concludes.

The Chinese company in charge of handing out domain names ending in “.top” has been given until mid-August 2024 to show that it has put in place systems for managing phishing reports and suspending abusive domains, or else forfeit its license to sell domains. The warning comes amid the release of new findings that .top was the most common suffix in phishing websites over the past year, second only to domains ending in “.com.”

Image: Shutterstock.

On July 16, the Internet Corporation for Assigned Names and Numbers (ICANN) sent a letter to the owners of the .top domain registry. ICANN has filed hundreds of enforcement actions against domain registrars over the years, but this is thought to be the first in which ICANN has singled out a domain registry responsible for maintaining an entire top-level domain (TLD).

Among other reasons, the missive chided the registry for failing to respond to reports about phishing attacks involving .top domains.

“Based on the information and records gathered through several weeks, it was determined that .TOP Registry does not have a process in place to promptly, comprehensively, and reasonably investigate and act on reports of DNS Abuse,” the ICANN letter reads (PDF).

ICANN’s warning redacted the name of the recipient, but records show the .top registry is operated by a Chinese entity called Jiangsu Bangning Science & Technology Co. Ltd. Representatives for the company have not responded to requests for comment.

Domains ending in .top were represented prominently in a new phishing report released today by the Interisle Consulting Group, which sources phishing data from several places, including the Anti-Phishing Working Group (APWG), OpenPhish, PhishTank, and Spamhaus.

Interisle’s newest study examined nearly two million phishing attacks in the last year, and found that phishing sites accounted for more than four percent of all new .top domains between May 2023 and April 2024. Interisle said .top has roughly 2.76 million domains in its stable, and that more than 117,000 of those were phishing sites in the past year.

Source: Interisle Consulting Group.

ICANN said its review was based on information collected and studied about .top domains over the past few weeks. But the fact that high volumes of phishing sites are being registered through Jiangsu Bangning Science & Technology Co Ltd. is hardly a new trend.

For example, more than 10 years ago the same Chinese registrar was the fourth most common source of phishing websites, as tracked by the APWG. Bear in mind that the APWG report excerpted below was published more than a year before Jiangsu Bangning received ICANN approval to introduce and administer the new .top registry.

Source: APWG phishing report from 2013, two years before .top came into being.

A fascinating new wrinkle in the phishing landscape is the growth in scam pages hosted via the InterPlanetary File System (IPFS), a decentralized data storage and delivery network that is based on peer-to-peer networking. According to Interisle, the use of IPFS to host and launch phishing attacks — which can make phishing sites more difficult to take down — increased a staggering 1,300 percent, to roughly 19,000 phishing sites reported in the last year.

Last year’s report from Interisle found that domain names ending in “.us” — the top-level domain for the United States — were among the most prevalent in phishing scams. While .us domains are not even on the Top 20 list of this year’s study, “.com” maintained its perennial #1 spot as the largest source of phishing domains overall.

A year ago, the phishiest domain registrar by far was Freenom, a now-defunct registrar that handed out free domains in several country-code TLDs, including .tk, .ml, .ga and .cf. Freenom went out of business after being sued by Meta, which alleged Freenom ignored abuse complaints while monetizing traffic to abusive domains.

Following Freenom’s demise, phishers quickly migrated to other new low-cost TLDs and to services that allow anonymous, free domain registrations — particularly subdomain services. For example, Interisle found phishing attacks involving websites created on Google’s blogspot.com skyrocketed last year more than 230 percent. Other subdomain services that saw a substantial growth in domains registered by phishers include weebly.com, github.io, wix.com, and ChangeIP, the report notes.

Source: Interisle Consulting.

Interisle Consulting partner Dave Piscitello said ICANN could easily send similar warning letters to at least a half-dozen other top-level domain registries, noting that spammers and phishers tend to cycle through the same TLDs periodically — including .xyz, .info, .support and .lol, all of which saw considerably more business from phishers after Freenom’s implosion.

Piscitello said domain registrars and registries could significantly reduce the number of phishing sites registered through their services just by flagging customers who try to register huge volumes of domains at once. Their study found that at least 27% of the domains used for phishing were registered in bulk — i.e. the same registrant paid for hundreds or thousands of domains in quick succession.

The report includes a case study in which a phisher this year registered 17,562 domains over the course of an eight-hour period — roughly 38 domains per minute — using .lol domains that were all composed of random letters.

ICANN tries to resolve contract disputes privately with the registry and registrar community, and experts say the nonprofit organization usually only publishes enforcement letters when the recipient is ignoring its private notices. Indeed, ICANN’s letter notes Jiangsu Bangning didn’t even open its emailed notifications. It also cited the registry for falling behind in its ICANN membership fees.

With that in mind, a review of ICANN’s public enforcement activity suggests two trends: One is that there have been far fewer public compliance and enforcement actions in recent years — even as the number of new TLDs has expanded dramatically.

The second is that in a majority of cases, the failure of a registry or registrar to pay its annual ICANN membership fees was cited as a reason for a warning letter. A review of nearly two dozen enforcement letters ICANN has sent to domain registrars since 2022 shows that failure to pay dues was cited as a reason (or the reason) for the violation at least 75 percent of the time.

Piscitello, a former ICANN board member, said nearly all breach notices sent out while he was at ICANN were because the registrar owed money.

“I think the rest is just lipstick to suggest that ICANN’s on top of DNS Abuse,” Piscitello said.

KrebsOnSecurity has sought comment from ICANN and will update this story if they respond.

A faulty software update from cybersecurity vendor Crowdstrike crippled countless Microsoft Windows computers across the globe today, disrupting everything from airline travel and financial institutions to hospitals and businesses online. Crowdstrike said a fix has been deployed, but experts say the recovery from this outage could take some time, as Crowdstrike’s solution needs to be applied manually on a per-machine basis.

A photo taken at San Jose International Airport today shows the dreaded Microsoft “Blue Screen of Death” across the board. Credit: Twitter.com/adamdubya1990

Earlier today, an errant update shipped by Crowdstrike began causing Windows machines running the software to display the dreaded “Blue Screen of Death,” rendering those systems temporarily unusable. Like most security software, Crowdstrike requires deep hooks into the Windows operating system to fend off digital intruders, and in that environment a tiny coding error can quickly lead to catastrophic outcomes.

In a post on Twitter/X, Crowdstrike CEO George Kurtz said an update to correct the coding mistake has been shipped, and that Mac and Linux systems are not affected.

“This is not a security incident or cyberattack,” Kurtz said on Twitter, echoing a written statement by Crowdstrike. “The issue has been identified, isolated and a fix has been deployed.”

Posting to Twitter/X, the director of Crowdstrike’s threat hunting operations said the fix involves booting Windows into Safe Mode or the Windows Recovery Environment (Windows RE), deleting the file “C-00000291*.sys” and then restarting the machine.

The software snafu may have been compounded by a recent series of outages involving Microsoft’s Azure cloud services, The New York Times reports, although it remains unclear whether those Azure problems are at all related to the bad Crowdstrike update.

A reader shared this photo taken earlier today at Denver International Airport. Credit: Twitter.com/jterryy07

Reactions to today’s outage were swift and brutal on social media, which was flooded with images of people at airports surrounded by computer screens displaying the Microsoft blue screen error. Many Twitter/X users chided the Crowdstrike CEO for failing to apologize for the massively disruptive event, while others noted that doing so could expose the company to lawsuits.

Meanwhile, the international Windows outage quickly became the most talked-about subject on Twitter/X, whose artificial intelligence bots collated a series of parody posts from cybersecurity professionals pretending to be on their first week of work at Crowdstrike. Incredibly,Twitter/X’s AI summarized these sarcastic posts into a sunny, can-do story about Crowdstrike that was promoted as the top discussion on Twitter this morning.

“Several individuals have recently started working at the cybersecurity firm Crowdstrike and have expressed their excitement and pride in their new roles,” the AI summary read. “They have shared their experiences of pushing code to production on their first day and are looking forward to positive outcomes in their work.”

The top story today on Twitter/X, as brilliantly summarized by X’s AI bots.

Matt Burgess at Wired writes that within health care and emergency services, various medical providers around the world have reported issues with their Windows-linked systems, sharing news on social media or their own websites.

“The US Emergency Alert System, which issues hurricane warnings, said that there had been various 911 outages in a number of states,” Burgess wrote. “Germany’s University Hospital Schleswig-Holstein said it was canceling some nonurgent surgeries at two locations. In Israel, more than a dozen hospitals have been impacted, as well as pharmacies, with reports saying ambulances have been rerouted to nonimpacted medical organizations.”

In the United Kingdom, NHS England has confirmed that appointment and patient record systems have been impacted by the outages.

“One hospital has declared a ‘critical’ incident after a third-party IT system it used was impacted,” Wired reports. “Also in the country, train operators have said there are delays across the network, with multiple companies being impacted.”

This is an evolving story. Stay tuned for updates.

At least a dozen organizations with domain names at domain registrar Squarespace saw their websites hijacked last week. Squarespace bought all assets of Google Domains a year ago, but many customers still haven’t set up their new accounts. Experts say malicious hackers learned they could commandeer any migrated Squarespace accounts that hadn’t yet been registered, merely by supplying an email address tied to an existing domain.

Until this past weekend, Squarespace’s website had an option to log in via email.

The Squarespace domain hijacks, which took place between July 9 and July 12, appear to have mostly targeted cryptocurrency businesses, including Celer Network, Compound Finance, Pendle Finance, and Unstoppable Domains. In some cases, the attackers were able to redirect the hijacked domains to phishing sites set up to steal visitors’ cryptocurrency funds.

New York City-based Squarespace purchased roughly 10 million domain names from Google Domains in June 2023, and it has been gradually migrating those domains to its service ever since. Squarespace has not responded to a request for comment, nor has it issued a statement about the attacks.

But an analysis released by security experts at Metamask and Paradigm finds the most likely explanation for what happened is that Squarespace assumed all users migrating from Google Domains would select the social login options — such “Continue with Google” or “Continue with Apple” — as opposed to the “Continue with email” choice.

Taylor Monahan, lead product manager at Metamask, said Squarespace never accounted for the possibility that a threat actor might sign up for an account using an email associated with a recently-migrated domain before the legitimate email holder created the account themselves.

“Thus nothing actually stops them from trying to login with an email,” Monahan told KrebsOnSecurity. “And since there’s no password on the account, it just shoots them to the ‘create password for your new account’ flow. And since the account is half-initialized on the backend, they now have access to the domain in question.”

What’s more, Monahan said, Squarespace did not require email verification for new accounts created with a password.

“The domains being migrated from Google to Squarespace are known,” Monahan said. “It’s either public or easily discernible info which email addresses have admin of a domain. And if that email never sets up their account on Squarespace — say because the billing admin left the company five years ago or folks just ignored the email — anyone who enters that email@domain in the squarespace form now has full access to control to the domain.”

The researchers say some Squarespace domains that were migrated over also could be hijacked if attackers discovered the email addresses for less privileged user accounts tied to the domain, such as “domain manager,” which likewise has the ability to transfer a domain or point it to a different Internet address.

Squarespace says domain owners and domain managers have many of the same privileges, including the ability to move a domain or manage the site’s domain name server (DNS) settings.

Monahan said the migration has left domain owners with fewer options to secure and monitor their accounts.

“Squarespace can’t support users who need any control or insight into the activity being performed in their account or domain,” Monahan said. “You basically have no control over the access different folks have. You don’t have any audit logs. You don’t get email notifications for some actions. The owner doesn’t get email notification for actions taken by a ‘domain manager.’ This is absolutely insane if you’re used to and expecting the controls Google provides.”

The researchers have published a comprehensive guide for locking down Squarespace user accounts, which urges Squarespace users to enable multi-factor authentication (disabled during the migration).

“Determining what emails have access to your new Squarespace account is step 1,” the help guide advises. “Most teams DO NOT REALIZE these accounts even exist, let alone theoretically have access.”

The guide also recommends removing unnecessary Squarespace user accounts, and disabling reseller access in Google Workspace.

“If you bought Google Workspace via Google Domains, Squarespace is now your authorized reseller,” the help document explains. “This means that anyone with access to your Squarespace account also has a backdoor into your Google Workspace unless you explicitly disable it by following the instructions here, which you should do. It’s easier to secure one account than two.”

AT&T Corp. disclosed today that a new data breach has exposed phone call and text message records for roughly 110 million people — nearly all of its customers. AT&T said it delayed disclosing the incident in response to “national security and public safety concerns,” noting that some of the records included data that could be used to determine where a call was made or text message sent. AT&T also acknowledged the customer records were exposed in a cloud database that was protected only by a username and password (no multi-factor authentication needed).

In a regulatory filing with the U.S. Securities and Exchange Commission today, AT&T said cyber intruders accessed an AT&T workspace on a third-party cloud platform in April, downloading files containing customer call and text interactions between May 1 and October 31, 2022, as well as on January 2, 2023.

The company said the stolen data includes records of calls and texts for mobile providers that resell AT&T’s service, but that it does not include the content of calls or texts, Social Security numbers, dates of birth, or any other personally identifiable information.

However, the company said a subset of stolen records included information about the location of cellular communications towers closest to the subscriber, data that could be used to determine the approximate location of the customer device initiating or receiving those text messages or phone calls.

“While the data does not include customer names, there are often ways, using publicly available online tools, to find the name associated with a specific telephone number,” AT&T allowed.

AT&T’s said it learned of the breach on April 19, but delayed disclosing it at the request of federal investigators. The company’s SEC disclosure says at least one individual has been detained by the authorities in connection with the breach.

In a written statement shared with KrebsOnSecurity, the FBI confirmed that it asked AT&T to delay notifying affected customers.

“Shortly after identifying a potential breach to customer data and before making its materiality decision, AT&T contacted the FBI to report the incident,” the FBI statement reads. “In assessing the nature of the breach, all parties discussed a potential delay to public reporting under Item 1.05(c) of the SEC Rule, due to potential risks to national security and/or public safety. AT&T, FBI, and DOJ worked collaboratively through the first and second delay process, all while sharing key threat intelligence to bolster FBI investigative equities and to assist AT&T’s incident response work.”

Techcrunch quoted an AT&T spokesperson saying the customer data was stolen as a result of a still-unfolding data breach involving more than 160 customers of the cloud data provider Snowflake.

Earlier this year, malicious hackers figured out that many major companies have uploaded massive amounts of valuable and sensitive customer data to Snowflake servers, all the while protecting those Snowflake accounts with little more than a username and password.

Wired reported last month how the hackers behind the Snowflake data thefts purchased stolen Snowflake credentials from dark web services that sell access to usernames, passwords and authentication tokens that are siphoned by information-stealing malware. For its part, Snowflake says it now requires all new customers to use multi-factor authentication.

Other companies with millions of customer records stolen from Snowflake servers include Advance Auto Parts, Allstate, Anheuser-Busch, Los Angeles Unified, Mitsubishi, Neiman Marcus, Progressive, Pure Storage, Santander Bank, State Farm, and Ticketmaster.

Earlier this year, AT&T reset passwords for millions of customers after the company finally acknowledged a data breach from 2018 involving approximately 7.6 million current AT&T account holders and roughly 65.4 million former account holders.

Mark Burnett is an application security architect, consultant and author. Burnett said the only real use for the data stolen in the most recent AT&T breach is to know who is contacting whom and how many times.

“The most concerning thing to me about this AT&T breach of ALL customer call and text records is that this isn’t one of their main databases; it is metadata on who is contacting who,” Burnett wrote on Mastodon. “Which makes me wonder what would call logs without timestamps or names have been used for.”

It remains unclear why so many major corporations persist in the belief that it is somehow acceptable to store so much sensitive customer data with so few security protections. For example, Advance Auto Parts said the data exposed included full names, Social Security numbers, drivers licenses and government issued ID numbers on 2.3 million people who were former employees or job applicants.

That may be because, apart from the class-action lawsuits that invariably ensue after these breaches, there is little holding companies accountable for sloppy security practices. AT&T told the SEC it does not believe this incident is likely to materially impact AT&T’s financial condition or results of operations. AT&T reported revenues of more than $30 billion in its most recent quarter.

Image: Shutterstock.

Apple and the satellite-based broadband service Starlink each recently took steps to address new research into the potential security and privacy implications of how their services geo-locate devices. Researchers from the University of Maryland say they relied on publicly available data from Apple to track the location of billions of devices globally — including non-Apple devices like Starlink systems — and found they could use this data to monitor the destruction of Gaza, as well as the movements and in many cases identities of Russian and Ukrainian troops.

At issue is the way that Apple collects and publicly shares information about the precise location of all Wi-Fi access points seen by its devices. Apple collects this location data to give Apple devices a crowdsourced, low-power alternative to constantly requesting global positioning system (GPS) coordinates.

Both Apple and Google operate their own Wi-Fi-based Positioning Systems (WPS) that obtain certain hardware identifiers from all wireless access points that come within range of their mobile devices. Both record the Media Access Control (MAC) address that a Wi-FI access point uses, known as a Basic Service Set Identifier or BSSID.

Periodically, Apple and Google mobile devices will forward their locations — by querying GPS and/or by using cellular towers as landmarks — along with any nearby BSSIDs. This combination of data allows Apple and Google devices to figure out where they are within a few feet or meters, and it’s what allows your mobile phone to continue displaying your planned route even when the device can’t get a fix on GPS.

With Google’s WPS, a wireless device submits a list of nearby Wi-Fi access point BSSIDs and their signal strengths — via an application programming interface (API) request to Google — whose WPS responds with the device’s computed position. Google’s WPS requires at least two BSSIDs to calculate a device’s approximate position.

Apple’s WPS also accepts a list of nearby BSSIDs, but instead of computing the device’s location based off the set of observed access points and their received signal strengths and then reporting that result to the user, Apple’s API will return return the geolocations of up to 400 hundred more BSSIDs that are nearby the one requested. It then uses approximately eight of those BSSIDs to work out the user’s location based on known landmarks.

In essence, Google’s WPS computes the user’s location and shares it with the device. Apple’s WPS gives its devices a large enough amount of data about the location of known access points in the area that the devices can do that estimation on their own.

That’s according to two researchers at the University of Maryland, who said they theorized they could use the verbosity of Apple’s API to map the movement of individual devices into and out of virtually any defined area of the world. The UMD pair said they spent a month early in their research continuously querying the API, asking it for the location of more than a billion BSSIDs generated at random.

They learned that while only about three million of those randomly generated BSSIDs were known to Apple’s Wi-Fi geolocation API, Apple also returned an additional 488 million BSSID locations already stored in its WPS from other lookups.

UMD Associate Professor David Levin and Ph.D student Erik Rye found they could mostly avoid requesting unallocated BSSIDs by consulting the list of BSSID ranges assigned to specific device manufacturers. That list is maintained by the Institute of Electrical and Electronics Engineers (IEEE), which is also sponsoring the privacy and security conference where Rye is slated to present the UMD research later today.

Plotting the locations returned by Apple’s WPS between November 2022 and November 2023, Levin and Rye saw they had a near global view of the locations tied to more than two billion Wi-Fi access points. The map showed geolocated access points in nearly every corner of the globe, apart from almost the entirety of China, vast stretches of desert wilderness in central Australia and Africa, and deep in the rainforests of South America.

A “heatmap” of BSSIDs the UMD team said they discovered by guessing randomly at BSSIDs.

The researchers said that by zeroing in on or “geofencing” other smaller regions indexed by Apple’s location API, they could monitor how Wi-Fi access points moved over time. Why might that be a big deal? They found that by geofencing active conflict zones in Ukraine, they were able to determine the location and movement of Starlink devices used by both Ukrainian and Russian forces.

The reason they were able to do that is that each Starlink terminal — the dish and associated hardware that allows a Starlink customer to receive Internet service from a constellation of orbiting Starlink satellites — includes its own Wi-Fi access point, whose location is going to be automatically indexed by any nearby Apple devices that have location services enabled.

A heatmap of Starlink routers in Ukraine. Image: UMD.

The University of Maryland team geo-fenced various conflict zones in Ukraine, and identified at least 3,722 Starlink terminals geolocated in Ukraine.

“We find what appear to be personal devices being brought by military personnel into war zones, exposing pre-deployment sites and military positions,” the researchers wrote. “Our results also show individuals who have left Ukraine to a wide range of countries, validating public reports of where Ukrainian refugees have resettled.”

In an interview with KrebsOnSecurity, the UMD team said they found that in addition to exposing Russian troop pre-deployment sites, the location data made it easy to see where devices in contested regions originated from.

“This includes residential addresses throughout the world,” Levin said. “We even believe we can identify people who have joined the Ukraine Foreign Legion.”

A simplified map of where BSSIDs that enter the Donbas and Crimea regions of Ukraine originate. Image: UMD.

Levin and Rye said they shared their findings with Starlink in March 2024, which said it began shipping software updates in 2023 that force Starlink access points to randomize their BSSIDs.

Starlink’s parent SpaceX did not respond to requests for comment. But the researchers shared a graphic they said was created from their Starlink BSSID monitoring data, which shows that just in the past month there was a substantial drop in the number of Starlink devices that were geo-locatable using Apple’s API.

UMD researchers shared this graphic, which shows their ability to monitor the location and movement of Starlink devices by BSSID dropped precipitously in the past month.

They also shared a written statement they received from Starlink, which acknowledged that Starlink User Terminal routers originally used a static BSSID/MAC:

“In early 2023 a software update was released that randomized the main router BSSID. Subsequent software releases have included randomization of the BSSID of WiFi repeaters associated with the main router. Software updates that include the repeater randomization functionality are currently being deployed fleet-wide on a region-by-region basis. We believe the data outlined in your paper is based on Starlink main routers and or repeaters that were queried prior to receiving these randomization updates.”

The researchers also focused their geofencing on the Israel-Hamas war in Gaza, and were able to track the migration and disappearance of devices throughout the Gaza Strip as Israeli forces cut power to the country and bombing campaigns knocked out key infrastructure.

“As time progressed, the number of Gazan BSSIDs that are geolocatable continued to decline,” they wrote. “By the end of the month, only 28% of the original BSSIDs were still found in the Apple WPS.”

Apple did not respond to requests for comment. But in late March 2024, Apple quietly tweaked its privacy policy, allowing people to opt out of having the location of their wireless access points collected and shared by Apple — by appending “_nomap” to the end of the Wi-Fi access point’s name (SSID).

Apple updated its privacy and location services policy in March 2024 to allow people to opt out of having their Wi-Fi access point indexed by its service, by appending “_nomap” to the network’s name.

Rye said Apple’s response addressed the most depressing aspect of their research: That there was previously no way for anyone to opt out of this data collection.

“You may not have Apple products, but if you have an access point and someone near you owns an Apple device, your BSSID will be in [Apple’s] database,” he said. “What’s important to note here is that every access point is being tracked, without opting in, whether they run an Apple device or not. Only after we disclosed this to Apple have they added the ability for people to opt out.”

The researchers said they hope Apple will consider additional safeguards, such as proactive ways to limit abuses of its location API.

“It’s a good first step,” Levin said of Apple’s privacy update in March. “But this data represents a really serious privacy vulnerability. I would hope Apple would put further restrictions on the use of its API, like rate-limiting these queries to keep people from accumulating massive amounts of data like we did.”

The UMD researchers said they omitted certain details from their research to protect the users they were able to track, noting that the methods they used could present risks for those fleeing abusive relationships or stalkers.

“We observe routers move between cities and countries, potentially representing their owner’s relocation or a business transaction between an old and new owner,” they wrote. “While there is not necessarily a 1-to-1 relationship between Wi-Fi routers and users, home routers typically only have several. If these users are vulnerable populations, such as those fleeing intimate partner violence or a stalker, their router simply being online can disclose their new location.”

The researchers said Wi-Fi access points that can be created using a mobile device’s built-in cellular modem do not create a location privacy risk for their users because mobile phone hotspots will choose a random BSSID when activated.

“Modern Android and iOS devices will choose a random BSSID when you go into hotspot mode,” he said. “Hotspots are already implementing the strongest recommendations for privacy protections. It’s other types of devices that don’t do that.”

For example, they discovered that certain commonly used travel routers compound the potential privacy risks.

“Because travel routers are frequently used on campers or boats, we see a significant number of them move between campgrounds, RV parks, and marinas,” the UMD duo wrote. “They are used by vacationers who move between residential dwellings and hotels. We have evidence of their use by military members as they deploy from their homes and bases to war zones.”

A copy of the UMD research is available here (PDF).

Virtual private networking (VPN) companies market their services as a way to prevent anyone from snooping on your Internet usage. But new research suggests this is a dangerous assumption when connecting to a VPN via an untrusted network, because attackers on the same network could force a target’s traffic off of the protection provided by their VPN without triggering any alerts to the user.

Image: Shutterstock.

When a device initially tries to connect to a network, it broadcasts a message to the entire local network stating that it is requesting an Internet address. Normally, the only system on the network that notices this request and replies is the router responsible for managing the network to which the user is trying to connect.

The machine on a network responsible for fielding these requests is called a Dynamic Host Configuration Protocol (DHCP) server, which will issue time-based leases for IP addresses. The DHCP server also takes care of setting a specific local address — known as an Internet gateway — that all connecting systems will use as a primary route to the Web.

VPNs work by creating a virtual network interface that serves as an encrypted tunnel for communications. But researchers at Leviathan Security say they’ve discovered it’s possible to abuse an obscure feature built into the DHCP protocol so that other users on the local network are forced to connect to a rogue DHCP server.

“Our technique is to run a DHCP server on the same network as a targeted VPN user and to also set our DHCP configuration to use itself as a gateway,” Leviathan researchers Lizzie Moratti and Dani Cronce wrote. “When the traffic hits our gateway, we use traffic forwarding rules on the DHCP server to pass traffic through to a legitimate gateway while we snoop on it.”

The feature being abused here is known as DHCP option 121, and it allows a DHCP server to set a route on the VPN user’s system that is more specific than those used by most VPNs. Abusing this option, Leviathan found, effectively gives an attacker on the local network the ability to set up routing rules that have a higher priority than the routes for the virtual network interface that the target’s VPN creates.

“Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface,” the Leviathan researchers said. “This is intended functionality that isn’t clearly stated in the RFC [standard]. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.”

Leviathan found they could force VPNs on the local network that already had a connection to arbitrarily request a new one. In this well-documented tactic, known as a DHCP starvation attack, an attacker floods the DHCP server with requests that consume all available IP addresses that can be allocated. Once the network’s legitimate DHCP server is completely tied up, the attacker can then have their rogue DHCP server respond to all pending requests.

“This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server,” the researchers wrote. “We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.”

The researchers say their methods could be used by an attacker who compromises a DHCP server or wireless access point, or by a rogue network administrator who owns the infrastructure themselves and maliciously configures it. Alternatively, an attacker could set up an “evil twin” wireless hotspot that mimics the signal broadcast by a legitimate provider.

ANALYSIS

Bill Woodcock is executive director at Packet Clearing House, a nonprofit based in San Francisco. Woodcock said Option 121 has been included in the DHCP standard since 2002, which means the attack described by Leviathan has technically been possible for the last 22 years.

“They’re realizing now that this can be used to circumvent a VPN in a way that’s really problematic, and they’re right,” Woodcock said.

Woodcock said anyone who might be a target of spear phishing attacks should be very concerned about using VPNs on an untrusted network.

“Anyone who is in a position of authority or maybe even someone who is just a high net worth individual, those are all very reasonable targets of this attack,” he said. “If I were trying to do an attack against someone at a relatively high security company and I knew where they typically get their coffee or sandwich at twice a week, this is a very effective tool in that toolbox. I’d be a little surprised if it wasn’t already being exploited in that way, because again this isn’t rocket science. It’s just thinking a little outside the box.”

Successfully executing this attack on a network likely would not allow an attacker to see all of a target’s traffic or browsing activity. That’s because for the vast majority of the websites visited by the target, the content is encrypted (the site’s address begins with https://). However, an attacker would still be able to see the metadata — such as the source and destination addresses — of any traffic flowing by.

KrebsOnSecurity shared Leviathan’s research with John Kristoff, founder of dataplane.org and a PhD candidate in computer science at the University of Illinois Chicago. Kristoff said practically all user-edge network gear, including WiFi deployments, support some form of rogue DHCP server detection and mitigation, but that it’s unclear how widely deployed those protections are in real-world environments.

“However, and I think this is a key point to emphasize, an untrusted network is an untrusted network, which is why you’re usually employing the VPN in the first place,” Kristoff said. “If local network is inherently hostile and has no qualms about operating a rogue DHCP server, then this is a sneaky technique that could be used to de-cloak some traffic – and if done carefully, I’m sure a user might never notice.”

MITIGATIONS

According to Leviathan, there are several ways to minimize the threat from rogue DHCP servers on an unsecured network. One is using a device powered by the Android operating system, which apparently ignores DHCP option 121.

Relying on a temporary wireless hotspot controlled by a cellular device you own also effectively blocks this attack.

“They create a password-locked LAN with automatic network address translation,” the researchers wrote of cellular hot-spots. “Because this network is completely controlled by the cellular device and requires a password, an attacker should not have local network access.”

Leviathan’s Moratti said another mitigation is to run your VPN from inside of a virtual machine (VM) — like Parallels, VMware or VirtualBox. VPNs run inside of a VM are not vulnerable to this attack, Moratti said, provided they are not run in “bridged mode,” which causes the VM to replicate another node on the network.

In addition, a technology called “deep packet inspection” can be used to deny all in- and outbound traffic from the physical interface except for the DHCP and the VPN server. However, Leviathan says this approach opens up a potential “side channel” attack that could be used to determine the destination of traffic.

“This could be theoretically done by performing traffic analysis on the volume a target user sends when the attacker’s routes are installed compared to the baseline,” they wrote. “In addition, this selective denial-of-service is unique as it could be used to censor specific resources that an attacker doesn’t want a target user to connect to even while they are using the VPN.”

Moratti said Leviathan’s research shows that many VPN providers are currently making promises to their customers that their technology can’t keep.

“VPNs weren’t designed to keep you more secure on your local network, but to keep your traffic more secure on the Internet,” Moratti said. “When you start making assurances that your product protects people from seeing your traffic, there’s an assurance or promise that can’t be met.”

A copy of Leviathan’s research, along with code intended to allow others to duplicate their findings in a lab environment, is available here.

The U.S. government is warning that smart locks securing entry to an estimated 50,000 dwellings nationwide contain hard-coded credentials that can be used to remotely open any of the locks. The lock’s maker Chirp Systems remains unresponsive, even though it was first notified about the critical weakness in March 2021. Meanwhile, Chirp’s parent company, RealPage, Inc., is being sued by multiple U.S. states for allegedly colluding with landlords to illegally raise rents.

On March 7, 2024, the U.S. Cybersecurity & Infrastructure Security Agency (CISA) warned about a remotely exploitable vulnerability with “low attack complexity” in Chirp Systems smart locks.

“Chirp Access improperly stores credentials within its source code, potentially exposing sensitive information to unauthorized access,” CISA’s alert warned, assigning the bug a CVSS (badness) rating of 9.1 (out of a possible 10). “Chirp Systems has not responded to requests to work with CISA to mitigate this vulnerability.”

Matt Brown, the researcher CISA credits with reporting the flaw, is a senior systems development engineer at Amazon Web Services. Brown said he discovered the weakness and reported it to Chirp in March 2021, after the company that manages his apartment building started using Chirp smart locks and told everyone to install Chirp’s app to get in and out of their apartments.

“I use Android, which has a pretty simple workflow for downloading and decompiling the APK apps,” Brown told KrebsOnSecurity. “Given that I am pretty picky about what I trust on my devices, I downloaded Chirp and after decompiling, found that they were storing passwords and private key strings in a file.”

Using those hard-coded credentials, Brown found he could then connect to an application programming interface (API) that Chirp uses which is managed by smart lock vendor August.com, and use that enumerate and remotely lock or unlock any door in any building that uses the technology.

Brown said when he complained to his leasing office, they sold him a small $50 key fob that uses Near-Field Communications (NFC) to toggle the lock when he brings the fob close to his front door. But he said the fob doesn’t eliminate the ability for anyone to remotely unlock his front door using the exposed credentials and the Chirp mobile app.

A smart lock enabled with Chirp. Image: Camdenliving.com

Also, the fobs pass the credentials to his front door over the air in plain text, meaning someone could clone the fob just by bumping against him with a smartphone app made to read and write NFC tags.

Neither August nor Chirp Systems responded to requests for comment. It’s unclear exactly how many apartments and other residences are using the vulnerable Chirp locks, but multiple articles about the company from 2020 state that approximately 50,000 units use Chirp smart locks with August’s API.

Roughly a year before Brown reported the flaw to Chirp Systems, the company was bought by RealPage, a firm founded in 1998 as a developer of multifamily property management and data analytics software. In 2021, RealPage was acquired by the private equity giant Thoma Bravo.

Brown said the exposure he found in Chirp’s products is “an obvious flaw that is super easy to fix.”

“It’s just a matter of them being motivated to do it,” he said. “But they’re part of a private equity company now, so they’re not answerable to anybody. It’s too bad, because it’s not like residents of [the affected] properties have another choice. It’s either agree to use the app or move.”

In October 2022, an investigation by ProPublica examined RealPage’s dominance in the rent-setting software market, and that it found “uses a mysterious algorithm to help landlords push the highest possible rents on tenants.”

“For tenants, the system upends the practice of negotiating with apartment building staff,” ProPublic found. “RealPage discourages bargaining with renters and has even recommended that landlords in some cases accept a lower occupancy rate in order to raise rents and make more money. One of the algorithm’s developers told ProPublica that leasing agents had ‘too much empathy’ compared to computer generated pricing.”

Last year, the U.S. Department of Justice threw its weight behind a massive lawsuit filed by dozens of tenants who are accusing the $9 billion apartment software company of helping landlords collude to inflate rents.

In February 2024, attorneys general for Arizona and the District of Columbia sued RealPage, alleging RealPage’s software helped create a rental monopoly in their states.