Rackspace kept running old Exchange for clients, and kept its old risks

The week

On December 2, 2022, Rackspace’s Hosted Exchange service began failing for customers. On December 6 the company confirmed a ransomware incident and began moving affected customers to Microsoft 365. The service was used mainly by small and mid-sized organizations that had chosen a managed version of Exchange instead of Microsoft’s own cloud service. Many were without normal email for days, and some waited much longer for historical mailbox data. Rackspace later attributed the attack to the Play ransomware group and said, after an investigation by CrowdStrike, that it used a then-unknown exploit chain, known as OWASSRF, that got around Microsoft’s published mitigations for the ProxyNotShell flaws. In early January 2023 Rackspace said the hosted Exchange environment would not be rebuilt. It reported that the attackers had accessed stored mailbox files of 27 customers.

Rackspace’s customers did not run their own Exchange servers. They paid a provider so that someone else would patch, monitor and recover the platform. The incident exposed a gap in that bargain that reaches well beyond email: hosting changes who does the work, but the software and its attack history stay the same. Every hosted platform needs three paths that the customer can see and test: a patch path, an exit path and a recovery path. Here, all three turned out to sit with the provider.

The patch path

On-premises Exchange was among the most targeted enterprise products of 2021 and 2022. ProxyLogon, ProxyShell and, in autumn 2022, ProxyNotShell each produced waves of exploitation. Microsoft revised its ProxyNotShell mitigation guidance several times as researchers found ways around it. The OWASSRF chain used against Rackspace reached the same vulnerable component through a different route, so a server could be correctly mitigated on paper and still exposed.

Hosted customers had no view of any of this. A typical agreement promised availability and support response times. It did not say how quickly critical patches would be applied, what the provider would do when only a mitigation existed, or whether customers would be told when the service was running mitigated rather than patched. For a product with that record, those are the questions that matter.

A customer can ask for them in contract terms. Examples include a maximum time to apply critical security updates, notice when the provider is relying on a temporary mitigation, and the right to see the provider’s vulnerability management reports or an independent assessment such as a SOC 2 Type 2 report that covers patching. The customer also needs someone internal who reads those reports. A small credit union or clinic network can assign that to its security lead as a quarterly task without hiring anyone.

The exit path

When Rackspace moved customers to Microsoft 365 instead of restoring the old service, each customer had to buy licenses, verify domains, configure identity, update DNS records and reconfigure every phone and laptop, all under pressure. Organizations that kept their own record of DNS, identity and device settings moved in days. Those that had relied on the provider for everything found that the knowledge of their own configuration sat with the provider too.

Exit planning is usually treated as a contract clause about returning data at the end of the term. A working exit plan answers operational questions instead. Who holds administrator credentials for the domain registrar and DNS. Which identity system controls sign-in, and could it point at a different service tomorrow. Where the authoritative copy of the data lives, in what format, and how long a bulk export would take. Which applications send mail through the service, such as scanners, line-of-business systems and alerting tools.

None of this is expensive to write down in advance. It is very expensive to reconstruct during an outage, when the provider’s own staff are overwhelmed. A useful test is a tabletop exercise in which the provider disappears for two weeks. Gaps surface within an hour. Typical findings include a registrar account tied to a former employee’s personal email, mail-flow records nobody has copied, and licensing that only the provider can change.

The recovery path

For many customers the hardest part was not the days without new email. It was the uncertainty over old mailboxes. In regulated organizations email is often a record: correspondence with members and patients, approvals, notices and complaints. Losing access touches retention schedules, litigation holds and supervisory expectations. Broker-dealers have specific electronic recordkeeping requirements under SEC Rule 17a-4. Health systems and public agencies have their own retention schedules and public records obligations.

Customers with an independent archive, through a journaling service or a separate backup tenant, could keep meeting those obligations while Rackspace worked through recovery. Customers who treated the provider’s resilience as their backup learned a hard distinction. A provider’s disaster recovery is designed to restore the provider’s service, not necessarily to give each customer its own data in a usable form. A backup inside the same administrative domain as the system it protects can be lost in the same incident. The independent copy should use separate credentials, a separate provider account and a restore procedure that someone has actually run.

The pattern is not specific to email. Hosted core banking, hosted EHR instances, hosted case management and hosted file transfer all involve a provider running software it did not write for customers who cannot see how it is run. The architectural question is whether the software is still being actively engineered for current threats, and whether the customer keeps enough control to patch around, leave or recover from the provider. For each hosted platform, someone inside the organization should be able to answer all three from documents the organization controls. Where nobody can, that platform belongs at the top of the risk register.

With hindsight

Rackspace did not bring hosted Exchange back, and customer lawsuits followed. Microsoft kept retiring on-premises Exchange: Exchange 2013 reached end of support in April 2023, and Exchange 2016 and 2019 followed on October 14, 2025, leaving a subscription edition as the supported on-premises option. Exchange stayed a target. In August 2025 CISA issued Emergency Directive 25-02, giving federal civilian agencies a few days to mitigate a hybrid Exchange flaw that could let an attacker with on-premises administrator access escalate into the connected Microsoft 365 environment. The recovery argument has aged best. Email remains a record for broker-dealers, health systems and agencies whatever happens to the platform, and an archive outside the provider’s administrative domain is the one control that held up in every version of this incident.