Having an Identity Crisis

My email address is my identity

In Active Directory on-premises or Azure Active Directory (AAD), used by Office 365, our User Principal Name (UPN) is often the same as our email address. These days, we often log in with our email addresses, which means that whatever we’re “using under the hood” from an authentication point of view is the same as our email address. This convention of making our email address the same as our UPN is common practice and even advocated by Microsoft.

Furthermore, for years we would start an Office 365 migration by moving Microsoft Exchange on-premises to Microsoft Exchange Online. The resultant prompts in Outlook, Outlook Online and now Outlook on the Web (OWA) would read – “Enter your email address and password to login.”

The resulting convention is that once I know your email address, I know “who” you are when you log in to an online service. This convention isn’t unique to Office 365, we have the same convention in most online platforms, but since I care most about Office 365 in this article, that’s what I’ll stick to. Once we can establish one email address for a specific user in a company, either by guessing it, trawling online media for a mention or even a specific listing of an email address, I have a really good idea of the naming convention of all of the email addresses in your enterprise. I can use some of the same online services that you use, LinkedIn, Facebook, GitHub, etc. to find more email addresses or just names of people who are working in your company in order to construct more email addresses.

Crafting the attack

Now that I have a list of email addresses I can search GitHub for one of the numerous password spray tools available to download and use immediately. Password Spray attacks are particularly useful, since a good attack will take place over time, attempting multiple passwords on every known account, taking care not to lock out any of them.

One of the factors that makes for a successful Password Spray attack is of course complex passwords. They’re too predictable. And they change with regularity to something predictable. Let’s take Contoso Corporation as an example. At Contoso, our diligent security department has trained our users to use uppercase, lowercase, symbol and numbers as part of our password convention. Users also may not write these passwords down anymore, since the last audit found many post-it notes with passwords posted on screens and other surfaces. That means passwords need to be complex – following our convention of numbers, symbols, character and case which we mentioned earlier – but still memorable.

As a result, our users prefer passwords like “ContosoSummer2020!”, “Cont0s0Winter!”

“ContosoP@ssw0rd” as opposed to “eR#3*88.yumP”, since a truly complex password that needs to change every 60-90 days is really difficult to remember.

Believe it or not, complex passwords make life easy for an attacker, since these password patterns are incredibly predictable, as well as easy to guess in an automated manner. We only need a few data points, like the company name, season – weather or sports season that is and we can craft a common complex password pattern.

Let’s revisit what our attackers have thus far:

Next, we execute our tools across multiple attack vectors, especially easy ones which support legacy authentication. At this point you may be sighing, since that may include your on-premises systems which you’ve published to the internet and Office 365 with legacy protocols enabled. These may include OWA, ActiveSync, ADFS, OneDrive, SharePoint, PowerShell, etc.

Our crafty attacker only needs one account to break, just one. Following which our malicious actor can logon to Exchange or Exchange Online, dump the GAL – including the list of groups containing administrators, finance and senior business decision makers and start with successive attack phases.

At this point our attacker can escalate attacks horizontally by cracking more accounts using the complete list of email addresses from the GAL, discovering more systems to exploit, reading our emails and more.

Next, our actors may craft fraudulent emails to syphon funds out of the company, with fake approval emails to finance from senior management or launch a targeted spear phishing attack against administrators or specific staff to compromise machines with malware for further attacks.

That sounded too easy, didn’t it?

Identities in crisis

There are several critical factors here:

• Passwords as the only form of security. I’ve written before about an on-premises mentality that customers consider themselves safe on the basis of a perimeter and a password. The definition of perimeter becomes very fuzzy in a cloud-enabled world.
• Legacy Protocols. Jaap wrote about legacy protocols support stopping in favor of Modern Authentication which is token based. Legacy authentication boils down to a username and password being exchanged over the wire for access to a service. Basic Authentication is incredibly easy to use and craft attacks against.
• Second Factor Authentication (2FA) or the lack thereof. Once modern authentication is enabled, we can enroll our users into a second factor authentication solution, which means that the username/password coupled with a successful second factor authentication event
• Microsoft Authenticator, Windows Hello, etc – allows our users to login.

Azure Active Directory can be configured to require 2FA based on a deciding factor, i.e. logons occurring outside of the office, or even threat vector like password lockout or rapid location change - which is easily achieved with a Conditional Access policy and our identities can no longer be compromised.

Even without Conditional Access, we can eliminate 98% of currently known identity attacks by:

• Eliminating legacy protocols wherever possible
• Enroll all our users into a 2FA solution. Since Microsoft’s modern authentication solution is OAUTH based, you can use your existing token solution as the additional factor, as long is it supports OAUTH.

Mobility as an attack vector

One of the biggest stumbling blocks against rolling out Modern Authentication and disabling Legacy Protocols is ActiveSync. It is not because ActiveSync doesn’t support Modern Auth – it has for a while – but rather it's because mobile device manufacturers have not implemented Modern Auth in their ActiveSync implementations.

In case you were wondering about how difficult it is to craft an attack against ActiveSync, I would refer you to the GitHub URL I included earlier. ActiveSync is a well understood attack vector supported by multiple open source and third-party attack stacks.

We can circumvent the lack of Modern Authentication support by your device manufacturer by using Outlook Mobile, which does use Modern Authentication. It’s also free, which is difficult to argue with as a price point. We can enforce the use of Outlook Mobile and block legacy authentication on ActiveSync using Conditional Access to create a user experience which prompts the user to install Outlook Mobile instead of using ActiveSync. I’ve advocated for a while that if we as IT support take something away from the user, i.e. native ActiveSync on the device which may be powering an integrated messaging and calendaring solution, then we need to replace that with something of more value – which is easily substantiated today with the use of Outlook Mobile.

What about Exchange On-Premises

On-premises support for modern authentication is very achievable using a feature known as Hybrid Modern Auth, which allows us to combine Modern Authentication methods and even Conditional Access rules against Exchange on-premises. Modern mail clients such as Outlook, Active Sync with Modern Auth, Outlook Mobile, etc., can authenticate against Azure Active Directory (AAD) using Modern Authentication instead of Exchange on-premises using Basic Authentication. Thus, we are now able to disable legacy authentication against Exchange On-premises and secure ourselves against identity attacks based on this attack vector. There is some fine print here however, specifically Exchange 2013 and higher are required. You will be unable to enable Modern Authentication should any Exchange 2010 servers still exist within your Exchange organization.

What do I do first?

•  
1. Fortify user authentication immediately by adding 2FA or even removing passwords. Raising the bar on user authentication is critical, understand that users may push back because of the potential inconvenience of this change, however you would rather have a mildly unhappy user base as opposed to massive financial losses.
2. Understand how much Basic Authentication you’re using and where. Start with Jaap’s Article on this subject and jump to “Monitoring for Basic Authentication”. Disabling Basic Authentication without planning for it can be disastrous for your organization as well as applications which are dependent on Exchange Online.
3. Remember that Exchange is not the only application using Basic Authentication. OneDrive, SharePoint, PowerShell and more will be surfaced in the Azure Active Directory report from point 2 above.

Conclusion

Security can be hard, very hard in fact, however most of the post-attack remediation discussion for commercial customers which I have been part of revealed that the entry vector for an initial attack was something simple. I’m certainly not discounting other entry points such as social engineering, malware, compromised websites, man in the middle, rouge AAD application, etc. Rather, I’m calling out how weak systems can be on the basis of a phishing attack or a password spray attack, or anything similar which compromises credentials. But, these attacks are only effective if passwords are the only means of securing your systems.

Adding a second authentication factor as well as massively reducing the attack surface for attacks go a long way – 98% of the way – to securing your identity landscape.

Active Directory Monitoring and Reporting

Active Directory is the foundation of your network, and the structure that controls access to the most critical resources in your organization. The ENow Active Directory Monitoring and Reporting tool uncovers cracks in your Active Directory that can cause a security breach or poor end-user experience and enables you to quickly identify and remove users that have inappropriate access to privileged groups (Schema Admins, Domain Administrators). While ENow is not an auditing software, our reports reduce the amount of work required to cover HIPAA, SOX, and other compliance audits.

Access your FREE 14-day trial to accelerate your security awareness and simplify your compliance audits. Includes entire library of reports.