Microsoft 365 send as impersonation
Mail was sent as, or on behalf of, another mailbox (Exchange SendAs / SendOnBehalf).
What it detects
Mail was sent as, or on behalf of, another mailbox (Exchange SendAs / SendOnBehalf). After taking over an account, attackers send from — or impersonate — a colleague or executive to make fraudulent requests (invoice fraud, wire transfer, internal spear-phishing) look authentic. The event evidence carries the impersonated mailbox (send_as / send_on_behalf) and the message subject, so an analyst can see exactly what was sent in whose name.
Deliberately LOW: most delegated sends are routine, so this is a lead to read, not a finding to act on. It fires on EVERY impersonated send because a single one can be the whole fraud — on a real case one SendOnBehalf carrying "FW: Financial Briefing", sent as a colleague from the attacker's address, was the entire payment-fraud staging step. Thresholding this rule to suppress volume silenced exactly that event. A RUN of impersonated sends is escalated separately by cloud.identity.m365_send_as_burst.
MITRE ATT&CK mapping
False positives and triage
SendAs / SendOnBehalf is legitimate for delegates, assistants, and shared or team mailboxes, so expect these routinely and rank them by what surrounds them. The signal is send-as activity from an unfamiliar client IP, at an odd time, to external recipients, or from an account with other suspicious events (new inbox rule, mass mail access). Read the impersonated mailbox and the subject in the evidence before escalating. A mailbox with standing delegates can be allowlisted once confirmed.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 40%. Source: rules/cloud/m365_send_as_impersonation.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_send_as_impersonation
version: 1.2.0
status: stable
severity: low
confidence: 0.4
platforms: [application]
mitre_techniques: [T1114, T1534]
description: |
Mail was sent as, or on behalf of, another mailbox (Exchange SendAs /
SendOnBehalf). After taking over an account, attackers send from — or
impersonate — a colleague or executive to make fraudulent requests (invoice
fraud, wire transfer, internal spear-phishing) look authentic. The event
evidence carries the impersonated mailbox (send_as / send_on_behalf) and the
message subject, so an analyst can see exactly what was sent in whose name.
Deliberately LOW (ADR-052): most delegated sends are routine, so this is a lead
to read, not a finding to act on. It fires on EVERY impersonated send because a
single one can be the whole fraud — on a real case one `SendOnBehalf` carrying
"FW: Financial Briefing", sent as a colleague from the attacker's address, was
the entire payment-fraud staging step. Thresholding this rule to suppress volume
silenced exactly that event. A RUN of impersonated sends is escalated separately
by `cloud.identity.m365_send_as_burst`.
match:
provider: Office365
event_action_any:
- SendAs
- SendOnBehalf
correlation_keys: [user_name]
false_positive_guidance: |
SendAs / SendOnBehalf is legitimate for delegates, assistants, and shared or
team mailboxes, so expect these routinely and rank them by what surrounds them.
The signal is send-as activity from an unfamiliar client IP, at an odd time, to
external recipients, or from an account with other suspicious events (new inbox
rule, mass mail access). Read the impersonated mailbox and the subject in the
evidence before escalating. A mailbox with standing delegates can be allowlisted
once confirmed.
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.