11.8 Eradication

Eradication

Containment (11.7) stopped the attacker’s access. Eradication removes the persistence mechanisms the attacker established. If you skip eradication, the attacker regains access when the containment measures expire or are removed.

Execute each action for every confirmed compromised account. The post-compromise activity summary from subsection 11.6 is your checklist.

Required role: Exchange Administrator (for inbox rules and forwarding), Authentication Administrator (for MFA methods), Application Administrator or Cloud Application Administrator (for OAuth consents).

Action 1: Remove malicious inbox rules

For each compromised user, remove the inbox rules identified in subsection 11.6 Step 1.

Execute via PowerShell:

1
2
3
4
5
6

// PowerShell — remove malicious inbox rules
// Connect-ExchangeOnline
// Get the rule IDs first:
// Get-InboxRule -Mailbox "j.morrison@northgateeng.com" | Format-List Name, RuleIdentity, ForwardTo, RedirectTo, DeleteMessage, MoveToFolder
// Then remove each malicious rule:
// Remove-InboxRule -Mailbox "j.morrison@northgateeng.com" -Identity "RULE-ID" -Confirm:$false

Or via Outlook Web Access: Settings → Mail → Rules → delete the malicious rules.

Blast radius: Only the specified inbox rules are removed. No impact on other email functionality or other users. Per-rule scope.

Rollback: If you remove a legitimate rule by mistake: recreate it from the Get-InboxRule output you captured before deletion. Always capture the full rule list before removing anything.

Verify:

1
2

// PowerShell — confirm malicious rules are removed
// Get-InboxRule -Mailbox "j.morrison@northgateeng.com" | Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.DeleteMessage -eq $true } | Format-List

Expected result: No rules with external forwarding, redirect, or delete actions remain. If the legitimate user has rules with internal forwarding (e.g., forwarding to a shared mailbox), those should remain.

Do this BEFORE sending the password reset notification email. If the attacker’s inbox rule is still active when you send the password reset link, the rule deletes the email — the user never receives it, and you do not notice.

Action 2: Remove mailbox-level forwarding

1
2
3
4

// PowerShell — check and remove mailbox forwarding
// Get-Mailbox -Identity "j.morrison@northgateeng.com" | Format-List ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward
// If ForwardingSmtpAddress or ForwardingAddress is set to an external address:
// Set-Mailbox -Identity "j.morrison@northgateeng.com" -ForwardingSmtpAddress $null -ForwardingAddress $null -DeliverToMailboxAndForward $false

Blast radius: Removes forwarding only. No impact on other mailbox functionality. Per-mailbox scope.

Verify: Re-run the Get-Mailbox command. ForwardingSmtpAddress, ForwardingAddress, and DeliverToMailboxAndForward should all be null/false.

Action 3: Remove attacker’s MFA registration

For s.chen (where MFA modification was detected in subsection 11.6 Step 4):

Execute: Entra ID → Users → s.chen → Authentication methods. Identify the attacker’s registered method: it will be the method registered from the attacker IP or at the time of compromise. Remove it.

Or via PowerShell/Graph API:

1
2
3
4
5

// PowerShell — list and remove authentication methods
// Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"
// Get-MgUserAuthenticationMethod -UserId "s.chen@northgateeng.com"
// Identify the attacker's method (registered after compromise timestamp)
// Remove-MgUserAuthenticationPhoneMethod -UserId "s.chen@northgateeng.com" -PhoneAuthenticationMethodId "METHOD-ID"

Blast radius: Only the specified authentication method is removed. The user’s other MFA methods remain functional. If you accidentally remove the user’s legitimate MFA method, they must re-register — manageable disruption. Per-method scope.

Before executing: Confirm which method is the attacker’s and which is the user’s. Compare registration timestamps with the compromise timeline. The attacker’s method was registered AFTER the compromise timestamp from the attacker’s IP. The user’s legitimate method was registered before the incident.

Verify: Re-list authentication methods. Only the user’s pre-incident methods should remain.

Action 4: Revoke malicious OAuth application consents

If subsection 11.6 Step 5 found OAuth consents granted by compromised users:

Execute: Entra ID → Enterprise applications → find the application by AppId → Properties → Delete. Or revoke the user’s consent: Enterprise applications → application → Users and groups → remove the compromised user.

Blast radius: Deleting the application revokes access for ALL users who consented — verify it is not a legitimate application. Revoking user consent only removes the specific user’s grant. Per-application or per-user scope.

Rollback: If a legitimate application was accidentally removed, the users must re-consent. The application registration can be restored from soft-delete within 30 days.

Verify:

1
2
3
4
5
6
7

// Verify: no active OAuth tokens from the malicious application
AuditLogs
| where TimeGenerated > ago(1h)
| where OperationName has "Remove app role assignment"
    or OperationName has "Remove delegated permission grant"
| where TargetResources[0].displayName == "MALICIOUS-APP-NAME"
| project TimeGenerated, OperationName

Action 5: Remove attacker device registrations

If the attacker registered a device to the compromised user’s account (T1098.005):

1
2
3
4
5
6
7
8
9

// Check for new device registrations by compromised users
AuditLogs
| where TimeGenerated > datetime(2026-02-27T08:00:00Z)
| where OperationName in ("Register device", "Add registered owner to device")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| where Actor in ("j.morrison@northgateeng.com", "s.chen@northgateeng.com", "a.patel@northgateeng.com")
| extend DeviceName = tostring(TargetResources[0].displayName)
| project TimeGenerated, Actor, DeviceName, OperationName,
    IPAddress = tostring(InitiatedBy.user.ipAddress)

If device registrations from the attacker IP exist: delete the device from Entra ID → Devices. This prevents the attacker from using the registered device to satisfy device-based conditional access policies in the future.

Eradication verification checklist

Run this final verification after completing all eradication actions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// Eradication verification — comprehensive check
// 1. No malicious inbox rules remain
// Get-InboxRule -Mailbox "USER" | Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.DeleteMessage -eq $true }

// 2. No mailbox forwarding active
// Get-Mailbox -Identity "USER" | Select ForwardingSmtpAddress, ForwardingAddress

// 3. No attacker MFA methods registered
// Get-MgUserAuthenticationMethod -UserId "USER" — verify only pre-incident methods

// 4. No malicious OAuth consents
// AuditLogs | where OperationName == "Consent to application" | where InitiatedBy.user.userPrincipalName == "USER"

// 5. No attacker device registrations
// AuditLogs | where OperationName == "Register device" | where InitiatedBy.user.userPrincipalName == "USER"

// 6. No new sign-ins from attacker IP (Livestream verification)
// SigninLogs | where IPAddress == "203.0.113.47" | where TimeGenerated > ago(1h)

Every check must return clean results before eradication is considered complete.

Subsection artifact: The eradication action sequence with verification commands. This is the eradication section of your AiTM investigation playbook. Each action maps directly to the post-compromise findings from subsection 11.6.

Knowledge check