DOSSIER 1

A forwarding rule after a suspicious sign-in

What evidence turns a temporal coincidence into a case worth investigating?

Synthetic case for educational purposes. Not real telemetry nor an audit.

Context

A synthetic Microsoft Graph record shows an interactive sign-in from a location other than the usual one. Three minutes later, a synthetic Exchange record shows the creation of a mailbox rule that forwards mail to an external domain. The account owner does not recognize that rule and asks to preserve the evidence.

Cited evidence

Each citation points to a concrete record in a versioned dataset. You can open it in its lab and see the same thing.

  1. M365 identity lab · mailbox-change · version 1 · mailbox-graph-external

    Establishes the initial interactive sign-in: time, IP address, and the absence of a managed-device flag.

  2. M365 identity lab · mailbox-change · version 1 · mailbox-portal-external

    Adds the authentication detail for that same access: MFA satisfied by a previous claim, not a new prompt.

  3. M365 identity lab · mailbox-change · version 1 · mailbox-exchange-forwarding

    This is the case's central action: creation of a mailbox rule with ForwardTo to an external domain, sharing the sign-in's IP address.

  4. Case file — email · mailbox-change-notice · version 1 · message

    Independent synthetic email whose date and Received headers share the same IP; it guides the review without relying only on the identity records.

  5. M365 identity lab · mailbox-change · version 1 · mailbox-exchange-bind

    Documents the scope of a later item access (Bind, two messages), which does not amount to confirmed human reading.

  6. M365 identity lab · mailbox-change · version 1 · mailbox-owner-denial

    The owner states they do not recognize the rule, which rules out that it is a configuration they remember making.

  7. M365 identity lab · mailbox-change · version 1 · mailbox-graph-routine

    A routine access within the same window, used to weigh an alternative explanation before ruling it out.

  8. M365 identity lab · mailbox-change · version 1 · mailbox-authorized-change

    Authorized change window cited as a possible alternative explanation for the rule.

Reasoning

  1. The synthetic Graph record places an interactive sign-in at 08:42Z from a documentation-only IP address (approx. Lisbon), on a device without a managed-device flag.

    Based on: citation 1

  2. The portal detail for that same access shows the MFA requirement was satisfied by an already-issued claim, not a new authentication, and that the conditional access policy evaluated as success.

    Based on: citation 2

  3. Three minutes later (08:45Z), a mailbox rule with ForwardTo to an external domain is created from the same IP as the 08:42Z sign-in.

    Based on: citation 1 citation 3

  4. An independent synthetic email, dated the same day, shares that IP in its Received headers: this is a correlation that guides the review, not proof that both elements come from the same session.

    Based on: citation 4

  5. Shortly after, an Exchange Bind record shows access to two messages; this documents scope, not confirmed human reading or exfiltration.

    Based on: citation 5

  6. The account owner states they do not recognize the rule and asks that the records be preserved, which rules out this being a change they remember authorizing.

    Based on: citation 6

  7. The same window also contains a routine access from a managed device and an authorized change window to review mailbox filters; neither matches the IP, time, or rule type observed at 08:42-08:45Z.

    Based on: citation 7 citation 8

Alternatives I ruled out

An honest investigation also shows what it could have been, and why it was not.

The window also includes a routine access from a managed device (Madrid, 08:05Z) and an authorized change window to review mailbox filters between 07:50Z and 08:20Z; either one could, in principle, explain a new mailbox rule.
Ruled out by: The authorized change window ends at 08:20Z, 25 minutes before the external forwarding rule was created at 08:45Z, and the routine access uses a managed device different from the one that shared an IP with that rule: neither matches the forwarding rule's time, device, or action type.

Decision

Investigate · medium confidence

The shared IP between an access without a managed-device flag and an external forwarding rule, together with the owner's denial, justifies investigating and preserving evidence; it does not assert confirmed compromise or mail delivery.

The detection I built

Flags any interactive sign-in with LogonType 10 (remote access), without yet distinguishing user or source address.

Result over the labeled dataset authentication
True positives False positives True negatives False negatives
2 2 1 0

The rule does not miss any real hit (zero false negatives), but it also flags two sign-ins from the support account - one successful, one with a wrong password (EventID 4625) - LogonType alone does not separate signal from noise in this set and needs extra context (user, device, attempt result) before escalating, just as the mailbox case review required.

MITRE ATT&CK

What this dossier does NOT prove

  • All records (Graph, portal, Exchange, and the email) are synthetic, generated for the lab; they do not come from a real tenant or a real breach.
  • Sharing an IP address between a sign-in and a mailbox rule does not prove the same session created the rule; Graph, portal, and Exchange identifiers belong to different products and are not automatically equated.
  • ForwardTo describes observed configuration; it does not prove a message was delivered, read, or exfiltrated.
  • The detection rule is evaluated against an independent synthetic event bench (the authentication scenario); it is not telemetry from the same mailbox case and must not be read as if it were.

Reproduce it yourself

The same data, in its lab. No signup needed.

← All dossiers