Product · 6 MIN READ · JAKE GODGART · JUL 18, 2025 · TAGS: AI & automation
TL;DR
- This auto remediation series focuses on understanding the functionality of all of Expel’s auto remediations
- Disabling a user account is an immediate containment action that prevents a compromised identity from being used to authenticate, leveraging integrations with identity providers (IdPs) like Microsoft Entra ID, Okta, and Active Directory
- You can find blogs on these auto remediations as well (post-publication): Contain host, block bad hash, delete malicious file, delete registry key, reset credentials, disable access key, and remove malicious email
There’s a special kind of dread that sets in when you realize an attacker isn’t just knocking at the door—they’re already inside, wearing the digital face of one of your own employees.
They have a legitimate username and password. They’re using it to poke around your network, access sensitive files, and plot their next move. Every second they have access, the potential damage multiplies. This is the moment when speed isn’t just a metric; it’s everything.
This is precisely the pain point the disable user account remediation action is built to solve. Think of it as the digital emergency brake. When we disable a user account, we’re immediately revoking its ability to authenticate to any corporate resource. The attacker, who was just confidently navigating your environment, suddenly finds their joyride has come to a screeching halt.
The “so what?” here is immediate, decisive containment. By disabling the account, we instantly sever the attacker’s primary access vector. It stops them from logging into new systems, accessing more data, or escalating their privileges. This one action buys time to further investigate the full scope of the incident and remediate properly, without the pressure of an active intruder roaming your network.
But disabling an account is a big step, and it’s important to know when to use it versus other actions. It’s a more forceful move than simply resetting credentials, which invalidates a password but might not kick out an attacker who already has an active session. It’s different from terminating a session, which logs an attacker out but doesn’t stop them from logging right back in if they still have the password. And it’s distinct from containing a host, which isolates a compromised device but doesn’t address the risk of the user’s credentials being used on another machine.
Disabling the user account is the go-to move when the identity itself has become the weapon, and you need to neutralize it completely.
How it works
To understand why this action is so critical, let’s walk through a scenario straight from the trenches. It’s 10pm on a Tuesday. Things are quiet. Then, an alert fires.
Microsoft Entra ID Protection flags a “High-Risk User” due to an impossible travel login for an account belonging to an employee—let’s call her Sarah. She just authenticated from her usual location in Chicago, Illinois, and then again three minutes later from an IP address in Romania. That’s our first indicator. An automated alert is a good start, but it’s not enough to act on. This could be a VPN misconfiguration or some other quirk.
But then, our analyst sees the second piece of the puzzle in Expel Workbench™. The login from Romania was followed by a successful multi-factor authentication (MFA) push which was accepted from Chicago. That’s a bigger red flag. Attackers are getting good at tricking users into approving these via a technique called MFA fatigue.
So the analyst digs deeper. The session originating from Romania isn’t just sitting there. It’s making a beeline for SharePoint and starts accessing folders related to a confidential M&A project—a project Sarah has no business reason to access. It becomes clear this is an active intrusion.
The combination of impossible travel, suspicious MFA approval, and anomalous data access tells our analyst with high confidence that Sarah’s account is compromised and is being actively used to exfiltrate sensitive data.
This is when an analyst reaches for the disable user account auto remediation. The trigger isn’t just one alert; it’s the correlation of multiple data points across multiple point solutions that paints a clear picture of malicious activity. The analyst needs to act before that M&A data ends up for sale on the dark web.
The general conditions are clear: we have strong evidence of an account takeover, and the attacker is using that access to cause harm. It’s time to pull the brakes.
When to expect Expel to use this action
Disabling a user account is a powerful tool, and we don’t use it lightly. Based on the runbooks we’ve agreed on with you, you can expect our analysts to use this action in these common situations:
- High-confidence identity protection alerts: An alert like “Impossible Travel” or “Anomalous Token” fires from your Identity Provider (IdP) like Entra ID or Okta, and our investigation quickly validates it with other suspicious activity, like the SharePoint access in our scenario.
- Confirmed phishing with malicious login: Our team sees a user accessing a phishing site and a subsequent successful login from a suspicious source. We don’t wait; we assume compromise and disable the account.
- Active business email compromise (BEC) threats: We detect signs of an attacker inside a user’s mailbox, doing things like creating malicious inbox rules to hide their activity, sending internal phishing emails to other employees, or attempting wire fraud. Disabling the account immediately stops any financial and reputational bleeding.
- Credential stealer malware confirmed: Your EDR detects and confirms an infostealer (like Lumma Stealer or RedLine) on a user’s laptop. At that point, we have to assume every credential stored on or entered into that machine is compromised. We’ll disable the associated user account as a proactive measure.
- Lateral movement using a valid account: Our investigation uncovers an attacker using a specific user’s credentials to move through your network—for example, using PowerShell remoting or RDP to jump from a low-value workstation to a domain controller. Disabling that account is a critical step in disrupting their attack chain.
The disable user account auto remediation workflow
So, how does this happen in practice? It’s a methodical process that balances speed with safety, ensuring we take the right action without disrupting your business unnecessarily. Let’s use our scenario with Sarah’s compromised account.
1. Detection
The impossible travel alert from Microsoft Entra ID Protection is ingested by Workbench. Seconds later, our own detection flags the subsequent anomalous SharePoint access from the same suspicious session. Both alerts are automatically correlated to the same user and appear in the incident timeline.
2. Validation & context
This is where our analyst’s experience is key. Before hitting the button, they run a quick mental checklist:
- Is this expected? A quick check shows Sarah isn’t on a travel list and the IP address isn’t associated with a commercial VPN.
- What’s the source? The Romanian IP is abnormal for Sarah’s normal behavior.
- What’s the behavior? Accessing M&A data is highly abnormal for Sarah, whose role is in marketing. The conclusion is clear and confident: this is a compromise in progress.
3. Customer approval check
Now, Workbench checks the rules you’ve set. Your policy states that for standard user accounts (which Sarah’s is), a high-confidence finding of an active compromise is pre-approved for the disable user account auto remediation. It is also possible to set rules for your organization to exclude accounts: this is configured within Workbench so that the decision isn’t left up to analysts. You’re always in control.
4. Execution
With all checks passed, the analyst executes the remediation action directly from Workbench. Our platform sends a secure, authorized API call to the Microsoft Graph API to set the accountEnabled property for Sarah’s account to $false. The command is sent, and within seconds, the change is effective across your Microsoft 365 environment. We have checks in place to confirm the API call was successful; if it were to fail for any reason, the analyst is alerted to try an alternative method.
5. Confirmation
The Microsoft Graph API returns a success code, which is logged in the Workbench incident timeline as a permanent record. The attacker is now locked out and their active session is terminated. Any attempt they make to use Sarah’s credentials will fail.
But the job isn’t done. The analyst immediately pivots to the next steps: start investigating what data was accessed, and coordinate with your IT team to begin the process of securely restoring Sarah’s access once her machine is verified as clean and her password has been reset.
The immediate threat is taken care of, and now the full investigation can proceed from a position of control.
How to set it up
Taking swift, decisive action during an identity compromise is a hallmark of a modern security operation. Disabling a user account is one of the most effective tools in the arsenal.
For current Expel customers, review your auto remediation settings or learn more about how to get this configured for your IdPs by reaching out to your Engagement Manager. We can walk you through the process and help you define rules that fit your risk appetite.
For those not yet with Expel, if you’re tired of the dread that comes with watching attackers use legitimate credentials to roam your network, let’s talk. See how our security operations platform and expert analysts can give you the power to act decisively when it matters most. Get in touch for a demo.
