BEC-ware the Phish (part 2): Respond and Remediate Incidents in M365

TL;DR

• Ensure you can reliably take initial containment actions such as disabling accounts, resetting passwords, and revoking tokens.
• Token binding ensures that a token only works on the specific device the token was issued and is currently the best protection against token theft.
• As a minimum enable Security Defaults to require MFA for all privileged users.
• Look to enable Conditional Access policies which enforce location, device compliance, and session lifetime controls for high value identities and services.
• Validate configuration changes, such as checking CA policies are enforced as expected with sign-in log data.
• Ensure admin account separation with segregated cloud-only identity for cloud administrative activities, without access to ‘phishable’ services like email.

Introduction

This is the second in a three-part series looking at the key steps for an effective investigation, response, and remediation of email-based threat in M365.

Part one looked at the key artefacts to optimise investigation outcomes for BEC in M365. Having the UAL enabled was critical to answering the investigation questions, and utilising Defender for Office and Defender for Cloud Apps tables in Advanced Hunting provides the most granular detail and scalable analysis.

This part covers the response and remediation actions in M365. The response steps help to contain an incident and buy time to establish the scope of compromise. Short-term remediation actions help get things back to business as usual, whereas long-term remediations focus on preventing the attackers getting back in.

Respond

Initial Containment

Disable compromised accounts quickly. This helps disrupt the attacker and buy time to work out the full scope of what has happened.

When disabling accounts in Entra, be mindful of the On-Premises Directory Synchronisation Service Account re-enabling those accounts. This is the dedicated account for hybrid identity used to synchronise on premise AD with the Microsoft Entra tenant of a M365 subscription.

As a defence in depth measure, you can remove any roles from the compromised account.

Reset the compromised password

The password reset should not be sent through email if the mailbox is presumed compromise.

For hybrid AD, Microsoft recommend changing the user’s password twice to mitigate the risk of pass-the-hash caused by delays in on-premises password replication.

Revoke tokens in Entra

If a user’s token has been compromised such as by AiTM phishing, resetting passwords will not go far enough to remove the attacker.

Revoking refresh tokens won’t immediately invalidate the access token, which typically has a one-hour lifetime. Entra ID issues authorised users an access token and a refresh token. When the access token expires, the refresh token is passed to Entra ID to silently reauthenticate the user. This means a threat actor will still have access to a revoked user’s account until the access token expires.

Consider token revocation for third party applications

For session tokens (cookies) facilitated by Entra, users receive two session tokens; one from Entra ID and another from the application. Entra’s authorisation policies will only be reevaluated as when the application sends the user back to Entra. Applications may be configured not to send users back to Entra when the application’s session token is valid. This can result in third party service tokens not being revoked even if the Entra token is.

Blocking emails with compromise indicators

Add indicators of compromise (IOCs) to security tooling to disrupt a phishing campaign in real time. IOCs can be added at different security layers including EDR and email security tooling.

Malicious domains or sender addresses can be added to Defender’s Tenant Allow/Block List,  which overrides Defender for Office or Exchange Online Protection (EOP) filtering.

Malicious URL’s or file hashes can be added to Defender (or in place EDR) to prevent users making network connections to an identified phishing page or downloading malicious attachments.

Prevent compromised users sending outbound emails

In the case of follow on BEC activity, add compromised users to Defender’s Restricted entities page to prevent them sending phishing emails.

Initiate takedowns

Phishing attacks use landing pages often hosted by legitimate web hosting services. Users are then directed to malicious sites impersonating Microsoft sign in, to capture credentials and intercept MFA prompts. Landing pages are typically registered within a 24-hour window of the first login to a compromised mailbox. Getting these sites taken down quickly renders the attack ineffective against is a good way to protect your reputation if phishing lures have been sent from your organisation.

Best practice for Respond actions

Defender automated investigation and response

Automating response actions means they can be taken rapidly and consistently.

Defender includes an Automated investigation and response (AIR) capability. When an alert is triggered a corresponding security playbook starts an automated investigation. This attaches response actions which require approval in the Action center.

For example, for a “Malicious URL (A malicious URL was detected by Safe Links)” alert, Defender for Office generates response actions “Soft delete email/cluster” and “Block URL (time-of-click verification)”.

Defender for Office 365 automated remediation actions include:

• Soft deleting email messages or clusters
• Block URL (time-of-click verification)
• Turning off external mail forwarding
• Removing delegation rules

Figure 1 – Source: https://learn. us/defender-office-365/remediate-malicious-email-delivered-office-365

 

Designing Sentinel playbooks or logic apps

Automating response actions can be configured with logic apps or Sentinel playbooks.

This allows actions like disabling a compromised account to be triggered automatically from an alert with automation rules or taken by a SOC analyst from the SIEM. Sentinel playbooks can be deployed from ARM templates such as the Sentinel playbook to revoke tokens for a compromised user.

Figure 2 – Source: https://www.anssipaivinen.fi/posts/Revoke-User-Sign-In-Sessions-by-Logic-App-Sentinel-Playbook/

 

Response account and permissions

Response actions require privileged permissions, the requirements for which can be complex.

For example, if using the revokeSignInSessions Graph API to revoke session tokens as discussed in the Sentinel playbooks, the delegate permissions needed to revoke refresh tokens will also depend on the privileges of the target account.

Best practice is to have a pre-configured account and/or applications with the required permissions to take necessary response actions.

Scalability and mass containment actions

Where a threat actor has had extensive access to an environment, mass containment may be required. Consider the challenges of taking remediation actions at scale, such as a company-wide password reset.

Short-term remediation

Once the key investigation questions have been answered and the incident scope established.

Bring disabled accounts back online.

It is important to do this only once the scope of the attack has been understood and trade this off with the business impact.

Best approaches would be to make sure that compromised users have passed a minimum-security standard before being re-enabled. This may include a clean AV scan, no EDR alerts, token revocation and password reset.

Once an account has been enabled there is usually a delay before of around 15 minutes for SharePoint and Teams, and 30 minutes for Exchange.

Restore functionality to the account.

If removed, re-add required permissions to the account. If the user was blocked from sending messages they can be removed from Defender’s restricted page or using the Exchange PowerShell cmdlets Get-BlockedSenderAddress and Remove-BlockedSenderAddress.

Address exposed sensitive information.

Consider the data has been exposed to the threat actor, as users may store sensitive information in their mailboxes and SharePoint. Exposed credentials should be reset to prevent further compromise, and any expose secrets expired and rotated.

The investigation should identify data accessed by the attacker, for which Unified audit logging events are essential. Purview can be used to scan an environment for sensitive information, such as credentials or PII that would have been exposed to an attacker.

Figure 3 – Example User login credentials pattern matching in Purview

 

If required, notify

Once the immediate threat to the environment has been contained, notify appropriate third parties or impacted organisations. This could a legal obligation to report a data breach to the information commissioner’s office (ICO ) or a notification to a third party for goodwill. For example, if compromise has resulted in follow on BEC activity, notify any recipient organisations.

Clean up

This should include the removal of malicious emails from user mailboxes, inbox-rules created by the attacker, or any malicious OAuth apps registered.

Server-side outlook rules can be managed with Exchange PowerShell’s Get-InboxRule , Disable-InboxRule and Remove-InboxRule cmdlets. However, client-side rules can only be deleted by singing into the user’s mailbox.

Remove external analyst accounts

If access has been granted to third-party analysts, remove these accounts. These accounts should always be configured with MFA, as they will likely require high privileges required to investigate and remediate the environment.

Long-term remediation

MFA

MFA provides a basic level of protection against standard phishing or brute force attacks, where only the password is known to the attacker.

Organisations are at different levels of maturity when it comes to MFA.

MFA can be enforced by three mechanisms:

• Adaptive MFA using Conditional Access (CA)
• MFA using Security Defaults
• Legacy MFA (Per-user)

Legacy MFA

Legacy MFA settings are configured on a per user basis. This does not enforce any minimum standard and can lead to inconsistencies.

If the organisation is still using legacy MFA, remove weaker MFA options and ensure all privileged roles have MFA enforced. Organisations still using legacy MFA should then move to Security Defaults or CA. Tenants created on or after October 2019 should have security defaults enabled by default.

Security defaults

Security defaults is targeted to smaller organisations and those using the free tier of Entra ID. This implements a good baseline, such as blocking legacy authentication protocols and enforcing MFA for administrative users.

Figure 4 – Source: https://learn.microsoft.com/en-gb/entra/fundamentals/security-defaults

 

Conditional access

Conditional access gives the most granular level control over access policies.

Suggested CA policies for BEC threats

• Only allow sign-ins from compliant devices registered with intune
• Location-based policies to deny or enforce MFA for sign-in events that originate from locations that sit outside of expected locations.
• Specify that only phishing-resistant authentication methods be used to access sensitive resources.
• Require bound tokens for accessing resources. Token binding prevents an attacker using a compromised token by binding the session token to the device to which it has been issued.

Figure 5 – Source: https://learn.microsoft.com/en-gb/entra/fundamentals/security-defaults

 

Authentication Strength

Authentication strength is a CA control that specifies which combinations of authentication methods can be used to access a resource.

Figure 6  Source:- https://learn.microsoft.com/en-us/entra/identity/authentication/media/concept-authentication-strengths/conditional-access-policy-authentication-strength-grant-control.png

 

The built-in Phishing-resistant options include Windows Hello for Business, FIDO2 security key or Microsoft Entra certificate-based authentication.

Figure 7 – Source: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths

 

Continuous access evaluation (CAE) addresses the time delay in token revocation, by providing a mechanism for a non-expired token to be rejected following a ‘critical event’ or in line with CA policies.

This provides effectively near real time token revocation for services like Exchange, SharePoint and Teams.

When the resource provider evaluates the validity of the token, it checks whether there are any revocation events for the user. The resource provider will reject a token for the following critical events:

• User Account is deleted or disabled
• Password for a user is changed or reset
• Multifactor authentication is enabled for the user
• Administrator explicitly revokes all refresh tokens for a user
• High user risk detected by Microsoft Entra ID Protection

Figure 8 – Source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/media/concept-continuous-access-evaluation/user-revocation-event-flow.png

 

Deploying CA policies

Rather than writing CA policies from scratch, Conditional Access templates provide a convenient method to deploy new policies aligned with Microsoft recommendations. Deploy policies in a monitoring-mode first and use the “What If” tool to understand the result of CA policies.

Figure 9 – Source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/what-if-tool

 

Focus on deploying these controls to applications and users that have the greatest risk, such as:

• Privileged users like Global Administrators
• Financial applications or those containing PII which may be targeted for exfiltration.
• Management access to cloud admin portals (Azure, Defender etc.)
• VPN or remote access portals

Validate CA policies

Once CA policies are implemented check the Sign in logs to check they are being enforced as expected. If Sign in logs are forwarded to Log Analytics, Azure AD has a selection of pre-built workbooks (dashboards) to review log data.

• Sign-ins using Legacy Auth
• Sign-ins
• Conditional Access Insights
• App Consent Audit
• Sensitive Operations Report
• Continuous access evaluation insights

Active Directory Workbooks:

Figure 10 – Source: https://katystech.blog/media/azure/azure-ad-log-analytics/log-analytics-3.png

 

Environment hardening

Use Intune to require managed and compliant devices

Using Intune enforce LSA protection and credential guard will prevent untrusted processes from accessing tokens. When used in combination with CA, this ensures only compliant devices can access company resources, reducing the likelihood that a token can be stolen from a device.

Entra Password Protection

Whilst not directly preventing phishing, Entra password protection hardens the environment to password spray attacks.  A default global banned password list is applied to all users and can be customised with company-specific terms. Look at modifying the threshold and lockout duration to suit risk tolerance.

Figure 11 –   Entra admin centre Protection > Authentication methods > Password protection. Source: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-password-smart-lockout

 

Restrict communication settings for External Teams users

Email is not the only vector used for phishing. Restrict external organisations being able communicate on Teams, by either excluding altogether or specifying the domains that can collaborate.

https://admin.teams.microsoft.com/ > Users > External Access

Figure 12: Teams external access configuration

 

Manage app consent policies

Consent (OAuth) Phishing tricks users into installing malicious OAuth applications rather than providing their credentials. Users may be presented with a link in an email that when clicked requests that the user consent to an application. If the user has the right to consent, the application is granted access to the data.

Consent phishing has been used by nation-state actors for purposes such as command-and-control (C2) communication, backdoors, phishing and cryptomining.

Configure user consent settings to control which applications users can consent to and Enable Admin Consent to require administrator approval. For example, enforce that users can only consent only apps developed by your organisation, from verified publishers, or those that require low-risk permissions.

Figure 13 – Source: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent?pivots=portal

 

Audit apps and consented permissions in accordance with the principles of least privilege. You can configure custom policies to alert on new OAuth apps, but Defender for Cloud Apps does the heavy lifting with OTB policies for risky OAuth apps.

Follow principle of least privilege

Identities should be assigned in accordance with the principle of least privilege. Compromised administrative accounts cause more damage and make investigations harder as they enable anti-forensics techniques such as deleting or disabling UAL.

Enforce cloud-only identities and privileged account separation

Users with high privileges in a tenant should have a segregated cloud-only identity for all administrative activities. These accounts should not have access to “phishable” services such as email or teams.

The reverse should also be considered, as privileged on-premises accounts could be used to pivot into Microsoft Entra ID, expanding the scope of the compromise. Synced service accounts are particularly vulnerable as cannot be subject to controls to the same controls as user accounts, such as MFA or Privileged Identity Management (PIM).

Summary

• Ensure quick, consistent response actions: disable accounts, reset passwords, and revoke tokens for compromised users.
• The permissions required to take response actions should be considered in advance, with Sentinel playbooks and pre-configure and automate response.
• Use Defender’s allow/block list to override email filtering policy where a phishing campaign has evaded existing controls.
• For follow-on phishing, initiate takedowns of landing pages and use restricted entities to prevent outbound emails being sent from your organisation.
• Short-term remediation should restore functionality once the scope of compromise is understood and consider any sensitive information exposed to an attacker.
• Harden the environment with MFA, app consent policies and conditional access for high value accounts and services.
• Enable CAE for near real-time token revocation and token binding to prevent use of compromised tokens.
• Follow the principle of least privilege, enforce cloud-only identities, and separate privileged accounts to protect valuable account from phishing.

You can read the last of this 3 post series here.