{
	"id": "5a7facf1-07af-4013-8c70-715a80b04db7",
	"created_at": "2026-04-06T00:17:42.298279Z",
	"updated_at": "2026-04-10T03:21:28.675915Z",
	"deleted_at": null,
	"sha1_hash": "895831f1a198d0301f1d1fc20dc2c111d07c06aa",
	"title": "Using Power Automate for Covert Data Exfiltration in Microsoft 365",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3283277,
	"plain_text": "Using Power Automate for Covert Data Exfiltration in Microsoft\r\n365\r\nBy Eric Saraga\r\nPublished: 2022-02-02 · Archived: 2026-04-05 18:43:58 UTC\r\nWhat is Power Automate?\r\nPower Automate, formerly known as Microsoft Flow, allows users to automate workflows between various apps\r\nand services. Using Power Automate, you can create \"flows\" in Microsoft 365 for Outlook, SharePoint, and\r\nOneDrive to automatically share or send files, forward emails, and much more.\r\nAlthough this feature is powerful for day-to-day automation, it can also be used by threat actors to automate data\r\nexfiltration, C2 communication, lateral movement, and evade DLP solutions.\r\nHow does it work?\r\nPower Automate is enabled by default with Microsoft 365 applications. It allows any user to create their own\r\nflows. Flows can be created programmatically or by using the flow planner UI.\r\nTo create a flow, a user must first create a connection. This connection allows the flow to access the application or\r\nresource using the user’s permissions.\r\nAs soon as the connection is established and the flow is saved, the flow will run. Any activity performed by the\r\nflow will be logged under the user who created the connection.\r\n×”. The actions are logged under the user Ringo since the connection was created with their account, but in reality,\r\nthey are automated.\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 1 of 11\n\nThis can be seen in the following log example from compliance.microsoft.com/auditlogsearch\r\nThis example is a log of an automated flow action where the user Ringo’s flow creates a share link for the file\r\n“Share_me.docx”. The actions are logged under the user Ringo since the connection was created with their\r\naccount, but in reality, they are automated.\r\nHow can attackers exploit Power Automate?\r\nSimilar to how forwarding rules in email clients can be used for exfiltration, Power Automate flows can be used to\r\nextract not only emails but files from SharePoint and OneDrive. You can also exfiltrate data from other Microsoft\r\n365 applications (even MSGraph).\r\nLet’s look at some examples.\r\nEmail exfiltration\r\n×\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 2 of 11\n\nThis is not a forward rule in Outlook/Exchange and therefore forward rule creation detections and preventions\r\nwill not block or detect this.\r\nFile exfiltration via shared links\r\nThe following flow creates an anonymous sharing link for every file created on the SharePoint site that the user\r\nhas access to and POSTs the link via an API call to the attacker’s server.\r\n×\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 3 of 11\n\nWhen creating a flow that uses file creation as a trigger (i.e. when a file is created do X), the flow will monitor\r\nevery file created on the SharePoint site, even if the flow owner did not create the file personally. If the flow\r\nowner has permission to view the file, the flow will trigger.\r\nIn most environments, SharePoint permissions are complicated and difficult to maintain. As a result, many users\r\nhave excessive access to information they don't need—giving attackers a large blast radius.\r\nA nice bonus is that if the flow is disabled for a few days, the file creations that were missed will be picked up by\r\nthe re-enabled flow and sent to the attacker.\r\nCreating Flows with a Script\r\nCreating flows can be done programmatically using the flow API. Although there’s no dedicated Power Automate\r\nAPI, the flow endpoints can be used to query for existing connections and to create a flow.\r\nOur script demonstrates an attacker’s approach for business email compromise.\r\nOnce a Microsoft 365 account is compromised, attackers can simply execute a command that will leak sensitive\r\ndata coming in, without the need to manually create the Power Automate flow.\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 4 of 11\n\nThe following script creates a flow called “Email Forwarding” to automatically forward all received emails to the\r\nattacker’s inbox.\r\n×\r\nThe flow will then appear in the UI and will be enabled:\r\n×\r\nThe flow name is customizable and can be changed to a more obscure value.\r\nMalicious flows can be leveraged for other activities, such as getting organizational trees from Delve, gathering\r\nSharePoint file statistics, and more.\r\nAbusing Flows via Azure Apps\r\nAs we discussed in our previous research, attackers can trick users into installing malicious Azure applications\r\nthat appear to be official, Microsoft-approved code.\r\nOnce a user installs the malicious Azure app, a threat actor can exploit Power Automate without ever having\r\naccess to the account’s credentials.\r\nFirst, we create an app in our attacker tenant and send a link to the victim. Clicking the link will automatically\r\nnavigate the victim to Azure’s application consent landing page. Once the user consents, our application will have\r\nthe necessary permissions to create a flow.\r\nHere we can see our malicious application requesting consent from a user to create and edit flows:\r\n×\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 5 of 11\n\nThe application authenticates the request using a valid Microsoft domain and URL, which increases the likelihood\r\nof success.\r\nThis method comes with a caveat: I could not find a way to create a new Power Automate connection using the\r\nAzure app. I could only use existing connections since the application’s token does not have permissions to create\r\na connection. This means that using Azure applications for this attack limits us to users who have already made\r\nconnections in Power Automate.\r\nThe more fool-proof method would be to use the user’s credentials or a Power Automate authentication token.\r\nUsing this method you can create connections and flows programmatically, without user interaction, and create\r\nautomatic exfiltration flows as your heart desires.\r\nDetection and Prevention\r\nThe attacks we discussed describe a few vectors threat actors can use to access Power Automate in an\r\norganization.\r\nVaronis adds behavior-based alerting to Microsoft 365, which can detect abnormal data access and email activity\r\nbased on the user’s historical baseline. This applies whether the actions are performed manually by the user, via\r\nscripts, or using Power Automate.\r\nThis is perhaps the most practical line of defense against Power Automate exfiltration because it doesn’t require\r\nthat you write specific detection rules or manually hunt for suspicious changes in IP addresses or user agent\r\nstrings.\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 6 of 11\n\nBehavior-based alerts are also extremely effective at detecting when a user is infected with malware that is\r\noperating under the user’s context—it’s very hard for attackers to emulate a user’s normal day-to-day behavior.\r\nMonitor Abnormal Authentication to the Power Automate Resource\r\nAzure AD monitors every login in its sign-in logs. This can be a powerful tool to monitor resource access.\r\nIn this case, we can look at logins made to the Power Automate (a.k.a. “Microsoft Flow Service”) resource and\r\nalert when abnormalities occur.\r\n×\r\nThe above login event shows our script running as user Ringo and authenticating to the Microsoft Flow Service\r\nusing the Azure Active Directory PowerShell application which is unexpected. Regular authentication via the UI\r\nwill use the Microsoft Flow Portal application.\r\nAnother abnormalities you could look for include:\r\nLogins from blacklisted locations\r\nLogins by dedicated admin accounts\r\nAbnormal data usage by a user\r\nMonitor PowerAutomate Flow Creations\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 7 of 11\n\nWe can directly look at flow logs to get an idea of newly created flows:\r\n×\r\nNote that flow logs lack data about what exactly changed in the flow or what flow was created with what\r\nconnection. However, we can still use this to get a more precise look at what happens after the user authenticates\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 8 of 11\n\nto the Power Automate resource. It might be that the user is allowed to login from every location but not to create\r\nflows from them.\r\nMonitor Automated Flow Activity\r\nAutomatic actions done by PowerAutomate are indicated by the User Agent “azure-logic-apps/*” in the logs as\r\nseen here:\r\n×\r\nAnother thing to note is that the action is always done from an Microsoft IP, however, relying on that might cause\r\nfalse positives since we’re dealing with a Microsoft platform.\r\nUsing this indicative user agent, we can either outright alert on suspicious actions or compare the automated\r\nactivity with the user’s regular activity and past automated activity to find abnormalities.\r\nAzure Application Monitoring\r\nUsing Azure applications for this attack creates a different log trace than using credentials directly. We can see the\r\ndifference in the Azure AD sign-in logs:\r\n×\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 9 of 11\n\nThe application used for authentication is the “MicrosoftOffice” app which is our malicious application (named\r\n“MicrosoftOffice” for phishing reasons), and the resource is the Microsoft Flow Service (same as before).\r\nMonitoring or limiting authentication to Flow service only for approved apps will limit the attack surface and, in\r\nturn, will help prevent exploitation of PowerAutomate.\r\nMonitoring consents given to applications can also help prevent this attack and other potentially destructive\r\nattacks.\r\nBlock Emails Forwarded from PowerAutomate\r\nDirectly block exfiltration using email by setting up controls for connectors:\r\nhttps://docs.microsoft.com/en-us/power-platform/admin/block-forwarded-email-from-power-automate\r\nReferences:\r\nhttps://medium.com/tenable-techblog/stealing-tokens-emails-files-and-more-in-microsoft-teams-through-malicious-tabs-a7e5ff07b138\r\nhttps://www.darkreading.com/application-security/hidden-dangers-of-microsoft-365-s-power-automate-and-ediscovery-tools\r\nhttps://www.vectra.ai/learning/power-automat\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 10 of 11\n\nSource: https://www.varonis.com/blog/power-automate-data-exfiltration\r\nhttps://www.varonis.com/blog/power-automate-data-exfiltration\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.varonis.com/blog/power-automate-data-exfiltration"
	],
	"report_names": [
		"power-automate-data-exfiltration"
	],
	"threat_actors": [],
	"ts_created_at": 1775434662,
	"ts_updated_at": 1775791288,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/895831f1a198d0301f1d1fc20dc2c111d07c06aa.pdf",
		"text": "https://archive.orkl.eu/895831f1a198d0301f1d1fc20dc2c111d07c06aa.txt",
		"img": "https://archive.orkl.eu/895831f1a198d0301f1d1fc20dc2c111d07c06aa.jpg"
	}
}