Compromise playbook: reset password and MFA
Step 2 closes the door the attacker came in through. Password and MFA reset together, with a secure credential handoff.
The password and MFA reset is step 2 of the compromise playbook. It closes the door the attacker came in through. Session revoke (step 1) ended their current sessions. The password reset ensures any future sign-in attempt using the old credentials fails. The MFA reset removes the attacker’s ability to satisfy second-factor challenges with methods they registered. The two belong together: resetting the password without resetting MFA leaves the attacker a foothold to recover the new password via password-reset flows that depend on MFA factors they still control.
The two-part action
Password reset. The user’s password changes to a new value. The old value (which the attacker held) no longer authenticates. The new value needs to reach the legitimate user securely.
MFA reset. The user’s existing MFA methods are removed (or partially removed, per the targeted-removal discipline in the MFA-devices lesson). Re-enrolment is required on the user’s next sign-in.
The Huntress portal usually pushes both to the identity provider in a single workflow. The action button on the Incident Report’s Recommendation is the standard trigger.
The procedure
Trigger the password and MFA reset
From the Huntress portal, on the affected identity (session revoke from step 1 already done), trigger the password and MFA reset action.
Capture the new password
The portal asks for or generates a new password. Auto-generated is preferred. It removes the operator-chosen-weak-password risk.
Verify the action applied
Portal shows reset completed. The identity’s password-last-changed timestamp updates. The MFA-methods list reflects the change.
Hand off the credential securely
Push the new password to your MSP’s documented secure-credential handoff tool (1Password Send, Bitwarden Send, a custom secure portal). Call the user on a documented-known number to confirm identity and walk them through accessing the credential. Document the handoff timestamp and method.
Secure credential handoff
The new password must reach the legitimate user without going through any channel the attacker may still control.
Do not email it to the user’s mailbox. The attacker may still be reading it via OAuth tokens or other persistence. Do not text it to the user’s recovery phone number. That may be a number the attacker added. Do not tell the customer’s IT manager casually over chat to “tell Sarah the new password.”
Use your MSP’s documented secure-credential handoff process: a password-handoff tool with a short-lived link, a phone call to a documented-known number, or a single-use secure portal. Verify the user’s identity at the handoff. Document the handoff timestamp and method.
The discipline: the new credential travels through a channel the attacker provably cannot access.
When the user re-enrols MFA
After the reset, the user signs in with the new password and is prompted to re-enrol MFA. Brief the user during the handoff call: “After you sign in, you will be prompted to set up your MFA again. Use your own phone, not a shared device. If you can, use an authenticator app rather than SMS.”
If the user cannot re-enrol immediately, the next sign-in attempt will prompt them. The attacker no longer has the password or working MFA, so they cannot get back in during the gap.
Common mistakes
Resetting the password but not the MFA. The attacker may have added their own MFA method. The password reset alone does not remove it. Future password-recovery flows would route to the attacker’s MFA. Both reset together.
Sending the new password via the user’s mailbox. The mailbox is potentially compromised. The new password lands where the attacker can see it. Out-of-band channel only.
Letting the user choose the new password verbally (“I will set it to MyDog2024”). The verbal password is in any voice-recording environment, possibly exposed. The operator-chosen-weak-password risk is real. Use the documented secure-credential generation in your MSP’s tooling.
When to escalate
- The portal’s reset action errors out. Retry once. Bump after the second failure.
- The reset succeeds but the user reports they cannot sign in with the new credentials. Could be a synchronisation issue with the identity provider. Bump.
- The affected identity is a service account or admin where a password reset has broader downstream impact (apps that authenticate as the account stop working). Bump. The senior coordinates with the customer’s IT.