In major gaffe, hacked Microsoft test account was assigned admin privileges
The hackers who recently broke into Microsoft’s network and monitored top executives’ email for two months did so by gaining access to an aging test account with administrative privileges, a major gaffe on the company’s part, a researcher said.
The new detail was provided in vaguely worded language included in a post Microsoft published on Thursday. It expanded on a disclosure Microsoft published late last Friday. Russia-state hackers, Microsoft said, used a technique known as password spraying to exploit a weak credential for logging into a “legacy non-production test tenant account” that wasn’t protected by multifactor authentication. From there, they somehow acquired the ability to access email accounts that belonged to senior executives and employees working in security and legal teams.A “pretty big config error”
In Thursday’s post updating customers on findings from its ongoing investigation, Microsoft provided more details on how the hackers achieved this monumental escalation of access. The hackers, part of a group Microsoft tracks as Midnight Blizzard, gained persistent access to the privileged email accounts by abusing the OAuth authorization protcol, which is used industry-wide to allow an array of apps to access resources on a network. After compromising the test tenant, Midnight Blizzard used it to create a malicious app and assign it rights to access every email address on Microsoft’s Office 365 email service.
In Thursday’s update, Microsoft officials said as much, although in language that largely obscured the extent of the major blunder. They wrote:
Threat actors like Midnight Blizzard compromise user accounts to create, modify, and grant high permissions to OAuth applications that they can misuse to hide malicious activity. The misuse of OAuth also enables threat actors to maintain access to applications, even if they lose access to the initially compromised account. 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. They created a new user account to grant consent in the Microsoft corporate environment to the actor controlled malicious OAuth applications. The threat actor then used the legacy test OAuth application to grant them the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes. [Emphasis added.]
Kevin Beaumont—a researcher and security professional with decades of experience, including a stint working for Microsoft—pointed out on Mastodon that the only way for an account to assign the all-powerful full_access_as_app role to an OAuth app is for the account to have administrator privileges. “Somebody,” he said, “made a pretty big config error in production.”
There’s good reason for tightly restricting the accounts that can assign such broad access to an OAuth app. It’s hard to envision a legitimate reason for assigning and maintaining such rights to a test account, especially one that reached legacy status.
What makes the configuration of the test account such a security taboo is that it broke the intended safety net the restrictions are supposed to provide. One of the most fundamental network security practices is the principle of least privilege. Accounts should always be configured with the fewest privileges required to perform their assigned tasks. In the case at hand, it’s hard to understand why the legacy test account needs administrator privileges.
“It’s a bit like having a Domain Admin user for the production system… except it’s a test domain, with no security, MFA, firewalls, monitoring etc.,” Beaumont wrote. Translation: A domain administer user has full administrative privileges to all devices connected to a network, including the domain controller and active directory that stores credentials and creates new accounts. As the most powerful users on a network, they should be cordoned off and rarely, if ever, made part of a production system. Allowing such accounts to go unprotected by strong passwords and other standard security measures would make the lapse worse.
Microsoft officials declined to explain the reasons for the configuration of the test account in the first place and why it was allowed to persist once it reached legacy status.
New hack, old tricks
Thursday’s update provided two additional details. The first was that Microsoft had detected additional breaches by Midnight Blizzard hitting other organizations and notified those affected. Hewlett Packard Enterprises said earlier this week that its network had also been hacked by Midnight Blizzard. That breach occurred in May and wasn’t discovered or contained until December.
The second detail: The password spraying used to access the test account was restricted to a limited number of accounts with a low number of attempts to access each one. Midnight Blizzard further reduced its malicious activity by conducting these attacks from a distributed residential proxy infrastructure. The method has been in use for several years, including in the 2020 SolarWinds supply chain attack, which was also carried out by Midnight Blizzard. By connecting to targets from IP addresses with good reputations and that are geolocated to expected regions, the hackers blended in with legitimate users.
Midnight Blizzard is one of several names used to track the hacking group, which the US and UK governments have said work on behalf of Russia’s Foreign Intelligence Service, also known as the SVR. Other names used to track the group include APT29, the Dukes, Cloaked Ursa, UNC2452, and Dark Halo.“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, to interact with the compromised tenant and, subsequently, with Exchange Online,” Microsoft officials wrote. “While not a new technique, Midnight Blizzard’s use of residential proxies to obfuscate connections makes traditional indicators of compromise (IOC)-based detection infeasible due to the high changeover rate of IP addresses.”
It’s unclear why Microsoft is only acknowledging this lesson now rather than in the aftermath of the SolarWinds campaign three years ago.