The Latest Microsoft Midnight Blizzard Breach is a Wakeup Call for SaaS Security

Originally published by Valence.

Microsoft recently published new guidance on the nation-state attack that they initially disclosed on January 19. According to Microsoft, the Russian state-sponsored threat actor Midnight Blizzard (also known as NOBELIUM or APT29) was able to leverage a test tenant account and a legacy OAuth application to gain access to corporate email accounts, including members of senior leadership, cybersecurity team, legal team, and others, and exfiltrated some emails and attached documents.

What we know so far?

• The attackers initially gained access via a password spray attack to non-production test tenant account (human identity) that didn’t have MFA enabled
• To avoid detection, the attackers leveraged a legacy test OAuth application (non-human identity) that had full access to mailboxes and to read emails
• The threat actor created additional malicious OAuth applications and granted them access to Microsoft’s corporate environment using newly created user accounts
• The malicious OAuth applications authentication to Microsoft Exchange Online and target Microsoft corporate email accounts. The attackers used residential proxy networks to obfuscate the source of their attack and leverage IP addresses of legitimate users

While there are probably still more unknowns than knowns regarding this breach, the early Microsoft disclosure, which included a Form 8-k filing on a major or material event to the U.S. Securities and Exchange Commission (SEC), discloses important information that can help organizations to improve their SaaS security posture. Below we’ll discuss a few key initial learnings from the disclosure, what organizations can do about it, and whether or not this is a one time breach (hint: it’s not). We’ll continue to follow details about the breach and will update accordingly.

Is this a vulnerability or misconfiguration?

This breach appears to be a classic SaaS/cloud focused breach that doesn’t leverage vulnerability exploitation, zero days or any manipulation of incorrect software logic. The initial Microsoft posts mostly focus on misconfigurations that were performed on the customer side of the shared responsibility model (even though the customer and vendor are the same here, it could have happened to any Microsoft customer). The attackers performed multiple changes to the tenant configurations including leveraging a test tenant account that didn’t have proper multi-factor authentication (MFA) configuration, abusing legacy OAuth applications that were over privileged, creating new human and non-human identities, and more. All of these actions can be used for legitimate purposes and are the responsibility of the customer or the user of the SaaS application to ensure they are properly configured.

The attackers were able to move from human to non-human identities and to move from a test non-production environment to the production corporate environment. This highlights how when it comes to SaaS applications, gaining a holistic view of your posture across your identities (human and non-human), third-party integrations, security configurations, and other misconfigurations is critical to ensure critical data is secure. SaaS applications, like Microsoft 365, hold the most critical data and privileges in modern enterprises so ensuring the security team manages potential attack paths that can leverage the complexity and interconnectivity of these applications is now more critical than ever.

Should I care about my test environment?

We often hear from customers that they are less concerned about their test environments - whether it's a development environment, a sandbox environment, or anything similar. Too often we encounter situations where production data is copied to these test environments for testing purposes or engineers grant production access to code, applications or automation that they are developing in the test environment before deploying it to production. In this case, the attackers identified a legacy test OAuth application that allowed them to elevate their access from a test environment to the Microsoft corporate environment. Later on, the attackers leveraged such access to grant themselves the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.

Even though non-production environments are typically considered less important than production environments - it is important to ensure proper monitoring of their security configurations and activities. Attackers will often look for the weakest link in an organization’s security posture - which in this case was a series of configurations that allowed both the initial access due to lack of MFA and the privilege elevation from the test environment to the corporate environment. To avoid such misconfiguration risks, we always recommend that developer and sandbox environments are treated similar to production environments in terms of the enforced security controls. A great start would be ensuring identities have least privilege and strong authentication, reducing unnecessary interconnectivity with production systems, and removing unneeded confidential or sensitive data from these systems.

Why should I enforce proper lifecycle management?

Another common misconfiguration that we see in SaaS applications are abandoned resources - which could be dormant accounts, legacy API/OAuth tokens, inactive external data shares, and more. Too often, security teams treat these unused resources as low risks since they are not used by the business. The main reasoning for that is that the assumption is that the used resources have a higher likelihood of getting stolen by a threat actor. While this may be true, the return on investment (ROI) on removing the unnecessary resources is in many cases significantly higher. If a resource is unused, in many cases the business wouldn’t mind if it’s removed or disabled, which can reduce the potential attack surface with little to no friction to the business users.

Once again this is a case where the attackers were searching for the weakest link in the SaaS security posture. Used resources typically mean tighter security controls such as MFA, more rigorous monitoring for abnormal activity, etc., where abandoned resources are often, as the name entitles, just abandoned. Attackers recognize these resources are likely a blindspot for security teams and leverage them to gain unauthorized access and remain undetected. Therefore, we strongly recommend enforcing lifecycle management for any SaaS identity, token, data share, security configuration, etc. to reduce unnecessary access and risk and reduce the likelihood of a blindspot. Implement manual or automated regular review of your SaaS configurations to ensure you timely remove anything that you see as a risk or that is no longer necessary for your business.

Is this a one time SaaS-focused breach?

Unfortunately, this case is not the first and not the last SaaS breach that will leverage similar techniques. The same threat actor also recently targeted Microsoft Teams users and gained unauthorized access to corporate emails at Hewlett Packard Enterprise (HPE). They also used similar OAuth applications abuse techniques in the infamous 2020 Solarwinds breach and based on Microsoft’s Threat Intelligence team “Midnight Blizzard is also adept at identifying and abusing OAuth applications to move laterally across cloud environments and for post-compromise activity, such as email collection”. But leveraging SaaS misconfigurations, abusing abandoned resources and targeting non-human tokens is becoming a common practice by threat actors - large and small.

The Drizly data breach that led to the FTC taking action against the CEO of the alcohol delivery company is another example of similar patterns. In this case, the company granted GitHub access to an executive for a one-day hackathon and never removed that access, even when the executive moved to a different subsidiary. To make things worse, the account did not have MFA configured and did not have a unique complex password. This allowed a malicious actor to reuse credentials obtained from another breach to gain unauthorized access to the executive’s GitHub account and therefore to Drizly’s GitHub repositories. The attacker then leveraged credentials, source code and vulnerabilities they discovered to gain access to Drizly’s production environment - including databases containing millions of records of user information - which led to exfiltration of more than 2.5 million records.

These are just several of dozens of SaaS breaches that were disclosed over the past few years.