Researchers Backdoored Azure Automation Account Packages And Runtime Environments

Runtime environments offer a flexible way to customize Automation Account Runbooks with specific packages.

While base system-generated environments can’t be directly modified, they can be indirectly changed by adding packages to the old experience and then switching to the new Runtime Environments feature. 

It could potentially be exploited by attackers who create new runtime environments with malicious packages and assign them to target runbooks. To mitigate this risk, it’s crucial to carefully manage and secure runtime environments and avoid using untrusted packages.

- Advertisement -

For the PowerShell proof of concept, they created a custom package named PowerUpSQL, similar to an existing package.

This package will contain two files: a psd1 file defining the module structure and a psm1 file containing the code. 

Free Webinar on How to Protect Small Businesses Against Advanced Cyberthreats -> Free Registration

The psm1 file will include functions to generate a Managed Identity token for the Automation Account and exfiltrate it via HTTP to a specified URL, which can be customized by replacing the hardcoded URL in the example files.

The complete package will be in the “Misc/Packages” folder of the MicroBurst repository.

The PowerShell script module, `PowerUpSQL`, defines a function named `a` that retrieves a token from Azure Active Directory using the System-Assigned Managed Identity and sends it to a specified callback URL via a POST request. 

This function is exported from the module along with metadata, including the module version, GUID, author, company, copyright, and exported functions, cmdlets, variables, and aliases.

The module’s root module file is `PowerUpSQL.psm1`, and the manifest file is `PowerUpSQL.psd1`.

It describes creating a malicious Python package, which includes a directory with an `__init__.py` file and other modules with using a specific tool, aws_consoler, as the target module. 

The text highlights the need to adjust dependencies based on the intended use potentially. Overall, it outlines the setup for a malicious Python package.  

It showcases a malicious Python package named “aws_consoler.” The `setup.py` file configures metadata for distribution, while the `aws_consoler.py` script retrieves a token from a predefined URL using environment variables and sends it to another malicious endpoint. 

The old method of uploading modules and Python packages involves selecting a file, specifying a Runtime version, and naming the package. This method can be used in both old and new system-generated environments. 

Users can add packages to modify an existing Runtime Environment, but this might not work for system-generated environments.

Creating a new environment allows more flexibility in adding packages but requires moving runbooks.

To use malicious packages in Azure Automation, add them to the Automation Account or Runtime Environment and call them in a runbook. For PowerShell, add a line to call the function, possibly obfuscating the function name. 

According to NetSPI, import the `aws_consoler` package for Python, schedule runbooks to regularly check in with a token, and consider creating webhooks for runbooks to establish persistence.

Analyse AnySuspicious Links Using ANY.RUN's New Safe Browsing Tool: Try It for Free