Controls for Protecting Microsoft 365: A First Person Incident Response Recount

Introduction

In recent years, the trend towards cloud-based solutions like Microsoft 365 has led to an influx of administrators who may not be fully versed in the security measures associated with online identity and access management solutions, such as Azure AD. Unfortunately, this knowledge gap can have serious consequences, as demonstrated by a recent client of mine who suffered a significant Azure Active Directory compromise. In this article, I aim to take a slightly different approach by conducting a root cause analysis of this compromise. Specifically, I will examine the actions I took to remediate the situation, explore how the client’s existing controls failed, detail the new controls I implemented to prevent future incidents, and provide recommendations for additional tools the client can use moving forward.

By delving into the specifics of this case, I hope to shed light on the importance of proactive security measures and the risks of relying solely on default security settings. My ultimate goal is to help other administrators avoid similar incidents and promote best practices for safeguarding cloud-based environments.

The Attack

To fully understand the attack that targeted a mid-size enterprise’s Azure AD, it’s important to paint a picture of the company’s knowledge and practices leading up to the incident. While the administrators were familiar with the basics of their Microsoft environment, such as creating users, mailboxes, and aliases, they had not taken the necessary steps to secure their environment or manage more advanced features.

Despite having established some conditional access policies years prior to the attack – such as blocking countries where the company had no business interests – these policies had not been reviewed or updated in some time. As a result, they had become stale, incomplete, and ultimately ineffective at preventing the type of attack that the company ultimately faced.

This scenario highlights the importance of staying vigilant and proactive when it comes to security measures. Simply establishing policies and assuming they will continue to protect your organization without regular review and updates is a recipe for disaster. By neglecting their security posture, the enterprise inadvertently created vulnerabilities that the attackers were able to exploit.

The attack began like this:

The chain of events that led to the compromise began with a seemingly innocuous email from a common customer of the targeted company. Unfortunately, the email contained a malicious hyperlink that was not detected by my client’s email security solution. This was the first failure in a series of missed security controls that ultimately resulted in the compromise.

Upon clicking the link, the user was directed to a popular file sharing platform where they unwittingly downloaded and executed a malicious file. Despite having active EDR in place, the macros embedded in the Excel file went undetected, enabling the attackers to harvest browser sessions from the compromised computer. This technique, known as Browser Session Hijacking, is categorized under the MITRE tactic T1185. This is the second security control that failed.

With access to the user’s browser data, the attackers were able to bypass the 2-factor authentication (2FA) mechanism in place and gain access to the account. The attackers registered their own 2FA application using a secondary authentication method, disguising themselves as being located in Phoenix, Arizona via a VPN connection.

The attackers’ successful bypass of 2FA and registration of their own 2FA application should have triggered alerts within both the SIEM and the Azure Premium P1 license, specifically for impossible travel. Despite the fact that the user signed in from several hundred miles away, these alerts went unmonitored due to the absence of a watchful eye on the risky user dashboard and the failure of the SIEM solution contracted by my client to detect the anomaly.

In hindsight, additional controls could have been implemented to mitigate the risk of such an attack. For example, notifying the user or a member of the helpdesk about any new registration of 2FA devices could have provided an additional layer of security. However, these controls were not in place, contributing to the overall failure of the security posture.

Over the course of several weeks, the malicious actor behind this attack connected to the compromised user account from various locations across the globe, including Russia, Great Britain, Canada, Mexico, India, Iran, and several US states. The sheer volume and geographic diversity of these sign-ins should have triggered alerts for impossible travel events.

Despite occasionally running into legacy conditional access policies that blocked access from certain countries, the attacker persisted, attempting to connect from these locations up to 30 times before ultimately resorting to a VPN connection from a different country. In nearly every instance of these attempts, the attacker should have triggered brute force alerts. However, the SIEM failed to pick up on these warning signs, compounding the vulnerabilities and ultimately leading to the successful compromise of the system.

These oversights demonstrate the importance of having robust monitoring and alerting mechanisms in place. Without them, even the most basic attacks can go unnoticed for extended periods, giving malicious actors ample time to wreak havoc. As we’ll explore in the next section, there are several steps organizations can take to improve their security posture and avoid similar breaches in the future.

After several weeks of reconnaissance and exfiltration, the attacker was ready to execute their plan. They created a simple phishing email that contained a link to a fake Office 365 login page and sent it to everyone in the domain, as well as all of the compromised user’s contacts.

This step represented another missed opportunity to detect and prevent the attack. While some email security measures had been implemented by the organization, they clearly were not sufficient to catch the phishing emails before they left the domain.

To address this gap, the organization should have invested in a more robust email security solution that leveraged advanced threat intelligence and machine learning algorithms to detect and block phishing attempts. Additionally, alerts could have been set up within the Office 365 environment or SIEM to flag any abnormally high volume of outbound emails, which may have indicated malicious activity.

Almost immediately after sending out this mass email, bounce back emails began landing in the users mailbox, so the actor created a rule to automatically mark incoming email as read, and immediately delete them in hopes of not being discovered by the user themselves for as long as possible.

The security team was only made aware of the compromise after the malicious email had been sent out. It was then that TridentStack, who had been retained for incident response, was brought in to assess the situation. The first steps taken by the security team and myself were to block all sign-ins to the compromised user’s account, change their password and 2FA, block the link sent out on their firewalls and VPN, and quarantine the user’s computer. To remediate the incident, I used Smart Search to pull the malicious email while saving a copy of it.

It was discovered that a number of phish-vulnerable users had already fallen prey to the malicious link and submitted their login credentials, thereby compromising their accounts. Nevertheless, the security team was quick to deploy their layer 7 firewalls to track all users who had visited the link and mandated immediate password resets for those affected. As a temporary measure, sign-ins were also temporarily blocked until the helpdesk could assist in securing the accounts of affected users.

Fortunately, due to the high adoption of MFA across the organization, the damage was contained and no secondary accounts were fully compromised. Nonetheless, the incident highlighted the importance of implementing proper security controls and training employees on safe computing practices. It also underscored the need for a proactive approach to threat detection and response, as relying solely on reactive measures could potentially result in significant damage to the organization.

Reviewing Failed Controls

It’s crucial to understand what went wrong in the first place before implementing any new security measures. By analyzing the attack and identifying the failed controls, we can determine what needs to be improved. Only then can we effectively implement new security measures to prevent similar attacks from happening in the future. It’s not just about getting the bad actors out post-compromise, but also preventing these compromises from happening in the first place. With this in mind, I reviewed every security control I implemented and/or recommended for the client, and included a detailed guide on how to implement and utilize each control. Additionally, I addressed the failures of their email security, SIEM, and EDR vendors.

My first step after freezing the compromised user accounts was to review in the Microsoft Protection Center https://protection.office.com/ to understand exactly how the account was compromised.

I also thoroughly reviewed the conditional access policies they had in place and cross-checked the logs from the 3rd party SIEM SAAS to ensure comprehensive visibility of their environment. In addition, I performed a quick scan using their antivirus tool on the end-user’s host to detect any malware incidents on the machine. Moreover, I examined any alerts generated by the client’s email protection program to identify any potential gaps that require immediate attention.

Once I had a clear understanding of the compromised system and potential vulnerabilities, I began building additional security controls to bolster their defenses.

Controls I Implemented and How to Implement Them Yourself

When dealing with a security breach, it’s important to utilize all available resources and work closely with your security vendors to remediate the issue. Blaming vendors or being aggressive towards them won’t solve the problem and can actually make the situation worse. Instead, it’s important to keep a level head and work collaboratively to get your environment secure again.

In this case, the first step was to open tickets with the client’s email security, endpoint protection, and SIEM SAAS vendors to get all available resources working on remediation as soon as possible. This approach allowed for a coordinated effort to address the compromised accounts and prevent any further damage.

It’s important to approach your security vendors with a collaborative mindset rather than a confrontational one. After all, the goal is to work together to remediate the issue and prevent it from happening again in the future. When opening tickets with your vendors, it’s helpful to provide a detailed account of the events that took place, including any potential points of failure that may have contributed to the compromise. This allows your vendors to have a better understanding of the situation and provide more effective support.

It’s important to avoid shifting blame or being aggressive towards your vendors in these initial tickets. Instead, focus on the facts and what needs to be done to remediate the issue. This creates an environment of cooperation and fosters a more productive relationship between you and your vendors. Ultimately, you want your vendors to help you address the issue and prevent it from happening again, rather than covering their own liability.

Despite the vector of compromise in this case, I found many insecure settings which, in my opinion, were more egregious and would have been significantly easier to exploit. I opted to fix those issues first starting with:

Email Protection Settings

https://security.microsoft.com/threatpolicy is your friend and Office 365’s native defense to security controls. Starting with the policies section.

1. An anti-phishing policy from security.microsoft.com/antiphishing was implemented. It includes Spoof Intelligence, which filters emails from senders who are spoofing domains and allows administrators to control which senders are allowed to spoof domains or external domains. If a message is detected as a spoof, it will be quarantined immediately and notify administrators.
   Microsoft has an Article about this setting that can be reviewed here.
   Show first contact safety tip: (the link goes to a simple Microsoft page with a phishing detection video. You can point this to your own training platform or video if desired)
   
   Show (?) for unauthenticated sendors for spoof: This helps users distinguish if the sender is actually who they say they are through a visual cue. Applies a “?” symbol in Outlook’s sender card if the sender fails authentication checks.
   Show “via” tag: This setting affects spoofed email that gets delivered. For these emails a via tag appears visually showing users the originating domain alongside a link to a Microsoft article about why this matters. Example: chris@contoso.com via fabrikham.com
   
2. An inbound, and outbound anti-spam policy from http://security.microsoft.com/antispam was been implemented and has the following settings:
   Alerts the security team when outbound emails per hour exceeds 100. Alerts the security team when inbound emails per hour exceeds 100.
3. An anti-malware policy from security.microsoft.com/antimalwarev2 was been implemented. This policy helps monitor the email traffic and alert the security team when there is a sudden surge in inbound or outbound emails, which could indicate a possible attack or compromise. By setting a threshold of 100 emails per hour, the policy can detect abnormal activity and trigger an alert to the security team for further investigation. This is a proactive measure to prevent potential attacks and limit the impact of any successful ones.

While the basic email security measures mentioned earlier can increase security to some extent, they fall short of providing comprehensive protection against sophisticated email attacks. That’s where a robust email security solution comes into play.

In my opinion, Abnormal Security is one of the best email security solutions on the market today. Its cutting-edge technology, coupled with its ease of use and customizability, make it a top choice for organizations looking to bolster their email security defenses. I am not sponsored or paid by Abnormal Security in any way. I simply love the platform and think other admins will too!

Unfortunately, due to the limitations of my client’s P1 license, certain settings such as alerts on risky users were not available. However, if you have a P2 license, I recommend checking out the following settings:

1. If you’re looking to secure your Azure IAM, the Microsoft Secure Score for IAM is a fantastic starting point. It offers a range of recommendations to strengthen your IAM security and is available for P1 licenses. However, do note that certain recommendations are only available with P2 licenses. https://entra.microsoft.com/#view/Microsoft_AAD_IAM/SecurityMenuBlade/~/IdentitySecureScore/menuId/RiskyUsers?Microsoft_AAD_IAM_legacyAADRedirect=true
2. By clicking on the link below, you will be directed to your Risky Users Page, where you can find a list of all risky user accounts in your organization. It’s important to note that there are other risk pages available on the left navigation menu, such as setting up automatic alerting and remediation policies based on risk scores. Implementing such policies can significantly enhance your organization’s security posture. Even with a P1 license, monitoring your user security through this page can be highly beneficial. https://entra.microsoft.com/#view/Microsoft_AAD_IAM/SecurityMenuBlade/~/RiskyUsers/menuId/RiskyUsers?Microsoft_AAD_IAM_legacyAADRedirect=true
   
3. Privileged Identity Management (PIM) is an essential tool for managing the life cycles of role assignments and identifying unused roles assigned to users that can be removed. This feature is directly related to the least privilege access model, which aims to restrict access to only those resources necessary for performing a specific job function, thereby reducing the risk of data breaches or cyberattacks. This feature is directly related to least privilege access model. You can access PIM through the Microsoft Azure portal, where you can quickly set up and configure PIM roles, assign and remove users, and manage access. PIM provides granular control over access, allowing you to specify the exact time and duration for which users have elevated privileges. Additionally, PIM sends alerts when privileged access is granted, and allows for immediate revocation of access if necessary. https://entra.microsoft.com/#view/Microsoft_Azure_PIMCommon/CommonMenuBlade/~/quickStart?Microsoft_AAD_IAM_legacyAADRedirect=true By leveraging PIM, organizations can effectively enforce a least privilege access model, reduce the attack surface, and improve security posture. Moreover, PIM can help organizations comply with various regulatory requirements, such as HIPAA and GDPR, which mandate the need for privileged access management.

In most cases, it’s sufficient to give P2 licenses to your administrators and/or security team who are responsible for managing and maintaining your security infrastructure. This allows them to take advantage of the advanced features and tools that come with the license, while minimizing licensing costs for the rest of the organization. P2 licenses allow the following features and more:

• Conditional access policies based on group membership, location, and device state
• Real-time risk detection using signals from Microsoft and partner security solutions.
• Identity protection policies to automatically respond to detected threats
• Privileged identity management to control access to resources and roles
• Advanced reports and alerts on user and admin activity
• Multi-factor authentication for all users and administrators
• Passwordless authentication options
• Cloud app discovery to identify shadow IT
• Azure AD Application Proxy for secure remote access to on-premises web applications
• Self-service password reset and group management
• Identity governance to manage access reviews and lifecycle
• Security baselines to enforce best practices
• Advanced security reports and alerts for Azure AD and Microsoft 365 services

Conditional Access Policies

As an expert in securing access to Microsoft 365, I highly recommend implementing conditional access policies. These policies are the key to maintaining a secure environment for your organization. With conditional access policies, you can control who can access your organization’s data, from where, and on which devices. These are some of the policies I implemented in this case:

1. Implementing a conditional access policy based on GEOIP is an effective measure to restrict access to Microsoft 365 resources. By blocking all countries except for those where your users are located, you can significantly reduce the attack surface of your organization. I recommend creating multiple policies tailored to different types of users in different countries to ensure the most appropriate access controls are in place. For instance, a user who primarily logs in from India and uses the company VPN to connect to HQ may only require sign-ins from India and the US. However, a satellite office manager based in Mexico may require access from multiple countries. By creating custom policies, you can ensure that each user’s access is aligned with their specific needs and risk profile. It’s worth noting that this approach may require some additional work to set up, but the benefits in terms of security and risk reduction are well worth it. Additionally, it’s important to regularly review and update these policies as user access needs change over time. By taking a proactive approach to access control, you can stay ahead of potential threats and ensure the security of your Microsoft 365 environment.
2. I took a hardline approach to session lifetime and completely removed it across all applications. Now, authentication is required every single time a user accesses the system. This effectively kills the attack vector that was previously used against my client, since the session would not be valid more than once. By requiring users to authenticate for each session, we’ve significantly reduced the risk of unauthorized access and improved the overall security posture of the organization.
3. Consider restricting or disabling legacy authentication in your Microsoft 365 environment to increase security. If legacy authentication is absolutely necessary for a specific group, ensure that their privileged access is highly limited and increase logging and monitoring for that group. It’s important to note that legacy authentication is more vulnerable to attacks compared to modern authentication methods. By disabling or restricting it, you can significantly reduce the attack surface and protect your organization’s sensitive data.
4. Another way to enhance the security of your organization is to create a conditional access policy that requires the use of the Microsoft Authenticator with token verification. This process involves selecting a matching number displayed on-screen with your sign-in attempt. By implementing this method, your users will be more resistant to phishing and voice phishing attempts and will be less likely to approve sign-ins that are not initiated by them. To further ensure that users are only validating attempts they initiated, the location of the sign-in attempt should be enabled within the MFA app. This additional layer of security will strengthen the overall security posture of your organization.
5. An exception to these policies is the breakglass account, which should be created outside of the conditional access policies. To secure this account, enable multi-factor authentication (MFA) through the user management menu and make the password long but easily typable. To store the password, use a non-federated password manager or print it and store it in a secure vault. Set up alerting for every sign-in attempt for this account, and it should never sign in unless it is necessary to recover access to Azure due to accidental blockage from conditional access policies

A Few Other Things to Check — Recommendations and rules you can put in your SIEM.

1. By default, access to view the Azure console is enabled for all users and policies across the entire Azure environment. This can be a significant security risk since any user with access to the console can view all resources and rules, potentially leading to data breaches or other security incidents. Therefore, it’s essential to limit access to the Azure console only to those who need it, such as administrators or other authorized personnel.
2. The “User login failed due to conditional access” rule is a crucial one to have in any Azure-connected SIEM. This alert fires when a user fails to sign in with correct credentials due to a conditional access policy. It could indicate that a user is on vacation or a business trip and needs temporary access to a different conditional access group. On the other hand, it could also suggest that there are compromised credentials, and immediate action is required to change the credentials and assess the user’s MFA status. title: Sign-in Failure Due to Conditional Access Requirements Not Met id: b4a6d707-9430-4f5f-af68-0337f52d5c42 status: experimental description: Define a baseline threshold for failed sign-ins due to Conditional Access failures references: - <https://docs.microsoft.com/en-gb/azure/active-directory/fundamentals/security-operations-privileged-accounts> author: Yochana Henderson, '@Yochana-H' date: 2022/06/01 tags: - attack.initial_access - attack.credential_access - attack.t1110 - attack.t1078.004 logsource: product: azure service: signinlogs detection: selection: ResultType: 53003 Resultdescription: Blocked by Conditional Access condition: selection falsepositives: - Service Account misconfigured - Misconfigured Systems - Vulnerability Scanners level: high
3. It’s crucial to have an “impossible travel” rule in place when monitoring user sign-ins. This rule detects when a user logs in from two different geographic locations within a short period of time, which is highly unlikely and could indicate a compromised account. A properly configured impossible travel rule is one of the most critical security measures for any organization, and it would have completely crippled the malicious actor in the case of this client. So make sure to set up this rule in your SIEM and configure it to trigger alerts immediately so you can take quick action to secure your environment.
4. Successful brute force — Brute force rules alone are usually pretty ineffective for deployment like Azure AD, where their username is their easily accessible email address. A brute force rule will constantly fire since accounts are getting brute forced all the time! Instead add some additional correlations for your brute force rules, I recommend the following: Successful sign in after 7+ failed attempts from the same device. Successful authentication of username/password, but failing 2fa.
5. Another useful rule to monitor is mass outbound emails from a user. While this rule can be set up in Office 365, it’s also possible to configure it in your SIEM. If you notice outbound emails exceeding 50-100 within an hour, there’s a high chance that the account has been compromised and is being used to attack other users. This alert can help you quickly identify and remediate the issue.

This article was definitely more high-level then usual. While these controls are not exhaustive, they form a strong foundation for a comprehensive security posture.

However, we understand that the implementation of security controls can be a daunting task, especially for organizations that lack the necessary expertise and resources. Therefore, we are excited to announce that next week, we will have one of the most respected names in the industry provide a deep dive into the configuration of Azure AD security controls. This expert will share implementation guides, screenshots, and other practical insights to help organizations strengthen their Azure AD security.

Stay tuned for this in-depth article, which will serve as a practical guide for organizations seeking to improve their security posture. In the meantime, we hope that this high-level overview will provide some valuable insights into the key security controls that organizations should consider implementing to secure their cloud environment.

Looking for incident response assistance? Contact us at incidentresponse@tridentstack.com, and we’ll be more than happy to assist you. Additionally, if you’re interested in a full-service SIEM SaaS that can detect attacks like the one described in this article, check out our website at https://tridentstack.com/ or email our sales team at sales@tridentstack.com.

We also offer a live demo of our platform that you can view at https://tridentstack.com/demo/. We believe that our platform can help your organization stay one step ahead of potential threats and attacks.

So, happy hunting! We hope that the information in this article has been helpful to you, and we look forward to hearing from you soon.