Ingext
Incident Investigation
A new device in Nigeria signed in 98 seconds after the real user, then read mail and hid a vendor's replies
Ingext AI escalated on an "impossible travel" and a BEC-style inbox rule, both from the same Nigerian IP; a human analyst closed it minutes later as a benign false positive. The raw Office365 audit shows the opposite: a brand-new device, never seen before or since, authenticated 98 seconds after the user's own UK session, read the mailbox, and planted a concealment rule against one external domain — and the tenant's own automated containment (a service principal named "Directory Sync Agent") killed the account 3 minutes 47 seconds later. Three of five AI-assist grounds held up; the human closure did not.
Confirmed account compromise (BEC-style mailbox reconnaissance and concealment), already contained: the account was auto-disabled within 4 minutes of the hostile sign-in and fully remediated (password reset forced, MFA wiped and re-registered) by a Global Administrator within the hour. No further containment action is required; residual verification only.
Case record
| Subject | j.morgan@acme.example (Jordan Morgan, Member, no admin roles; account created 2026-08-06) |
| Tenant | Acme Corp |
| Window | 2026-10-12 05:30Z → 13:02Z (ticket + remediation) |
| Incident time | 2026-10-12 05:30:00Z (first summary bucket); compromise at 12:13:44Z |
| Peak riskScore | 7200 (O365_AzureAD_UserLoggedIn + O365_Exchange_New-InboxRule, ML first-seen boosts) |
| Rules | O365_AzureAD_UserLoggedIn, Office365:InboxRule_Change, O365_Exchange_New-InboxRule |
| AI-assist verdict | ESCALATE_TO_TIER_TWO (both tiers); overridden by analyst analyst1@acme.example 36 minutes later: status → closed, classification "Benign Positive", comment "No risk was found" |
Five grounds the AI-assist cited — three held, one was backwards, one was incomplete
Quoted verbatim from the ticket's AI-Assistant comment, tested against the raw Office365 audit (no AzureSigninLogs/AzureAuditLogs or Log Analytics workspace on this tenant — confirmed again via list_data_tables and azure_logs_list_tables; Core-Directory fallback used throughout).
1“"Rapid location change: the United Kingdom → Nigeria within 2 minute(s)... impossible travel." Reasoning cited two clusters "~40 minutes apart."”
The 40-minute framing was wrong — raw Office365 rows show the real gap is 98 seconds: a sign-in from Leeds, United Kingdom (a mobile carrier, device 4f1c0a92…, the user's own known device) at 12:12:06Z, then a sign-in from Nigeria (AIRTEL, 203.0.113.77) at 12:13:44Z using a different device id (9b3e5d10…) and a different browser (Chrome vs. the user's normal Edge). A 30-day ip_census shows 203.0.113.77 / AIRTEL used by exactly 1 user, 13 events, all inside a 92-second window — never seen before or after on this tenant. This is not a shared corporate IP or carrier NAT artifact (contrast the account's own 198.51.100.24 and 198.51.100.61, each used by 48 and 39 distinct employees).
2“"Suspicious inbox rule created from Nigeria... hides and marks messages (Move+MarkAsRead) targeting admin@vendor.example."”
Confirmed from the raw Audit.Exchange event (Id c51e0f84…): SubjectOrBodyContainsWords=admin@vendor.example;@vendor.example, MoveToFolder=Conversation History, MarkAsRead=True, StopProcessingRules=True, created at 12:15:11Z from IP 203.0.113.77 and device 9b3e5d10… — the same device that signed in at 12:13:44Z. MailItemsAccessed fired 8 times from that same Nigerian IP at 12:14:31Z, one minute before the rule was written: the attacker read the mailbox before hiding replies from one external domain. The 14-day activity_profile confirms this is the account's only New-InboxRule event, ever.
3“"5 failed login(s) followed by a successful sign-in" (tier two), read as credential guessing before access.”
Backwards. Decomposed by ErrorNumber (53011) and timestamp: all 19 UserLoginFailed rows in the window come from the account's own known UK IPs (198.51.100.24, 198.51.100.61) and start at 12:22:05Z — after the account was disabled at 12:18:58Z. These are the legitimate owner locked out by containment, not a pre-compromise brute force. Matches the standing tenant note that this AI-assist miscounts account-state interrupts as "failed logins".
4“"Account was disabled by a service principal... confirm if this corresponds to an automated Identity Protection or Defender for Cloud Apps response."”
ServicePrincipal_7a2e91c4… ("Directory Sync Agent") disabled the account at 12:18:58Z — 3 minutes 47 seconds after the inbox rule was written — and revoked its session tokens in the same transaction. Checked tenant-wide for the same 48 hours: this principal touched only j.morgan's account, not a batch of users, so this was targeted automated containment, not routine sync noise.
5“"The user holds no privileged roles... reducing blast radius."”
Confirmed via the office365User snapshot: isAdmin=false, roles empty, member of ordinary groups only (All Staff, All Users, Engineering, Sales). No role, licence or group changes appear anywhere in the 30-day directory audit on this account.
Ninety-eight seconds, then containment in under four minutes
All times from the raw Office365 index, not the summary's 2-minute bucket labels.
| Time (UTC) | Actor | Event |
|---|---|---|
| 12:12:06Z | j.morgan (own device, 4f1c0a92…) | Sign-in from Leeds, United Kingdom (a mobile carrier network) |
| 12:13:44Z | Unknown device 9b3e5d10…, Chrome | Sign-in from Nigeria (203.0.113.77, AIRTEL) — never seen on this tenant before or since |
| 12:14:31Z | Same Nigerian session | 8× MailItemsAccessed — mailbox read |
| 12:15:11Z | Same Nigerian session | New-InboxRule: hide + mark-read + stop-processing on mail mentioning admin@vendor.example |
| 12:18:58Z | ServicePrincipal_7a2e91c4 ("Directory Sync Agent") | Disable account. + revoke session tokens — automated containment |
| 12:22:05Z – 13:38:33Z | j.morgan (own IPs) | 19 UserLoginFailed (ErrorNumber 53011) — the real owner locked out post-containment |
| 12:48:38Z – 12:50:56Z | admin1@acme.example (Global Administrator) | Re-enables the account, revokes tokens again |
| 12:48:22Z | analyst1@acme.example | Ticket closed — "No risk was found", classified Benign Positive (one minute before the admin's re-enable completed) |
| 12:58:09Z | Microsoft password reset service (admin-forced) | Reset user password., ForceChangePassword → True |
| 13:01:42Z – 13:02:45Z | Azure Credential Configuration Endpoint Service | All prior authenticator/phone methods cleared and re-registered |
Creating an inbox rule is routine here; this rule's content and origin were not
Step 2 census, this account only, 7 days before the incident.
Every other inbox-rule hit this week was a mundane self-sort rule created from an established UK IP; none carried stop-processing + hide-and-mark-read against one external domain, and none came from a device or country never seen before.
| Rule | Other entities in 7 days | Who |
|---|---|---|
| Office365:InboxRule_Change | 3 | a.lee×2, b.khan, c.ortiz@acme.example |
| O365_Exchange_New-InboxRule | 4 | d.ngo@acme.example, b.khan, e.price, c.ortiz@acme.example |
What did not happen
Each negative below was run against a control proving the query finds these operations elsewhere on the tenant — a zero from a broken query looks identical to a real one.
- No forwarding, delegation or OAuth consent. 30-day
bec_sweep(Office365 fallback) returns exactly the one known New-InboxRule hit and nothing else — no Set-Mailbox, Add-MailboxPermission, Add-RecipientPermission, consent, or transport-rule changes on this account. Control: the same account's 14-day activity profile shows 1 New-InboxRule, ever. - No mail sent during or after the compromise window. Last Exchange
Sendby this account was 12:07:25Z, before the 12:11:58Z compromise window opened; zeroSendrows after it in the 14-day activity profile. - No privilege held or gained.
office365Usersnapshot: isAdmin=false, roles empty; 30-day directory audit shows zero role, licence or group changes on the account.
"40 minutes apart" was a scoring artifact, not the real gap. The AI-assist's own impossible-travel reasoning understated the anomaly: the true gap between the legitimate and hostile sign-ins is 98 seconds, not 40 minutes, because it read the summary's 2-minute bucket labels rather than the raw event times.
Gap — two new devices registered during the compromise window were not resolved. Device Registration Service added "DESKTOP-A1B2C3" and "DESKTOP-D4E5F6" as registered owner/user devices for j.morgan at 12:12:11Z–12:13:00Z, straddling the hostile sign-in. office365Device returned zero rows for either name (a readability gap on that resource table, not confirmed as clean or as attacker-created) — not established either way. Recommend the tenant review and, if unrecognised, revoke these device registrations.
Gap — whether vendor.example is a genuine counterparty is unverified. A free-text search for "vendor" across 30 days of Office365 returned zero hits tenant-wide, but a control lookup on the known rule's own event id shows the term lives inside a nested Parameters array that this search does not appear to tokenize — the zero is a search-coverage gap, not evidence that no one else corresponds with that domain. If vendor.example is a real client or vendor, they should be warned a BEC actor targeted correspondence with them.
No AzureSigninLogs, AzureAuditLogs or Log Analytics workspace on this tenant. Confirmed again via list_data_tables and azure_logs_list_tables. All directory and sign-in analysis above used the Office365 Core-Directory fallback; PIM activity, failed/abandoned MFA registrations, self-service password reset's own audit trail, and initiator IP on directory-change rows remain unavailable on this tenant, as previously noted for this account.
Recommendation
Confirmed malicious, already contained — do not reopen as benign. The account was auto-disabled 3m47s after the hostile sign-in and fully remediated (forced password reset, MFA wiped and re-registered) by a Global Administrator within the hour; no further credential action is needed on current evidence.
Remaining steps: have the tenant (a) confirm or remove the two device registrations (DESKTOP-A1B2C3, DESKTOP-D4E5F6) added during the compromise window, (b) check whether vendor.example is a real counterparty and warn them if so, and (c) review the 8 MailItemsAccessed events at 12:14:31Z for anything sensitive, since Office365 does not log what was read.
Tuning: no rule change is proposed. The behavior rules fired correctly and the base rate (3–4 other inbox-rule creators in 7 days) shows they are not over-matching; the failure here was the human closure, not the detection.
Process finding, not a rule finding: the ticket was escalated correctly by the AI-assist and misclosed by the human analyst ("No risk was found") 36 minutes later, one minute before the admin's own remediation steps completed. The analyst's note did not reflect the containment and credential-reset activity already visible in the audit log at the time of closure. Recommend review with analyst1@acme.example.
Evidence
Evidence: behavior_summary_search (1 ticket, 3 rules, 7-day base-rate census over 2 rules); Office365 (30-day directory audit on subject: 15 operations; 14-day activity profile: 72 operation types; UserLoggedIn/UserLoginFailed raw rows in ±24h window: 24 rows; bec_sweep: 1 hit; MailItemsAccessed detail in compromise window: 14 rows); office365User snapshot (1 row); list_data_tables and azure_logs_list_tables (confirmed no AzureSigninLogs/AzureAuditLogs/Log Analytics). All findings: Acme Corp only.