Microsoft Defender XDR includes a powerful response capability with the name Attack Disruption. As part of the Defender XDR solution attack disruption capabilities can protect the environment against sophisticated, high-impact attacks. Attack Disruption works automatically; however, it still needs manual configuration of the individual products to interact with the attack. In this blog, I will explain the requirements of Attack Disruption and how to make sure Attack Disruption can run automatically in the environment. Still, I see environments where some components of Attack Disruption are not configured correctly. Let’s explain Attack Disruption in-depth.

Microsoft attack disruption is using the power of Defender XDR to correlate all signals from multiple products. When the attack is in progress Microsoft 365 Defender disrupts the attack by containing the assets that the attacker is using via the attack disruption capability. With this approach, Microsoft stops the attack early prevents further damage, and more importantly reduces the overall impact of the attack.

Microsoft releases attack disruption to answer to the ever-growing volume of advanced, rapid, large-scale cybersecurity attack challenges. With the use of attack disruption, it is possible to answer quicker and prevent high-fidelity alerts.

How works attack disruption

Attack disruption is part of the Microsoft 365 Defender XDR ecosystem and correlates all signals from individual Defender and Microsoft security products. Attack disruption is enabled by default when all prerequisites are correctly enabled and configured – the feature is built-in and is based on the collected insights/ security research and AI models to combine and correlate events to identify advanced attacks and perform automated actions (attack disruption). How more tools and data are connected – how more threats will be automatically handled via Attack Disruption.

When checking the complete flow Automatic attack disruption operates in three stages:

Stage 1: Correlates events from Microsoft 365 Defender XDR across all products and creates one single, high-confidence incident based on all collected data from endpoints, identities, email, and collaboration tools. Calculation is performed to calculate high-fidelity attacks to avoid false positives

Stage 2: Identify affected assets controlled by the attacker that are used during the attack

Stage 3: Take automated response actions to contain the attack and isolate affected machines

Since automatic actions can lead to potential impact when the alert/ signal is classified as a false positive. Attack disruption is designed to rely on high-fidelity signals. Microsoft shares the following information:

In addition to XDR capabilities that correlate incidents with millions of Defender product signals across email, identity, applications, documents, devices, networks, and files. Insights from the continuous investigation of thousands of incidents by Microsoft’s security research team ensure that automatic attack disruption maintains a high signal-to-noise ratio (SNR). Microsoft

Based on the incident Microsoft calculates the incident and knows the “impact”. When multiple products are correlating alerts, Microsoft can validate the real attacks with confidence to avoid running automation as a false positive.

Simplified overview of the flow (not official Microsoft)

Available actions

Microsoft is leveraging the Microsoft XDR response actions which are part of the product. Example of available actions:

Endpoint (Microsoft Defender for Endpoint)

  • Contain device (part of the flow)
  • Contain user
  • Contain IP

With the leverage of Defender for Endpoint device discovery and containment, it is possible to detect unmanaged devices and block incoming/outgoing communication with the suspected device. With this approach the contain action is way more powerful, since attackers can use unmanaged devices as part of the network.

Attackers leverage mostly unmanaged devices for performing advanced attacks. With the use of contain it is possible to contain the unmanaged devices, even when the machine is not onboarded to Defender. Good to know – for the Contain action there is no requirement to have Defender for Identity – since the contain is part of Defender for Endpoint.

Identity (Microsoft Defender for Identity)

  • Disable user

With the leverage of Defender for Identity is it possible to block users in AD/ Entra ID. The actions will be performed via Defender for Identity. For on-premises/hybrid/cloud accounts there is a different flow:

  • When the user account is hosted in Active Directory: Defender for Identity triggers the disable user action on domain controllers running the Defender for Identity agent.
  • When the user account is hosted in Active Directory and is synced on Microsoft Entra ID: Defender for Identity triggers the disable user action via onboarded domain controllers. Attack disruption also disables the user account on the Entra ID synced account.
  • When the user account is hosted in Entra ID only (cloud native account): attack disruption disables the user account on the Entra ID synced account.

NOTE: When the user account is only in Microsoft Entra ID it is not dependent on the deployment of Microsoft Defender for Identity.

EntraID

  • Disable OAuth applications

Supported attacks

Currently, Microsoft supports a couple of attacks where attack disruption will take place. The following attacks are currently supported by attack disruption:

  • Human Operator Ransomware (HumOR)
  • Business email compromise (BEC)
  • Adversary in the middle (AiTM)
  • Password Spray attacks

There are more supported attacks based supporting for Attack Disruption; not all the scenarios are listed above. Most of the attacks are well known – let me explain the most common attacks quickly:

Human Operator Ransomware (HumOR)

In cases on Human human-operated ransomware, the attack will block access to critical data, network, or physical infrastructure. Human-operated ransomware can have a major impact since the deployment is rapid to increase the full damage. During attack disruption, it is important to reduce the risk from the earlier states.

Business email compromise (BEC)

A BEC attack relies upon the ability to look like someone with power within a company or a trusted external partner. Typical types of BEC attacks; (False invoice scam, CEO fraud, Account compromise, Attorney Impersonation, Data Theft).

BEC attacks are typically focused on financial gain, where the attacker tries to convince the victim to transfer funds to fraudulent accounts or pay fake invoices.

More information: What is business email compromise

Adversary in the middle (AiTM)

During AiTM attacks, a phished user interacts with an impersonated site created by the attacker. This allows the attacker to intercept credentials and session cookies – cookies include the MFA token, which makes this attack able to bypass multifactor authentication.

More information: Detecting and mitigating a multi-stage AiTM phishing and BEC campaign | Microsoft Security Blog & Automatically disrupt adversary-in-the-middle attacks with XDR (microsoft.com)

How to enable automatic attack disruption?

Automatic attack disruption is automatically enabled when using Microsoft 365 Defender. When using all Defender products it will increase the protection coverage. For automatically containing devices it is required to deploy Defender for Endpoint, blocking of user accounts requires Defender for Identity.

When checking the complete XDR view of Defender products – the following configuration is important. The reason is that attack disruption is an XDR capability – it requires multiple signals from multiple sources to gain confidence in the compromised assets.

  • Defender for Office
  • Defender for Endpoint
  • Defender for Identity
  • Defender for Cloud Apps
  • Azure AD Identity Protection (Correlated with Microsoft 365 Defender)
  • Microsoft Sentinel (only SAP Financial Process Manipulation)

Prerequisites

  • Defender products configured (to get full visibility)
  • Correct license/ subscription available
  • Defender for Endpoint device discovery set to standard discovery
  • Defender for Endpoint configured with automation level

The following prerequisites are needed. More information: Prerequisites for automatic attack disruption in Microsoft 365 Defender

Attack disruption works at its best when all products are deployed and configured. Each attack (AiTM/ BEC/ Operated ransomware) works on multiple signals across the Defender 365 product suite.

Ransomware (Human-Operated Ransomware) flow

Ransomware is complex and relies on multiple products and signals. The first phase of ransomware is based on initial access, reconnaissance, credential theft, lateral movement, persistence, reconnaissance, and defense evasion. Ransomware is not only focused on devices; since email for the initial access and reconnaissance is an important step during a real attack.

When attacks are complex; Microsoft relies on the following products to share and correlate events:

  • Defender for Identity
  • Defender for Office
  • Defender for Endpoint
  • Azure AD Identity Production

The typical action during Human-operated ransomware is to contain the device used for the ransomware deployment and block/contain the affected user. With the use of Defender for Identity it is possible to disable the user completely.

More information: Automatic disruption of Ransomware and BEC attacks with Microsoft 365 Defender

Configure features in the products

When having the products – make sure they are correctly configured. It is always recommended that best practices be followed for all individual products and that the products be configured with the best protection and event collection. For attack disruption, the following is important for each single product:

Defender for Endpoint

Since attack disruption relies heavily on the discovery and contain feature it is important to configure Defender for Endpoint to discover unmanaged devices in the network and the automatically responses actions.

Device discovery

First, we need to configure the device discovery to standard discovery. With the use of device discovery Defender for Endpoint can discover unmanaged devices connected to the corporate network.

In general, there are two ways of discovery

  • Basic discovery
  • Standard discovery

For the contain and attack disruption functionality it is needed to configure the standard discovery mode. This discovery is active and based on common discovery protocols/ multicast with smart active probing. Without the standard discovery, the contain will not work in a typical attack, and for ransomware, devices must contain as soon as possible.

Configuration is possible via Microsoft 365 Defender. Navigate to Settings -> Device Discovery.

The discovery mode must be “standard discovery”. It is recommended to discover via all devices; when needed it is possible to select device groups to discover by tag. Unwanted networks can be excluded via the monitored network configuration.

Run the following query to check if machines are discovered in the environment.

DeviceInfo
| summarize arg_max(Timestamp, *) by DeviceId  // Get latest known good per device Id
| where isempty(MergedToDeviceId) // Remove invalidated/merged devices
| where OnboardingStatus != "Onboarded"

Automation levels

The automated action in Defender for Endpoint is based on the automation level for device groups. Ideally, actions will be performed automatically during Attack Disruption responses. With the levels of automation, it is possible to define the level and exclude devices from automated response actions.

I recommend using the Full – remediate threats automatically level – since this remediates threats automatically and will perform automatic actions ( file collections/quarantine/ submissions). When needed configures exclusions for specific machines.

Sense

The minimal Sense Agent needs to be 10.8470 or higher. This is needed to get the Contain User action supported. It is heavily recommended to update the Sense agent to the latest available and supported version. Since other features are relying on Sense and Microsoft is fixing bugs with the Sense versions.

Outdated versions (MMA)

Make sure to update the agents and follow the trends and latest innovations. I see often environments with a Defender for Endpoint configuration from years ago; where the MMA agent is still used for down-level servers. It is important to keep the agents up to date with the latest version to use new features like attack disruption and deception.

Follow the trends; Microsoft is developing Defender XDR hard with unique features like Automatic attack disruption and deception. Another good tip is to track compliance for all discovered machines – make sure to onboard as many systems to Defender for Endpoint. With the use of device discovery in Defender for Endpoint, it is possible to detect non-onboarded machines in the network.

Defender for Identity

The disabled user activity is based on the Microsoft Defender Identity capability. As part of the integration, the attack disruption flow will automatically block the compromised account to prevent additional damage.

Manage action accounts

To get this feature up and running it is needed to configure the action account in Defender for Identity. Currently, there are two options for configuring the action account:

  • Automatically use the sensor’s local system account
  • Manually configure your management accounts

When selecting manual it is possible to configure a gMSA account. When using the automatic option the local system account of the sensor is used.

More information: Microsoft Defender for Identity action accounts

The disable user action relies on the on-premises Active Directory. When the account is not found/ or detected the following error is visible in M365D Action Center:

Sensor

Another important point is to set up the correct auditing for Microsoft Defender for Identity – make sure the logs are correctly configured and auditing is enabled following the Defender for Identity best practices and instructions. Check in the portal that all sensors are healthy and working correctly.

In some environments there are scripts to check if all active employees have enabled accounts (HR toolings) – of course, this can increase the risk when deactivated accounts by attack disruptions are getting automatically re-enabled.

Defender for Cloud Apps

For Defender for Cloud Apps make sure the Microsoft 365 connector is correctly enabled. Another point related to Defender for Cloud Apps is the enablement of App Governance.

Defender for Office 365

In Defender for Office 365, it is needed to enable a minimal set of auditing. The following mailbox events need to be audited as minimal:

  • HardDelete
  • MailItemsAccessed
  • UpdateInboxRules
  • MoveToDeletedItems
  • SoftDelete

And make sure there is a Defender for Office safelinks policy available in the tenant.

Attack disruption in action

Simulate the Human-Operated Attack and Attack Disruption in action

Let’s start with some fun. In this simulation, the attack starts with the use of a non-onboarded Windows Server exposed to the internet (internet facing). This machine is not onboarded to Defender for Endpoint and part of the domain, it was vulnerable with a couple of CVEs.

The attacker uses Mimikatz/ other credential dump tools to dump the domain administrator account since it was stored on the machine. During this attack, the account with domain administrator privileges is Bill, since the credentials were exposed on the server and collected by credential dumping.

From now on the attacker is using the account Bill

All remaining devices and the domain controller are already onboarded to Defender for Endpoint and the domain controller is onboarded to Defender for Identity.

Creating new accounts

From the internet-facing machines and with the use of the account Bill the attacker is creating additional accounts with the name Backup-account using Command Prompts and adds the backup account to the Domain Administrator group.

This activity is already detected by the use of Defender for identity with the alert title “Suspicious additions to sensitive groups”

Lateral movement to a domain controller

Using the account, the attacker now connects to a domain controller using RDP. The attacker now has full control of the network via the domain controller/ and additional accounts with high privileges.

Summarize:

  • Attacker has access to a compromised VM part of the domain DC-LAB7
  • Attacker is using the Domain Admin account Bill
  • Atttacker is targeting against DC-LAB5 for further lateral movement
  • Attacker created an additional Domain Admin account with the name Backup

Sounds game over right with full control; right?

Malicious activity

With the use of impacket (common attack framework), the attacker starts using the dump of credentials and other malicious activity related to lateral movement. Since Defender for Endpoint is already onboarded on the other machines, impacket is blocked by Defender AV. From this stage, the attacker with the account bill is suspicious of the use of lateral movement/ account creation and malicious attempts using impacket.

Privilege escalation is performed with the use of Impacket

impacket-smbexec 'm365securitylab.local/Bill:Secret20231@DC01.m365securitylab.local' 

impacket-wmiexec 'm365securitylab.local/Bill:Secret20231@DCLAB-5.m365securitylab.local' whoami

lsassy -u Bill -p Secret2023! DCLAB-5.m365securitylab.local

Credential dump for additional lateral movement is failed, due to hardening restrictions.

Impacket is performed via wmiexec/ smbexec. This toolkit is already detected by Defender AV and blocked in the execution. In the below screenshot, you can see the referenced account with the name Bill is already disabled.

Impacket is blocked by Defender AV and detected by the EDR component.

Automatic attack disruption

Policy to contain user

Attack disruption is putting a policy on all the machines (all onboarded machines) – from this stage inline/ real-time the account is blocked to block the login attempt from the Bill account. It is not performed by Defender for Identity/ contain user is blocked on the endpoint is using Defender for Endpoint.

Good to know when the user is contained – this sign-in restriction control takes effect immediately and is effective regardless of the state of the account (enabled/ disabled). It leverages Defender for Endpoint and does not leverage Defender for Identity.

The policy is located:

The remote desktop session ended

The remote desktop session performed to the Domain Controller or other onboarded machines is directly restricted. Since Automatic attack disruption is near to real-time it blocks the active session which results in the following screen:

In case a compromised account had already a foothold on the device; attack disruption will disconnect the session. Once the session is terminated the attacker is restricted by a sign-in restriction control policy.

Other account Backup

But wait; Bill created an account with the name Backup. So we have all times a backup. Let’s try to reconnect to the domain controller with the use of the backup account since it was created before.

The account creation was already detected in the early stage and is blocked as well. So there is no activity possible via the Backup account.

Create additional account

The attacker may detect now the Domain Admin user is already blocked/ suspicious. Since Bill has still access to the non-onboarded internet-facing machine, the attacker is trying to create additional accounts. We are creating Backup2.

Attack disruption is disabling activities to use further in lateral movement, the account creation is now blocked – since the capabilities are limited for the user Bill and lateral movement activity is blocked.

Visibility in Defender XDR

In Defender XDR the complete picture is visible. It started with the following alerts:

  • User-created or modified an account that later performed malicious activity
  • User was created or modified by a compromised account
  • User’s password was changed by a compromised account

The lateral movement is detected with the following alert:

  • Possible lateral movement

The dumps of credentials and the use of Impacket are detected by the EDR sensor with the following alerts:

  • Suspicious service registration
  • Suspicious behavior by cmd.exe was observed
  • Suspicious command launched from a remote location
  • Suspicious Scheduled Task Process Launched
  • Suspicious remote activity
  • Impacket module execution
  • Process memory dump
  • ‘DumpLsass’ malware was detected during lateral movement

The hands-on-keyboard attack via the Impacket toolkit is detected and triggers the following alerts:

  • Ongoing hands-on-keyboard attack via Impacket toolkit
  • Compromised account conducting hands-on-keyboard attack
  • Impacket toolkit
  • ‘Impacket’ malware was detected during lateral movement

Each related Attack Disruption alert is tagged with the tag “Attack Disruption”

Further lateral movement is triggered by the following alerts:

  • Lateral movement using SMB remote file access is blocked on multiple devices
  • Lateral movement using RDP blocked
  • Lateral movement using remote logon by contained user blocked on multiple endpoints

Full incident picture

Attack disruption can be easily detected by the set tag “Attack Disruption” and the yellow informational bar with the following text:

“Important! Attack disruption has automatically taken multiple response actions. For more details, go to the Action Center.”

Different view leveraging the DCLAB-7 as initial stepping machine to leverage access to the Domain Controller. In this view, you can see perfectly that the account billg created the backup account from the DCLAB-7 machine and leverages access to the DClab-5 machine via impacket.

In the Defender XDR Action Center we can view the history of the automated attack disruption actions. All actions are visible in the Action source category “Attack disruption”

  • Contain user is performed by MDE (Backup account/ Bill account)
  • Disable user is performed by MDI (Bill account)

With the action center buttons, it is possible to enable/ disable the account. For the disabled user, the action can be restored via “Enable user”.

For the contain the action can be undone with the “Undo” button. This restriction is automatically lifted after a 12-hour duration. Important: Always check the investigation in-depth and don’t restore accounts without any further investigation. This action will restore the user’s connection to the network and can have an impact during real attacks – since the account can perform additional/ further actions.

When opening the user’s Sid or Displayname the user detail page will be opened.

Account from Bill (contained and disabled)

Created Backup account (contained)

View events in Advanced Hunting

Using Advanced Hunting it is possible to view all events related to the Contain future in the DeviceEvents table. In the example below it shows the UserLogonBlocked events/ RemoteDesktopDessionDisconnected and more like ContainedUserSMBSessionStopped.

Conclusion

Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully. Make sure that all features and configurations are available. It is enabled out-of-the-box in all the tenants, the actions depend on the configuration and used products. With more sources connected Attack Disruption can stop more attacks and gain more events. So double-check that Attack Disruption is working correctly and is configured following the best practices!