How Azure AD Could Be Vulnerable to Brute-Force and DOS Attacks

Azure AD is the de facto gatekeeper of Microsoft cloud solutions such as Azure, Office 365, Enterprise Mobility. As an integral component of their cloud ecosystem, it is serving roughly 12.8 million organizations, 950+ million users worldwide, and 90% of Fortune 500 companies on a growing annual basis. Given such a resume, one might presume that Azure Active Directory is secure, but is it?

Despite Microsoft itself proclaiming “Assume Breach” as the guiding principle of their security strategy, if you were to tell me a week ago that Azure or Office 365 was vulnerable to rudimentary attacks and that it could not be considered secure, then I probably would have even laughed you out of the room. But when a client of ours recently had several of their Office 365 mailboxes compromised by a simple brute-force attack, I was given no alternative but to question the integrity of Azure AD as a whole instead of attributing the breach to the services merely leveraging it and what I found wasn’t reassuring.

After a simple “Office 365 brute force” search on google and without even having to write a line of code, I found that I was late to the party and that Office 365 is indeed susceptible to brute force and password spray attacks via remote Powershell (RPS). It was further discovered that these vulnerabilities are actively being exploited on a broad scale while remaining incredibly difficult to detect during or after the fact. Skyhigh Networks named this sort of attack “Knock Knock” and went so far as estimating that as many as 50% of all tenants are actively being attacked at any given time. Even worse, it seems as if there is no way to correct this within Azure AD without consequently rendering yourself open to denial of service (DOS) attacks.

Source: https://cssi.us/office-365-brute-force-powershell/

In fact, this sort of attack is so prevalent that it happens to be one of the biggest threats to cloud tenant security at Microsoft according to Mark Russonivich (CTO of Azure) and is among several reasons that Microsoft itself advises their customers to enable multi-factor authentication (MFA) for all users and implement advanced threat intelligence available only to E5 subscription levels or greater; basically requiring companies to give Microsoft more money to secure their own solutions. But MFA also doesn’t impede hackers from cracking passwords or protect businesses from a DOS attack nor does it help those that are unaware of its necessity as many tenants are at present.

Source: https://docs.microsoft.com/en-us/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/mfa-connect-to-exchange-online-powershell?view=exchange-ps

Further and since RPS does not work with deferred authentication (DAP) and MFA, partners consisting of consultants, managed services and support providers also cannot use their partner credentials to connect to the tenants of their clients via RPS for advanced administration and scripting. Even though they can easily manage their clients via a browser-based admin center with MFA, they often have to resort to creating admin accounts within Office 365 tenant itself instead, but others do it simply for ease of access to the admin console or for when they are not the Partner On Record. In turn, these accounts are precisely what many of these attacks are targeting, often unbeknownst to admins, and Deloitte’s breach is a perfect example of such a scenario.

Unfortunately, these accounts are often stripped of MFA security to make them more convenient and accessible for the multitude of support and operations staff to use while working for various companies offering support services and they seldom change upon company exit or expire. By default in Office 365 and on top of being vulnerable to being cracked and breached, the password expiration policy is further set to a 730-day expiration and further disabled, rendering accounts vulnerable to a prolonged breach at that. Needless to say, they are ripe for attack and this exact scenario is what enabled a hacker to have unabridged administrative access to Deloitte’s Exchange Online tenant for 6+ months.

Complicating matters even further, the natural solution to this problem renders the tenant vulnerable to DOS attacks by virtue of being able to lock users out of their accounts for a fixed duration imposed by Azure AD; but this is still in preview phases. For example, by default Azure AD Smart Lockout (Preview Stage), which is still in preview, is configured to allow 10 password attempts before subjecting the account to a 60-second lockout, giving attackers a theoretical limit of 14,400 attempts per account/per day. You could decrease the threshold to 5 and increase the duration to 5 minutes protect against breaches, reducing attempts to 1,440 per day, but this would create the potential for downtime for users whenever their accounts are being attacked with brute force and password spray attacks.

Source: https://cssi.us/office-365-brute-force-powershell/

However, Tyler Rusk at CSSI also called out that Microsoft doesn’t seem to throttle or limit authentication attempts made through RPS. As shown, Tyler was able to surpass the theoretical 14,400 per day limit listed in Azure AD Smart Lockout Preview without added logic, moving at a rate of 48,000 per day had he let it run for a 24 hour period or an est. 17,520,000 attempts over 365 days. However, there are obvious ways to optimize these efforts even further through via background jobs (start-job cmdlet) by essentially running attacks asynchronously instead of synchronously while optimizing for custom lockout limits, max attempts, and minimal detection. The possibilities are endless with regard to password spray attacks for obvious reasons. To be fair to Tyler and CSSI though and in my opinion, they didn’t need to leverage such measures to validate their concern.

If their lockout feature were to work though and if you were able to reduce the threat surface in the manner above, you would then have to contend with the hard countdown of the duration time. It’s immutable which means that users have to wait for it expire in order to render the account accessible again. The unlock cannot be expedited administratively at present. As such, it can just as easily result in an intentional DOS for end users if they or an unintentional DOS while running the possibility of exposing the attack; that is when/if it starts actually working. Obviously protecting from breach takes precedent over downtime, but becoming prone to DOS attacks is hardly a consolation prize.

body[data-twttr-rendered="true"] {background-color: transparent;}.twitter-tweet {margin: auto !important;}

Account Lockouts: for when you want malware and lazy users to cause denial of service attacks because you're too cheap to use proper intrusion protection software.

 — @NerdPyle

Banned passwords nor MFA cannot protect against DOS or brute-force attacks either, only against the breach itself. In fact, when brute forcing an account protected by MFA, the MFA challenge itself can be treated as confirmation of a valid cracked username and/or password. In turn, they can then begin to try these credentials in other places which may not be protected by MFA as users and admins alike tend to keep them as similar as possible in multiple directories so that they’re easy to remember. I’ll defer to Ned Pyle of Microsoft as to whether this applies to his employer and their partners.

Summarizing matters thus far, you can brute force accounts housed in Azure AD used via RPS. Obvious solutions for this such as MFA, customized password blocking, and advanced threat intelligence are either ineffective, insufficient, paywalled, and/or generate significantly more overhead in order to offset these vulnerabilities. Further, these solutions are often ignored by lazy admins, consultants, and managed services providers and many may be oblivious to this threat entirely; possibly even to breaches of their own. Deloitte has proven that this can even hit the best of them.

As offensive as all of this may seem though, it’s important to remember that AD was never designed to be public facing, quite the opposite. It has actually always been inherently vulnerable to brute-force, password spray, and DOS attacks by design. AD has always been designed to be implemented in conjunction with various other counter-measures in order to maintain its integrity. This includes but certainly is not limited to relying on physical security measures such as controlled entry and limiting the ability to access the domain to those that make it past physical security measures successfully; with the obvious exception of VPN users. This is nothing new.

That said, AD was never, ever, meant to be the sole source of security for IT infrastructure and is fundamentally dependent on other security measures in order to be effective. Consequently, AD becomes markedly more vulnerable when other pre-emptive methods fail or are non-existent. Put simply, such breaches should be the expectation when depending on Azure AD alone for IT security, and this sadly applies to any Office 365 tenant with its default security settings. However, understanding its limitations helps us illuminate ways to harden Azure AD and mitigate these problems just the same.

It almost goes without saying, but none of the measures to necessary to patch these vulnerabilities are free to companies leveraging these services at present. Even if Microsoft were to fix this, who is to say that something else just as simplistic and embarrassing isn’t hiding around in the corner or already being used? That said, avoiding products backed by a 20-year-old security system streamlined for vendor lock-in seems like a viable solution to avoiding this problem in the first place.

Source: https://www.microsoft.com/en-us/microsoft-365/blog/2017/11/13/how-organizations-are-connecting-their-on-premises-identities-to-azure-ad/

Before anything else, I truly think that the onus is on Microsoft to ensure that their baseline configuration for cloud accounts doesn’t expose their tenants unnecessarily. Sure, we could blame ignorant users and lazy admins, but I don’t think that this is fair given the scope of this vulnerability, which is essentially 46% of AzureAD’s user-base (password hash sync + cloud only = 46%). It is unknown how many have MFA enabled and the scope of this is ultimately an unknown both with regard to those who are vulnerable to it, actively being attacked, and/or those already breached though. But as a former tier 3 support engineer for Exchange Online at Microsoft, I can confirm that a significant amount of individuals as well as small-medium businesses are relying on Azure AD exclusively without further counter-measures and that they account for a sizable amount of Office 365’s user-base.

Microsoft has clearly acknowledged this problem, but rather than hardening their tenants from such attacks as other cloud services have, they have offered solutions only available to their high tier plans so as to capitalize on this problem rather than fixing it. As expensive as they are to migrate away from now, or sticky as they like to call it, their products are just going to become more costly to manage, vulnerable, and difficult to migrate away from over time. This is the malady of any legacy solution.

One easy way for Microsoft to mitigate such attacks is to update their RPS module to support DAP and develop other creative avenues for admins and the like to efficiently and securely manage their clients’ tenants. They should also extend their threat intelligence and advanced customizations available only to costly, high tier license subscribers to all license levels, at least until proper solutions are implemented for all tenant levels.

As an immediate mitigation step though, Microsoft could simply swap the order of authentication. Rather than requiring a password prior to doing a two-step verification on your phone, they could require the phone verification through authenticator app or a third party MFA app such as Duo as the initial means of authentication. By deferring their password in Azure AD as the second step instead of the first, they could buffer its weak password security at present and buy time to implement a proper solution. However, this only applies to users and tenants with MFA enabled and in-use.

Just as Active Directory seems to create necessity for other costly ancillary solutions, Microsoft seems to have built AzureAD to generate further necessity for more costly solutions coincidentally offered by them just the same. On top of this and if they had their way, their solution to enable MFA would also require employers to buy phones and mobile plans for two-step verification for all of their employees which can cost more on an annual basis than any of their plans.The same can be said of the costs associated with a proper MFA solution and/or an on-premises or hosted ADFS solution (if none exist) as they drastically complicate the solution as a whole while consequently inflating the ownership costs associated with it. As complexity increases, stability falters while costs skyrocket. All of which is why I recommend avoiding their solutions entirely.

Source: https://blogs.partner.microsoft.com/mpn/create-stickiness-with-ip/

But if a company is entrenched with Microsoft products and migration is out of reach, there are options. One solution that companies can implement is ADFS which defers authentication attempts to your own domain controllers on-premise rather than Azure AD while immediately granting more granular control of password policies with Active Directory on-premise and as much protection as money can buy on the network layer. All of which can be quite costly from a licensing perspective alone, let alone the hardware, network infrastructure, and labor required to implement it all let alone the staff to maintain it. This creates a single point of failure unless implemented in a highly available manner.

They can also implement an MFA solution as well but there still remains added exposure and vulnerabilities which may require further consideration. But as mentioned before, there are also added costs and MFA may not protect accounts entirely. Users tend to manually synchronize their passwords across multiple platforms for the sake of remembering it, but not all of them have the same protections, MFA or otherwise. Similar to ADFS, access to your mailbox and other apps are restricted when MFA services are degraded, also becoming a single point of failure, as shown today by Azures MFA outage. So if you go with an MFA solution, diversify with a 3rd party MFA provider.

While the existence of dirsync can do little to protect against brute-force attacks, enforcing a strong password policy including a customized banned password list on premise can be mirrored in the cloud. Customers with dirsync already pay for this functionality with Active Directory on premise and can simply have it be mirrored in the accounts synced to the Azure AD forest. Although this cannot protect from brute force, password spray, or denial of service attacks, it can absolutely harden accounts against prolonged breaches.

I suppose they could also call support to complain about it and see if they’ll fix it, but you will likely be met by someone difficult to understand without experience on such matters. Or maybe they could even get a technical account manager to yell into the void or possibly even find someone with half of an ass on your behalf if you have deep enough pockets for a premier membership. While you’re at it, maybe you could upgrade your E3 plan to an E5 plan at almost double your monthly cost of E3 just to pay Microsoft to compensate for its own vulnerabilities.

In summary, Microsoft services built on Azure AD along with the businesses leveraging them are vulnerable to brute-force and password spray attacks which can be carried out by anyone with the capacity to run a script in RPS. Also, there isn’t an adequate means of hardening these services without incurring significant financial burden and paying for more of Microsofts services. All of which has probably been the case for as long as the ability to access tenants via RPS has been widely available to admins and ultimately why you would be wise to assume breach with Microsoft cloud solutions just as Microsoft does. Entities can absolutely mitigate these vulnerabilities, but Office 365 and Azure would cease to function as true cloud solutions while generating significantly more overhead costs in the process.

All things considered, it seems as if there is no way to harden Azure AD or the services such as Azure or Office 365 when leveraged by itself without incurring significant costs in addition to the aforementioned introduction of further complexity, points of failure, and on-premise dependencies for your cloud architecture. This is not to say that Azure cannot be made to be secure, but it comes at a cost while sacrificing cloud resiliencies. Although they advise others to assume breach, Microsoft seems to be omitting this reality from Office 365 and Azure advertisements and such inconsistencies are indicative of this stance being more of a cop out than a tenable security strategy because of this.

How Azure AD Could Be Vulnerable to Brute-Force and DOS Attacks was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.