M365 IR Containment: Password Reset Sequencing, Bulk Graph API Resets, TAP, and MFA Re-Registration

The password reset is necessary but not sufficient

IR6.2 blocked authentication and revoked sessions. The attacker can't sign in and their existing sessions are terminated. But the attacker still knows the compromised passwords. If you remove the emergency CA policy without resetting passwords, the attacker walks back in with the same credentials. The password reset is Step 3 in the containment sequence: it ensures the attacker's known credentials are invalid before the CA policy is eventually relaxed.

But a password reset alone doesn't remediate the authentication. Consider three failure modes. First, the attacker compromised the user's MFA method (registered a new phone number, added a software token, or intercepted push notifications via AiTM). The new password paired with the attacker's MFA method gives the attacker a path back in. Second, the attacker registered a FIDO2 key on the compromised account. The new password is irrelevant because the attacker authenticates passwordlessly with the key. Third, the password reset is communicated via email, and the attacker's forwarding rule (not yet removed) sends the new password to the attacker's external address.

The authentication remediation must address the password, the authentication methods, and the communication channel simultaneously. This section covers the sequencing, the bulk execution, and the MFA cleanup that makes the credential reset actually work.

Reset sequencing: privileged accounts first

The order of password resets matters when the attacker holds multiple accounts at different privilege levels. If you reset the standard user accounts first, the attacker (still holding the privileged account) can observe the resets in the audit log and take counter-actions: re-compromise the reset accounts, escalate other accounts, or establish new persistence before you reach the privileged account.

The correct sequence:

First: Service accounts and break-glass accounts. If any service accounts or break-glass accounts are compromised, reset these immediately. Service accounts may have standing permissions that the attacker is using for persistence. Break-glass accounts have unconditional Global Admin access that bypasses Conditional Access policies, including the emergency policy you deployed in IR6.2. A compromised break-glass account negates every other containment action because the attacker can undo anything you do from an account that no CA policy restricts.

Second: Privileged accounts. Reset accounts with administrative roles: Global Admin, Exchange Admin, Application Admin, Security Admin, and any custom roles with elevated permissions. The attacker's ability to counter your containment depends on their administrative access. Removing that access first protects the remaining containment steps. If the finance director's account had Exchange Admin (as in the walkthrough from IR5.15), that account is in this tier, not the standard tier, because the admin role changes the risk profile.

Third: Standard compromised accounts. Reset the remaining compromised accounts. With the privileged accounts already secured, the attacker can't use admin access to observe or counter the standard account resets. These resets can proceed at a normal pace with proper user communication.

# CONTAINMENT: Bulk password reset for compromised accounts
$accounts = @(
    @{ UPN = "breakglass@yourdomain.com";    Priority = "Break-glass" },
    @{ UPN = "finance.director@yourdomain.com"; Priority = "Privileged" },
    @{ UPN = "ap.clerk@yourdomain.com";        Priority = "Standard" },
    @{ UPN = "procurement.mgr@yourdomain.com"; Priority = "Standard" },
    @{ UPN = "cfo.assistant@yourdomain.com";   Priority = "Standard" }
)

foreach ($account in $accounts) {
    $newPassword = [System.Web.Security.Membership]::GeneratePassword(24, 6)
    $params = @{
        PasswordProfile = @{
            Password = $newPassword
            ForceChangePasswordNextSignIn = $true
        }
    }
    Update-MgUser -UserId $account.UPN -BodyParameter $params
    Write-Host "Reset: $($account.UPN) [$($account.Priority)] at $(Get-Date -Format 'u')"

    # Immediately revoke sessions after reset
    Revoke-MgUserSignInSession -UserId $account.UPN
}

The script generates a strong random password for each account and forces a password change on next sign-in. The Revoke-MgUserSignInSession after each reset ensures any cached tokens from the old password are invalidated. The ForceChangePasswordNextSignIn flag means the temporary password is single-use: the user must set a new password the first time they sign in.

Communicate the temporary passwords to users through an out-of-band channel: phone call, in-person, or a pre-established secure channel. Never through email. The attacker may still be reading forwarded email from the persistence mechanisms not yet removed in IR6.4. If the inbox rules and forwarding are still active (they are at this point in the sequence), any password sent via email goes directly to the attacker's external address. This is the most common operational mistake in password reset procedures: the IR team resets the password and emails the user their new credentials, and the forwarding rule sends the email (containing the new password) to the attacker.

If the organization has a large number of compromised accounts (more than 10), consider using a self-service password reset workflow with TAP rather than manually communicating individual passwords. Issue each user a TAP via the portal or Graph API, communicate the TAP via phone, and let the user reset their own password during the TAP-authenticated session. This scales better and reduces the risk of the IR team handling dozens of plaintext passwords.

Temporary Access Pass for passwordless re-onboarding

If the compromised users were using passwordless authentication (FIDO2 keys, Windows Hello for Business, Microsoft Authenticator passwordless) before the compromise, the password reset disrupts their passwordless experience. They now have a temporary password and need to re-establish their passwordless credentials. Temporary Access Pass (TAP) provides a time-limited, use-limited credential that allows the user to sign in and register new authentication methods without needing the temporary password.

TAP is particularly important when the attacker compromised the user's MFA method. If the user's push notification MFA was bypassed via AiTM, you don't want them re-authenticating with the same push notification method that was just defeated. TAP lets them sign in with the time-limited pass and register a phishing-resistant method (FIDO2 key, certificate-based authentication) as their new primary authentication. The old method is removed. The new method is resistant to the attack vector that caused the compromise.

The TAP workflow for IR re-onboarding:

1. Issue a single-use TAP with 1-hour lifetime via the Entra portal or New-MgUserAuthenticationTemporaryAccessPassMethod.
2. Communicate the TAP to the user via phone call (not email, not Teams, not any channel the attacker might still access).
3. The user signs in with the TAP and is prompted to register a new authentication method.
4. The user registers a phishing-resistant method (FIDO2 key or Windows Hello for Business).
5. The IR team verifies in the authentication methods list that only the newly registered method appears.
6. The TAP expires automatically after the lifetime.

If the organization doesn't have FIDO2 keys available for immediate deployment, Microsoft Authenticator with number matching is the next-best option. Number matching is significantly more resistant to MFA fatigue attacks than simple push approval, though it's still vulnerable to AiTM. The post-incident improvement recommendation should include deploying phishing-resistant MFA for all accounts in high-risk roles (finance, executive, IT admin).

Forced MFA re-registration

When the attacker bypassed MFA through AiTM, the MFA method itself isn't compromised: the attacker intercepted the authentication flow, not the method. The user's phone and authenticator app are still secure. But when the attacker registered their own authentication method on the compromised account (added a phone number, enrolled a software token), that method must be removed before the user re-authenticates.

# CONTAINMENT: Review and clean authentication methods
$userId = "compromised.user@yourdomain.com"

# List all registered authentication methods
$methods = Get-MgUserAuthenticationMethod -UserId $userId
$methods | ForEach-Object {
    Write-Host "Method: $($_.AdditionalProperties.'@odata.type') ID: $($_.Id)"
}

# Remove a suspicious phone method
Remove-MgUserAuthenticationPhoneMethod -UserId $userId `
    -PhoneAuthenticationMethodId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# Remove a suspicious software token
Remove-MgUserAuthenticationSoftwareOathMethod -UserId $userId `
    -SoftwareOathAuthenticationMethodId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Review every registered authentication method for each compromised account. Compare the registered methods against the user's known devices. If the user has one corporate phone and the authentication methods show two phone numbers, the second number is the attacker's. If the user has one FIDO2 key and the methods show two, the second key was registered by the attacker. Remove any method that doesn't correspond to a known user device.

For a complete authentication reset, remove all methods and have the user re-register from scratch using TAP. This is the most secure approach: you know with certainty that every registered method was enrolled by the legitimate user during a supervised session. The downside is operational overhead. Each user needs a phone call or in-person meeting, a TAP, and a supervised re-registration session. For four compromised accounts, this takes 30-60 minutes of IR team time. For 40 compromised accounts, it requires a coordinated re-enrollment process.

For a targeted cleanup, remove only the suspicious methods and leave the user's known legitimate methods in place. This is faster but carries a risk: the attacker may have registered a method that closely resembles the user's legitimate method (a phone number one digit off, a software token with a similar display name). The targeted approach works when you can confidently identify every legitimate method through direct verification with the user.

The recommendation for most BEC incidents: complete reset for privileged accounts (the security cost of a missed attacker method on an admin account is too high), targeted cleanup for standard accounts (verify with the user which methods are legitimate, remove everything else).

The AuditLogs record authentication method registration events. Cross-reference the method registration timestamps with the compromise timeline. Any method registered during the compromise window from the attacker's IP is attacker-registered and must be removed. Methods registered before the compromise window are the user's legitimate methods.

// CONTAINMENT: Find authentication methods registered during compromise
let compromisedUsers = dynamic(["user1@yourdomain.com", "user2@yourdomain.com"]);
let compromiseStart = datetime(2026-03-12T00:00:00Z);
AuditLogs
| where TimeGenerated > compromiseStart
| where OperationName has_any ("Register", "authentication method",
    "Update user", "strongAuthentication")
| where TargetResources[0].userPrincipalName in (compromisedUsers)
| project TimeGenerated, OperationName,
    InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
    Target = tostring(TargetResources[0].userPrincipalName),
    ModifiedProperties = tostring(TargetResources[0].modifiedProperties)
| sort by TimeGenerated asc

After cleaning the authentication methods and issuing TAP, coordinate with each user to re-register their legitimate authentication methods. Verify that the only registered methods are ones the user personally enrolled during the supervised re-registration. The IR team should have a direct communication channel with each affected user (phone call, in-person meeting) to walk them through the re-registration and confirm the methods are legitimate.

Once all compromised accounts have reset passwords, cleaned authentication methods, and re-registered with verified methods, Step 3 of the containment sequence is complete. The attacker has no valid credentials, no valid tokens, no registered authentication methods, and the emergency CA policy prevents any authentication attempt. IR6.4 addresses the remaining persistence: the applications, inbox rules, forwarding, and sharing links that operate independently of user credentials.