14.2 Incident Briefing: INC-2026-0320-003

Incident Briefing: INC-2026-0320-003

The alert

At 11:42 UTC on 20 March 2026, a Sentinel analytics rule fires: P1-Persistence-TokenReplayAfterPasswordReset. The rule detected: a non-interactive sign-in from a non-corporate IP (203.0.113.91) for user r.williams@northgateeng.com — 48 hours after r.williams’ password was reset as part of the February AiTM incident containment (Module 12).

What you know at this point

r.williams was one of the accounts compromised in the AiTM campaign (Module 12, Wave 4). Containment was executed on 28 February: password reset, token revocation, inbox rule removal. r.williams resumed normal work on 1 March with a new password and re-registered MFA.

The analytics rule fired because a non-interactive sign-in succeeded from IP 203.0.113.91 on 20 March — 20 days after containment. The IP is not in the known AiTM attacker IP set from Module 12. It belongs to a different ASN (residential proxy network, not VPS infrastructure).

The critical question: How is the attacker accessing r.williams’ account 20 days after tokens were revoked and the password was reset? There are four possibilities:

1. The token revocation in February was incomplete. A refresh token was missed — perhaps from a different client or application. The attacker’s token was never actually revoked.

2. The attacker re-compromised r.williams. A second phishing attack, credential stuffing with a reused password, or compromise through a different vector (consent phishing, malware).

3. The attacker registered a persistent access mechanism during the original compromise. An OAuth application consent (Module 12.6 Step 5) or a device registration (Module 12.8 Action 5) that survived eradication.

4. The attacker stole a new token from r.williams’ device. Malware on the endpoint extracted the PRT or session cookies from the browser.

The investigation in subsections 13.3-13.5 determines which of these four scenarios occurred.

Organisation context

Same Northgate Engineering. The February AiTM campaign (Module 12) compromised 6 accounts across 5 waves. Containment and eradication were completed by 28 February. The March BEC attempt (Module 13) was linked to a surviving inbox rule on a.patel’s account. This new incident suggests the eradication may have had additional gaps.

Knowledge check

The eradication gap cascade — Modules 12-14

This incident is not isolated. It is the third attack enabled by incomplete eradication from the February AiTM campaign:

Module 12 (AiTM) → February. Six accounts compromised across five attack waves. Containment executed. Eradication completed — or so it appeared.

Module 13 (BEC) → March. An inbox rule on a.patel’s account survived the M12 eradication. The rule silently intercepted vendor payment emails for 3 weeks, enabling the £47,000 BEC attempt.

Module 14 (Token Replay) → March. An OAuth consent on r.williams’ account survived the M12 eradication. The application has been accessing r.williams’ mailbox for 20 days — completely invisible in the user’s sign-in logs because the application authenticates as a service principal.

Each incident reveals a different persistence mechanism that the M12 eradication verification checklist should have caught. The cascade demonstrates: eradication is not a single action (revoke tokens + reset password). It is a multi-step verification process that must confirm removal of: refresh tokens, session cookies, inbox rules, mail forwarding, delegate permissions, MFA methods, OAuth consents, and device registrations. Missing any one creates the gap that enables the next incident.

This is why Module 12 (subsection 12.8) includes a verification checklist — and why Module 13 (subsection 13.14) recommends a 7-day follow-up check. The follow-up check would have caught both the surviving inbox rule and the surviving OAuth consent before they were exploited.