A Mimecast-issued certificate provided to certain customers to authenticate Mimecast Sync and Recover, Continuity Monitor, and IEP products to Microsoft 365 Exchange Web Services has been compromised by a sophisticated threat actor.
In a notice, Mimecast said approximately 10% of customers use this connection, and "there are indications that a low single digit number of our customers’ M365 tenants were targeted."
As a precaution, they asked the subset of Mimecast customers using this certificate-based connection to immediately delete the existing connection within their M365 tenant and re-establish a new certificate-based connection using the new certificate they’ve made available.
Terence Jackson, Chief Information Security Officer at Thycotic, a Washington D.C. based provider of privileged access management (PAM) solutions, notes, “The certificates that were compromised were used by Mimecast email security products. These products would access customers Microsoft 365 exchange servers in order for them to provide security services (backup, spam, and phishing protection). Since these certificates were legit, an adversary would have been able to connect without raising suspicions to eavesdrop and exfiltrate email communications.”
Vishal Jain, CTO at Valtix, a Santa Clara, Calif.-based provider of cloud native network security services, says that with the recently issued NSA advisory wherein the recommendation is to use TLS1.2 with perfect forward secrecy cipher suites or TLS1.3, the issue of a compromised key becomes moot. This problem exists if you don't follow this recommendation. At Valtix, for instance, we take out the misconfiguration possibility by only supporting PFS suites. You can also add the good practice of having (1) CRLs and/or (2) OCSP in place. Both are a bit expensive for handshakes, but can help in revoking compromised certs where the key exchange for a new session was not PFS protected.”
Once an organization has been breached, all of the organization’s digital certificates (ones the organization owns and has private keys for) should be destroyed and recreated as it is nearly impossible to know with certainty that the attacker has not stolen the private keys, says Oliver Tavakoli, CTO at Vectra, a San Jose, Calif.-based provider of technology which applies AI to detect and hunt for cyberattackers.
"If the attacker compromises a server, steals the private key for a certificate and then restores the server to its original state, the server will appear to have escaped the breach, but the attacker can now use the private key to perform any actions that the certificate entitles," Tavakoli adds. "This underlines the importance of protecting private keys, as in many cases they should be regarded in the same manner as privileged accounts. Secure storage using an HSM, or other secure enclaves together with an audit log of usage, is an absolute necessity.”
