Azure Automation Account Packages & Runtime Environments Backdoored
- С сайта: Vulnerability(cybersecuritynews.com)
- Вернуться к списку новостей
С сайта: Vulnerability(cybersecuritynews.com)
Azure Automation is a service that automates processes across various cloud platforms, making it easier to manage complicated hybrid setups.
It comes with a runtime environment that lets users set up the environment for running scripts and updates them to the most recent language versions.
Custom modules and packages can be specified to use in your runbooks through the “Automation Account service.” This feature can be compromised to allow an attacker persistent access to the Automation Account.
Understanding Runtime Environments
Users can configure specific execution environments for Automation Account Runbooks using the Runtime Environments functionality.
This enables users to set up particular packages that are suitable for use with an Automation Account container. An Automation Account now has more flexibility without causing package bloat on the base containers.
It is not possible to add more packages to the base “System-generated Runtime environments” in the new Runtime Environments system via the portal.
When you use the Runtime Environments feature, you can add packages that will be transferred to the new System-generated environments if you go back to the previous experience.
Runtime Environments feature
Once the feature becomes standard, it’s uncertain that you’ll be able to modify these base environments.
“If this does become the standard going forward, an attacker would need to create a new runtime, inject a malicious package into it, and swap the environment over for the target runbook. Alternatively, they could just create a new runbook and assign a new Runtime Environment to it”, reads the NetSPI blog.
A threat actor can use the package upload feature to add packages to the Automation Account. Once added, the malicious packages can be utilized in a runbook.
Detecting Any Existing Malicious Packages In Your Automation Accounts
You can manually inspect your current modules and packages for any custom modules in the Azure portal to aid in the detection of any malicious packages that may already be present in your Automation Accounts.
Review current modules and packages
Experts believe it is realistic to expect a threat actor to try poisoning packages used by Automation Accounts, given previous supply chain attacks.
Although this persistence strategy has been discussed for a while, it is not currently in use in the wild.
Hence, this is a good chance to quickly review the packages in your Automation Accounts and determine whether anything unexpected is present in the containers.
#cloud #Cyber_Security_Research #Vulnerability #Automation_Account #Azure_Security #cyber_security
Оригинальная версия на сайте:
Azure Automation Account Packages & Runtime Environments Backdoored
Author: Varshini SenapathiAzure Automation is a service that automates processes across various cloud platforms, making it easier to manage complicated hybrid setups.
It comes with a runtime environment that lets users set up the environment for running scripts and updates them to the most recent language versions.
Custom modules and packages can be specified to use in your runbooks through the “Automation Account service.” This feature can be compromised to allow an attacker persistent access to the Automation Account.
Understanding Runtime Environments
Users can configure specific execution environments for Automation Account Runbooks using the Runtime Environments functionality.
This enables users to set up particular packages that are suitable for use with an Automation Account container. An Automation Account now has more flexibility without causing package bloat on the base containers.
It is not possible to add more packages to the base “System-generated Runtime environments” in the new Runtime Environments system via the portal.
When you use the Runtime Environments feature, you can add packages that will be transferred to the new System-generated environments if you go back to the previous experience.
Runtime Environments featureOnce the feature becomes standard, it’s uncertain that you’ll be able to modify these base environments.
“If this does become the standard going forward, an attacker would need to create a new runtime, inject a malicious package into it, and swap the environment over for the target runbook. Alternatively, they could just create a new runbook and assign a new Runtime Environment to it”, reads the NetSPI blog.
A threat actor can use the package upload feature to add packages to the Automation Account. Once added, the malicious packages can be utilized in a runbook.
Detecting Any Existing Malicious Packages In Your Automation Accounts
You can manually inspect your current modules and packages for any custom modules in the Azure portal to aid in the detection of any malicious packages that may already be present in your Automation Accounts.
Review current modules and packages Experts believe it is realistic to expect a threat actor to try poisoning packages used by Automation Accounts, given previous supply chain attacks.
Although this persistence strategy has been discussed for a while, it is not currently in use in the wild.
Hence, this is a good chance to quickly review the packages in your Automation Accounts and determine whether anything unexpected is present in the containers.
#cloud #Cyber_Security_Research #Vulnerability #Automation_Account #Azure_Security #cyber_security
Оригинальная версия на сайте:
