Exploring Azure Logic Apps and Turning Misconfigurations into Attack Opportunities

Exploring Azure Logic Apps and Turning Misconfigurations into Attack Opportunities

Speakers: Chirag Savla & Raunak Parmar — White Knight Labs

Conference: NorthSec 2025 — May 15–16, 2025, Marché Bonsecours, Montreal

Watch on YouTube: https://www.youtube.com/watch?v=xNAGjMXHx1w

Reading time: ~7 minutes

TL;DR

Chirag Savla and Raunak Parmar of White Knight Labs methodically map the attack surface of Azure Logic Apps — Microsoft's low-code workflow automation service — demonstrating how Logic App Contributor permissions, exposed webhook URLs, misused managed identities, storage account misconfigurations, hardcoded credentials in assemblies, and inline code execution combine to create a path from initial access to cloud-wide compromise and cloud-to-on-premises lateral movement.

Introduction

Azure Logic Apps is positioned as an accessible automation platform: drag-and-drop workflow design, over a hundred pre-built connectors, zero-code integration with virtually any Azure service or third-party application. That accessibility is exactly what makes it a compelling target. A service that sits at the intersection of email, Teams, databases, storage, virtual machines, and external APIs — and that can be configured by non-developers — accumulates permissions and secrets in ways that are difficult to audit and easy to overlook.

Chirag Savla and Raunak Parmar present this attack surface from the perspective of practicing offensive security engineers. Both work at White Knight Labs and have presented at Black Hat, DEF CON, and other major conferences. Their NorthSec 2025 session is grounded in real penetration testing engagements, not theoretical attack chains. The case that anchors the talk — a service principal embedded in a Logic App that enabled full Azure and on-premises compromise — came from a real-world assessment they conducted.

Logic Apps Architecture: The Attacker's Orientation

Before cataloguing vulnerabilities, the speakers establish the architectural primitives an attacker needs to understand.

▶ Watch: Logic Apps architecture — plans, triggers, and actions (2:00)

Logic Apps run under one of two plans. A Consumption plan executes a single workflow on demand, scales automatically, and creates no additional Azure resources. A Standard plan supports multiple concurrent workflows, acts more like a full application host, and at creation time automatically provisions an App Service, a storage account, and a Function App-compatible runtime. This distinction matters offensively: Standard plan deployments expose a larger attack surface by default because all workflow definitions are synchronised to the associated storage account's file share.

Every workflow contains two kinds of components: a trigger (the condition that starts execution — an HTTP POST to a unique webhook URL, a schedule interval, or an event from a connected service) and one or more actions (the operations the workflow performs). The webhook URL associated with an HTTP-triggered workflow is globally accessible; no authentication is enforced beyond knowing the URL. Exposing this URL — through documentation, code repositories, or misconfigured access controls — is sufficient for any external actor to execute the workflow.

The Logic App Contributor Role: A Near-Total Compromise Path

The first major attack vector the speakers develop is the consequences of holding Logic App Contributor permissions in a target environment.

▶ Watch: Contributor permissions and managed identity token theft (8:00)

With Contributor access, an attacker controls all workflows within the Logic App. The most immediate capability is stealing OAuth tokens via managed identity. Azure managed identities allow a Logic App to authenticate to other Azure resources without storing credentials: the Logic App calls the instance metadata endpoint to obtain a short-lived access token for a specified resource (e.g., management.azure.com or graph.microsoft.com).

An attacker with Contributor access can create a new workflow containing a single HTTP action configured to use managed identity authentication — but directed at an attacker-controlled server. When the workflow executes, the Azure platform generates a valid access token and sends it in the Authorization header to the attacker's endpoint. The token is fully functional and grants whatever permissions the Logic App's managed identity has been assigned in the environment. No credentials need to be stolen; the platform delivers them.

Contributor access also enables API connection hijacking. Logic Apps connect to third-party services (Outlook, Teams, SharePoint, etc.) through API Connection resources that store OAuth tokens. If an attacker lacks direct access to those services, they can create a new Logic App and reference the existing API Connection in their workflow's code view — effectively piggybacking on credentials another user has already authorised.

Storage Accounts: The Persistent Exposure Layer

Standard plan Logic Apps automatically synchronise all workflow definitions, assembly files, and configuration to an Azure Storage Account file share. This creates a second attack path that does not require Logic App permissions at all.

▶ Watch: Storage account as an attack surface — workflow exfiltration and assembly analysis (12:00)

An identity holding the Storage Blob Data Reader role — a permission that may seem benign to an administrator focused on data segregation — can list and download the full contents of the Logic App's file share. This includes workflow JSON definitions, which may contain hardcoded secrets, service principal credentials, connection strings, or API keys placed there by developers who did not realise the storage account was accessible to additional identities.

Assembly files present a further risk. Logic Apps support uploading .NET assemblies that can be called from inline code actions. These are stored in the same file share. Because they are standard .NET binaries, they can be decompiled with common tools. Real-world assessments have found hardcoded credentials in these assembly dependencies — credentials that the developer never intended to expose but that are fully recoverable from the binary.

The write-access scenario escalates further. With Storage Blob Data Contributor or higher access, an attacker can modify the workflow JSON stored in the file share. Because Logic App Standard plan workflows synchronise from storage, a modified workflow definition is loaded and executed the next time the workflow triggers — without any action through the Logic App management interface.

Inline Code Execution and Cloud-to-On-Premises Lateral Movement

A relatively recent Logic App feature — support for inline code in Node.js, C#, and PowerShell — significantly expands the impact of any workflow-level compromise.

▶ Watch: Inline code execution and C# system commands (14:00)

Prior to this feature, an attacker with workflow control could exfiltrate tokens and data through HTTP calls, but could not execute arbitrary system commands. With inline code support, a Logic App can now function as a command-and-control execution environment — running .NET code with access to the managed identity's permissions, the network context of the Logic App's hosting plan, and any secrets hardcoded in the workflow or referenced from Key Vault.

The real-world engagement the speakers describe illustrates the combined impact of these vectors. The Logic App under assessment had a service principal credential hardcoded in a workflow action — present because the developer had copied credentials from a configuration file without recognising the risk. That service principal had been granted read-level Graph API permissions for a stated purpose. But through additional Azure RBAC assignments accrued over time, it also held permissions sufficient to compromise the full Azure tenant: hijacking the Intune environment, the Azure DevOps organisation, the on-premises Active Directory connect server, and ultimately achieving Global Administrator status in Entra ID.

Defensive Guidance

The speakers conclude with practical mitigations, framing each vulnerability class in terms of preventable configurations.

▶ Watch: Defensive recommendations and configuration hygiene (22:00)

Webhook URLs should be treated as credentials: stored in Key Vault, rotated periodically, and never committed to repositories or documentation. Managed identity permissions should be scoped to the minimum required resource and reviewed regularly — the Logic App's identity assignment history often shows permissions granted for specific projects that were never revoked. Storage account access should be audited with the understanding that Storage Reader on a Standard plan Logic App's associated account is equivalent to read access on all workflow definitions and assemblies.

Hardcoded credentials in workflow actions or assembly files should be treated as a secret sprawl problem; Logic Apps should use Key Vault references for all secrets. Inline code execution, where not operationally required, should be disabled through Azure Policy. Finally, API connection permissions should be inventoried: connections created under a named user's OAuth token persist and remain usable even after the user leaves the organisation.

Notable Quotes

"One URL to rule your workflow. If it's exposed, anyone in the world can just hit a POST request, and it can run those workflows."

"If you have Logic App Contributor permissions, it's almost over — because you have full control over all the workflows."

"Why would you use a vault if you can just run Control+C to paste some service principal credentials?"

"The whole attack path was: hijack the complete infrastructure of the Azure, even the on-prem systems, the Intunes, the DevOps, and becoming the Global Admin over the Entra ID."

Key Takeaways

• Logic App Contributor is effectively a privilege escalation path. This role enables managed identity token theft, API connection hijacking, and full workflow manipulation without any credential access.
• Standard plan Logic Apps create implicit storage exposure. The auto-provisioned storage account synchronises all workflows and assemblies; Storage Reader access on that account is a significant reconnaissance and persistence vector.
• Hardcoded credentials in Logic App actions and assemblies are recoverable. Developers routinely embed service principal credentials and API keys in workflows; .NET assemblies are decompilable and frequently contain secrets.
• Inline code execution turns Logic Apps into cloud execution environments. C#, Node.js, and PowerShell support means workflow control now implies arbitrary code execution in the Logic App's cloud context.
• Webhook URL exposure is a direct trigger for attacker-controlled workflows. URLs should be treated as secrets, rotated regularly, and never committed to public repositories.
• Permissions accumulate over time. The real-world compromise in this talk succeeded because a service principal granted minimal permissions for one project had accumulated additional roles that collectively enabled full tenant compromise.