The recent Midnight Blizzard state-sponsored espionage group attack on Microsoft provides another wake-up call to organizations: The increasingly complex web of workload-to-workload interconnectivity, combined with the lack of workload identity governance, is providing bad actors with new, unsecured attack surfaces.
This analysis provides a rundown of the attack, highlights Microsoft’s guidance, and then introduces steps you can take to intelligently enforce secure access that goes beyond just trying to outrun the hackers.
Here are some key highlights, taken from Microsoft’s post, of the attack:
Threat actors like the Midnight Blizzard group compromise user accounts to create, modify, and grant high permissions to OAuth applications that they can misuse to hide malicious activity.
As part of their multiple attempts to obfuscate the source of their attack, Midnight Blizzard used residential proxy networks, routing their traffic through a vast number of IP addresses that are also used by legitimate users. This makes traditional indicators of compromise (IOC)-based detection infeasible due to the high changeover rate of IP addresses.
Midnight Blizzard leveraged their initial access to identify and compromise a legacy test OAuth application that had elevated access to the Microsoft corporate environment. The actor created additional malicious OAuth applications. Midnight Blizzard leveraged these malicious OAuth applications to authenticate to Microsoft Exchange Online and target Microsoft corporate email accounts.
Ultimately, we’re left wanting more detailed information about specific steps of the attack, which would have given us the appropriate details to better isolate the most critical and the least effort/most reward responses to this incident. (We weren’t the only ones who thought the details didn’t add up.) But, lacking that, we must go on our understanding plus infer likely attack vectors from Microsoft’s recommendations.
Here’s What Microsoft’s Recommendations Say (And Don’t Say)
In Microsoft’s write-up, researchers devoted significant space to defining a set of activities you can take to protect your MSFT-based APIs, as well as Exchange.
Rather than repeat all of those recommendations here (here’s a link to the blog post again so you can review them), let’s summarize them – and see what’s missing.
Their primary recommendations are as follows:
- Understand who has privileged access and why. In particular, pay attention to identities, and understand privileges in relation to identity.
- Manually reduce privileges. In particular, examine service accounts (service principals) as they are often highly privileged.
- Eliminate insecure passwords. (Apparently, this is still advice.)
- Monitor and alert user identity activity with Microsoft Entra.
- The post also provides specific hunting rules for Microsoft Sentinel and specific alerts for Microsoft Entra ID Protection
Technically, Microsoft’s security guidelines are sound. But you can go further with measures. Let’s consider the similarities between the advice aimed at users and the strategies needed for managing workloads. Enhancing your efforts in this way can significantly bolster your defense against sophisticated attacks like Midnight Blizzard.
How Workload Identity Security Can Play a Big Role
Our main observation is that, while Midnight Blizzard used forgotten user accounts to infiltrate Microsoft, once inside the gates their goals were to access highly privileged service accounts (service principals) thereby giving them both freedom and access to move laterally within the system. Moreover, once this highly privileged position was achieved, the attackers were able to create more OAuth applications, forcing Microsoft into a serious game of whack-a-mole.
Given modern application design and the distributed workforce, network perimeter security is no longer as strong a defense as it used to be. We think taking Microsoft’s advice and more specifically applying it to workload-to-workload access will provide greater defense against malicious hackers accessing sensitive applications or executing lateral movement within your infrastructure. More specifically:
- Cryptographically verify the identity of an application (not just users) before it attempts to access other, sensitive systems. Much like Microsoft recommends securing users more completely, starting with the identity of the workload will significantly reduce the risk of a malicious application taking action. Attestation should be done on a very regular basis (every few hours or minutes depending on your security requirements.) Attestation must use corroborating data from the operating environment, not just IP addresses, much like you’d watch sign-on properties of a user to further verify valid access.
- Don’t expect IP addresses to provide the data you need. Instead, logging based on workload identity will provide the details you need to quickly and further analyze access via OAuth. Patterns can be based on workload identity instead of proxy IP addresses. This will make the hunting and detection rules Microsoft describes more effective.
- Avoid hard-coded service principal secrets, API keys, or access tokens within applications. Much like Microsoft recommends moving users away from insecure passwords, application-to-application access often depends on static and long-lived keys stored within client applications. Secret sprawl makes it easier for bad actors to find an access point to the rest of your system. Instead, inject credentials into request flows for just-in-time access, after policy evaluation has occurred.
- Use conditional access for workloads, not just users. Additional factors should be layered into access policies, including time of day, geography, frequency of access, and information on how the security posture of the workload requesting access is being managed.
- Implement a separate system to attest to workload identities and evaluate access policies. In the event that service accounts are infiltrated, you should not have the same system validating access rights.
- Consistently implement controls across all environments and for all services. Microsoft’s advice assumes the only services and data at risk are Microsoft. You likely face similar risks in other clouds and on-premises as well as SaaS services on which you depend. You may have cross-cloud connectivity where some of Microsoft’s recommendations may fall short or simply not apply.
We’ll continue to monitor this incident, as well as be on the lookout for the next Microsoft incident that involves workload-to-workload access.
We encourage you to enhance or start a project to manage how workload access is enforced, audited, and governed within your organization.
If your organization extensively uses custom-developed software or scripts to interact with distributed applications, APIs, or SaaS services, you may benefit from implementing a Workload Identity and Access Management (IAM) system like Aembit, which manages access based on workload identities, instead of secrets.