- The Weekend Byte
- Posts
- How Midnight Blizzard Hacked Microsoft
How Midnight Blizzard Hacked Microsoft
Plus a primer on how OAuth works
Good morning. It looks like the SEC’s security event notification rules are starting to kick in. Microsoft came forward with news that an elite Russian hacking group hacked them and stole emails. HP wasn’t far behind with news that the same group hit them too.
So today, we’re covering all of this and a bit more, including:
WTF is OAuth?
Russian hackers used OAuth applications to steal Microsoft’s emails.
The lure of free flights busted a $130M money-laundering scheme.
-Jason
Spotlight
You OAuth to Know About This
In last week’s newsletter, I mentioned that Microsoft reported that Midnight Blizzard, a Russian hacking group, gained access to a legacy non-production environment and accessed email from senior level Microsoft employees. What we didn’t know last week was how they made the leap from non-production environment to production email.
Now we do…an OAuth application.
We’ll dig into exactly how in a bit, but first, let’s learn what OAuth is. Chances are that you’ve been using OAuth for quite some time and didn’t even realize it.
OAuth is a standard that allows a website or application to access resources hosted by other web applications on your behalf. Any of these sound familiar to you?
You log into a website using your Google or social media account.
You use Calendly or another meeting scheduling software to schedule meetings based on your calendar availability.
You allow a third party application access to your Google Drive to access your files.
There’s a near-endless list of integrations. And we have OAuth to thank for making that possible.
OAuth uses an Access Token to let other applications access data or services hosted on other third-party applications. Not only does it grant access, but it also says what resources it is allowed to access. For the Calendly example, it’s says that it can access your calendar, but not your emails.
To get that access token, applications works with the user to get authorization from another third-party application. In the example of Calendly and your Google Calendar, the OAuth process works like this:
𝗕𝗼𝗯 (𝗨𝘀𝗲𝗿): Hey, Calendly. I want you to access my calendar to see when I have free time to make scheduling meetings easier.
𝗖𝗮𝗹𝗲𝗻𝗱𝗹𝘆: Sure thing, Bob. Let me ask permission from Google so that I can access your calendar.
𝗖𝗮𝗹𝗲𝗻𝗱𝗹𝘆: Hey Google, your user Bob wants me to access their calendar. Are you cool with that?
𝗚𝗼𝗼𝗴𝗹𝗲: Sure thing, dawg. But first, I have to ensure Bob is cool about this.
𝗚𝗼𝗼𝗴𝗹𝗲: Hey Bob, Calendly tells me that you want them to access your calendar. If that's right, can you log in to your Google account? I'll then confirm with you the permissions you want Calendly to have.
𝗕𝗼𝗯 (𝗨𝘀𝗲𝗿): Hi Google! Yeah, I know Calendly. I sent them to you so they could access my calendar. I don't want them to access anything else in Google, though, just my calendar.
𝗚𝗼𝗼𝗴𝗹𝗲: Sounds good, Bob. Thanks for confirming. I'll handle it from here. Hey Calendly, I talked with Bob, cool guy. He said he's good with you accessing his calendar, but you can't access anything else. Take this access token, and you can access his calendar info. Oh, here's a refresh token too. When your access token expires, just send the refresh token, and I'll get you a fresh access token.
𝗖𝗮𝗹𝗲𝗻𝗱𝗹𝘆: Awesome, thanks Google. Hey Google Calendar, I need to check Bob’s calendar for free time. Here’s his access token.
𝗚𝗼𝗼𝗴𝗹𝗲 𝗖𝗮𝗹𝗲𝗻𝗱𝗮𝗿: Hey Calendly, great to see you. Let me check with my Dad, Google, to confirm this access token first. Hey Google, here's an access token that Calendly is saying is from Bob. Does it check out?
𝗚𝗼𝗼𝗴𝗹𝗲: Hey Google Calendar, yeah this checks out. Let him access Bob's calendar but nothing else.
𝗚𝗼𝗼𝗴𝗹𝗲 𝗖𝗮𝗹𝗲𝗻𝗱𝗮𝗿: Thanks Dad. Hey Calendly, everything checks out with this access token. Bob is only free on Monday at 9 AM because he’s busy learning about OAuth. What a nerd.
And there you have it, that’s how OAuth brokers access between applications for you. It’s a key technology that allows authorized sharing of data. Because sharing is caring as long but only as long as it’s authorized by the user.
Keep in mind how OAuth allows access between different applications as we dig into what happened with Microsoft…
Deep Dive
Microsoft Digs Out From Midnight Blizzard
We know from Microsoft’s SEC filing and blog post that Midnight Blizzard, the Russian hacking group behind the SolarWinds attack, gained access to a legacy non-production system. This allowed the attackers to “access a very small percentage of Microsoft corporate email accounts, including members of our senior leadership team and employees in our cybersecurity, legal, and other functions, and exfiltrated some emails and attached documents.”
Let’s dig into how…
Initial Access: The attackers used a password spray attack to guess the username and password combination for an account in the legacy non-production test tenant. Microsoft confirmed that the compromised user account did not have MFA enabled.
Unlike a brute force attack that guesses a large number of usernames and passwords, a password spray attack limits the number of usernames and passwords to commonly used passwords or those that were previously leaked in other data breaches (similar to a credential stuffing attack). This leaves much of the fluff out and only focuses on the most likely combination of credentials.
The attackers showed their level of sophistication by using a low number of login attempts to evade detection. They also routed the login attempts through “residential proxy infrastructure.” Said differently, they just routed traffic through residential Internet Service Providers (ISPs), possibly using compromised systems as proxies. Together with the low number of login attempts made it more difficult to detect and block.
Enter an old OAuth Application: The attackers hit the jackpot with the account they compromised. It had access to “a legacy test OAuth application that had elevated access to the Microsoft corporate environment.”
Said another way, this tenant had an old test application with administrative access to Microsoft’s corporate email. Yes, that’s as bad as it sounds. This provided the attacker the ability to do the following:
Create additional malicious OAuth applications (possibly to maintain persistence in the environment).
Create a new user account to grant consent from Microsoft’s corporate environment to the malicious OAuth applications.
Use the legacy test OAuth application to grant access to Microsoft email account’s mailboxes.
Compromising Email Accounts: That legacy test OAuth application was critical to the email access. Like the Calendly OAuth example above, the legacy test already had the necessary privilege to access data from Microsoft’s production email service. The attacker piggybacked off those rights to view emails from Microsoft employees in the following departments:
Senior leadership team
Cybersecurity
Legal
Other functions
The email access allowed the attackers to steal emails and documents from those users. Ironically, they targeted information related to their own hacking group, likely in an attempt to understand what Microsoft knew about them.
The Uproar: Reaction to this attack has predictability been outrage (do we expect anything different at this point)? Many latched onto the fact that the account did not have MFA in place. Others, including myself, focused on why this legacy non-production environment had elevated access to the production environment.
Security celebrity Alex Stamos pointed out a few other key issues:
The threat actors targeted additional companies. We know that Hewlett Packard Enterprise Company was one such company from another SEC filing.
The ability to detect this activity is largely dependent on Microsoft’s own security products, which cost more money.
Microsoft provided recommendations for organizations to defend against similar types of attacks. These include:
Audit the privileges level of all identities in your Azure tenants. Only grant access that is required for the functionality.
Audit identities that have ApplicationImpersonation privileges, which allow a user to impersonate another user and access their resources (like their email).
Search for malicious OAuth applications.
Only allow access to your tenant from managed devices.
Ensure all user accounts have MFA enabled.
Eliminate weak passwords.
All of these are easier said than done, of course, but the first step is to start paying attention to your environment.
News
What Else is Happening?
🇸🇪 The Finnish IT software and services company, Tietovry, is recovering from a ransomware attack that impacted data centers in Sweden. The attack occurred on the night of January 19th, when the company isolated the affected platform. Kudos to them for one of the most transparent and honest notifications I’ve seen in a while for a ransomware attack.
🛫 A fascinating story of how investigators used airline miles to bust a $130 million dollar money-laundering scheme. The ringleader booked flights for money mules and didn’t want to miss out on reward miles, so they used their frequent-flyer number. While great for free flights, it also helped the investigators track all of the money mules that were booked under the same account.
📞 The 2024 election will be known for how GenAI changed everything. We saw the first glimpse, where someone made a deep fake voice recording of President Joe Biden and urged voters not to vote in the New Hampshire primary election. I’m legitimately scared to see how this escalates.
If you enjoyed this, forward it to a fellow cyber nerd.
If you’re that fellow cyber nerd, subscribe here.
See you next week!
Reply