EXPEL BLOG

Explore Expel’s auto remediations: Reset credentials

alt=""

· 5 MIN READ · JAKE GODGART · AUG 18, 2025 · TAGS: AI & automation

TL;DR

  • This auto remediation series focuses on understanding the functionality of all of Expel’s auto remediations
  • The reset credentials action invalidates a user’s current password and terminates their active sessions, forcing them to create a new password after a successful multi-factor authentication (MFA) challenge using your identity provider (IDP)
  • You can find blogs on our other auto remediations here:  Kill process, contain hostblock bad hashdelete malicious filedelete registry key, disable access key, and remove malicious email

 

Stolen credentials are the skeleton keys of the internet. For an attacker, getting a valid username and password combination is like finding gold. Even with MFA in place, a compromised password is a serious liability. Attackers can use it in password spraying attacks against other services, wait for a lapse in MFA enforcement, or use it to add legitimacy to social engineering attempts. It’s a threat that doesn’t just go away on its own.

This is where security teams feel the pressure. You know a credential is out there in the wild, but what’s the right move? Do you lock the account and disrupt the user? Do you wait and see if the attacker actually gets in? The reality is, you need to act fast to make that stolen password worthless.

That’s precisely what our reset credentials auto remediation does. It’s the digital equivalent of immediately changing the locks when you know a key has been copied. With your pre-approval, we can instantly invalidate the compromised password and terminate all active sessions associated with that user. The attacker’s key no longer works, and if they were somehow already inside, they’re kicked out. The legitimate user will be prompted to create a new password on their next login, securing the account without the prolonged drama of a full-blown compromise investigation. It’s a fast, effective, and low-disruption way to neutralize a very common threat.

 

How it works

Let’s walk through a scenario that’s probably all too familiar. An employee gets a highly convincing phishing email. It looks like a legitimate notification from your IT department about a new VPN client, complete with company branding. The user clicks the link, lands on a pixel-perfect clone of your single-sign-on (SSO) page, and enters their username and password.

A second later, they get an MFA push notification on their phone from a city they’ve never been to. Thankfully, they’re savvy enough to hit “deny.” Your MFA control worked; the attacker didn’t get in. But here’s the problem: they now have the user’s valid password.

Our SOC gets an alert for “MFA denied due to suspicious location.” An analyst immediately jumps on it. They see the failed login attempt from an IP address associated with a known VPN service favored by attackers. By correlating that with email security logs, they see the user received and clicked a link in a known phishing campaign just moments before.

The conclusion is clear: the password is out. The attacker’s initial attempt was blocked, but they’re not going to just give up. They’ll hold onto that credential and try again later, maybe against a different service that isn’t protected by MFA. The credential is now a ticking time bomb.

With your pre-approval for this type of scenario, analysts can handle the compromised credentials themselves without requiring action from your team.. They trigger the reset credentials remediation action directly from Expel Workbench™. Our system sends an API command to your identity provider—like Microsoft Entra ID (Azure AD) or Okta—to expire the password and terminate all of the user’s active sessions. The attacker’s stolen key is now useless.

 

When to expect Expel to use this action

Resetting credentials is a surgical action. It’s not as disruptive as disabling an account, but it’s a powerful way to mitigate risk. Here are the common situations where our analysts will use this, assuming you’ve given us the go-ahead:

  • After a confirmed phishing credential submission: A user reports they entered their credentials into a fake login page. Even if MFA blocked the login, the password itself is compromised and needs to be invalidated.
  • Responding to credential stuffing/spraying attacks: We see a high volume of failed login attempts against one or more accounts, but the logs show the attackers are using the correct passwords. This indicates a breach somewhere else, and those passwords must be changed.
  • Post-infostealer malware cleanup: An endpoint was infected with malware known to steal credentials stored in browsers or other applications. As a critical cleanup step, we reset the password for any user who logged into that machine.
  • As a required step for account re-enablement: If we previously had to disable an account due to a compromise, we’ll force a password reset as a mandatory condition before giving the user access back.

 

The reset credentials auto remediation workflow

We don’t just blindly hit a button. Every remediation action follows a clear, logical process to ensure it’s the right move, every time. Here’s how it works using our phishing scenario.

1. Detection & identification

An alert fires in Workbench. It could be an “impossible travel” alert from your IDP, an MFA denial, or a user self-reporting phishing. The system flags the user account and the associated activity for review.

Example: An alert for “MFA denied for user ‘bob.smith’ from suspicious location” appears in Workbench moments after Bob reports a phishing email.

2. Validation & context

This is where our analyst digs in. They don’t just take the alert at face value. They correlate data from multiple sources. Is the source IP known to be malicious? Did the user recently click a link in a suspicious email? Are there other anomalous logins for this user? They’re confirming that the credential is truly compromised and that a password reset is the appropriate, proportional response.

Example: The analyst confirms the login attempt came from an IP address tied to a recent phishing campaign. They see in the email gateway logs that Bob received and clicked that exact phishing URL. They now have high confidence his password is in the hands of an attacker.

3. Customer approval check

Before taking any action, Workbench checks the rules you set. You have granular control over our auto remediations. You can choose to approve this action for all users, only for certain groups (e.g., non-executives), or require manual approval every time. We operate based on your comfort level. It’s your environment, your rules.

Example: The analyst submits a remediation action to reset credentials for any user confirmed to have submitted credentials to a phishing site. Based on your settings, either the action will be completed automatically or it will require action from your team to complete.

4. Execution

With the threat confirmed, Workbench executes the remediation. Workbench checks for permissions for auto remediation and sends a secure, automated command via API to your IDP (e.g., Entra ID, Okta). This single action does two things simultaneously: it flags the user’s account with “user must change password at next logon” and it terminates all of their current login sessions. This dual-action is critical for kicking out an attacker who might already be logged in.

Example: The analyst clicks the “reset credentials” button for bob.smith in Workbench. Our platform sends an API call to Microsoft Entra ID to expire Bob’s password and revoke all of his active session tokens.

5. Confirmation & next steps

We don’t just fire and forget. Workbench waits for a success message back from your IDP to confirm the action was completed. The entire workflow—from alert to remediation—is logged in the incident timeline for full transparency. The immediate threat is neutralized. The analyst then documents the findings and provides recommendations for follow-up, such as ensuring Bob’s device is clean.

Example: The Microsoft Entra ID API returns a success code. Workbench updates the incident, showing the password was reset and sessions were terminated. The next time Bob tries to log in, he’ll enter his old password, pass an MFA check, and then be immediately forced to create a new, secure password.

 

How to set it up

If you’re an Expel customer and want to turn on this capability, it’s straightforward. You can learn more about the reset credentials auto remediation and configure it for your environment right in Workbench. It involves ensuring your IDP integration is set up with the right permissions, and then defining the scope for whom you want this action to be automated. Reach out to your Expel account expert and they can walk you through it.

Not an Expel customer yet, but like the sound of no-nonsense security that works with the tools you already own? Let’s talk. We can show you how this works in your own environment.