Microsoft 365 mail written directly to folder
A message was written straight into a mailbox folder — Drafts, Sent Items or similar — rather than arriving through mail flow.
What it detects
A message was written straight into a mailbox folder — Drafts, Sent Items or similar — rather than arriving through mail flow.
Mail created via the Graph API never passes the transport pipeline, which is where every email security control lives. Nothing scans it, no transport rule sees it, and no gateway logs it. Two uses matter: planting a message in Sent Items so a fraudulent thread appears to have a history the victim wrote, and staging content in Drafts as a dead-drop that is read by a second session and never actually sent, so no message ever leaves the tenant to be caught.
Confidence is moderate because ordinary clients also create items this way; the rule is a lead that becomes strong when the actor is an application rather than the mailbox owner.
MITRE ATT&CK mapping
False positives and triage
Every mail client saves drafts and records sent mail, so volume alone means nothing and this rule will be noisy read on its own. What matters is WHO wrote the item: creation by a service principal or an OAuth application against a mailbox that person owns, especially one that recently granted consent, is the shape worth pursuing. Compare the client string against the mailbox owner's usual clients, and check whether the same session also read mail in bulk.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 55%. Source: rules/cloud/m365_mail_written_directly_to_folder.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_mail_written_directly_to_folder
version: 1.0.0
status: stable
severity: high
confidence: 0.55
platforms: [application]
mitre_techniques: [T1114, T1564.008]
description: |
A message was written straight into a mailbox folder — Drafts, Sent Items or
similar — rather than arriving through mail flow.
Mail created via the Graph API never passes the transport pipeline, which is where
every email security control lives. Nothing scans it, no transport rule sees it,
and no gateway logs it. Two uses matter: planting a message in Sent Items so a
fraudulent thread appears to have a history the victim wrote, and staging content
in Drafts as a dead-drop that is read by a second session and never actually sent,
so no message ever leaves the tenant to be caught.
Confidence is moderate because ordinary clients also create items this way; the
rule is a lead that becomes strong when the actor is an application rather than
the mailbox owner.
match:
provider: Office365
event_action_any:
- Create
raw_message_contains_any:
- "Drafts"
- "Sent Items"
- "SentItems"
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
Every mail client saves drafts and records sent mail, so volume alone means
nothing and this rule will be noisy read on its own. What matters is WHO wrote the
item: creation by a service principal or an OAuth application against a mailbox
that person owns, especially one that recently granted consent, is the shape worth
pursuing. Compare the client string against the mailbox owner's usual clients, and
check whether the same session also read mail in bulk.
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.