13.9 Eradication

Eradication

Containment stopped the attacker’s access. Evidence is preserved under litigation hold. Now remove the persistence mechanisms. This follows the same pattern as M11.8 but includes BEC-specific items.

Required role: Exchange Administrator (inbox rules, forwarding). Authentication Administrator (MFA methods).

Pre-condition: Litigation hold MUST be active before eradication (subsection 13.7 Action 2). Verify: Get-Mailbox -Identity "a.patel@northgateeng.com" | Select LitigationHoldEnabled — must return True.

Action 1: Remove malicious inbox rules

Same procedure as M11.8 Action 1. For BEC, pay special attention to rules targeting financial keywords.

1
2
3
4
5
6
7
8
9

// PowerShell — list and remove rules with financial keyword targeting
// Get-InboxRule -Mailbox "a.patel@northgateeng.com" | Where-Object {
//     $_.SubjectContainsWords -match "invoice|payment|bank|wire|transfer|remittance" -or
//     $_.BodyContainsWords -match "invoice|payment|bank|wire|transfer|remittance" -or
//     $_.FromAddressContainsWords -match "meridian"
// } | Format-List Name, RuleIdentity, ForwardTo, MoveToFolder, DeleteMessage
//
// For each malicious rule:
// Remove-InboxRule -Mailbox "a.patel@northgateeng.com" -Identity "RULE-ID" -Confirm:$false

Blast radius: Only the specified rules are removed. Per-rule scope.

Verify: Get-InboxRule -Mailbox "a.patel@northgateeng.com" | Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.DeleteMessage -eq $true }— should return zero financial-keyword rules.

Action 2: Remove mailbox forwarding and delegate permissions

1
2
3
4
5
6
7

// PowerShell — remove forwarding
// Set-Mailbox -Identity "a.patel@northgateeng.com" -ForwardingSmtpAddress $null -ForwardingAddress $null -DeliverToMailboxAndForward $false
//
// Remove unauthorized delegate access
// Get-MailboxPermission -Identity "a.patel@northgateeng.com" | Where-Object { $_.User -ne "NT AUTHORITY\SELF" -and $_.AccessRights -like "*FullAccess*" }
// For each unauthorized delegate:
// Remove-MailboxPermission -Identity "a.patel@northgateeng.com" -User "UNAUTHORIZED-USER" -AccessRights FullAccess -Confirm:$false

Action 3: Remove attacker MFA methods and OAuth consents

Same procedure as M11.8 Actions 3-4. Check for MFA methods registered from non-corporate IPs and OAuth application consents granted during the compromise period.

Action 4: Revert the fraudulent vendor bank details

Work with the finance team to revert the vendor record in the finance system to the original, verified bank details. Verify the original details by calling the vendor directly (subsection 13.8 vendor notification).

This is a business process action, not a technical action. But it is part of eradication — the fraudulent data in the finance system is a persistence mechanism. If not reverted, the next payment to this vendor will also go to the attacker’s account.

Eradication verification

After completing all actions, verify:

1. No malicious inbox rules remain (PowerShell check).
2. No mailbox forwarding active (Get-Mailbox check).
3. No unauthorized delegate permissions (Get-MailboxPermission check).
4. No attacker MFA methods registered (Entra ID authentication methods check).
5. No malicious OAuth consents (Entra ID enterprise applications check).
6. Vendor bank details reverted in finance system (finance team confirmation).
7. No new sign-ins from non-corporate IPs (SigninLogs check).

Subsection artifact: The BEC eradication checklist including the vendor bank detail reversion step — unique to BEC and not covered in the AiTM eradication (M12.8).

Knowledge check

Comprehensive eradication verification

After completing all eradication actions, run this verification sequence:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// BEC Eradication Verification — run after all cleanup actions
// 1. No malicious inbox rules remain
// Get-InboxRule -Mailbox "a.patel@northgateeng.com"
//   | Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.DeleteMessage -eq $true
//     -or $_.SubjectContainsWords -match "invoice|payment|bank" }

// 2. No mailbox forwarding active
// Get-Mailbox -Identity "a.patel@northgateeng.com"
//   | Select ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward

// 3. No unauthorized delegate permissions
// Get-MailboxPermission -Identity "a.patel@northgateeng.com"
//   | Where-Object { $_.User -ne "NT AUTHORITY\SELF" -and $_.AccessRights -like "*FullAccess*" }

// 4. Vendor bank details reverted in finance system
// [Manual verification with finance team — confirm original bank details restored]

// 5. No new attacker sign-ins
SigninLogs
| where TimeGenerated > ago(2h)
| where UserPrincipalName == "a.patel@northgateeng.com"
| where IPAddress !in ("192.0.2.10", "192.0.2.15")
| project TimeGenerated, IPAddress, ResultType

Every check must pass before eradication is considered complete. If any check fails: investigate the failure, remediate, and re-verify. Do not close the incident with outstanding eradication items — each one is a potential re-compromise vector.

The vendor bank detail reversion (check 4) is the most commonly forgotten BEC eradication step. It is not a technical action — it requires coordination with the finance team. But if the fraudulent bank details remain in the finance system, the next payment to that vendor goes to the attacker. Add this to your incident checklist as a mandatory sign-off item.

Post-eradication monitoring. Continue the Livestream from containment (13.7) for 48 hours after eradication. If the attacker returns: a persistence mechanism was missed or a new compromise has occurred.