Practical Protection: Hardening Against Midnight Blizzard-Style Attacks

It’s a truism in the public relations business that when you have bad news to announce, you do it on a Friday evening (ideally the Friday before a major holiday). This minimizes the likelihood that people will notice. Sure enough, Microsoft did exactly this with the January 19 announcement that they had been attacked by a “nation-state” actor known as Midnight Blizzard. Tony already covered the known basics of the attack for Practical 365; in this column, I want to try to draw some practical conclusions and actions that you can take to prevent similar compromises in your own environment.

You’re at Risk from Democratization of Attacks

Midnight Blizzard appears to be a state-sponsored actor; in particular, its attacks have been attributed to the Russian Foreign Intelligence Service (Sluzhba vneshney razvedki, or SVR). Many admins look at attacks such as this and, quite rationally, assess their own risk as low. After all, nation-state-level groups have to be choosy about who they target, and for what purpose. However, there’s a well-established trend in cybersecurity. At first, new attack methods or classes of vulnerability are exploited by the top tier of intelligence and security agencies. As knowledge of their methods and tools spreads (or leaks), criminal organizations (such as ransomware gangs) and less-skilled nation-states are able to take advantage of them. Inevitably, attack tools and methods continue to filter down until they are accessible to nearly anyone. Malware, ransomware, password-compromise attacks, phishing, and various other types of network intrusions have all followed this pattern. So the first conclusion I want to share with you is that this very sophisticated, complex attack pattern won’t be a one-off. The techniques the attacker used, whatever they are revealed eventually to be, may be deployed against you too.

The one exception to this conclusion may be attacks that depend on a very specific confluence of factors. For example, the Storm-0558 attacks mounted by China depended on a number of concurrent mistakes that Microsoft made, plus some good luck. The Triangulation attacks against Russian assets (including Kaspersky Security) depended on four different zero-day vulnerabilities (each worth millions of dollars on the vulnerability market) chained together—a combination that is very unlikely to happen often. However, in the same way that betting on extremely rare occurrences is a bad way to make money in Vegas, betting that the next democratized attack will be too esoteric to pose a risk is a bad bet.

Isolated Systems Aren’t Always Isolated

Microsoft’s description of the attack is fairly vague. What we know so far: the attacker used a password-spray attack to compromise a “legacy non-production test tenant account” and then pivoted from there. If you think about that for a second, you might be wondering how a “legacy non-production test tenant account” would have any access whatsoever to any production system. That’s a very good question, which as of now Microsoft has not answered publicly. However, it is a sad truth that many of us have “test” or “non-production” or “legacy” systems that are still interconnected with, and have access to, production systems. This exact path, from supposedly isolated systems directly to production, is exactly what bit Microsoft badly during the Storm-0558 attacks. That attack should’ve been a wake-up call to organizations of all sizes to find and disconnect linkages between systems that shouldn’t be connected.

Microsoft didn’t do this well enough, and you can now benefit from their failure—you have a second chance to isolate labs, test tenants, and other systems that are supposed to be disconnected. Better yet, if you have systems that you no longer need, decommission them. Attackers can’t compromise systems that are turned off.

Don’t Spray It

It’s hard to believe that a password-spray attack could be successful in 2024. And yet!

The deprecation of basic authentication throughout the service in October 2022 was supposed to help reduce the success rate of password-spray attacks. Undoubtedly, Microsoft will point to the still-relatively-low rate of MFA adoption as a contributing cause for why spray attacks still take place, but of course that doesn’t excuse the fact that their own enterprise was compromised in that way.

The conclusion here, at least until we get more details, is simple: enable MFA for everyone, everywhere, and use conditional access policies to ensure that you’re enforcing MFA where you need it (including on “legacy non-production test tenant account[s]”).

As a related note, Defender XDR has a playbook for investigating password spray attacks. If you use an XDR tool, find out what detection and investigation capabilities it has. Get proficient with it, starting with checking to see if there are any signs of previous attacks that maybe you didn’t notice.

The Finding-out Phase

There’s a popular Internet phrase that rhymes with “truck around and find out.” Unfortunately, we now live in a world where various nation-states (including the US, Russia, China, France, North Korea, Turkey, and Israel) have all gotten caught attacking competitors, inviting further retaliatory attacks. These attacks will inevitably trickle down to whatever level your organization is at. Prepare yourself by keeping your eyes open and patching regularly. This particular cat is probably not going back in its cyber-bag anytime soon, so now we all have to deal with the fallout.