Business Email Compromise via Azure Administrative Privileges

Most of the time when you hear about business email compromise (BEC), you hear a single user account was compromised, leading to large amounts of financial damage. But in this instance, we found that an attacker had their hands on multiple accounts. 👀

To continue our series exposing the tradecraft around BEC, this blog will look at how Huntress found and helped stop a massive attack targeting multiple user accounts within a single organization. This was done via a compromised Azure Active Directory (soon to be known as Microsoft Entra ID) administrator account, and it was all found during the beta phase of our newest product, Managed Detection and Response (MDR) for Microsoft 365.

How the Attack Went Down

One of our SOC analysts was reviewing recent Microsoft 365 activity when she encountered several suspicious inbox rules that were added across multiple user accounts in the same Azure domain in rapid succession. Digging more into the data, she realized that all the inbox rules had been added on behalf of the users by one of the Azure administrators who was logging in from an unexpected location: Lagos, Nigeria.

Our SOC squad immediately reported the action to our partner, who went in to ensure the offending account had its password reset, multi-factor authentication (MFA) was added as a requirement and the inbox rules were removed. But of course, our investigation did not stop there… 

Due to the nature of the compromise, we wanted to answer:

• What else did the threat actor do while having the keys to the Azure kingdom? This meant we needed to go back to the very first potential signs of compromise.
• Were there other actions our partner needed to take to ensure their environment was secured? This meant we needed to audit every single user action taken while the threat actor was logged in.

What we found during this investigation bordered on the unbelievable, as it culminated in an epic battle between the legitimate Azure administrator and the threat actor over who had the credentials to various accounts. 🔥

Initial Attack Actions

Soon after the initial login from Lagos, the threat actor took immediate action to maintain access to the compromised Azure environment. 

How did they do this? It was quite simple: They picked another user account that was not utilized often, reset the credentials, then granted that account full admin privileges in Azure too. In other words, the attacker now had two accounts with full administrative privileges they could use to wreak havoc. 

As the attacker found out when testing though, just granting admin privileges didn’t get their alternate admin account the permissions they wanted. So, they then assigned actual licenses to this secondary account using the original compromised account. If this wasn’t clear before, hopefully it is now—an attacker that has the ability to log into an account with Azure global administrator permissions can really and truly take any action within the environment.

Give Me All the Emailz

Secure in knowing they have a backup method in case they lose access, the attacker began full smash-and-grab mode, granting themselves permission to view user inboxes and send emails on behalf of the users. Rather than continue targeting specific users, they just started doing this to users in large batches.

Then the attacker started a spree of adding email rules on behalf of said users via the first admin account, which would move emails from a specific legitimate-looking domain to the Conversation History folder and mark them as read. This would allow the attacker to browse the contents of these emails unnoticed while having persistent access.

Then things got even more interesting. The attacker modified the rules a few times, first adding a Gmail email and then an AOL email address to the rules. 

Whack-A-Mole Azure Style

All things must come to an end, and in our attacker's case, the legitimate admin was notified of their bad activities by Huntress. The admin then logged in to begin full remediation. We recommended temporarily shutting down the admin account and changing credentials, as a part of the remediations, as well as auditing permissions of any other accounts that had admin permissions. 

Initially, we saw the real admin pop in and reset the credentials and refresh the token for the compromised account (Account 1). It even proved successful—shortly thereafter a failed login attempt popped up where the attacker tried to log back in from the Nigerian IP.

But our attacker was quite persistent and continued to try to maintain and regain access.

Remember that second account they had compromised and made into an admin? Within minutes, they popped back on via the second compromised account (Account 2) using the persistent access that they configured at the beginning of the attack.

The attacker is, of course, worried about losing access. So they set up access to a third account (Account 3) using the same methodology as before where they reset a password for a user account not often used, then granted permissions.

What happened next was the attacker began using Account 3 to continue adding malicious rules, when the admin went in and disabled the account. Not to be outdone, the attacker popped right back into Account 2, reset the password for Account 3 and re-enabled it again, then logged right back into Account 3. 

Within about 15 minutes, the true admin did manage to regain control of all the compromised accounts. But it was quite the wild ride getting there.

Closing Thoughts

So how could all of this have been prevented? And what’s the best way to halt an attack like this where the attacker has access to multiple accounts?

• Any user with any kind of administrative privileges should be required to use multi-factor authentication (MFA). Not enforcing MFA is like locking a door and then taping the keys to the outside of the door so that anyone can grab them. Ideally, every user should have MFA enforced, but this is a non-negotiable for any user with administrative power.
• Consider using conditional access policies in Azure where possible that prevent users from logging in from countries they are not expected to be in. During an ongoing compromise, it may be prudent to quickly add a conditional access policy preventing logins from the same country as the threat actor while investigating the extent of the compromise and making longer-term security policy improvements.
• Regularly audit users in Azure that have administrative permissions. If they are on extended leave, consider revoking the permissions temporarily or setting up alerts for unexpected activity. If they no longer need the permissions, remove them.

As always, we hope this helps those of you combating threat actors in the wild west of Microsoft 365. If ever you decide you need someone to provide some Managed Detection and Response for Microsoft 365, you know who to call. 😉 

Continue to part five: Legitimate Apps as Traitorware for Persistent Microsoft 365 Compromise

Special thanks to @f0xtrot_sierra and Sharon Martin for their contributions to this blog post.