On his last day, a manager set his corporate mail to forward to a personal address. His login was clean, his MFA was the strongest kind, and the device was his own. Artemis flagged it anyway, hours before his account was even disabled.
On the day HR marked as his last, a departing finance manager created the first inbox rule his mailbox had ever had and pointed it at his personal Gmail. Every individual signal was clean: home ISP, his own managed Mac, phishing-resistant MFA, zero failed logins. Every control waved it through. Artemis caught it by reading the facts together: a first-ever forwarding rule, a destination matching the personal email on file for him, and a termination date written to his identity profile that same morning. It opened the case about seven hours before routine offboarding disabled the account. The rule would have outlived his badge.
The account that did everything right
For the week before his last day, this manager’s activity was unremarkable in every measurable way: the same residential ISP across roughly two thousand email events, sign-ons clearing Okta Verify FastPass (a phishing-resistant, hardware-protected, device-bound factor) on his own healthy, managed Mac, no failed logins, and no phishing seen against the account in thirty days.
This is the point most tooling never gets past. A trusted user, on his own device and network, clearing strong MFA, is the definition of a session you do not alert on. The baseline was clean, and the baseline was the setup.
The last-day rule
At 15:32 UTC he opened his mailbox in the browser and created an inbox rule. He named it “Last day emails.” The rule redirected incoming mail to his personal Gmail; a minute later he extended it to forward as well. It was the first inbox rule this mailbox had ever created inside our visibility window.
{
"Operation": "New-InboxRule",
"UserId": "<user>@<company>",
"ClientIP": "<home IP>",
"Workload": "Exchange",
"ResultStatus": "True",
"ObjectId": ".../<mailbox>\\Last day emails",
"Parameters": [
{ "Name": "RedirectTo", "Value": "<personal-gmail>" },
{ "Name": "Name", "Value": "Last day emails" }
]
}
Code language: JSON / JSON with Comments (json)Two ways to read the same day
Read with one prior, the rest of that day’s mailbox activity is a person cleaning out a desk. The surrounding 48 hours were reading, tidying, and deleting: existing inbox rules switched off in the same session (the new forwarding rule was the one left standing), files and messages trashed, barely any downloads.
Read with a different prior, the same audit trail is a textbook business email compromise. An external forwarding rule plus manipulation of the mailbox’s other rules is exactly how BEC actors establish persistence after taking over an account, one of the most common post-compromise moves in Microsoft 365. The difference between “page the IR team” and “remove the rule and finish offboarding” lives entirely outside the mailbox.
The morning write nobody connected
Hours earlier, at 08:10 UTC, the identity provider had recorded an automated profile change on the same user. The changed attribute was terminationDate.
{
"eventType": "user.account.update_profile",
"actor": "system@okta.com",
"target": "<user>@<company>",
"debugContext": { "changedAttributes": "terminationDate,newEmployeeData" }
}
Code language: JSON / JSON with Comments (json)So the sequence for that day, once you line it up:
| Time (UTC) | What happened | ATT&CK |
|---|---|---|
| 08:10 | HR marks the user’s termination date; the identity provider writes it to the profile | — |
| 15:32 | First inbox rule the mailbox has ever had, redirecting mail to a personal Gmail — the detection point | T1114.003 |
| 15:33 | Rule extended to forward as well as redirect | T1114.003 |
| 15:41 | Session re-authenticates with phishing-resistant MFA, no anomaly raised | — |
| +1 day 00:51 | Routine offboarding disables the account. The forwarding rule survives it | — |
That last row is the whole risk. Disabling an account does not remove an inbox rule. A forward pointed at a personal address is a channel that keeps working after the badge stops.
How Artemis caught it
Four ordinary, individually authorized facts, pointing the same way at once: a first-ever forward, to a personal address on file, for a user whose exit was written to his profile that morning, with offboarding already running. None of them is an alert on its own. Together they describe a channel that was about to outlive the account it belonged to.
That is why the timing is the finding. Artemis opened the case while the account was still live, on the user’s last afternoon, roughly seven hours before routine offboarding disabled it. Left alone, the account would have been dutifully deprovisioned at 00:51, the rule would have survived it, and the first anyone heard of the forward would have been whenever someone noticed internal mail arriving in a personal inbox, if anyone ever did.
What this means
The move here was not to steal a password or drop a tool. It was to use a permitted feature to set up a forward that would keep delivering after the account was gone. Nothing in that chain trips a threshold; the tell was three ordinary facts pointing the same way at once. Detection that reasons about intersections and per-account history catches it. Detection that matches rules does not. And remember the timeline’s second lesson: offboarding workflows kill identities, not mailbox state.
For defenders
There are no attacker indicators to share here: he used his own credentials, device, and network, so there is nothing external to block. What is worth hunting for are the behaviors.
Three things you can act on today, whatever you run:
- Join mailbox-rule creation to HR lifecycle state. An external-forwarding rule is noise on its own and signal the moment it intersects a user who is in offboarding or has a termination date set. That intersection is the entire verdict in this case.
- Rank forwarding rules on novelty, not a threshold. A mailbox creating its first-ever auto-forward to an external or personal domain is far more interesting than the hundredth. Score against the mailbox’s own history.
- Make offboarding sweep mailbox state, not just sessions. Disabling the account and revoking tokens leaves inbox rules, mailbox-level forwarding attributes, and delegate grants intact, and a retained or shared-converted mailbox keeps receiving mail. Add rule enumeration and forwarding-attribute checks to the offboarding runbook.
Detection as a prompt
Role: You triage identity and email activity for a company over its own logs.
Trigger: A mailbox creates or edits a rule that forwards or redirects mail to an
external or personal address.
Investigate, in order:
1. Is this the first forwarding rule this mailbox has ever created? Compare against
its full rule history, not a fixed window.
2. Does the destination match a personal email on file for this user in the identity
directory (secondary email, recovery address)?
3. Has this user's identity profile been marked with a termination or offboarding
date? Check the identity provider's profile-change events for the last 14 days.
4. Is offboarding already in motion (account-disable, deprovision) around this action?
A forwarding rule survives account disable.
5. Confirm the session is really the user (device, network, MFA) — then set that
aside.
6. Measure exposure: enumerate every rule and forwarding attribute on the
mailbox, and message-trace from rule creation to removal to inventory what
was actually forwarded.
Do not treat strong MFA, low identity-risk, or a known device as exoneration. Those
confirm who is at the keyboard, not whether the action should stand.
Code language: PHP (php)Drawn from real findings in a customer environment; details anonymized and indicators sanitized.
