Microsoft 365 mail lure delivered
A message whose subject carries a MONEY or CREDENTIAL instruction was delivered to a mailbox — it was not quarantined, not filtered, it landed.
What it detects
A message whose subject carries a MONEY or CREDENTIAL instruction was delivered to a mailbox — it was not quarantined, not filtered, it landed.
This rule answers a question an investigation asks constantly and could not previously answer: **who actually received it.** Once one account is known to be compromised, the next step is establishing the blast radius — which other users got the same lure, and whether the message reached them or was blocked. That is a message-trace question; the audit log cannot answer it.
The subject list is phrases, not words. "Invoice" appears in a finance mailbox all day; "update your bank details" does not. The phrasing of a lure is remarkably consistent because it has to survive a skim-read.
Severity is medium and confidence is low on purpose. A hit means a message ASKED for a payment change or a credential — it does not say the sender was hostile. Legitimate services send several of these.
MITRE ATT&CK mapping
False positives and triage
Real services send real versions of most of these. Microsoft sends quarantine digests, payroll providers send direct-deposit confirmations, and every SaaS product sends password-expiry mail.
The discriminator is the SENDER DOMAIN, not the subject: a genuine Microsoft quarantine notification comes from a Microsoft domain, and a genuine payroll notice from the payroll provider's. A payment-redirect subject from a free-mail domain, or from a look-alike of a supplier's domain, is the finding.
Read the direction too. A payment-redirect subject arriving INBOUND is an attempt on this tenant; the same subject going OUTBOUND from a tenant mailbox means the tenant is being used to defraud its own customers, which is a materially worse conversation to have and a different response.
Because one campaign lands in many mailboxes, expect this to fire in clusters. That is the intended behaviour — the cluster IS the blast radius — and the alert rollup groups them.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/cloud/m365_mail_lure_delivered.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_mail_lure_delivered
version: 1.0.0
status: stable
severity: medium
confidence: 0.6
platforms: [application]
mitre_techniques: [T1566.002, T1656]
description: |
A message whose subject carries a MONEY or CREDENTIAL instruction was delivered
to a mailbox — it was not quarantined, not filtered, it landed.
This rule answers a question an investigation asks constantly and could not
previously answer: **who actually received it.** Once one account is known to be
compromised, the next step is establishing the blast radius — which other users
got the same lure, and whether the message reached them or was blocked. That is
a message-trace question; the audit log cannot answer it.
The subject list is phrases, not words. "Invoice" appears in a finance mailbox
all day; "update your bank details" does not. The phrasing of a lure is
remarkably consistent because it has to survive a skim-read.
Severity is medium and confidence is low on purpose. A hit means a message
ASKED for a payment change or a credential — it does not say the sender was
hostile. Legitimate services send several of these.
match:
provider: Office365
event_action: message_delivered
# knowledge/business-context.yaml -> mail_lure_subjects
ext:m365.subject_contains_any:
# payment_redirect
- "bank details"
- "banking details"
- "change of bank"
- "updated remittance"
- "remittance advice"
- "payment instruction"
- "wire transfer request"
- "update payment method"
- "direct deposit"
# credential_harvest
- "password was reset"
- "password expires"
- "verify your account"
- "unusual sign-in"
- "action required: sign in"
- "re-authenticate"
- "mailbox is full"
- "quarantine notification"
correlation_keys: [target_user_name, user_name]
false_positive_guidance: |
Real services send real versions of most of these. Microsoft sends quarantine
digests, payroll providers send direct-deposit confirmations, and every SaaS
product sends password-expiry mail.
The discriminator is the SENDER DOMAIN, not the subject: a genuine Microsoft
quarantine notification comes from a Microsoft domain, and a genuine payroll
notice from the payroll provider's. A payment-redirect subject from a
free-mail domain, or from a look-alike of a supplier's domain, is the
finding.
Read the direction too. A payment-redirect subject arriving INBOUND is an
attempt on this tenant; the same subject going OUTBOUND from a tenant mailbox
means the tenant is being used to defraud its own customers, which is a
materially worse conversation to have and a different response.
Because one campaign lands in many mailboxes, expect this to fire in clusters.
That is the intended behaviour — the cluster IS the blast radius — and the
alert rollup groups them.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.