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 Compromised by SolarWinds Threat Actors via Azure/O365 Abuse
## Executive Summary
Malwarebytes, a US cybersecurity firm, was successfully breached by the threat actors responsible for the SolarWinds incident, though this attack was separate from the SolarWinds supply chain compromise. Attackers bypassed traditional defenses by exploiting privileged access within Malwarebytes' Microsoft Office 365 and Azure environments, resulting in the exposure of a limited subset of internal company emails. The root cause involved the abuse of a dormant O365 protection product combined with an Azure Active Directory vulnerability that allowed threat actors to escalate privileges using a self-signed certificate to request email data via MSGraph API calls.
## Incident Details
- Discovery Date: January 20, 2021 (Date of public announcement/investigation findings)
- Incident Date: Pre-January 20, 2021 (Actual compromise date not specified, but occurred prior to public disclosure)
- Affected Organization: Malwarebytes
- Sector: Cybersecurity
- Geography: U.S.
## Timeline of Events
### Initial Access
- Date/Time: Undisclosed prior to Jan 20, 2021
- Vector: Abuse of privileged application access within Microsoft Office 365 and Azure environments.
- Details: Attackers exploited a vulnerability in Azure Active Directory allowing them to escalate privileges by assigning credentials to applications.
### Lateral Movement
- Details: The investigation confirmed the attackers leveraged a **dormant email protection product** within the Office 365 tenant to gain access. Lateral movement appears focused on escalating privileges within the cloud identity framework rather than traditional internal network movement.
### Data Exfiltration/Impact
- Details: A **limited subset of internal company emails** was accessed and/or exfiltrated. Malwarebytes confirmed they do not use Azure cloud services in production environments, suggesting the impact was limited to corporate communications.
### Detection & Response
- Details: Malwarebytes discovered the incident and released an official statement detailing the investigative findings regarding the abuse of the O365 tenant. (Specific detection mechanism not detailed beyond internal investigation.)
## Attack Methodology
- Initial Access: Exploiting Azure AD vulnerability to gain credentials/access setup for an application instance.
- Persistence: The specific method of persistence is not detailed, but continuous access was achieved via the method described below.
- Privilege Escalation: Threat actors added a **self-signed certificate with credentials to the service principal account**, allowing them to authenticate via the key and make API calls.
- Defense Evasion: Not explicitly detailed, but the attack vector bypassed traditional network defenses by targeting cloud identities/applications.
- Credential Access: Inferred via the certificate/key utilization to authenticate against the service principal.
- Discovery: Likely included reconnaissance within the O365/Azure environment to locate the dormant product.
- Lateral Movement: Movement involved transitioning from a user context (inferred) to administrator rights, enabled by the Azure AD configuration issue.
- Collection: Targeting and gathering internal company emails via MSGraph API calls.
- Exfiltration: Data (emails) extracted via successful MSGraph API calls.
- Impact: Unauthorized access and exfiltration of corporate email data.
## Impact Assessment
- Financial: Not specified.
- Data Breach: A limited subset of internal company emails.
- Operational: No impact on production environments was reported.
- Reputational: Public disclosure required to manage perception as a cybersecurity firm.
## Indicators of Compromise
- **Network Indicators (Defanged):** Calls made to **MSGraph API** after authentication succeeded via the self-signed certificate key.
- **File Indicators:** Use of a **self-signed certificate** attached to a service principal account.
- **Behavioral Indicators:** Unaccounted/unauthorized activity associated with a **dormant email protection product** within the O365 tenant. Transition from user context to administrator rights (as noted by CISA's description of related TTPs).
## Response Actions
- **Containment Measures:** Investigation initiated based on discovery. (Specific immediate technical containment steps were not published in detail.)
- **Eradication Steps:** The threat actors’ ability to authenticate using the self-signed certificate key was likely revoked once identified.
- **Recovery Actions:** Analysis and confirmation that production environments were unaffected.
## Lessons Learned
- **Key Takeaways:** Cloud identity management, specifically securing Azure AD tenants and service principal accounts, remains a critical vulnerability, allowing sophisticated attackers to pivot to sensitive data (like emails) even without breaching the main supply chain.
- **What could have been done better:** Stronger controls or monitoring over dormant applications within the Office 365 tenant; tighter policies around the assignment of credentials and certificates to service principals to prevent privilege escalation via self-signed certificates.
## Recommendations
- Strictly enforce multi-factor authentication and review all application permissions, especially those with privileged access to Microsoft 365 and Azure environments.
- Regularly audit all service principal accounts, particularly looking for newly added or unusual authentication methods like self-signed certificates.
- Implement granular monitoring and alerting for any activity utilizing the MSGraph API from unusual service accounts or under elevated privileges.
- Review and decommission any dormant or unused security/protection applications within cloud tenants.