Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


06:00 PM
Connect Directly

Mimecast Says SolarWinds Attackers Accessed Its Source Code Repositories

But the amount of code downloaded is too little to be of any use, the email security vendor says in its latest update.

Hackers who gained access to Mimecast's systems via a poisoned SolarWind's software update late last year appear to have caused more damage than originally thought.

The email security vendor's continuing investigation of the breach has revealed that the attackers accessed and downloaded at least some of its source code repositories and also email addresses, contact information and hashed, salted credentials belonging to some customers.

Related Content:

SolarWinds Attackers May Have Hit Mimecast, Driving New Concerns

Special Report: Building an Effective Cybersecurity Incident Response Team

New From The Edge: DDoS's Evolution Doesn't Require a Security Evolution

In an update this week — at least the third since news of the breach first broke — Mimecast described the source code theft as limited in scope and unlikely to have any negative consequences for customers.

"We believe that the source code downloaded by the threat actor was incomplete and would be insufficient to build and run any aspect of the Mimecast service," the company said.

There is also no evidence that the threat actor used their access to modify Mimecast source code or impact products in any way, the security vendor noted.

Mimecast is one of many organizations around the world that was impacted when a believed nation-state backed threat actor installed malware called SUNBURST on their networks by quietly hiding the malicious code in legitimate software updates from SolarWinds. Some 18,000 SolarWinds customers — such as Mimecast — received and downloaded the poisoned updates. But relatively few of them were subsequently targeted for further exploits.

Mimecast discovered the attack in January when Microsoft notified the company about a compromise involving certificates used to authenticate Mimecast security products to Microsoft 365 Exchange Web Services environments. Along with the certificates, the attackers also accessed related customer server connection information.

Mimecast said Microsoft had discovered the threat actor using the compromised certificates to illegally access networks that belonged to a handful of their mutual customers. In its initial advisory, Mimecast said about 10% of its customers used the compromised certificates. But it said less than 10 of those customers had their Microsoft 365 environments illegally accessed via the compromised certificate-based connection. Mimecast asked all customers to delete their existing connection to their M365 tenant and re-establish a fresh one with the company's newly issued keys.

Mimecast's subsequent investigation — with FireEye Mandiant's help — showed the attackers had used their initial foothold to move laterally to the company's production environment, which contained "a small number" of Windows servers. The attackers then queried and likely extracted encrypted service account credentials from the servers that potentially gave them access to on-premises and cloud-hosted systems belonging to mutual customers of Microsoft and Mimecast in the US and UK.

According to Mimecast, it did not find any evidence to suggest that the encrypted credentials were later decrypted and misused in any way.

"The update from Mimecast reiterates the fact that the recent attack did not stop with the initial target," says John Morgan, CEO of Confluera.The threat actors used their access on Mimecast's network to steal certificates and keys that allowed them to further expand attacks beyond Mimecast's own environment and affiliated systems, he says. This was a scenario that played out at many of the organizations that were impacted in the SolarWinds supply chain attack.

"Another takeaway from the Mimecast report is how critical lateral movement was to the overall attack," Morgan notes. "As with many modern attacks, after gaining initial access, the attacker moved from the point of access to the targeted servers via lateral movement."

One of the reasons why many modern attacks are so effective is because organizations often cannot detect such lateral movement, he says.

Mimecast Reiterates Earlier Recommendation
In its advisory this week, Mimecast reiterated its recommendation that all of its customers reset server connection credentials being used on the Mimecast platform. The company said it had reset the hashed and salted credentials that were accessed, changed all impacted certificates and encryption keys, and implemented closer monitoring of all its certificates and encryption keys.

In addition, the company has decommissioned the SolarWinds Orion platform, changed credentials for all employees, and implemented two-factor authentication for employees requiring access to production systems. It has also implemented measures to ensure its source code is secure and cannot be tampered with and is currently working on developing a new OAuth-based authentication and connection mechanism between Microsoft and Mimecast environments.

A Mimecast spokesman declined to say when the new mechanism would become available.

Dirk Schrader, global vice president of security research at New Net Technologies, says Mimecast's response and remediation measures have been laudable, but its failure to detect the breach in the first place is concerning. Measures such as host monitoring, system and file integrity checks, and change control are essential and should have been implemented, he says. They would have helped Mimecast detect the intrusion, instead of having to be alerted by Microsoft days later, he adds.

The fact that the credentials stolen from Mimecast's environment gave threat actors a way to potentially attack both cloud and on-premises systems is troubling as well, Confluera's Morgan says.

"This should be a wake-up call for any organizations who have preconceived notions about the security of the servers based on its deployment models," he says. "It reiterates the need for organizations to adopt a security model that can detect and respond to threats in real-time across their entire environment."  

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel function where a lack of checks allows the exploitation of an integer overflow on the size parameter of the tz_map_shared_mem function.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel�s tz_handle_trusted_app_smc function where a lack of integer overflow checks on the req_off and param_ofs variables leads to memory corruption of critical kernel structures.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel where an integer overflow in the tz_map_shared_mem function can bypass boundary checks, which might lead to denial of service.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in TSEC TA which deserializes the incoming messages even though the TSEC TA does not expose any command. This vulnerability might allow an attacker to exploit the deserializer to impact code execution, causing information disclosure.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in all TAs whose deserializer does not reject messages with multiple occurrences of the same parameter. The deserialization of untrusted data might allow an attacker to exploit the deserializer to impact code execution.