Microsoft announced last year a new feature with the name; Automatic Attack Disruption in Defender XDR (Microsoft 365 Defender). Since October last year, Microsoft expanded the Automatic attack disruption feature with the support of human-operated attacks and the ability of user containment. My earlier published blog includes the basics of Attack disruption; this blog will go more in-depth about Human-operated ransomware and user containment as part of Defender XDR. With this new feature, Microsoft can stop human-operated attacks on its own with the use of automated actions.

Human-operated ransomware attacks

In these attacks; lateral movement follows initial access during the next stage of the attack and targets valuable assets and sensitive data. User account compromise is based on different techniques like credential dumping, keylogging, brute-forcing, or poor credential hygiene.

With poor credential hygiene lateral movement can quickly lead to the compromise of domain-level accounts. With the use of domain-admin level accounts the attackers gain access to domain resources and devices and have mostly the ability to take over the complete network. For example; an attacker can target a vulnerable internet-facing server for the initial access.

Highly privileged user accounts are the most important assets for attackers with access to Active Directory. In addition to the compromised accounts, attackers are mostly creating new highly privileged user accounts as “backup” to keep access in the environment.

What is user containment?

User containment prevents a compromised user account from accessing endpoints and other resources in the network, with the main focus on limiting the attacker’s ability to move in the environment. User containment is part of Attack Disruption and is automatically triggered by high-fidelity signals indicating that a compromised user account is being used in an ongoing active attack.

The actual set of controls triggered to contain a user might vary depending on the attack scenario and stage, and includes:

  • Sign-in restrictions
  • Intercepting SMB activity
  • Filtering RPC activity
  • Disconnecting or terminating active sessions

More information: https://www.microsoft.com/en-us/security/blog/2023/10/11/automatic-disruption-of-human-operated-attacks-through-containment-of-compromised-user-accounts/

What happens when an identity is contained?

When an identity is contained, any supported Microsoft Defender for Endpoint onboarded device will block incoming traffic in specific protocols related to attacks (network logons, RPC, SMB, RDP) while enabling legitimate traffic. User containment supports terminating active RDP sessions and prevents further activity. The image below gives a good view of the human-operated attack stage:

Source: Microsoft

Must read blog from Microsoft related to human-operated attacks and the use of user containment: Automatic disruption of human-operated attacks through containment of compromised user accounts

How works automatic attack disruption?

Attack disruption is part of the Microsoft 365 XDR ecosystem and correlates all signals from individual Defender/ Microsoft security products as part of the XDR solution. 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).

If the beginning of a human-operated attack is detected on a single device, attack disruption will stop the campaign on that device and inoculate all other devices in the organization to prevent further damage. The goal of automatic attack disruption is to contain compromised users across all devices to outmaneuver attackers before they have the chance to act with malicious items (credential theft/ data exfiltration/ remote encryption). More later in this blog including a simulation.

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.

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 correlate alerts, Microsoft can confidently validate the real attacks 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)

The below actions are performed by Defender for Endpoint

  • Contain device
  • Contain user
  • Contain unmanaged devices

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.

Identity (Microsoft Defender for Identity)

The disable user action is powered by the Defender for identity sensor/ product.

  • 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.

How to enable automatic attack disruption in Defender XDR?

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 – Defender XDR is more efficient with the full product suite and signals across the products.

The reason is that attack disruption is an XDR capability – it requires multiple signals from multiple sources to gain confidence in the compromised assets. During the simulation, it makes it more clear why it is important to leverage multiple sources from identity to endpoint to gain full access and protection in typical ransomware attacks. The following products are involved in attack disruption:

  • Defender for Office
  • Defender for Endpoint
  • Defender for Identity
  • Defender for Cloud Apps
  • Entra ID Identity Protection (Correlated with Microsoft 365 Defender)

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

Blocking incoming communication with a “contained” user is supported on onboarded Microsoft Defender for Endpoint Windows 10 and 11 devices (Sense version 8740 and higher), Windows Server 2019+ devices, and Windows Servers 2012R2 and 2016 with the modern agent. More information: Contain user from the network

Configure features in the Defender products

When having the products – make sure they are correctly configured. It is always recommended to follow the best practices for all individual products and make sure the products are 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.

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. 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.

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:

Simulate the Human-Operated Attack and Attack Disruption in action

Collect credentials/ Initial access

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
  • Atatcker 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 is 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 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 impact during real attacks – since the account is able to 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.

Example KQL query to view all events related to contain:

DeviceEvents
| where Timestamp > ago(1d)
| where ActionType startswith "contain"

IMPORTANT – Attack disruption requires always investigation

Automatic attack disruption is no ultimate protection (detect and forget) – it is critically important to make sure the analyst is investigating the full attack. When the assets are contained/ blocked – the attacker will try to bypass and find more ways to launch the attack again. Always, Always investigate attack disruption alerts directly. Don’t think; it is already blocked we can resolve the alert.

When the attack is ‘stopped’ by attack disruption it is important to review the alerts/ incidents. Attack disruption will not resolve the full attack; it will give additional time for the SOC team and stop the growing count of infected assets. Since the attack is under control the SOC team can focus fully on the investigation and further remediation of the attack.

Stay up to date and onboard all machines

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.

Tip; read the following blog post from known mistakes around Defender for Endpoint: Common mistakes during Microsoft Defender for Endpoint deployments

Sources

Microsoft: Microsoft Defender for Endpoint now stops human-operated attacks on its own

Microsoft: Automatic disruption of human-operated attacks through containment of compromised user accounts

Microsoft: To learn more: Ninja show on October 12, 2023

Other attack disruption sources

Microsoft: Automatic attack disruption in Microsoft 365 Defender

Microsoft: Configure automatic attack disruption capabilities in Microsoft 365 Defender

Microsoft NinjaShow: Attack Disruption | Virtual Ninja Training with Heike Ritter

Microsoft Ignite: Microsoft 365 Defender: Stop attacks with automated cross-domain (XDR) security | LRN201

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