Microsoft 365 Power Automate mail flow
A Power Automate flow was created, modified or shared in a way that can move mail out of a mailbox.
What it detects
A Power Automate flow was created, modified or shared in a way that can move mail out of a mailbox.
This exists because of a gap that is structural rather than incidental: **every mail-forwarding detection in this pack keys on inbox rules or transport rules, and a flow is neither.** An attacker who sets up a flow with an "When a new email arrives" trigger and a "Send an email" or HTTP action gets continuous exfiltration that:
* creates no inbox rule, so m365_inbox_forwarding_rule, m365_inbox_rule_change and m365_mailbox_hiding_rule cannot see it; * creates no transport rule, so m365_transport_rule cannot see it; * sets no mailbox forwarding address, so m365_smtp_forwarding cannot see it; * survives a password reset, because the flow runs under a stored connection rather than an interactive session.
It is also quiet by design: flows are a self-service productivity feature, so their creation is unremarkable and rarely reviewed.
MITRE ATT&CK mapping
False positives and triage
Power Automate exists to be used, and in a tenant that has adopted it this will fire on ordinary work — approval flows, ticket routing, teams notifications, SharePoint list automation. Treat the volume itself as a tenant characteristic, not a finding.
What makes one worth reading:
* **A mail trigger paired with an outbound action.** "When a new email arrives" plus "Send an email", an HTTP POST, or a connector to consumer storage is the exfil shape. Approval and notification flows do not read a mailbox and then send its contents somewhere else. * **Who owns it, and who it is shared with.** A flow created in one user's context but sharing its output elsewhere is not automation, it is a forwarding rule wearing a different hat. * **When it appeared.** A flow created within hours of a risky sign-in, an MFA-method registration, or an inbox-rule change belongs to that incident.
Response note: revoking sessions and resetting the password does NOT stop a flow. The flow and its stored connections have to be deleted explicitly, and this is the most commonly missed step in M365 incident response.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 65%. Source: rules/cloud/m365_power_automate_mail_flow.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_power_automate_mail_flow
version: 1.0.0
status: stable
severity: high
confidence: 0.65
platforms: [application]
mitre_techniques: [T1114.003, T1020, T1546]
description: |
A Power Automate flow was created, modified or shared in a way that can move
mail out of a mailbox.
This exists because of a gap that is structural rather than incidental: **every
mail-forwarding detection in this pack keys on inbox rules or transport rules,
and a flow is neither.** An attacker who sets up a flow with an
"When a new email arrives" trigger and a "Send an email" or HTTP action gets
continuous exfiltration that:
* creates no inbox rule, so `m365_inbox_forwarding_rule`,
`m365_inbox_rule_change` and `m365_mailbox_hiding_rule` cannot see it;
* creates no transport rule, so `m365_transport_rule` cannot see it;
* sets no mailbox forwarding address, so `m365_smtp_forwarding` cannot see it;
* survives a password reset, because the flow runs under a stored connection
rather than an interactive session.
It is also quiet by design: flows are a self-service productivity feature, so
their creation is unremarkable and rarely reviewed.
match:
provider_any: [Office365, MicrosoftFlow, PowerAutomate]
event_action_contains_any:
- CreateFlow
- EditFlow
- PutFlow
- StartFlow
- ShareFlow
- CreateFlowFromTemplate
- EditPermissions
- CreateConnection
- UpdateConnection
correlation_keys: [user_name]
false_positive_guidance: |
Power Automate exists to be used, and in a tenant that has adopted it this will
fire on ordinary work — approval flows, ticket routing, teams notifications,
SharePoint list automation. Treat the volume itself as a tenant characteristic,
not a finding.
What makes one worth reading:
* **A mail trigger paired with an outbound action.** "When a new email
arrives" plus "Send an email", an HTTP POST, or a connector to consumer
storage is the exfil shape. Approval and notification flows do not read a
mailbox and then send its contents somewhere else.
* **Who owns it, and who it is shared with.** A flow created in one user's
context but sharing its output elsewhere is not automation, it is a
forwarding rule wearing a different hat.
* **When it appeared.** A flow created within hours of a risky sign-in, an
MFA-method registration, or an inbox-rule change belongs to that incident.
Response note: revoking sessions and resetting the password does NOT stop a
flow. The flow and its stored connections have to be deleted explicitly, and
this is the most commonly missed step in M365 incident response.
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.