Mimecast Certificate Compromise 2021: How SolarWinds Attackers Used a Stolen Certificate to Reach Microsoft 365 Tenants

On 12 January 2021, email security company Mimecast disclosed that "a sophisticated threat actor" had compromised a certificate it issued to customers so that its products could connect to their Microsoft 365 Exchange services. Microsoft had told Mimecast about the compromise. About 10 percent of Mimecast's customers used the connection, and Mimecast said a low single-digit number of their Microsoft 365 tenants were targeted. Two weeks later Mimecast confirmed the incident was linked to the SolarWinds Orion compromise, and that the attacker had also reached encrypted service account credentials that US and UK customers used to connect Mimecast to their directories and mail servers. Its final report in March 2021 said the intrusion began with the SUNBURST backdoor in its own Orion installation, and that the attacker also downloaded part of its source code. Mimecast replaced the certificate, rotated keys and credentials, decommissioned Orion and said it found no evidence that customer email or archive content was accessed.

At a glance

What happened

Mimecast sells email security, archiving and continuity services. Several of its products need to talk to customers' Microsoft 365 Exchange environments, and for that Mimecast issued a certificate that customers configured as the connection between the two. On 12 January 2021, Mimecast said a sophisticated threat actor had compromised that certificate, which authenticated Mimecast Sync and Recover, Continuity Monitor and Internal Email Protect to Microsoft 365 Exchange Web Services. "Approximately 10 percent of our customers use this connection," the company said. "Of those that do, there are indications that a low single digit number of our customers' M365 tenants were targeted."

Mimecast asked customers using the connection to delete it and set up a new one with a replacement certificate. A Microsoft spokesperson told TechTarget: "We can confirm that a certificate provided by Mimecast was compromised by a sophisticated actor." At Mimecast's request, Microsoft blocked the old certificate on Monday 18 January 2021, TechTarget reported. On 26 January Mimecast went further: "Our investigation has now confirmed that this incident is related to the SolarWinds Orion software compromise." It said the attacker had accessed, and possibly exfiltrated, encrypted service account credentials of customers hosted in the US and UK. Those credentials connect Mimecast tenants to services such as LDAP, Azure Active Directory, Exchange Web Services, POP3 journaling and SMTP-authenticated delivery routes. Mimecast said it was not aware that any had been decrypted or misused, but advised customers to reset them.

Mimecast completed its investigation with Mandiant in March. Its incident report of 16 March 2021 said the initial intrusion resulted from SUNBURST, the backdoor in trojanised SolarWinds Orion updates. The attacker used the certificate to connect to "a low single-digit number of our mutual customers' M365 tenants" from IP ranges outside Mimecast. It also accessed hashed and salted credentials, which Mimecast reset, and downloaded a limited number of source code repositories, which Mimecast believed were incomplete and showed no sign of modification. "We have no evidence that the threat actor accessed email or archive content held by us on behalf of our customers," Mimecast said.

Mimecast replaced all compromised servers, decommissioned SolarWinds Orion, rotated certificates, encryption keys and employee and system credentials, strengthened encryption of stored credentials and added hardware-based two-factor authentication for production access. It also said it was developing a new OAuth-based connection with Microsoft to replace the certificate-based one.

Timeline

How it happened: the identity attack path

1. Supply chain foothold. Mimecast ran SolarWinds Orion, and the SUNBURST backdoor in its trojanised updates gave the attacker a way into Mimecast's network.
2. Vendor certificate taken. The attacker obtained the certificate that customers trusted to authenticate Mimecast products to their Microsoft 365 Exchange Web Services.
3. Customer tenants targeted. Using the certificate from non-Mimecast IP ranges, the attacker connected to a low single-digit number of customers' Microsoft 365 tenants.
4. More machine credentials. The attacker also reached encrypted service account credentials that US and UK customers used to connect Mimecast to LDAP, Azure AD and mail services, plus hashed and salted credentials.
5. Revocation and rotation. Customers moved to a new certificate, Microsoft blocked the old one, and Mimecast rotated certificates, keys and credentials and removed Orion.

Impact

• Confirmed by Mimecast: the certificate was used to connect to a low single-digit number of customers' Microsoft 365 tenants; encrypted service account credentials for US and UK customers could have been extracted; hashed and salted credentials were accessed; a limited number of source code repositories were downloaded.
• Exposure: about 10 percent of Mimecast customers used the affected connection and had to replace it. Mimecast did not say how many that was; BleepingComputer's estimate was about 3,600.
• Not found: Mimecast found no evidence that the encrypted credentials were decrypted or misused, that its source code was modified, or that customer email or archive content it held was accessed.
• Not disclosed: which customers were targeted and what the attacker did inside their tenants.

What this means for NHI governance

The Mimecast certificate was a machine identity shared across thousands of customer relationships. Each customer trusted it to let a Mimecast service into its Microsoft 365 environment, so whoever held it could present itself as Mimecast to all of them. The attacker did not need to break into those customers separately; it needed one credential from the vendor in the middle. The encrypted service account credentials told the same story at a smaller scale: secrets that customers had handed to a supplier so that the supplier's systems could reach their directories and mail servers.

This is the third-party side of non-human identity risk. Organisations should know which vendors hold credentials or certificates that reach into their tenants, what those credentials can do, and how quickly they can be revoked. Vendors should replace shared, long-lived certificates with per-customer, scoped and short-lived credentials, which is the direction Mimecast took with its OAuth-based connection. The SolarWinds supply chain compromise and the Malwarebytes breach show the same actor working through trusted machine identities. Our Third-Party Access Guide and Machine Identity, PKI and Certificate Lifecycle Guide cover the controls.

Recommendations

• Inventory vendor credentials that reach your tenant. List every certificate, app registration and service account a supplier uses to connect to Microsoft 365 or your directories, and what each can do. See our Third-Party Access Guide.
• Prefer per-customer, scoped and short-lived credentials. Ask vendors to use OAuth applications with least-privilege permissions rather than shared certificates. See our SaaS and OAuth App Governance Guide.
• Be ready to revoke a vendor certificate quickly. Know how to remove a supplier's connection and replace it without breaking mail flow, as Mimecast customers had to. See our Machine Identity, PKI and Certificate Lifecycle Guide.
• Restrict where vendor identities can connect from. The certificate was used from IP ranges outside Mimecast; conditional access or location restrictions for workload identities would flag or block that.
• Rotate secrets you have given to a breached supplier. Reset the LDAP, directory and mail credentials you stored with them, even when the supplier says they were encrypted. See the Leaked Credential Response Playbook.
• Monitor vendor application activity in your tenant. Alert on unusual mailbox access by service identities. See our ITDR Guide.

Frequently asked questions

What happened in the Mimecast breach in 2021?

Attackers linked to the SolarWinds compromise got into Mimecast's network through the SUNBURST backdoor in SolarWinds Orion. They stole a certificate Mimecast used to connect its products to customers' Microsoft 365 Exchange services and used it against a low single-digit number of customer tenants. They also took encrypted customer service account credentials and some source code.

Was the Mimecast breach connected to SolarWinds?

Yes. On 26 January 2021 Mimecast said its investigation had confirmed the incident was related to the SolarWinds Orion software compromise, and its March 2021 incident report said the initial intrusion resulted from SUNBURST malware.

Did the attackers read Mimecast customers' email?

Mimecast said it had no evidence that the attacker accessed email or archive content it held for customers. The stolen certificate was used to connect to a small number of customers' own Microsoft 365 tenants; what the attacker did there has not been disclosed.

Related NHI Mgmt Group resources

SolarWinds Supply Chain Compromise · Malwarebytes Breach 2021 · Microsoft Midnight Blizzard Breach 2024 · Third-Party Access Guide · Machine Identity, PKI and Certificate Lifecycle Guide

How NHI Mgmt Group can help

Vendor certificates, app registrations and stored service account credentials give suppliers standing access to your environment. We help organisations map that access, scope it down and be ready to revoke it within hours when a supplier is breached. See our NHI and AI agent security training.

References

• The Hacker News: Hackers Steal Mimecast Certificate Used to Securely Connect with Microsoft 365 (13 January 2021)
• TechTarget: Mimecast certificate compromised by SolarWinds hackers (26 January 2021)
• Mimecast: Incident report (16 March 2021)
• BleepingComputer: Mimecast: SolarWinds hackers stole some of our source code (16 March 2021)