Security Hot Takes: The Rackspace Breach

Table of Contents

• Module 1: The Rackspace Hosted Exchange Ransomware Breach
  • Incident Overview
  • Initial Access: Exploiting Microsoft Exchange
  • The ProxyNotShell Patch and the November Gap
  • The OWASSRF Exploit Chain: CVE-2022-41080 and CVE-2022-41082
  • Was This Really a Zero-Day?
  • Post-Exploitation Activity: Remote Access Tools
  • Impact: Data Theft and Service-Wide Disruption
  • The Multi-Tenant Cloud Risk
  • Rackspace’s Response: Discontinuing Hosted Exchange
  • Attack Timeline
  • Defensive Recommendations
• Summary

Module 1: The Rackspace Hosted Exchange Ransomware Breach

Incident Overview

In early December 2022, Rackspace’s Hosted Exchange email service was hit by a ransomware attack. The intrusion involved an externally facing service application being compromised — specifically a Microsoft Exchange server — and it resulted in ransomware being deployed against a cloud service provider’s shared infrastructure.

At a high level, the incident had three defining characteristics:

1. Initial access vector: an internet-facing Microsoft Exchange server was exploited through a known vulnerability chain.
2. Threat actor: the intrusion was attributed to the Play ransomware group, which is known for using this specific exploitation technique as an initial access method.
3. Outcome: ransomware was deployed, customer data was stolen, and the entire Hosted Exchange service was ultimately taken offline in response.

mindmap
  root((Rackspace Breach))
    Target
      Hosted Exchange service
      Externally facing OWA
    Threat actor
      Play ransomware group
    Vector
      ProxyNotShell mitigation bypass
      SSRF chained to RCE
    Outcome
      Data theft - 27 customers
      Service outage - all 30000 customers
      Discontinuation of Hosted Exchange

Initial Access: Exploiting Microsoft Exchange

The attack began the way most large-scale Exchange compromises begin: mass internet scanning. Threat actors scan the internet for Exchange services that are publicly exposed, fingerprinting them via HTTP response headers returned by the web service. Once a list of exposed Exchange servers has been built, the attackers cross-reference which of those servers are unpatched and therefore vulnerable, and then launch the exploit against that subset.

sequenceDiagram
    participant Attacker as Play Ransomware Group
    participant Internet as Internet-wide Scanner
    participant Exchange as Rackspace Exchange/OWA Server

    Attacker->>Internet: Scan for internet-exposed Exchange servers
    Internet->>Exchange: HTTP request to OWA
    Exchange-->>Internet: Response headers reveal Exchange version/build
    Internet-->>Attacker: Build target list of exposed servers
    Attacker->>Attacker: Cross-reference target list against known-unpatched builds
    Attacker->>Exchange: Launch exploit chain against vulnerable target
    Exchange-->>Attacker: Remote code execution achieved

The ProxyNotShell Patch and the November Gap

Rackspace had, in fact, patched their Exchange servers for the well-known ProxyNotShell vulnerability chain when Microsoft’s fix for it was released in September. That patch addressed a remote code execution vulnerability, and Rackspace treated it as important — just as most well-run organizations did.

The problem arose with the next relevant Patch Tuesday release. On November 8th, Microsoft shipped another patch that included a fix rated 8.8 (Critical) and categorized at the time as a privilege escalation vulnerability. Crucially, this fix was bundled into a large cumulative update alongside many other, unrelated security fixes — the kind of “Patch Tuesday” batch that ships every month containing numerous CVEs.

Rackspace made the decision not to apply that November patch immediately. Their stated reasoning was that they were concerned the update might impact their own service upgrade processes, and — since the vulnerability was categorized as privilege escalation rather than remote code execution at the time — they didn’t perceive it as urgent.

flowchart TD
    A[September: ProxyNotShell RCE patch released] --> B[Rackspace applies September patch]
    B --> C[November 8: New cumulative patch released<br/>Rated 8.8 Critical - Privilege Escalation]
    C --> D{Rackspace patches immediately?}
    D -->|No - risk of impacting service upgrades| E[Patch deferred]
    E --> F[Attackers combine both CVEs to bypass<br/>ProxyNotShell mitigations via SSRF]
    F --> G[Remote code execution achieved]
    style E fill:#f8d7da,stroke:#c62828
    style G fill:#f8d7da,stroke:#c62828

The OWASSRF Exploit Chain: CVE-2022-41080 and CVE-2022-41082

The specific vulnerabilities contained in that November patch were CVE-2022-41080 and CVE-2022-41082. When combined, these two CVEs created an exploitation chain that allowed server-side request forgery (SSRF) to be escalated into remote code execution (RCE).

In plain terms: the combined chain represented an evasion of the previous mitigations that had been put in place for ProxyNotShell, paired with an SSRF primitive that let the attacker get through those mitigations and reach RCE. This specific combination had not been observed being exploited publicly before this incident, but it was a known vulnerability chain because Microsoft had already documented and patched it.

flowchart LR
    subgraph "OWASSRF-style exploit chain"
        A[CVE-2022-41080<br/>Privilege escalation flaw] --> C[Combined bypass of<br/>ProxyNotShell mitigations]
        B[CVE-2022-41082<br/>SSRF primitive] --> C
        C --> D[SSRF escalated to<br/>Remote Code Execution]
        D --> E[Attacker executes code<br/>on Exchange/OWA server]
    end

Was This Really a Zero-Day?

A significant part of the discussion centered on Rackspace’s own public characterization of the incident. When the attack was first publicized, Rackspace referred to the exploited vulnerability as “previously unknown” and used the term zero-day exploit.

This framing was challenged on the following grounds:

• The term “zero-day” is often used by breached organizations to imply “there is no way we could have prepared for this.”
• In this case, however, a CVE had been publicly released for the relevant vulnerability chain over a month before the breach occurred.
• A patch that would have fixed the issue had also been available for that same period.
• While it’s true that this specific combined exploitation technique (chaining these two CVEs to bypass ProxyNotShell mitigations) had not been observed publicly before this breach, that does not mean it hadn’t been used elsewhere, and it does not change the fact that the underlying vulnerability had been disclosed and patchable for 30+ days.
• Therefore, “publicly disclosed” and “zero-day” are not equivalent — the vulnerability was disclosed and patchable well before exploitation, which makes this closer to an N-day exploitation of a known-but-unpatched flaw than a true zero-day.

flowchart TD
    A["Vulnerability publicly disclosed and patched<br/>(Nov 8)"] --> B["30+ days pass"]
    B --> C["Organization does not patch<br/>(risk accepted for other reasons)"]
    C --> D["Attacker exploits the known,<br/>unpatched vulnerability"]
    D --> E{"Is this a zero-day?"}
    E -->|"No"| F["This is exploitation of a<br/>known, disclosed, patchable flaw"]
    E -->|"Common but misleading framing"| G["Organization publicly calls it<br/>'zero-day' / 'previously unknown'"]
    style G fill:#fff3cd,stroke:#f9a825
    style F fill:#d4edda,stroke:#2e7d32

The broader point made in the discussion: Microsoft ships collections of patches — often referred to as “Patch Tuesday” updates — bundled together as cumulative updates every month, addressing a number of different vulnerabilities at once. When one of those bundled fixes carries a severity score like 8.8, it warrants prompt attention regardless of whether it is officially categorized as privilege escalation or remote code execution. Deferring that patch is a risk decision, and in this case, that risk decision did not pay off.

Post-Exploitation Activity: Remote Access Tools

Once the attackers had remote code execution on the Exchange server, they moved into what is best described as “normal” ransomware-actor tradecraft — the tactics, techniques, and procedures (TTPs) that these more manual, hands-on-keyboard threat actors consistently reuse.

Specifically, the incident responders (CrowdStrike, who were brought in to perform the forensic investigation) confirmed the use of two remote access tools during the intrusion:

• Plink (PuTTY Link) — a command-line SSH/tunneling utility.
• AnyDesk — a legitimate remote desktop application repurposed for attacker remote access.

These tools give the attacker an interactive, remote desktop-style session on the compromised host, which is exactly the operating model favored by these more manual/hands-on-keyboard ransomware operators: once inside, they log in via a remote access tool and run commands directly through that interactive session rather than relying purely on automated payloads.

Importantly, Plink and AnyDesk are only the tools that were disclosed in the public press release / incident summary — it’s likely that additional tools or techniques were used that were not publicly detailed, since organizations typically only publish what they can confirm and are willing to share.

sequenceDiagram
    participant Attacker as Play Ransomware Operator
    participant Exchange as Compromised Exchange Server
    participant EDR as Security Monitoring (should detect this)

    Attacker->>Exchange: Exploit OWASSRF-style chain (RCE)
    Attacker->>Exchange: Deploy Plink (SSH tunneling tool)
    Attacker->>Exchange: Deploy AnyDesk (remote desktop tool)
    Note over Attacker,Exchange: Interactive remote session established
    Attacker->>Exchange: Hands-on-keyboard commands via remote session
    Note over EDR: This entire post-exploitation phase<br/>is detectable if EDR/monitoring is deployed
    Attacker->>Exchange: Stage and execute ransomware encryption

The key lesson drawn here: the initial access technique (the OWASSRF-style exploit chain) is genuinely complex and gets most of the press coverage, but there is a window of time — likely days — between initial access and the ransomware actually encrypting data, during which these very “loud,” well-known post-exploitation tools should have been detected by endpoint detection and response (EDR) tooling and security monitoring. The zero-day framing does not excuse missing detection of this later stage: the vulnerability does not encrypt files — the threat actors get in, look around, and then encrypt the files. That gap is where defenders have an opportunity to catch the intrusion before ransomware deployment.

Impact: Data Theft and Service-Wide Disruption

When the attack was first discovered, Rackspace initially stated that no customer data had been breached. Later, once a full forensic investigation was completed, Rackspace disclosed that customer data had been stolen for 27 customers, out of a Hosted Exchange customer base of roughly 30,000 customers.

On its face, “27 out of 30,000” sounds like a small, contained incident. However, this framing understates the real impact for two reasons:

1. Those 27 “customers” are often companies, not individuals. As a cloud service provider, Rackspace’s customers are frequently organizations. If the emails, contacts, calendar meetings, and messages of 27 companies were stolen — not 27 individual mailboxes — that represents a substantial and significant data breach in aggregate, even though the customer count looks small.
2. The service-wide outage affected all 30,000 customers, regardless of whether their data was stolen. Once the ransomware hit, Rackspace shut down their entire mail service in response. For an entire day (or longer), every customer who relied on Rackspace for mail — all 30,000 of them — was unable to use their email service at all. So while only 27 customers had confirmed data theft, the availability impact was universal across the customer base.

flowchart TD
    A["~30,000 Hosted Exchange customers"] --> B["27 customers: confirmed data theft<br/>(emails, contacts, calendars, messages)"]
    A --> C["All ~30,000 customers: service outage<br/>(entire mail service shut down)"]
    B --> D["Data breach impact:<br/>likely affects multiple companies,<br/>not just 27 individuals"]
    C --> E["Availability impact:<br/>full day+ of lost email access<br/>for the entire customer base"]
    style B fill:#f8d7da,stroke:#c62828
    style C fill:#fff3cd,stroke:#f9a825

The Multi-Tenant Cloud Risk

A broader lesson emerging from this incident applies to any shared/multi-tenant cloud service, not just Rackspace specifically: if you are collocated on a shared cloud service, you can be affected by an incident even if your own data was never touched.

In this case, the 27 affected customers had data directly stolen, but every customer collocated on that same Hosted Exchange service was impacted by the resulting outage. This same dynamic applies broadly: even if only a small portion of a shared cloud service is directly compromised, the response to that compromise (shutting the service down, for example) can take the whole service offline — impacting tenants whose own data was never accessed.

This is a risk factor that organizations should explicitly account for in their risk assessments when evaluating any cloud service they rely on: the “blast radius” of an incident on a shared service is not limited to the specific tenants whose data is stolen — it can extend to every tenant on that shared infrastructure.

flowchart LR
    subgraph "Shared Cloud Service (Hosted Exchange)"
        T1["Tenant: data stolen"]
        T2["Tenant: not directly compromised"]
        T3["Tenant: not directly compromised"]
        Tn["... thousands more tenants"]
    end
    Incident["Ransomware incident on shared infrastructure"] --> Response["Provider shuts down entire service"]
    Response --> T1
    Response --> T2
    Response --> T3
    Response --> Tn
    style Response fill:#fff3cd,stroke:#f9a825

Rackspace’s Response: Discontinuing Hosted Exchange

Following the breach, Rackspace announced that it was discontinuing its Hosted Exchange service entirely and migrating customers to Microsoft 365.

This decision makes practical sense from Rackspace’s perspective: maintaining a self-hosted Exchange offering has ongoing operational and security costs, and the breach materially increased the risk calculus of continuing to run and maintain that infrastructure themselves. It also raises a broader question about why organizations would pay a third party to run Exchange for them rather than adopting Microsoft 365 directly — though the business reasons behind those historical purchasing decisions are outside the scope of what a security-focused analysis can fully answer.

flowchart TD
    A[Rackspace Hosted Exchange breach] --> B[Forensic investigation + service outage]
    B --> C[Rackspace evaluates ongoing risk/cost<br/>of maintaining self-hosted Exchange]
    C --> D[Decision: discontinue Hosted Exchange service]
    D --> E[Customers migrated to Microsoft 365]

Attack Timeline

Defensive Recommendations

The discussion closed with concrete, actionable recommendations for organizations running externally facing services such as Exchange/OWA:

1. Patch critical vulnerabilities promptly — especially on externally accessible systems. A rating of 8.8 or higher on an internet-facing service warrants urgent attention, regardless of whether it’s classified as privilege escalation or remote code execution; bundled Patch Tuesday updates deserve careful review line-by-line, not just for the headline CVE.
2. If you cannot patch immediately, disable the exposed service. In this case, the vulnerable component sat on top of Outlook Web Access (OWA); if patching isn’t immediately possible, disabling OWA (or the affected service) removes the exposure until a patch can be applied.
3. Deploy EDR and alerting tuned to detect common post-exploitation tooling. Ransomware groups reuse the same TTPs repeatedly — tools like Plink and AnyDesk are known indicators. Alert on the presence of remote access/tunneling tools that should not normally be running in your environment, especially on Exchange servers.
4. Treat multi-tenant/shared-cloud exposure as part of your risk matrix. Even if your own workload is never directly touched, an incident affecting a shared service you depend on can still take that service offline for you.
5. Do not rely on “zero-day” framing as a security control. If a CVE has been publicly disclosed and a patch is available, the clock on your exposure starts immediately — deferring the patch is an active risk decision, not an unavoidable circumstance.

flowchart TD
    A[Critical vuln on internet-facing service] --> B{Can you patch now?}
    B -->|Yes| C[Patch immediately]
    B -->|No| D[Disable the exposed service<br/>e.g. turn off OWA]
    C --> E[Deploy/verify EDR coverage]
    D --> E
    E --> F[Alert on known post-exploitation tools<br/>Plink, AnyDesk, unexpected remote access]
    F --> G[Include shared-cloud blast-radius<br/>in your risk matrix]
    G --> H[Avoid treating disclosed-but-unpatched<br/>flaws as unavoidable zero-days]

Summary

The Rackspace Hosted Exchange breach illustrates how a known, already-patched vulnerability chain — not a true zero-day — can still lead to a major ransomware incident when patching is deferred for operational reasons. The Play ransomware group exploited a combination of CVE-2022-41080 and CVE-2022-41082 to bypass previously issued ProxyNotShell mitigations via SSRF, achieving remote code execution against an internet-facing Exchange/OWA server that Rackspace had chosen not to patch for over a month. Post-exploitation, the attackers relied on well-known, easily detectable remote access tools (Plink and AnyDesk) to operate hands-on-keyboard for what was likely a window of days before ransomware was deployed. The resulting impact was twofold: confirmed data theft affecting 27 customers (likely representing multiple companies’ worth of email, contacts, and calendar data), and a service-wide outage affecting the entire ~30,000-customer base, since Rackspace shut down the whole Hosted Exchange service in response. Rackspace ultimately discontinued the Hosted Exchange offering entirely, migrating customers to Microsoft 365.

Key Takeaways

• “Publicly disclosed” is not the same as “zero-day.” A vulnerability that has been patched and documented for 30+ days is a known risk, not an unavoidable surprise — deferring the patch is a deliberate risk decision.
• Bundled cumulative patches deserve scrutiny. High-severity CVEs (8.8+) shipped as part of a larger monthly update batch still warrant urgent attention.
• The exploit doesn’t encrypt your data — the attacker does, later. There is typically a detectable window between initial access and ransomware deployment; this is where EDR and monitoring earn their value.
• Common post-exploitation tools are strong detection opportunities. Tools like Plink and AnyDesk are reused constantly by ransomware operators and should trigger alerts when seen on servers like Exchange.
• Shared/multi-tenant cloud services carry collective risk. An incident affecting a small subset of tenants can still take the entire service offline for everyone.
• Major incidents can force strategic re-evaluation. Rackspace’s decision to discontinue Hosted Exchange entirely and migrate to Microsoft 365 reflects how a single incident can shift an organization’s long-term platform strategy.

Defensive / Mitigation Checklist

• Maintain a rapid patch cadence for internet-facing services, prioritizing anything rated Critical (7.0+) regardless of its stated vulnerability category.
• Review the full contents of bundled/cumulative patches (e.g., Patch Tuesday releases) rather than only reacting to headline CVEs.
• Have a documented fallback plan to disable an exposed service (e.g., OWA) when immediate patching isn’t possible.
• Deploy EDR across all externally facing infrastructure, including Exchange/mail servers.
• Create detection rules/alerts for known post-exploitation remote access tools (Plink, AnyDesk, and similar).
• Monitor for anomalous remote desktop or tunneling activity on servers that shouldn’t normally have such tools installed.
• Incorporate shared/multi-tenant cloud provider risk into your organizational risk matrix, even when your own data isn’t directly targeted.
• Avoid public or internal characterizations of incidents as “zero-day” when a patch was available prior to exploitation — accurately labeling the root cause improves lessons-learned quality.
• Periodically reassess whether outsourced/hosted services (like third-party Exchange hosting) still make sense compared to direct vendor-managed alternatives (e.g., Microsoft 365) from a risk and cost perspective.

Search Terms

security · hot · takes · rackspace · breach · threat · intel · networking · systems · exchange · access · defensive · hosted