Heard at TEC: Don’t Feed The Script Kiddies – Enable MFA Now!

Talking Secure Systems at TEC 2022

The attendees at the TEC 2022 conference in Atlanta might feel that a conspiracy exists to scare them witless about the vulnerability of IT systems. Following Paula Januszkiewicz’s keynote about Revising Cybersecurity Priorities, they listened to Alex Weinert speak on Identity Perimeter and Defenses (Figure 2)

Alex is the Microsoft VP of Identity Security, and his team is responsible for protecting anything to do with identities across Microsoft, including Microsoft 365 and other cloud properties like Xbox and Microsoft’s consumer services. What he had to say has immediate relevance to administrators and anyone associated with securing Azure AD and Microsoft 365.

Only 26.64% of Azure AD Accounts Use MFA

During his session, Alex kept on returning to the need to secure accounts with multi-factor authentication (MFA). He noted that over the four-year period from 2018 to today, the percentage of Azure AD accounts protected by MFA grew from a paltry 1.8% to 26.64%. Alex said that roughly 6% is due to Microsoft enforcing MFA on tenant admins through Security Defaults. These tenants tend to be smaller, which then means that many large enterprises continue to use unprotected accounts.

As it turns out, there’s a typo on the slide shown in Figure 3. When we chatted after the presentation, Alex clarified that the real number of admin accounts (those holding an Azure AD admin role) protected by MFA is 34.15%. That number sounds impressive, but it’s not when you consider that nearly two-thirds of accounts with Azure AD admin roles rely on user names and passwords to stop attacker compromise. This is especially true when you consider the massive growth in password spray attacks to 5 million (observed by Microsoft) annually. As Paul Robichaux observed last year, it’s well past the time for people to grasp this nettle and use MFA for both admin and non-admin accounts.

It’s also the case that people continue to use admin accounts that are not dedicated to performing administrative work. When people use admin accounts for email, it’s more likely that these accounts will be compromised by phishing and other attacks. Break the habit of a lifetime and stop using admin accounts for day-to-day email.

Rather depressingly, Alex said that Microsoft consumer accounts are 50 times less likely to be compromised than enterprise accounts. Why? Simply put, Microsoft sets and enforces policies to protect consumer accounts. They rely on customers to protect Azure AD accounts, and that just doesn’t happen sometimes.

Quashing Illicit Consents

Alex covered several techniques exploited by attackers to penetrate tenants such as stolen token replay and illicit consents (to Graph and other permissions). Smarter apps will help prevent token reply by detecting conditions when an app reuses a token in an unusual manner (for instance, the IP address for the connection is different from the token’s last use) and force reauthentication.

In terms of detecting illicit permission grants, tenants should keep a close eye on OAuth permissions held by the service principals for Azure AD enterprise, registered apps, and managed identities. If you find that a service principal receives a new permission, ask why that permission is necessary and who assigned it. This article describes how to use the Microsoft Graph PowerShell SDK to create a permissions reports for service principals.

The MSP Target

Managed Service Providers (MSPs) run many Microsoft 365 tenants on behalf of companies. Alex pointed out that the admin accounts used by MSPs “have a big target painted on them” because attackers have figured out that if they compromise an MSP account, it allows them entry to multiple tenants.

The same logic applies to contractor accounts. Contractors tend to work with multiple companies, so if their accounts are compromised, it could create a pathway into multiple Microsoft 365 tenants. The learning here is to make sure that any accounts used by MSPs or contractors are secure, and then double-check that they are secure.

Vulnerability of On-Premises Systems

Another cardinal rule for security is that on-premises AD accounts that are synchronized to Azure AD should never hold admin roles. Many attacks (like last year’s HAFNIUM episode) focus on penetrating on-premises environments with the aim of penetrating weaker security barriers and then following through to the cloud. As Alex said, if an attacker compromises the on-premises environment, recovery is probably a case of burn and redo. It’s even worse if they compromise both on-premises and cloud because that leads to redoing both environments. At that point, “you’ll be using carrier pigeons for communication.”

This Microsoft guide is a useful resource to learn how to protect Microsoft 365 from attacks that originate on-premises.

Stop the Script Kiddies

Alex ended his session by appealing to the audience to drive the use of MFA. He said that MFA will stop attacks like password sprays launched by script kiddies (and make Microsoft 365 less of a target). If tenants use MFA methods that are not susceptible to phishing like FIDO keys, Windows Hello, and the Microsoft Authenticator app, they’ll be a lot more difficult to attack and a lot less likely to experience a compromise.

Speaking of Microsoft Authenticator, another nugget of information dropped into the session was that 1% of all users respond to an MFA authentication prompt without thinking. Attackers can take advantage of that human weakness to work around MFA, but forcing people to take an action, such as selecting a number to match in the Authenticator app, stops that problem.

One Last Thought

Alex’s session focused on Azure AD. That’s natural because he looks after identities. But one thing that every Microsoft 365 tenant with Exchange Online licenses can do is to put an authentication policy in place to block attempts to connect using insecure email protocols. The great thing about an authentication policy is that it kicks in before Azure AD attempts to authenticate an account. If the connection comes in over a blocked protocol like IMAP4 and POP3, the attempt is stopped immediately. The advantage is that potential attackers don’t get any chance to test if an account exists or if they have the correct credentials, and that’s a lovely thing.