M365 Security: Your Users Have More Power Than You Think, and the Hackers Know It

Executive Outlook 

With the meteoric rise in Microsoft 365 usage over the last few years, many organizations moved to a cloud native platform without fully understanding the security implications of their decisions. Microsoft has tried to help their clients by removing some of the insecure low hanging fruit (e.g., disabling legacy authentication protocols), and you’ve heard the cyber industry rant about the same basic security controls such as blocking external forwarding rules and implementing MFA.  

However, as we reviewed in our last blog post there continue to be secure configuration weaknesses that organizations are not accounting for. Additionally, there are services within M365 that are overextending your organization’s credential attack surface without you even knowing it.  

A key aspect of our M365 Hardening Assessments includes reviewing permission sprawl within the tenant. We typically identify two major areas that organizations are not considering. 

Technical Perspective 

1. Unknowingly Allowing Application Consent  

Of particular concern are cloud applications and end users’ ability to consent to a wide range of permissions. Since there are no default consent restrictions in M365, users can approve risky access such as allowing an application to send email on its behalf, gaining access to the entire user directory, or accessing data in Teams and OneDrive. These permissions can lead to a “trojan horse” of sorts if a third-party application is compromised and used to impact its customers. 

When our team was assisting UKG in their response to their ransomware attack in 2021, the primary concern customers had was whether UKG’s breach had spread into their own environment and what exposure they might now have internally.    

As we see more zero-day and application compromises due to geopolitical instability around the globe, it is likely that threat actors will exploit this pervasive permissioning to gain access to tenants through vendor applications or add additional permissions in the hopes users will agree to them without notice. 

How can you prepare? 

  • Require approval from an administrator for any new application consents. Like how opening a port on a firewall is poking a hole in your security, so is consenting to each app in M365. 
  • Enforce strong data loss prevention (DLP) policies for all cloud resources (e.g., OneDrive, SharePoint). Examples policies could include preventing users from copying or sharing highly sensitive documents, preventing and alerting when large number of documents are attempting to be copied externally. 
  • Enable Purview logging. With lower M365 licenses, tenants have a log retention of 90 days. Purview Audit Premium licensing enables a default retention of 1 year, with the option to retain longer if needed. Retention of 1 year should be sufficient for most organizations but be sure to check with your organization’s compliance policies.  

2. Sprawling Single Sign-On (SSO) Permissions 

SSO can be a double-edged sword. On one side, it reduces the number of accounts for end users and the potential for password breaches. On the other, if a threat actor gains control of a workstation, they will be able to access all SSO applications for that user and not be prompted for additional authentication.  

As organizations increasingly centralize their authentication (e.g., single sign-on) through Microsoft 365, we anticipate threat actors will leverage this single point of reliance more frequently to disrupt services more effectively. However, the below steps will help harden your SSO implementation to protect against threat actor attempts to compromise your environment.  

  • Ensure multi-factor authentication (MFA) is enabled for all user accounts. 
  • Monitor access and sign-in logs for suspicious activities such as unusual login times and escalation of privileges.  
  • Implement principle of least privilege to SSO applications. Often organizations will stick with default permissions, and these can be much more than what is required for end users.  
  • If SSO connectors are housed on-premises or in the cloud, treat them as tier-0 applications and strictly control administrative access to them. 

3. Accessibility of Administrative Tools  

By default, any user can access Azure PowerShell to perform queries on the tenant. This could include any information located in Azure AD, such as the phone number and location of all users. Or for more privileged accounts, running scripts and commands in the back end that change permissions, add users, export, or even delete sensitive data.  

With an increase in security monitoring tools, threat actors have pivoted to hiding their malicious activity by “living off the land”, meaning they perform nefarious actions using the same tools that administrators use for legitimate purposes, which makes it more difficult to identify what is expected activity vs. malicious.  

  • Block access to Azure PowerShell for end users utilizing through command lines tools or Conditional Access. 
  • Segment administrative accounts to have a separate admin-only, cloud-only account that should only be used when escalated privileges are required. This account should not have a mailbox, and if you have an on-premises environment, the account should not be synced.  
  • Enable temporary administrator privileges with Azure AD Privileged Identity Management (requires Azure AD Premium P2 licensing). This greatly reduces the attack surface as administrator credentials are temporarily granted to execute a task when needed and then revoked when finished similar to traditional PAM methodologies.  

As we see the threat landscape continue to shift towards a renewed focus on M365 and cloud security attacks, we anticipate a wave of new attacks that will take advantage of these lesser talked about security controls in the M365 ecosystem. We encourage all of our clients to review their own tenants or undergo a M365 Hardening Review to make sure you are able to  

                                       Enduir the next Attack and Become Resilient.

Not sure if your deployment is configured correctly?

Reach out to the Enduir Team (info@enduir.com) to hear how we help organizations evaluate and remediate MFA deployments.