Blog by Sr. Risk and Compliance Consultant Tim Paschal and Principal Risk and Compliance Consultant Anton Abaya.
One of our Risk and Compliance team members likes to tell a story of when he was young and foolish and went with a couple of friends to try self-guided whitewater kayaking. The kayaks they rented were made for calmer water, they had no waterproof “skirts” to seal off the cockpit, and they brought no helmets. Basically, they had little gear that a seasoned whitewater enthusiast would consider essential beyond a boat and paddle.
As the guys hauled their meager equipment down to the river, a team of elite-looking kayakers prepping for their own float trip seemed to be sizing up the rag-tag group headed their way. One of the experienced kayakers shouted over, “Before you fellas put in, do you want to know our recovery fee?”
That kind of question could be taken as condescending (“Bro, do you even kayak?”), but it’s also possible that the kayakers had witnessed the consequences of other ill-prepared adventurers heading into whitewater, and they might have even been called in to assist. We’ll just assume they were keenly aware of risks that might not be as evident to novices.
The scenario of a more experienced group seeing faulty practices in others can also be seen in the business world with Office 365 (O365) / Microsoft 365 (M365) cloud security.
At Accudata, we’ve seen the painful consequences of small to medium organizations migrating parts of their business operations to the cloud without first considering fundamental security needs. This often leads to tough lessons learned and incident response engagements.
In this blog series, we’ll review a list of issues we regularly see that introduce significant risk to Azure Active Directory (AAD) / Microsoft 365 environments. These are the security issues we might file under the “OK, but have you considered the cost of IR/recovery?” discussion. Today, in part one of the series, we’ll discuss issues that start with two critical areas: authentication / access control and account privileges.
Authentication and Access Control Issues
Not Requiring Multi-Factor Authentication
You can’t throw a rock without hitting a security expert shouting about the need for multi-factor authentication (MFA), so why are we bringing it up yet again? That’s because we still see too many companies that are not enforcing MFA, or at least not enforcing MFA in a meaningful way to help secure cloud resources. We have observed and responded to quite a few security incidents as late as Q4 2020 that could potentially have been prevented, or at least slowed down to provide more time for detection and response, if MFA had been required. This is particularly true for opportunistic attackers who are simply looking to pick the lowest-hanging fruit.
This is not to suggest Microsoft’s protections are foolproof, but their advancements are generally beyond what many organizations can deploy on-prem. It’s a game of cat and mouse, no doubt.
Compliance professionals may also raise a hand here to point out differences between multi-factor and multi-step authentication, which is not as secure as MFA. That’s valid. Then presents the argument that any fool can call a mobile carrier and socially engineer their way to a phone number compromise. There’s truth to that too, as Accudata’s pen testing team has demonstrated bypass of such controls on pen tests before, but that’s a story for another blog entry. We stand beside our assertion that even SMS-based multi-step authentication is almost always better than single-factor authentication alone.
We don’t want to give a false sense of security. There’s a lengthy list of caveats with MFA solutions (e.g., no single control is bulletproof, not all MFA solutions are equal in their protection, proper configuration cannot be overlooked, social engineering will still pose a risk), but any MFA is generally preferable over none. That said, if you have a better option, such as an app-based solution like Microsoft’s Authenticator or a hardware device such as the YubiKey, by all means, use it instead!
MFA solutions, however, shouldn’t be deployed without security awareness training. Authenticator apps that provide a short code challenge are relatively convenient, but be cautious if you use a solution that only prompts for a yes/no approval as the second factor. We’ve seen many instances in which users approve yes/no MFA prompts without hesitation, even when they had not taken any action that might generate a prompt. We’re only human, and that’s the “snooze button” of authentication.
Prioritize MFA on Administrator Accounts
If you can’t enable MFA globally right now, prioritize administrator accounts and other high-value targets like executives and accounting personnel. Business email takeover is entirely too common, and the consequences often cost far more than premium M365 licensing.
If you’re planning a migration to O365/M365, know that AAD global administrators have the highest level of administrator privilege at the tenant level. This is similar to the domain admin role in an on-premises AD environment. The AAD global administrators are the first accounts created so that administrators can begin configuring their tenants and eventually migrate their users. If not quickly secured, there’s an increased risk that an attacker could compromise these powerful cloud-based accounts and establish persistence in the environment as a customer migrates to M365.
MFA Everything Exposed to the Internet
It’s important to consider MFA for your whole environment and not just cloud assets. During penetration tests, it’s not uncommon to find that a customer has one or more on-prem services exposed to the internet that require domain credentials for authentication but are not carrying the same protection packaged with M365 services, such as limiting failed login attempts from a given IP address.
For example, during a recent offensive security engagement, we found that a customer enabled MFA for M365 service access for all users. The customer also had an on-prem HTTP service exposed that allowed NTLM-over-HTTP authentication against AD. With no observable controls in place to hinder repeated password-spraying attacks against the service, we scripted a quick-and-dirty loop for password guessing with cURL. We were then able to compromise valid domain user credentials that could then be used in subsequent cloud attacks. If MFA had been implemented, our attack would have fallen flat on its face.
Even with all external-facing resources enforcing MFA, other M365 configurations could serve as an easy bypass if left unchecked.
Leaving the Back Door Unlocked by Allowing Legacy Authentication Protocols
If you enable MFA but still allow “legacy authentication” without restrictions, you’re essentially leaving a back door unlocked. Legacy authentication in M365 terms include POP3, IMAP, SMTP, and other types of authentication that cannot be used with MFA. Some organizations may still need to permit one or more legacy authentication types for a valid reason, but it’s worth noting Microsoft’s guidance here:
“Today, the majority of all compromising sign-in attempts come from legacy authentication. . . . Even if you have an MFA policy enabled on your directory, a bad actor can authenticate using a legacy protocol and bypass MFA. The best way to protect your account from malicious authentication requests made by legacy protocols is to block these attempts altogether.”
For example, when we performed a recent cloud security assessment for an organization primarily based in Houston, we found over 17,000 failed legacy authentication sign-in attempts from at least 219 locations around the world!
During offensive security assessments in which we capture a domain user credential, we now check for potential access we might gain via a legacy authentication that’s supported. You can be sure threat actors are doing this too. Open-source tools are available to make quick work of those checks, so be sure that disabling legacy authentication is on your “fix now” list.
If you identify any services or applications that legitimately require some kind of legacy authentication (which should be an initial step in your approach), you may be able to limit such authentication to specific users and network locations to greatly mitigate the risk. This can be done with conditional access policies.
Not Taking Advantage of Security Defaults or Conditional Access Policies
Late in 2019, Microsoft began deploying a feature for all new tenants that enforces a preconfigured set of policies that closely align with recommendations in this post. The following are some of the settings that make up the security defaults:
- All users are required to register for Azure MFA.
- Administrators must perform MFA.
- Legacy authentication protocols are blocked.
- Privileged activities like access to the Azure portal are restricted.
If you’re a small business with the free tier of AAD licensing, or if you have not developed your own security policies, security defaults are a good place to start. There’s not really flexibility here, but if you have basic licensing, you may not need any granularity. However, if your tenant was created before October 2019, there’s a good chance the security defaults were not enabled by default.
Having said that, if you’re already paying for Microsoft premium licenses, you may want or need more granular control over access. This is where conditional access policies are beneficial.
Conditional access policies are a set of highly customizable rules applied based on conditions you define, allowing you to reduce your attack surface further while making exceptions to minimize the burden on your users. According to Microsoft, “Conditional access policies at their simplest are if-then statements. If a user wants to access a resource, then they must complete an action.”
- The following are examples of possible conditional access policies:
- Do you want to block all logins from IP addresses associated with foreign countries?
- Do you want to waive the MFA requirement for standard users logging in from the main office’s IP address but still require it for privileged users everywhere?
- Did you identify a single host or service that needs to log in via SMTP authentication, but you want to eliminate legacy auth elsewhere?
Too Many Accounts, Too Many Privileges
There are multiple sub-issues we find here that often lead to significant, unnecessary risk. Unfortunately, the problem usually starts in the on-prem AD environment and migrates to the cloud, where the stakes may be even higher. Overlooking something that takes a few minutes to set up (AD Sync) can result in hundreds/thousands of hours of pain in the case of a breach.
All On-Prem AD Accounts are Sync’d to AAD
There are likely several accounts currently in your on-prem AD with no real business being in AAD. Most of the necessary on-prem service accounts may not even have an associated mailbox or ever need to log in to AAD. Extra accounts in AAD mean a bigger attack surface, more administration, more housekeeping. We often advise customers to choose options that simplify operations and reduce attack surfaces where possible. The advice to avoid syncing on-prem accounts to AAD is much like the advice to avoid needlessly exposing services to the internet: Simply eliminate what you can from exposure. Ultimately, that means less busywork for the administrators. Think of the service accounts carrying excessive privileges while using passwords that haven’t been changed in the past decade. There’s probably a threat actor getting ready to test generic credentials against your M365 tenant, using [email protected]<yourdomain.com> with a password of . . . “copier.” (You can substitute any generic office term there and be confident that adversaries are trying it.)
Using various methods described in the link below, you can configure your on-prem AAD Connect to filter specific accounts or groups of accounts from syncing to the cloud environment:
Overprivileged User or Service Accounts
Overprivileged accounts. Everyone knows they’re out there, but nobody wants to talk about them. Almost every internal penetration test report we write includes a recommendation to audit the top-privileged accounts in the domain, such as Domain Admin and Enterprise Admin memberships, and downgrade accounts where possible. But, once again, AD account issues that start on-prem often carry over to AAD/M365/O365.
Suppose Bob has the Global Admin role associated with his “daily driver” account, the same one he uses to log in to his corporate laptop, check email, surf the web, etc. That greatly increases the risk to your entire organization. A compromise of Bob’s account could potentially mean a compromise of the tenant. This kind of finding generally makes our pen test engagements easier when it comes to gaining access to critical data, services, or hosts.
Separate Administrator Accounts (No Mailbox) from Everyday Accounts
Create separate DA/GA accounts for all users who absolutely require those privileges. For the love of all that is holy, persuade them to only use privileged accounts for the tasks that require them. Talk to your admin users and ensure they’re not reusing passwords across their daily driver accounts and administrative accounts. We continuously find reused and weak passwords on occasion, and we’re eager to abuse them. Such a demonstration can show the associated risk of poor password practices. You can be sure that threat actors abuse poor passwords too. Let us check this out during your next pen test. We’d love to help identify any two or more accounts using the same password.
Assign Administrator Roles Using Role-Based Access Control
Given its high level of default privilege, the Global Administrator account should only be used when absolutely necessary. Using another of Azure AD’s numerous built-in administrator roles, instead of the Global Administrator account, can limit assigning overly permissive privileges to legitimate administrators. Practicing the Principle of Least Privilege, assigning administrators only the minimum permissions they need to perform their tasks can greatly reduce a compromised account’s impact.
Review the Keys to Your Kingdom
You should conduct an annual audit of stale accounts and work hard to limit highly privileged accounts (Global Admin just as Domain Admin) to only those who need such privileges for the tasks required.
Where possible, avoid using community accounts that are shared among multiple users. If you already have premium licensing, be aware that Microsoft offers Privileged Identity Management in AAD that provides more granular control for privileged accounts and just-in-time administration.
Final Remarks
The above cloud considerations for small to medium businesses are far from exhaustive. Still, our goal is to help you spot quick wins in your environment that can be addressed to mitigate significant risk ASAP. Again, these are our do-now or Have you considered the cost of IR/recovery? items.
Our next entry, part two in the series, will cover additional security priorities for your cloud environment, including how to put a bouncer at the front door to get a better read on the Johnny who just happened to have and use Bob’s password.
Thanks for reading, and stay tuned!
Every 39 seconds, there is a cyberattack. And, the complexity by which an organization can be impacted – whether hacking, malware, or ransomware – continues to rise because of new vulnerabilities that exist in an interconnected world of service providers leveraging cloud-based systems to support them. Inadequately protected networks invite regulation violations, data loss, and significant business disruptions.
Concerned about “bad actors” in your network? Accudata’s decades of cybersecurity, risk, and compliance expertise can help protect you from bad actors so you can focus on running your business.
