Practical Protection: Malicious Azure Account Takeovers and What You Should Do About Them

There’s a Threat

It probably seems like every Practical Protection column follows a pattern: “There’s a threat! The threat is bad! You should do something!” I can’t even argue with this perception, because there are a lot of threats out there and new ones keep popping up all the time. This particular column is no exception—there’s a new threat (or an old threat with a new twist, maybe) that you need to be aware of so you can protect your environment.

Single Sign-on Considered Harmful?

One of the key selling points of Entra ID, Okta, and other centralized identity provider (IdP) systems is that they allow you to centralize account management into a single place. When I started my first large-enterprise software company twenty-plus years ago, I was flabbergasted to learn that I needed seven different sets of login credentials: one for email, one for our bug database, and so on. The proof is clear that, if you put users in a situation like that, they’ll pick weak passwords and then reuse them, so there’s an obvious and provable security benefit to using single sign-on (SSO) so that application access is brokered through a single IdP.

The problem, however, is equally obvious: a compromise or failure of the central IdP can affect all the applications that depend on that IdP. An attacker who can steal an account in the IdP can then use it to access any application for which SSO is configured on that IdP.

One manifestation of this problem is: if an attacker can compromise an Entra ID account, they will be able to access any on-prem and/or Azure resources to which that account has legitimate access.

Account Takeover Campaigns at Scale

This brings us to Proofpoint’s February 12, 2024 security advisory. They reported on an organized phishing campaign that targets accounts with fancy titles (“President & CEO” and “Chief Financial Officer” are examples). This may not sound like anything unusual, but there are some aspects of this campaign that are worth digging into more.

First, is the fact that the accounts are individually targeted. Unlike the lazy phishers who blast out millions of emails telling their would-be conquests that they’ve won a Stanley Cup, or free tools at Harbor Freight, or whatever, the attackers are putting in the effort to tailor phishing messages specifically to the targets. (Proofpoint apparently knows this since, as an email security vendor, their customers are giving them access to the message contents.) I would imagine that means these phishing messages are more convincing than the garden-variety crappy ones.

Once the attacker succeeds in tricking a victim, the next interesting part of this campaign is what they do. Proofpoint outlines five specific actions the attackers are taking:

1. Changing MFA settings on the target accounts. Despite Microsoft’s continuing Herculean efforts, only 38% of Entra ID accounts are protected with MFA, and those 38% are at risk if an attacker is able to access the account with legitimate credentials. Monitoring key accounts for MFA setting changes through the unified audit log or with a tool such as Sentinel is an appropriate defense here, but of course, it’s only useful if you implement it before the attackers arrive.
2. Stealing data. Naturally, an attacker can use a stolen account to read, copy, change, or delete anything that the legitimate account owner can do. There’s very little you can do to prevent this before the fact, of course, but sensitivity labeling and auditing may lower the risk somewhat.
3. Re-phishing (a term I just made up). Attackers can use the newly captured account to phish others. If you got a message from your own company’s CEO that was verifiably from her real account, you’d be less likely to doubt it, and attackers count on that. Of course, re-phishing can target both users in the same organization and external users.
4. Fraud and theft. A stolen account from a senior executive can easily be leveraged to steal money (“dear accounts payable: please pay Paul Robichaux US$50,000”), commit various types of HR-related fraud (“dear HR: please hire this North Korean spy”), or misbehave in various other, potentially expensive, ways.
5. Modifying mailbox rules to cover up mail sent, or received, in pursuit of the other activities on this list.

The Proofpoint report didn’t discuss the risk that the attacker could use the stolen account to move laterally into an Azure or AWS environment and steal or damage data. While this is a significant risk in general, it’s less of a risk for the accounts that are being targeted—if you want to get into someone’s Azure tenant and steal their data, using the CFO’s account probably isn’t the best means of access… but using the CFO’s account to phish the CFO and the director of engineering might actually work.

Leveraging Indicators of Compromise

Proofpoint lists several IOCs for this attack. I won’t repeat them here. Instead, I’ll encourage you to go look at them and then ask yourself whether you are currently able to check your network, tenant, and devices for those specific indicators. If not, why not, and what are you going to do about it? The ability to search for and verify the presence (or identify the absence) of specific indicators of compromise is a key capability. If your organization doesn’t have the ability to do things like look for user agent strings in logs, or verify whether specific domains have been queried or accessed through your DNS, then you’ve got some work to do in order to get to that point.

“Whodunit” Doesn’t Matter

Most of the attack campaigns we cover here at Practical 365 are attributed to some specific organization, whether a criminal gang or a nation-state. Proofpoint didn’t attribute this campaign, and it turns out that that’s completely fine. Unless you have the resources required to make the attacker stop, it doesn’t really matter exactly who’s attacking you; it’s much more important to be able to detect an attack, block it to limit the damage, and clean up afterwards. If you have good auditing and appropriate permission and detection systems in place, you’ll reduce the risk to your organization no matter who the attackers are.