Full Report
Malwarebytes, a US cyber-security firm, has announced that it was hacked by the same threat actors responsible for the SolarWinds breach.
Analysis Summary
# Incident Report: Malwarebytes Compromise via Azure/O365 Privilege Abuse
## Executive Summary
Malwarebytes, a US cybersecurity firm, was targeted and breached by the same threat actors behind the SolarWinds attack. The compromise was achieved by exploiting a vulnerability within Microsoft Office 365/Azure environments, specifically by abusing privileged access via an application's service principal. The impact was limited to a subset of internal company emails, and the investigation focused on securing the Azure tenant configuration.
## Incident Details
- **Discovery Date:** January 20, 2021 (Date of public announcement/investigation findings)
- **Incident Date:** Not explicitly stated when infiltration began, but occurred prior to January 2021.
- **Affected Organization:** Malwarebytes
- **Sector:** Cybersecurity Software/Technology
- **Geography:** United States
## Timeline of Events
### Initial Access
- **Date/Time:** Unknown prior to discovery.
- **Vector:** Abuse of a dormant email protection product within the Office 365 tenant, exploiting an Azure Active Directory vulnerability.
- **Details:** Attackers gained access by adding a self-signed certificate with credentials to a service principal account, which allowed them to authenticate and request access via MSGraph.
### Lateral Movement
- **Details:** Movement was focused within the Microsoft O365/Azure environment, leveraging compromised credentials/certificates associated with a privileged service principal to access specific resources.
### Data Exfiltration/Impact
- **Details:** A limited subset of internal company emails was accessed and potentially exfiltrated. Malwarebytes confirmed they do not use Azure cloud services in their production environments.
### Detection & Response
- **Details:** The breach was confirmed through internal investigation following external context from the broader SolarWinds incident disclosure. Response actions focused on securing the Azure tenant configuration, specifically the service principal account abuse mechanism.
## Attack Methodology (Inferred from Context)
- **Initial Access:** Abuse of a misconfigured or compromised application/service principal within Azure AD, possibly preceded by credential spraying or password guessing targeting administrative credentials (as suggested by CISA alerts regarding the threat actor).
- **Persistence:** Through the addition of a self-signed certificate to the service principal account, facilitating subsequent authentication.
- **Privilege Escalation:** Achieved by transitioning from a user context (or application context) to obtaining administrator/elevated rights necessary to query Microsoft Graph API for email data.
- **Defense Evasion:** Utilizing legitimate infrastructure (Microsoft O365/Azure APIs) to blend in with normal traffic.
- **Credential Access:** Not explicitly detailed, but likely involved obtaining initial access credentials to elevate rights toward the service principal or exploiting the mechanism that allowed certificate addition.
- **Discovery:** Internal email enumeration via MSGraph API calls.
- **Lateral Movement:** Movement confined to the Azure/O365 trust boundary using the compromised service principal mechanism.
- **Collection:** Gathering internal company emails.
- **Exfiltration:** Data (emails) exfiltrated via MSGraph API calls authenticated by the self-signed certificate.
- **Impact:** Theft of sensitive internal communications.
## Impact Assessment
- **Financial:** Not disclosed.
- **Data Breach:** Limited subset of internal company emails compromised.
- **Operational:** While the breach was serious—affecting a security vendor—direct operational impact on customer-facing services appears minimal, as production environments were reportedly separate from the breached Azure tenant.
- **Reputational:** Significant, as it attributes the breach to the sophisticated actors behind the SolarWinds campaign and involves a cybersecurity company being compromised.
## Indicators of Compromise
- **Network indicators:** Requesting emails via **MSGraph API** authenticated via a self-signed certificate token.
- **File indicators:** Self-signed certificate deployment.
- **Behavioral indicators:** Unusual API calls or modifications to **Service Principal** accounts within Azure AD where a new authentication method (self-signed certificate) is established.
## Response Actions
- **Containment measures:** Identified and revoked the access granted by the compromised self-signed certificate/service principal.
- **Eradication steps:** Actions taken to secure the Azure tenant configuration, specifically addressing the vulnerability that allowed certificate addition for privilege escalation.
- **Recovery actions:** Focused on auditing and hardening access controls related to application permissions and service principals within the O365/Azure environment.
## Lessons Learned
- **Key takeaways:** Third-party services (like cloud identity platforms Azure AD) connected via service principals represent critical, high-value targets that require stringent security, even when production environments are externally isolated.
- **What could have been done better:** Tighter controls or monitoring on the creation of self-signed certificates or modification of service principal credentials, especially for dormant applications.
## Recommendations
- Implement CISA's recommended security best practices for Azure tenants, focusing on blocking password spraying and implementing strict access controls.
- Regularly audit service principal accounts for unauthorized certificate additions or privilege escalations.
- Enforce Principle of Least Privilege strictly for all application registrations and service principals in Azure AD.
- Review and monitor privileged access within the Microsoft O365 tenant, ensuring that dormant or low-activity applications are aggressively scrutinized or disabled.