Why Is Ransomware So Successful? It May Not Be What You Think

The techniques or artifacts used for cyber exploitation, while often highly advanced and well thought out, are not necessarily where the effectiveness of successful ransomware campaigns comes from.

There is a term that many will be familiar with, called "golden image." This is an operating system image used by companies to be replicated or cloned a large number of times, so that both servers and workstations share the same operating system, configurations, and commonly used software.

When these images are created, which does not happen frequently, perhaps annually or every six months, the goal is to include the latest updates and patches, at least for the operating system, as well as EDR agents, antivirus, or however many monitoring and security tools are used within the organization. However, once that image is "in production," its evolution tends to be very different.

And the context must be made clear: When we talk about the use of golden images for workstations, we are referring to large organizations, for which providing support to all of their users is complicated, or simply impossible, since they are spread across different geographies. In other words, many of those users are probably working remotely and will not always be connected to the corporate network or VPN from which synchronizations are usually performed. Some of those devices, if the organization's policies allow it, may never be used, because the user will prefer to work from their personal computer. In the cases where the devices are on premises, the fact that a machine is "physically inside the company" usually means that certain exceptions end up being applied.

A very interesting case happened to me recently. An integrator that had assigned me a laptop asked me whether I was having problems with the device, because Microsoft Defender had not been updating for a couple of weeks and it was showing as non-compliant. When I told him that the reason was most likely that the end client had installed CrowdStrike's EDR on it, he said he would still try to access it to check, through TeamViewer, which CrowdStrike immediately blocked.

In other words, the owner of the device, located in another country, lost control of its own equipment due to the policies of its own client, and with that, it lost the ability to keep the device updated and properly configured. Not to mention that the client's policies were stricter than its own.

This happens to them constantly because it is a multinational integrator that hires third parties to deliver its services, has its own staff assigned to clients, constantly raises exceptions that clients request in order to operate, and countless other actions that complicate its administration.

Chaotic Environments

we move to the server side, granular administration tends to be complicated. Normally, we can summarize it as "the owner or custodian of the asset is the one responsible for keeping the asset compliant." The problem arises when we ask what that asset is actually used for.

If we are talking about servers or instances used for development, the reality is that they tend to be extremely chaotic environments, with outdated libraries and components, some of them internal, test users, test data, and countless omissions, since they are basically test servers. If we are talking about production servers, their compliance will usually be closely tied to their use, and to making sure there is no impact on the business.

In short, we can conclude from both sides, workstations as well as servers, that administration is complicated and generally represents a technical challenge. However, the complexity increases with omissions, or with complications caused by a lack of understanding or poorly established procedures.

Last year, a company was affected by CVE-2025-53770, a CVE that affects SharePoint instances. What was the scenario?

This company, with several thousand assets, had only three SharePoint servers, which were running on Windows 2003, without support, without updates, and without having received any type of compensating control. The reason for this was that the company was already migrating to OneDrive, and for them these servers were legacy assets that would soon stop being used.

The period of time between when they were going to be decommissioned and when they showed up as impacted by CVE-2025-53770 was 20 years. Yes, these servers had been non-compliant since 2005, and in 2025 someone remembered them because a critical vulnerability affecting them appeared in the vulnerability scanner console.

Since these servers obviously no longer had support, and SharePoint was already in the process of being migrated, the server had a risk acceptance exception. On the one hand, there was an exception at the operating system level because they were running an unsupported operating system, and on the other, there was an exception covering SharePoint updates because these servers were no longer licensed, and those licenses would not be renewed.

And this is where the confusion begins.

'Not Supported OS'

When we execute a vulnerability scan, regardless of the vulnerabilities detected on an asset, if it is a server running an unsupported operating system, "Not supported OS" will appear as a critical vulnerability. What the asset owners did was create an exception under which any vulnerability affecting the server at the operating system level was documented and accepted, on the grounds that there was no support.

This is incorrect. While the lack of support is relevant, on many occasions Microsoft has released patches for Windows versions that are no longer supported because they understand the severity of the consequences of a vulnerability. Furthermore, it is one thing for the operating system to no longer receive updates due to this lack of support, and quite another for there to be configuration errors, deviations from the baseline, or missing compensating controls.

The second issue affecting these instances was that they had an exception based on the lack of SharePoint licensing. As a result, the administrators did not even bother to verify notifications related to SharePoint because they already had an exception covering SharePoint. That was also false, since regardless of licensing, Microsoft usually releases critical patches and updates even when the software is not licensed.

Even though this situation was detected and communicated, the asset owners took shelter in their exceptions, and within a couple of days they were infected by ransomware, which spread to other assets on the network.

But we are not here to talk about isolated cases, but rather about the reasons why ransomware is so effective: On the one hand, the complexity of managing the technology infrastructure of companies, and on the other, the inability to follow established security guidelines. As I once said in this same space, administrators prefer to process an exception rather than address the causes of the risk.

These omissions, this lack of responsiveness, is what truly makes ransomware effective because in these cases, risk acceptance letters are not valid.

But perhaps for many, at least for those who actually see the day-to-day operation, this is something quite common. Why does it happen? Is it really the case that we cannot reduce that complexity and act?

Lack of Understanding

In my opinion, the root cause is the lack of understanding of the risks associated with a vulnerability. And what makes that risk exponential is that the people who are not understanding that risk are IT personnel, security personnel, and even risk personnel, who believe that having documented exceptions, documented risks, and policies in order will keep risk low, but that is only true in calculations.

On the other hand, this risk also comes from vendors. I have seen quite a few penetration testing RFPs where the RFP itself establishes that the pentester will not be authorized to exploit vulnerabilities. Yes, that is right; as illogical as it may seem given the nature of the service, there are CSOs who establish in their requirements that the exploitation of vulnerabilities will not be authorized, and vendors that limit themselves to only performing detection of potential vulnerabilities, in many cases as a consequence of the low prices companies are willing to pay for an exercise that requires specialized personnel.

Another cause is that security teams today focus more on metrics, on KPIs, and on other aspects than on the actual associated risk. Even when risk management is discussed, their metrics focus more on the calculation of the risk than on the mitigation of the risk as such.

Unfortunately, the criminal groups that operate ransomware campaigns have little interest in KPIs. They are simply out there, constantly searching for vulnerable services to exploit, or buying initial access, in order to execute their campaigns, and they continue to be successful.

This problem is something that will not change until we go back some 10 years, to a time when, before thinking about a KPI, we thought about actually taking action. And in that regard, it seems there is more regression than progress.