Abuse Azure Logic App Automation

What this lab covers

You begin from information an employee published without realising its value, establish a foothold, and work into the tenant's automation, where a workflow's connections and identity provide the access.

The open source intelligence stage is worth taking seriously. Social media posts routinely contain screenshots, naming conventions, tooling references and occasionally credentials, and reconnaissance from public sources leaves no trace at all.

It is rated intermediate and suits anyone who administers automation, since these platforms are frequently outside the scope of both security review and identity governance.

How automation platforms become attack paths

Logic Apps execute workflows against other services using connections, which hold delegated authorisation, and optionally a managed identity for Azure resources. The permissions are standing, because the workflow must run without a person present.

Editing a workflow is therefore acting with those permissions. An attacker who can modify a Logic App can add a step that reads data, writes to storage, sends mail as the connected account or calls Azure APIs, without ever seeing the underlying credential.

Governance is usually the weak point. Automation is built by operations, finance and business teams as much as by engineers, connections are created with whatever account was convenient, and the resulting workflows are rarely inventoried or reviewed against the access they hold.

How to detect this in your own environment

Alert on workflow modification. Logic App definition changes are control plane events, they are infrequent in stable automation, and adding a step is the action that turns automation into an attack path.

Baseline what each workflow's identity and connections actually do. Automation is repetitive by nature, so a workflow suddenly touching a new service is a strong signal.

Watch for new connections being created, particularly ones authorised with privileged accounts, since that is how automation quietly acquires more access than intended.

How to prevent it

Inventory your automation and the access each workflow holds. Most organizations cannot produce this list, and producing it usually reveals connections authorised by administrators years ago.

Use dedicated, narrowly scoped identities for automation rather than connections authorised with a person's account. A connection tied to an individual inherits everything that individual can do.

Restrict who can edit workflows and treat that permission as equivalent to the access the workflow holds, because it is.

Real-world context

Low-code and automation platforms have become a recognized gap in cloud security. They hold real credentials and real access, they are edited by people outside engineering, and they are frequently absent from the identity governance that covers everything else.

The reconnaissance stage is equally realistic. Publicly posted screenshots and announcements routinely disclose internal tooling, naming conventions and occasionally credentials, and that collection is invisible to the target.

The pattern maps to MITRE ATT&CK T1593 Search Open Websites and Domains, T1078.004 Cloud Accounts and T1648 Serverless Execution.

Applying this at work

• Produce an inventory of your Logic Apps and similar automation, with the connections and identities each one holds.
• Replace connections authorised with individual user accounts with dedicated, scoped identities.
• Restrict and review who can edit workflow definitions.
• Alert on workflow modification and on new connection creation.
• Search your organization's public posts for screenshots and details that disclose internal systems.

Frequently asked questions

Why are automation platforms a security concern?

Because they hold standing permissions to the systems they integrate, and they are frequently edited by people outside engineering. Modifying a workflow is a way to act with those permissions without holding the credentials.

What makes a connection risky?

Connections authorised with an individual's account inherit everything that person can do. A dedicated identity scoped to the workflow's actual needs limits what an abused workflow can reach.

How do I find automation I do not know about?

Inventory it directly through the platform rather than asking teams. Automation is commonly built outside engineering, so the people who own it are frequently not the people security would think to ask.

Do I need my own Azure account to practice this?

No. The lab runs in a live Azure environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.