Microsoft recently pushed out an updated alert regarding the ongoing attack by Midnight Blizzard (also known as NOBELIUM, APT 29, Cozy Bear, and others). Midnight Blizzard is a nation-state threat group operating on behalf of the Russian government as part of the Foreign Intelligence Service of the Russian Federation (SVR). The APT group’s primary objective entails acquiring intelligence through enduring and meticulous espionage activities targeting foreign interests, primarily governmental bodies, diplomatic institutions, non-governmental organizations (NGOs), and IT service providers, where they can gain a foothold to access sensitive information.
The threat actors’ attack strategy resembles the one we simulate in our “Purple Teaming” workshop at Panther. The initial intrusion involves password spraying, followed by the attacker escalating privileges and gaining access to critical applications by exploiting OAuth. From there, the attackers could pivot into privileged applications, such as Microsoft corporate email accounts, where secrets were shared with customers.
The initial intrusion into Microsoft’s email systems was detected in January, apparently due to a successful password-spraying attack against a test system that did not have MFA enabled. Microsoft did not detect the initial compromise as the attackers leveraged “low and slow” methods to avoid detection. From the compromised system, the attackers could exploit OAuth to create, modify, and escalate privileges on accounts, create new OAuth accounts, and ultimately access Microsoft’s corporate email system.
Microsoft did not publish a traditional set of IoCs, such as IP addresses of attack infrastructure, as the attackers successfully obfuscated their activities through a distributed residential proxy infrastructure. In addition, it appears the attackers’ techniques leveraged Living-Off-the-Land (LOTL) attacks, so no information on any malicious binaries has been shared.
As many suspected, the initial intrusion into Microsoft’s email was just the first shoe to drop. In addition to sensitive information on Microsoft, the attackers could access secrets shared via email by Microsoft with customers. These secrets have been used to access customers’ code repositories, internal systems, and cloud infrastructure. Microsoft did not share why these secrets were shared with customers via email. Microsoft did not specify if the code repositories and infrastructure were limited to Microsoft’s ecosystem or if the attackers could pivot into third-party tools.
Microsoft made it a point to specify that “the attack was not the result of a vulnerability in Microsoft products or services,” however one could argue that the success of the attack was a vulnerability in Microsoft’s processes, something they admit in their advisory:
As we said late last year when we announced Secure Future Initiative (SFI), given the reality of threat actors that are resourced and funded by nation-states, we are shifting the balance we need to strike between security and business risk – the traditional sort of calculus is simply no longer sufficient. This incident highlighted Microsoft’s urgent need to move even faster. We will act immediately to apply our current security standards to Microsoft-owned legacy systems and internal business processes, even when these changes might disrupt existing business processes.
Regarding the initial intrusion that led to Microsoft’s compromise, Panther provides an example of a saved search that can be used to detect these low and slow password spraying attempts here; although the example uses AWS, any authentication log can leverage the same approach to look for authentication anomalies across a wider aperture of time. Microsoft also recommends auditing identities with “ApplicationImpersonation” permissions in Exchange Online. Microsoft advises customers to identify malicious OAuth apps leveraging their “Anomaly Detection Policies.”
Microsoft has stated they are contacting customers they believe have been impacted by the exposure of secrets. However, as the incident is still under investigation, it would be a good idea for customers to audit privileged accounts to ensure the identities are known, as well as pay special attention to any identity-related anomalies, new OAuth applications created, and their level of access. Additional guidance from Microsoft can be found here.
The compromise of Microsoft’s infrastructure raises the risk posed by relying solely on a cloud provider to provide services and monitor, telemetry, and security controls related to these services. Most cloud providers have a shared responsibility model; however, when things go wrong with the provider and there is a compromise on the vendor side, there is often a lack of transparency, and customers are often waiting for more details and not able to be proactive about mitigating the threat.
When a cloud vendor’s infrastructure is compromised it’s not only the unknowns, but also the challenge of being able to trust the telemetry you are seeing, if an attacker gains privileged access to systems they could easily modify security controls and suppress critical telemetry needed to identify a given threat. Having third-party monitoring of these systems can provide more confidence in what the security team is seeing, as well as identify anomalies the built-in detections the vendor provides may not detect.
Join us for a live, hands-on workshop. We will run through a similar threat scenario posed by Midnight Blizzard with actual attacks on identity, code, and DevOps infrastructure. In these workshops, you will learn to leverage detection-as-code to write real-time detections and use a Security Data Lake and purple teaming techniques.
BSides Tampa – Friday, April 5-6
Code-to-Cloud: Securing the Software Supply Chain
Location: BSides Tampa – University of South Florida 4103 USF Cedar Circle, Tampa, Florida
BSides Seattle – Saturday, April 27
Purple Teaming with Detection-as-Code for Modern SIEM
Location: Building 92, 15010 NE 36th St, Redmond 98052, WA
