Cybersecurity provider Malwarebytes is the latest company to acknowledge that it saw an (apparently limited) breach in the wake of the Solarwinds compromise activity, with the threat actor responsible accessing one of the Santa Clara-based firm's Microsoft Office 365 tenants.
"We, like many other companies were recently targeted by the same threat actor [which abused] applications with privileged access to Microsoft Office 365 and Azure environments" CEO Marcin Kleczynski said.
He added: "We performed an extensive investigation of both our cloud and on-premises environments for any activity related to the API calls that triggered the initial alert. 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. We do not use Azure cloud services in our production environments."
"We performed a thorough investigation of all Malwarebytes source code, build and delivery processes, including reverse engineering our own software. Our internal systems showed no evidence of unauthorized access or compromise in any on-premises and production environments. Our software remains safe to use." CEO Marcin Kleczynski
Microsoft -- which tipped Malwarebytes off the breach and which has performed a crucial role in pushing back against the campaign -- has born the brunt of secondary tactics used by the attackers to gain access to cloud tenants, typically by (once in a network) stealing an AD token-signing certificate and using it to forge tokens that give it cloud access.
(As many security professionals have noted, these “illicit consent” attacks are difficult to detect; there is no malware involved, and the activity may not raise any alarms within the compromised cloud tenants.)
In a separate new report today out by Microsoft, Redmond highlighted the impressive opsec measures of the attackers, which included "methodic avoidance of shared indicators for each compromised host... each Cobalt Strike DLL implant was prepared to be unique per machine and avoided at any cost overlap and reuse of folder name, file name, export function names, C2 domain/IP, HTTP requests, timestamp, file metadata, config, and child process launched. This extreme level of variance was also applied to non-executable entities, such as WMI persistence filter name, WMI filter query, passwords used for 7-zip archives, and names of output log files."
Microsoft added: "Applying this level of permutations for each individual compromised machine is an incredible effort normally not seen with other adversaries and done to prevent full identification of all compromised assets inside a network or effective sharing of threat intel between victims."
Malwarebytes breached: How are the SolarWinds hackers accessing Azure and O365?
In a detailed 35-page report published January 19, Mandiant spelled out how the threat actors behind the campaign -- wich saw FireEye, and ~10 federal agencies hit -- are pivoting to Azure or O365 tenants. In brief (in FireEye's words), the four primary approaches are as follows.
1: Golden SAML
"Steal the Active Directory Federation Services (AD FS) token-signing certificate and use it to forge tokens for arbitrary users (sometimes described as Golden SAML). This would allow the attacker to authenticate into a federated resource provider (such as Microsoft 365) as any user, without the need for that user’s password or their corresponding multi-factor authentication (MFA) mechanism."
2: Modify trusted AZURE AD domains
"Modify or add trusted domains in Azure AD to add a new federated Identity Provider (IdP) that the attacker controls. This would allow the attacker to forge tokens for arbitrary users and has been described as an Azure AD backdoor."
3: Grab global admin accounts
"Compromise the credentials of on-premises user accounts that are synchronized to Microsoft 365 that have high privileged directory roles, such as Global Administrator or Application Administrator."
4: Add a new application credential as a backdoor
"Backdoor an existing Microsoft 365 application by adding a new application or service principal credential in order to use the legitimate permissions assigned to the application, such as the ability to read email, send email as an arbitrary user, access user calendars, etc."
For more indepth details on the above and mitigation techniques, read here. (pdf)
For those who haven't availed themselves of CISA's free tool "Sparrow” to help track such potential cloud compromise (this helps users check the unified audit log in Azure/M365 for certain IoC’s, list Azure AD domains, and Azure service principals and their Microsoft Graph API permissions to identify potential malicious activity) or CrowdStrike's own free tool, FireEye has added its own to the mix: "Azure AD Investigator".
CrowdStrike has blamed Azure for having admin tools that are allegedly inadequate for those wanting to review permissions across AD environments. The endpoint protection specialist hit out last month at a lack of clear documentation, an inability to audit via API, and warned that “auditing Azure AD permissions… is a time-consuming and complex process”.
