On 19 January 2021, security company Malwarebytes disclosed that it had been targeted by the same nation-state actor behind the SolarWinds supply chain attack, even though it did not use SolarWinds software. Microsoft's Security Response Center had alerted Malwarebytes on 15 December 2020 to suspicious activity from a third-party application in its Microsoft Office 365 tenant. The investigation that followed, with Microsoft's Detection and Response Team, found that the attackers had abused a dormant email protection product in the tenant. They added a self-signed certificate as a credential to the application's service principal in Azure Active Directory, authenticated as that application and used the Microsoft Graph API to read email. Malwarebytes says the attacker "only gained access to a limited subset of internal company emails" and that it found no evidence of access to its on-premises or production environments, or of any change to its software. How the attackers first got enough privilege in the tenant to add the credential has not been disclosed.
Key takeaways
- Malwarebytes was breached through an application identity, not a user: attackers added a self-signed certificate credential to the service principal of a dormant email protection product in its Office 365 tenant.
- Authenticating as that application, the attackers used Microsoft Graph to request email and reached a limited subset of internal company emails, according to Malwarebytes.
- Microsoft alerted Malwarebytes on 15 December 2020; Malwarebytes disclosed on 19 January 2021 and attributed the activity to the actor behind the SolarWinds attacks.
- Malwarebytes found no evidence of compromise of its on-premises or production environments, reviewed its source code and build processes, and said its software remained safe to use.
- The identity lesson: an unused application with mail permissions is a standing privileged identity, and anyone who can add a credential to it inherits those permissions.
At a glance
| Organisation | Malwarebytes, a cybersecurity software company |
|---|---|
| When | Microsoft alerted Malwarebytes on 15 December 2020; Malwarebytes disclosed the breach on 19 January 2021 |
| Attacker | The nation-state actor behind the SolarWinds attacks, according to Malwarebytes and Microsoft's notification |
| Entry point | Not disclosed. The attackers abused applications with privileged access to Office 365 and Azure; Malwarebytes did not use SolarWinds |
| Identities abused | The Azure AD service principal of a dormant email protection product, given an attacker-controlled self-signed certificate credential |
| Impact | A limited subset of internal company emails accessed; no evidence of access to on-premises or production environments or of changes to Malwarebytes software |
| Category | NHI. Incident class: confirmed NHI breach (service principal credential added and used to read mail via Microsoft Graph) |
What happened
In December 2020 the SolarWinds compromise became public, and companies began checking whether the trojanised Orion software had reached them. Malwarebytes did not use SolarWinds. "While Malwarebytes does not use SolarWinds, we, like many other companies were recently targeted by the same threat actor," chief executive Marcin Kleczynski wrote. On 15 December, Microsoft's Security Response Center told Malwarebytes it had seen suspicious activity from a third-party application in the Malwarebytes Office 365 tenant consistent with the tactics of the SolarWinds attackers. Malwarebytes brought in its own incident response team and Microsoft's Detection and Response Team.
"The investigation indicates the attackers leveraged a dormant email protection product within our Office 365 tenant that allowed access to a limited subset of internal company emails," Kleczynski wrote. The mechanism was an application identity. "In our particular instance, the threat actor added a self-signed certificate with credentials to the service principal account. From there, they can authenticate using the key and make API calls to request emails via MSGraph." Malwarebytes described this as "another intrusion vector that works by abusing applications with privileged access to Microsoft Office 365 and Azure environments", separate from the Orion backdoor.
Malwarebytes said it does not use Azure cloud services in its production environments. It reviewed its source code, build and delivery processes, including reverse engineering its own software, and said: "We found no evidence of unauthorized access or compromise in any of our internal on-premises and production environments." The Register noted that the initial access vector was not disclosed, and that a US government alert on the campaign, CISA's AA21-008A, cited password guessing and the exploitation of administrative or service credentials as possible ways in.
The technique had been described before. Security researcher Dirk-jan Mollema had reported to Microsoft that application administrators could escalate privileges by assigning credentials to service principals; Microsoft told him this was documented behaviour, The Register reported. "In my opinion, it shouldn't be possible to assign credentials to first-party Microsoft applications," Mollema said. Malwarebytes also noted that CrowdStrike had been targeted in an unsuccessful attempt and had released a tool to help find Azure AD risks.
Timeline
| Date | Event |
|---|---|
| December 2020 | The SolarWinds supply chain compromise becomes public. |
| 15 December 2020 | Microsoft's Security Response Center alerts Malwarebytes to suspicious third-party application activity in its Office 365 tenant. |
| December 2020 to January 2021 | Malwarebytes and Microsoft's Detection and Response Team investigate and find the abused email protection product. |
| 19 January 2021 | Malwarebytes discloses the breach and the service principal technique. |
| 20 January 2021 | The Register reports the breach and researcher Dirk-jan Mollema's earlier warnings about service principal credentials. |
How it happened: the identity attack path
- Privileged access to the tenant. The attackers obtained enough rights in Azure AD to change application credentials. How they did so has not been disclosed.
- Dormant application chosen. They targeted the service principal of an email protection product that was no longer in active use but still had permission to read mail.
- Credential added. They added their own self-signed certificate to the service principal, giving them a way to authenticate as the application.
- Authenticate as the app. Using the key for that certificate, they obtained access to Microsoft Graph as the application, not as any user.
- Read email. They made Graph API calls to request internal emails, reaching a limited subset before Microsoft's alert led to the investigation.
Impact
- Confirmed: a limited subset of Malwarebytes internal company emails was accessed through the abused application.
- Not found: Malwarebytes found no evidence of unauthorised access or compromise in its on-premises and production environments, and no evidence that its software was altered.
- Not disclosed: which emails were read, how long the access lasted and how the attackers first obtained the rights to modify the application.
- Wider: the case showed that the SolarWinds actor also used Azure AD application abuse against organisations that never ran Orion.
What this means for NHI governance
Every application registered in Microsoft Entra ID (formerly Azure AD) has a service principal, and that service principal is a non-human identity with its own permissions and its own credentials. An email security product that needs to scan mail is granted broad mail access. When the product falls out of use, the permissions usually stay. In the Malwarebytes case the attackers did not need to steal a password or bypass MFA for any person; they needed only the ability to add a certificate to an application that already had the access they wanted. Activity by the application then looks like the product doing its job.
The controls are straightforward to state and often missing: an inventory of enterprise applications and their permissions, removal of unused ones, tight limits on who can add credentials to them, and alerts when a credential is added. The same pattern appears in the SolarWinds supply chain compromise, where hijacked app identities were part of the post-compromise playbook, and in the Mimecast certificate compromise disclosed the same month. Our SaaS and OAuth App Governance Guide and Active Directory and Entra ID Hardening Guide cover these controls.
Recommendations
- Inventory enterprise applications and their permissions. List every service principal, what it can access and who owns it. See our SaaS and OAuth App Governance Guide.
- Remove dormant applications. When a product is retired, delete its service principal and revoke its consent; an unused app with mail access is a ready-made backdoor.
- Restrict who can add application credentials. Limit Application Administrator and similar roles, protect them with phishing-resistant MFA and just-in-time activation. See our Active Directory and Entra ID Hardening Guide.
- Alert on new credentials on service principals. Adding a certificate or secret to an existing application is rare and should raise an alert. See our ITDR Guide.
- Scope mail permissions down. Use application access policies or equivalent to limit which mailboxes an app can read, rather than tenant-wide access.
- Assign an owner to every service principal. An owner who reviews its use and permissions each quarter is the simplest guard against forgotten access. See our NHI Ownership Guide.
Frequently asked questions
Was Malwarebytes hacked by the SolarWinds attackers?
Malwarebytes said in January 2021 that it was targeted by the same nation-state actor behind the SolarWinds attacks, even though it did not use SolarWinds software. The attackers reached a limited subset of internal company emails by abusing an application in its Office 365 tenant.
How did the attackers access Malwarebytes email?
They added a self-signed certificate as a credential to the Azure AD service principal of a dormant email protection product, authenticated as that application and used the Microsoft Graph API to request emails. How they first got the rights to do this was not disclosed.
Was Malwarebytes software compromised?
No evidence of that was found. Malwarebytes reviewed its source code, build and delivery processes, including reverse engineering its own software, found no evidence of unauthorised access to its on-premises or production environments and said its software remained safe to use.
Related NHI Mgmt Group resources
SolarWinds Supply Chain Compromise · Mimecast Certificate Compromise 2021 · Microsoft Midnight Blizzard Breach 2024 · SaaS and OAuth App Governance Guide · Active Directory and Entra ID Hardening Guide
How NHI Mgmt Group can help
Application identities in Entra ID and other identity providers often outnumber users and are rarely reviewed. We help organisations inventory them, remove the ones nobody uses, and put ownership, credential controls and monitoring around the rest. See our NHI and AI agent security training.
References
- Malwarebytes: Malwarebytes targeted by Nation State Actor implicated in SolarWinds breach (19 January 2021)
- Security Affairs: Malwarebytes email systems hacked by SolarWinds attackers (19 January 2021)
- The Register: Malwarebytes says its Office 365, Azure tenancies invaded by SolarWinds hackers, insists its tools are still safe to use (20 January 2021)
- SecureWorld: SolarWinds Threat Actor Targets Malwarebytes (22 January 2021)