Login
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.
A DNS lookup on the domain az.mastercard.com on Jan. 14, 2025 shows the mistyped domain name a22-65.akam.ne.
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.
MasterCard’s request to Caturegli, a.k.a. “Titon” on infosec.exchange.
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.”
Caturegli posted this screenshot of MasterCard domains that were potentially at risk from the misconfigured domain.
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).
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.”
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.
Caturegli said he has now defensively registered a number of domains ending in .ad, such as internal.ad and schema.ad. But perhaps the most dangerous domain in his stable is wpad.ad. WPAD stands for Web Proxy Auto-Discovery Protocol, which is an ancient, on-by-default feature built into every version of Microsoft Windows that was designed to make it simpler for Windows computers to automatically find and download any proxy settings required by the local network.
Trouble is, any organization that chose a .ad domain they don’t own for their Active Directory setup will have a whole bunch of Microsoft systems constantly trying to reach out to wpad.ad if those machines have proxy automated detection enabled.
Security researchers have been beating up on WPAD for more than two decades now, warning time and again how it can be abused for nefarious ends. At this year’s DEF CON security conference in Las Vegas, for example, a researcher showed what happened after they registered the domain wpad.dk: Immediately after switching on the domain, they received a flood of WPAD requests from Microsoft Windows systems in Denmark that had namespace collisions in their Active Directory environments.
Image: Defcon.org.
For his part, Caturegli set up a server on wpad.ad to resolve and record the Internet address of any Windows systems trying to reach Microsoft Sharepoint servers, and saw that over one week it received more than 140,000 hits from hosts around the world attempting to connect.
The fundamental problem with WPAD is the same with Active Directory: Both are technologies originally designed to be used in closed, static, trusted office environments, and neither was built with today’s mobile devices or workforce in mind.
Probably one big reason organizations with potential namespace collision problems don’t fix them is that rebuilding one’s Active Directory infrastructure around a new domain name can be incredibly disruptive, costly, and risky, while the potential threat is considered comparatively low.
But Caturegli said ransomware gangs and other cybercrime groups could siphon huge volumes of Microsoft Windows credentials from quite a few companies with just a small up-front investment.
“It’s an easy way to gain that initial access without even having to launch an actual attack,” he said. “You just wait for the misconfigured workstation to connect to you and send you their credentials.”
If we ever learn that cybercrime groups are using namespace collisions to launch ransomware attacks, nobody can say they weren’t warned. Mike O’Connor, an early domain name investor who registered a number of choice domains such as bar.com, place.com and television.com, warned loudly and often back in 2013 that then-pending plans to add more than 1,000 new TLDs would massively expand the number of namespace collisions.
Mr. O’Connor’s most famous domain is corp.com, because for several decades he watched in horror as hundreds of thousands of Microsoft PCs continuously blasted his domain with credentials from organizations that had set up their Active Directory environment around the domain corp.com.
It turned out that Microsoft had actually used corp.com as an example of how one might set up Active Directory in some editions of Windows NT. Worse, some of the traffic going to corp.com was coming from Microsoft’s internal networks, indicating some part of Microsoft’s own internal infrastructure was misconfigured. When O’Connor said he was ready to sell corp.com to the highest bidder in 2020, Microsoft agreed to buy the domain for an undisclosed amount.
“I kind of imagine this problem to be something like a town [that] knowingly built a water supply out of lead pipes, or vendors of those projects who knew but didn’t tell their customers,” O’Connor told KrebsOnSecurity. “This is not an inadvertent thing like Y2K where everybody was surprised by what happened. People knew and didn’t care.”
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.”
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 a CBS Interactive Inc. domain initially registered in 2009 at GoDaddy. However, in 2010 the DNS was updated to DNSMadeEasy.com servers, and in 2012 the domain was transferred to 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 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.
If only Patch Tuesdays came around infrequently — like total solar eclipse rare — instead of just creeping up on us each month like The Man in the Moon. Although to be fair, it would be tough for Microsoft to eclipse the number of vulnerabilities fixed in this month’s patch batch — a record 147 flaws in Windows and related software.
Yes, you read that right. Microsoft today released updates to address 147 security holes in Windows, Office, Azure, .NET Framework, Visual Studio, SQL Server, DNS Server, Windows Defender, Bitlocker, and Windows Secure Boot.
“This is the largest release from Microsoft this year and the largest since at least 2017,” said Dustin Childs, from Trend Micro’s Zero Day Initiative (ZDI). “As far as I can tell, it’s the largest Patch Tuesday release from Microsoft of all time.”
Tempering the sheer volume of this month’s patches is the middling severity of many of the bugs. Only three of April’s vulnerabilities earned Microsoft’s most-dire “critical” rating, meaning they can be abused by malware or malcontents to take remote control over unpatched systems with no help from users.
Most of the flaws that Microsoft deems “more likely to be exploited” this month are marked as “important,” which usually involve bugs that require a bit more user interaction (social engineering) but which nevertheless can result in system security bypass, compromise, and the theft of critical assets.
Ben McCarthy, lead cyber security engineer at Immersive Labs called attention to CVE-2024-20670, an Outlook for Windows spoofing vulnerability described as being easy to exploit. It involves convincing a user to click on a malicious link in an email, which can then steal the user’s password hash and authenticate as the user in another Microsoft service.
Another interesting bug McCarthy pointed to is CVE-2024-29063, which involves hard-coded credentials in Azure’s search backend infrastructure that could be gleaned by taking advantage of Azure AI search.
“This along with many other AI attacks in recent news shows a potential new attack surface that we are just learning how to mitigate against,” McCarthy said. “Microsoft has updated their backend and notified any customers who have been affected by the credential leakage.”
CVE-2024-29988 is a weakness that allows attackers to bypass Windows SmartScreen, a technology Microsoft designed to provide additional protections for end users against phishing and malware attacks. Childs said one of ZDI’s researchers found this vulnerability being exploited in the wild, although Microsoft doesn’t currently list CVE-2024-29988 as being exploited.
“I would treat this as in the wild until Microsoft clarifies,” Childs said. “The bug itself acts much like CVE-2024-21412 – a [zero-day threat from February] that bypassed the Mark of the Web feature and allows malware to execute on a target system. Threat actors are sending exploits in a zipped file to evade EDR/NDR detection and then using this bug (and others) to bypass Mark of the Web.”
Update, 7:46 p.m. ET: A previous version of this story said there were no zero-day vulnerabilities fixed this month. BleepingComputer reports that Microsoft has since confirmed that there are actually two zero-days. One is the flaw Childs just mentioned (CVE-2024-21412), and the other is CVE-2024-26234, described as a “proxy driver spoofing” weakness.
Satnam Narang at Tenable notes that this month’s release includes fixes for two dozen flaws in Windows Secure Boot, the majority of which are considered “Exploitation Less Likely” according to Microsoft.
“However, the last time Microsoft patched a flaw in Windows Secure Boot in May 2023 had a notable impact as it was exploited in the wild and linked to the BlackLotus UEFI bootkit, which was sold on dark web forums for $5,000,” Narang said. “BlackLotus can bypass functionality called secure boot, which is designed to block malware from being able to load when booting up. While none of these Secure Boot vulnerabilities addressed this month were exploited in the wild, they serve as a reminder that flaws in Secure Boot persist, and we could see more malicious activity related to Secure Boot in the future.”
For links to individual security advisories indexed by severity, check out ZDI’s blog and the Patch Tuesday post from the SANS Internet Storm Center. Please consider backing up your data or your drive before updating, and drop a note in the comments here if you experience any issues applying these fixes.
Adobe today released nine patches tackling at least two dozen vulnerabilities in a range of software products, including Adobe After Effects, Photoshop, Commerce, InDesign, Experience Manager, Media Encoder, Bridge, Illustrator, and Adobe Animate.
KrebsOnSecurity needs to correct the record on a point mentioned at the end of March’s “Fat Patch Tuesday” post, which looked at new AI capabilities built into Adobe Acrobat that are turned on by default. Adobe has since clarified that its apps won’t use AI to auto-scan your documents, as the original language in its FAQ suggested.
“In practice, no document scanning or analysis occurs unless a user actively engages with the AI features by agreeing to the terms, opening a document, and selecting the AI Assistant or generative summary buttons for that specific document,” Adobe said earlier this month.
Article tags
The fake USPS phishing page.
Recent weeks have seen a sizable uptick in the number of phishing scams targeting U.S. Postal Service (USPS) customers. Here’s a look at an extensive SMS phishing operation that tries to steal personal and financial data by spoofing the USPS, as well as postal services in at least a dozen other countries.
KrebsOnSecurity recently heard from a reader who received an SMS purporting to have been sent by the USPS, saying there was a problem with a package destined for the reader’s address. Clicking the link in the text message brings one to the domain usps.informedtrck[.]com.
The landing page generated by the phishing link includes the USPS logo, and says “Your package is on hold for an invalid recipient address. Fill in the correct address info by the link.” Below that message is a “Click update” button that takes the visitor to a page that asks for more information.
The remaining buttons on the phishing page all link to the real USPS.com website. After collecting your address information, the fake USPS site goes on to request additional personal and financial data.
This phishing domain was recently registered and its WHOIS ownership records are basically nonexistent. However, we can find some compelling clues about the extent of this operation by loading the phishing page in Developer Tools, a set of debugging features built into Firefox, Chrome and Safari that allow one to closely inspect a webpage’s code and operations.
Check out the bottom portion of the screenshot below, and you’ll notice that this phishing site fails to load some external resources, including an image from a link called fly.linkcdn[.]to.
Click the image to enlarge.
A search on this domain at the always-useful URLscan.io shows that fly.linkcdn[.]to is tied to a slew of USPS-themed phishing domains. Here are just a few of those domains (links defanged to prevent accidental clicking):
usps.receivepost[.]com
usps.informedtrck[.]com
usps.trckspost[.]com
postreceive[.]com
usps.trckpackages[.]com
usps.infortrck[.]com
usps.quicktpos[.]com
usps.postreceive].]com
usps.revepost[.]com
trackingusps.infortrck[.]com
usps.receivepost[.]com
usps.trckmybusi[.]com
postreceive[.]com
tackingpos[.]com
usps.trckstamp[.]com
usa-usps[.]shop
usps.infortrck[.]com
unlistedstampreceive[.]com
usps.stampreceive[.]com
usps.stamppos[.]com
usps.stampspos[.]com
usps.trckmypost[.]com
usps.trckintern[.]com
usps.tackingpos[.]com
usps.posinformed[.]com
As we can see in the screenshot below, the developer tools console for informedtrck[.]com complains that the site is unable to load a Google Analytics code — UA-80133954-3 — which apparently was rejected for pointing to an invalid domain.
Notice the highlighted Google Analytics code exposed by a faulty Javascript element on the phishing website. Click to enlarge. That code actually belongs to the USPS.
The valid domain for that Google Analytics code is the official usps.com website. According to dnslytics.com, that same analytics code has shown up on at least six other nearly identical USPS phishing pages dating back nearly as many years, including onlineuspsexpress[.]com, which DomainTools.com says was registered way back in September 2018 to an individual in Nigeria.
A different domain with that same Google Analytics code that was registered in 2021 is peraltansepeda[.]com, which archive.org shows was running a similar set of phishing pages targeting USPS users. DomainTools.com indicates this website name was registered by phishers based in Indonesia.
DomainTools says the above-mentioned USPS phishing domain stamppos[.]com was registered in 2022 via Singapore-based Alibaba.com, but the registrant city and state listed for that domain says “Georgia, AL,” which is not a real location.
Alas, running a search for domains registered through Alibaba to anyone claiming to reside in Georgia, AL reveals nearly 300 recent postal phishing domains ending in “.top.” These domains are either administrative domains obscured by a password-protected login page, or are .top domains phishing customers of the USPS as well as postal services serving other countries.
Those other nations include the Australia Post, An Post (Ireland), Correos.es (Spain), the Costa Rican post, the Chilean Post, the Mexican Postal Service, Poste Italiane (Italy), PostNL (Netherlands), PostNord (Denmark, Norway and Sweden), and Posti (Finland). A complete list of these domains is available here (PDF).
A phishing page targeting An Post, the state-owned provider of postal services in Ireland.
The Georgia, AL domains at Alibaba also encompass several that spoof sites claiming to collect outstanding road toll fees and fines on behalf of the governments of Australia, New Zealand and Singapore.
An anonymous reader wrote in to say they submitted fake information to the above-mentioned phishing site usps.receivepost[.]com via the malware sandbox any.run. A video recording of that analysis shows that the site sends any submitted data via an automated bot on the Telegram instant messaging service.
The traffic analysis just below the any.run video shows that any data collected by the phishing site is being sent to the Telegram user @chenlun, who offers to sell customized source code for phishing pages. From a review of @chenlun’s other Telegram channels, it appears this account is being massively spammed at the moment — possibly thanks to public attention brought by this story.
Meanwhile, researchers at DomainTools recently published a report on an apparently unrelated but equally sprawling SMS-based phishing campaign targeting USPS customers that appears to be the work of cybercriminals based in Iran.
Phishers tend to cast a wide net and often spoof entities that are broadly used by the local population, and few brands are going to have more household reach than domestic mail services. In June, the United Parcel Service (UPS) disclosed that fraudsters were abusing an online shipment tracking tool in Canada to send highly targeted SMS phishing messages that spoofed the UPS and other brands.
With the holiday shopping season nearly upon us, now is a great time to remind family and friends about the best advice to sidestep phishing scams: Avoid clicking on links or attachments that arrive unbidden in emails, text messages and other mediums. Most phishing scams invoke a temporal element that warns of negative consequences should you fail to respond or act quickly.
If you’re unsure whether the message is legitimate, take a deep breath and visit the site or service in question manually — ideally, using a browser bookmark so as to avoid potential typosquatting sites.
Update: Added information about the Telegram bot and any.run analysis.
FreshRSS