Rackspace Ransomware Incident Highlights Risks of Relying on Mitigation Alone

Organizations often defer patching because of business disruption fears — but that didnt work out very well for Rackspaces Hosted Exchange service.

The recent ransomware incident at Rackspace that took down the companys hosted Microsoft Exchange server environment has focused attention on the often-risky gamble that security teams take when choosing to mitigate a vulnerability — rather than apply a patch for it.
Last week, Rackspace disclosed that a Dec. 2 intrusion into the hosting companys Exchange server service environment resulted from its decision to hold off on applying a patch for a server-side request forgery (SSRF) vulnerability in Exchange Server (
CVE-2022-41080
) that Microsoft had patched in November. The vulnerability, when chained with another previously disclosed remote code execution (RCE) flaw in Exchange Server — tracked as
CVE-2022-41082
— gives attackers a way to take complete control of affected servers.
According to Rackspaces chief security officer, Karen OReilly-Smith, the company held off on applying the patch for the SSRF flaw over
concerns that it would cause disruptive authentication errors
. Instead, Rackspace decided to apply a mitigation measure that Microsoft had issued for the vulnerability thinking it would be an effective measure. OReilly-Smith said that Microsofts notes on CVE-2022-41080 merely described it as a privilege escalation vulnerability and made no mention of the fact that it was part of an RCE chain.
A Microsoft spokesman tells Dark Reading that the company had nothing to share at this time on Rackspaces comments related to the companys patch for the SSRF flaw, or the notes that accompanied its disclosure.
Rackspaces decision to hold off on patching the vulnerability is not unusual, says John Bambenek, principal threat hunter at Netenrich. Often mitigations are preferable, especially in highly public resources where there is sensitivity to downtime, he says. In fact, the more public-facing an application is, the more organizations will go for mitigations, he says.
Most of the time it can be a good bet if the mitigations are sound and complete, Bambenek notes. But it requires a really savvy professional who can read between the lines to make a sound judgement.
In Rackspaces case, its mitigation strategy failed because an attacker — later identified as the Play ransomware group — found a way to
use CVE-2022-41080 to trigger the CVE-2022-41082 RCE flaw
in its environment. Up to that point security researchers had only observed attackers triggering the RCE flaw via a different Exchange Server SSRF vulnerability tracked as
CVE-2022-41040
, in the combination known as ProxyNotShell. The attack caused widespread service outages for Rackspace customers, many of which are small and midsize businesses.
Rackspace put mitigations in place in relation to the
ProxyNotShell chain
disclosed by Microsoft in late September, prior to patches being available, which didn’t happen until November, an external adviser of Rackspace tells Dark Reading.
When the patches did become available, Rackspace held off on applying them because of concerns over reported authentication issues related to the patches and because the company already had the appropriate mitigations in place, the adviser says.
At that time, there were no known or disclosed remote code execution risks associated with CVE-2022-41080, which CrowdStrike discovered while investigating the Rackspace incident, the adviser adds.
The incident highlights the risks organizations take when they rely too much on mitigations alone to keep them safe from vulnerability exploits, says Mike Parkin, senior technical engineer at Vulcan Cyber
.

Deploying vendor recommended mitigations for a known vulnerability is not supposed to be the end of the issue, he says. They’re what you do until the vendor in question can develop a patch and you can deploy it.
The only time its OK to mitigate and not patch is when the vendor has no patch for the vulnerability yet, or theres some technical reason why an organization cannot deploy it in a target environment, Parkin says.
There are going to be cases where change-management procedures delay deploying the patch. But a good process from both change management and security perspectives is to have patches going in as soon as possible while meeting stability concerns, he says, adding that this is especially true when there are known exploits in the wild targeting a particular vulnerability.
Patching and vulnerability remediation in general remains a major challenge for organizations. A study that vulnerability management vendor Edgescan conducted last year showed that organizations still
take an average of 60 days to fix critical vulnerabilities
of the sort that tripped up Rackspace.
The study found that 57% of observed vulnerabilities on enterprise networks were more than two years old and a startling 17% were more than five years old. All of these vulnerabilities had working exploits in the wild, and adversaries — including nation-state actors and cybercriminal groups — had exploited many of them.
Making matters worse is the fact that cybercriminals have become much faster at exploiting new vulnerabilities, so the time between
initial disclosure and exploit availability
has been shrinking rapidly.
The trend pushed the US Cybersecurity and Infrastructure Security Agency (CISA) to issue a directive in Nov. 2021 that requires all federal civilian branch agencies to
remediate known exploited vulnerabilities
within a specific — usually two-week — timeframe. CISA has also advocated that all organizations refer to its catalog of Known Exploited Vulnerabilities (KEV) regularly to see what vulnerabilities attackers are exploiting in the wild so they can remediate them immediately. CISA adds new vulnerabilities to its catalog only if a patch or clear remedial action is available from the affected vendor.
Richard Stiennon, chief research analyst at IT-Harvest, says the fact that many companies still take 60 days to patch critical vulnerabilities is not surprising given the complexity of the task, especially for large organizations. Patching often involves scheduled downtime, which for many organizations tends to be on early weekend mornings, he says. The task involves taking down all affected severs, installing the patch, and rebooting and testing them before bringing the systems back up.
Imagine you are a big company with 2,000 servers that need an emergency patch, Stiennon says. Of course, you would apply a mitigation first. You cannot do it the same day.
Steinnon says cloud adoption has begun changing vulnerability management processes in many organizations. These days, a system that needs patching may be a container or a virtual machine. Now the process is to mirror the production system, patch it, test it, and swap the updated instances into production with no down time.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Rackspace Ransomware Incident Highlights Risks of Relying on Mitigation Alone