This article is more than 1 year old
Malwarebytes says its Office 365, Azure tenancies invaded by SolarWinds hackers, insists its tools are still safe to use
Points finger at privilege escalation via application rights in Azure AD, which Microsoft says is as designed
Security company Malwarebytes suspects a breach of its Office 365 and Azure tenancies is by the same attacker behind the SolarWinds hack, but reckons flaws in Azure Active Directory security are also to blame.
Malwarebytes, whose products include widely used anti-malware tools for consumers and businesses, said that it does not use SolarWinds but believes that the same attacker used "another intrusion vector that works by abusing applications with privileged access to Microsoft Office 365 and Azure environments".
The attack was spotted because of suspicious activity reported by Microsoft's Security Response Center.
The intruder "only gained access to a limited subset of internal company emails" said Malwarebytes, and there was no evidence of unauthorised access to internal or on-premises and production environments. Malwarebytes also checked its source code and build processes including "reverse engineering our own software" but could not find any evidence of compromise, concluding that "our software remains safe to use."
I don't really see why credentials can be assigned to default service principals this way and what a possible legitimate purpose would be of this
How was Malwarebytes breached? There is some but not complete information on this subject in the company's report. On Microsoft's cloud, there are directory objects called service principals which can have privileges assigned to them. Service principals are specific to an Azure AD tenancy and represent an application in that tenancy. When admins give permission to an application, they actually give permissions to its service principal.
Users are not the same as applications, but there are techniques by which a user can log in as an application. To do this, admins can assign a password or a certificate to a service principal, and then log in as that service principal, thereby gaining the same privileges as the application.
Security researcher Dirk-jan Mollema considers this to be a vulnerability since it allows application administrators to escalate their privileges.
"I don't really see why credentials can be assigned to default service principals this way and what a possible legitimate purpose would be of this," he said. "In my opinion, it shouldn't be possible to assign credentials to first-party Microsoft applications. The Azure portal doesn't offer this option and does not display these 'backdoor' service principals credentials, but the APIs such as the Microsoft Graph and Azure AD Graph have no such limitations." He reported the issue to Microsoft but was told that it was documented behaviour and therefore not a vulnerability.
Malwarebytes said this was the mechanism for its own breach. "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," the company said.
It is still necessary to have privileges in order to escalate them so what was the initial attack against MalwareBytes? This detail is not revealed. The nearest thing is a reference to this US government advisory which states that password guessing or unsecured service credentials might (in the general case) be used to compromise an Azure AD environment. Since MalwareBytes says that its internal network was not breached, logic dictates that some external method like this was used.
MalwareBytes' report shines the spotlight on Azure AD security. In this context, the recent FireEye report on monitoring Azure AD security is relevant, noting also that the widely used AD Connect tool, which synchronises on-premises Active Directory with Azure AD, means that villains with unauthorised access to on-premises AD can soon extend their access to the cloud environment. In a report from March 2019, Mollema showed how an AD Connect server can be exploited to gain full privileges on Azure AD.
Symantec has recently reported on the "Raindrop" malware, which it believes is sometimes deployed by a compromised SolarWinds installation. Raindrop allows remote command and control. Symantec noted activity on a victim's computer that installed DSInternals, which they say "is a legitimate tool which can be used for querying Active Directory servers and retrieving data, typically passwords, keys, or password hashes."
Securing Azure AD is challenging and MalwareBytes references the CrowdStrike tool as useful for mitigation. Along with the tool, CrowdStrike lists a range of steps admins can take, including reviewing access awarded to third parties such as partners and resellers, limiting objects synchronised with AD Connect, cleaning up unused applications registered with Azure AD, enforcing multi-factor authentication for all users, and reviewing Exchange for suspicious rules such as mailbox forwarding.
Microsoft's hybrid approach to the cloud increases the number of possible attacks, but without Microsoft's security intelligence tools picking up suspicious activity, Malwarebytes might still be unaware of the breach of its systems. ®