Forum Discussion
AIR (Automated Investigation and Response) disables user in Active Directory, suspends in Entra ID
My organization saw an incident yesterday with a new-to-us behavior: Defender disabled the user access in Active Directory and suspended the user in Entra ID.
It was an AitM (Attacker in the Middle) scenario, which we believe was delivered via phishing message and a shared OneDrive file. Defender correctly identified the malicious activity and disabled the account shortly after.
I am curious because we have not seen this behavior before. Does anyone know if this is a new feature? Or possibly something that just hasn't hit our environment before (which seems unlikely)? I checked the following pages but didn't see anything that looked related:
- https://learn.microsoft.com/en-us/defender-xdr/whats-new
- https://learn.microsoft.com/en-us/defender-for-identity/whats-new
- https://learn.microsoft.com/en-us/defender-endpoint/whats-new-in-microsoft-defender-endpoint
I do see in security.microsoft.com under Settings - Microsoft Defender XDR -- Automation -- Identity automated response that we have the capability to exclude users from the automated response. It's possible this capability has been enabled for a while.
1 Reply
Hi redherring
this sounds more like an action taken by Automatic Attack Disruption. It's capabilities span across the Defender suite of products and in your particular case it leverages Defender for Identity, and its Domain Controller agent, to disable users on-premises. Note: DFI is not required for User disablement in Entra ID.
Attack Disruption has been GA since 2023 I believe and is very solid as far as its ability to identify truly malicious behavior and jump in the way. You can always revert the actions it takes very simply by going to the Action Center, finding the action issued by Automatic Attack Disruption and click Undo, as shown here. ( or scroll up a bit on that page and you can do it on the asset page of the remediated asset)
You can change the automation level for different device groups, here. I and many others have not seen Attack Disruption trigger on frivolous detections, so I'd recommend leaving it at Full Remediation (and you can always undo) but that's a choice you'll have to make for your org.
And as you pointed out you can add exclusions to disruption which may not be a bad idea in the case a bug/update/pentest accidentally attempts to lock out an important account. But hopefully you have a break glass procedure in such a case.
Hopefully this helps explain the activity you saw and happy to hear it jumped in at the right time!
Best regards,
Dylan
