Azure Automation - CraftedSignal Threat Feed

Azure Automation Runbook Created or Modified

hello@craftedsignal.io — Thu, 25 Jan 2024 12:00:00 +0000

This detection identifies the creation or modification of Azure Automation runbooks, a technique that adversaries can use to execute malicious code within an Azure environment and establish persistence. Azure Automation runbooks are scripts that automate tasks in cloud environments. The activity is detected by monitoring Azure activity logs for specific operations related to runbook creation or modification. While legitimate updates and maintenance may trigger this detection, unauthorized changes to runbooks can introduce backdoors or malicious functionality. The detection focuses on "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE", "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE", or "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION" operations. This activity is a part of exploiting cloud resources for unauthorized purposes.

Attack Chain

Adversary gains initial access to an Azure account with sufficient privileges to manage Automation Accounts.
The adversary navigates to the Azure Automation service.
The adversary creates a new runbook or modifies an existing one.
The runbook is populated with malicious code, such as PowerShell scripts designed to create a backdoor or exfiltrate data.
The adversary publishes the runbook, making it active within the Azure environment.
The runbook is scheduled to execute automatically or triggered manually.
The malicious code within the runbook executes, performing unauthorized actions such as data exfiltration or resource manipulation.
The adversary maintains persistence by ensuring the runbook continues to execute on a schedule.

Impact

A successful attack can lead to unauthorized access to sensitive data, resource hijacking, and persistent backdoors within the Azure environment. The impact ranges from data breaches and service disruption to long-term control of the compromised Azure resources. Even though rated low severity, successful exploitation leads to further malicious actions within the cloud environment, potentially impacting multiple services and data stores.

Recommendation

Deploy the Sigma rule Azure Automation Runbook Creation or Modification to your SIEM and tune for your environment to detect suspicious activity (rule).
Review Azure activity logs for the MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE, MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE, and MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION operations to identify potential unauthorized changes (logs).
Implement strict access controls and multi-factor authentication for Azure accounts with permissions to manage Automation Accounts (best practice).
Regularly audit and review the content of Azure Automation runbooks to identify any unauthorized or suspicious code (best practice).
Consider enabling logging of runbook execution to gain deeper visibility into their activity (best practice).

Azure Automation Runbook Deleted

hello@craftedsignal.io — Thu, 11 Jan 2024 12:00:00 +0000

This detection identifies when an Azure Automation runbook is deleted. Azure Automation runbooks are used to automate repetitive tasks and manage cloud resources. An adversary may delete an Azure Automation runbook to disrupt normal automated business operations or to remove a malicious runbook they previously deployed, thus covering their tracks. The detection focuses on monitoring Azure activity logs for events indicating the successful deletion of runbooks. While often legitimate, unexpected or unauthorized runbook deletions warrant investigation, especially in sensitive environments. The rule is designed to work with data ingested through the Azure Fleet integration or Filebeat module, which provides the necessary Azure activity logs.

Attack Chain

An adversary gains initial access to an Azure account, potentially through compromised credentials or exploiting a vulnerability in the Azure environment.
The attacker identifies Azure Automation accounts and their associated runbooks.
If the attacker previously created a malicious runbook for persistence or other malicious purposes, they may delete it to evade detection.
Alternatively, the attacker may delete legitimate runbooks to disrupt automated processes and cause operational impact.
The attacker executes the runbook deletion command, triggering an event logged in the Azure activity logs. The specific operation name is "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DELETE".
The Azure platform records the deletion event, including the user identity and timestamp of the action.
If successful, the runbook is permanently removed from the automation account.
The deletion leads to disruption of the automated tasks previously performed by the runbook, potentially impacting business operations or security measures.

Impact

Successful deletion of Azure Automation runbooks can lead to the disruption of critical automated tasks, affecting business operations and potentially causing financial or reputational damage. The severity depends on the importance of the deleted runbooks. If malicious runbooks are deleted, it serves as defense evasion, potentially delaying incident response.

Recommendation

Deploy the Sigma rule provided below to your SIEM to detect Azure Automation runbook deletions and tune it for your environment.
Investigate any detected runbook deletions, focusing on the user identity and context of the event (refer to the investigation steps in the rule description).
Implement stricter access controls and auditing for Azure Automation accounts to limit the ability to delete runbooks to authorized personnel.
Consider enabling versioning or backups of Azure Automation runbooks to facilitate restoration in case of accidental or malicious deletion.
Monitor user accounts for suspicious activity prior to the deletion event, such as privilege escalation or unusual access patterns.

Suspicious Azure Automation Account Creation

hello@craftedsignal.io — Thu, 04 Jan 2024 16:00:00 +0000

Azure Automation accounts allow users to automate management tasks and orchestrate actions across systems. An attacker may create an Automation Account for persistence, defense evasion, or lateral movement. The primary technique involves creating a valid account (T1078) within the Azure environment and abusing it for malicious purposes. This activity can be difficult to detect because the creation of Automation Accounts is a legitimate administrative function. Defenders need to monitor these events and correlate them with other suspicious activities. This brief focuses on detecting the initial creation of such accounts, providing a starting point for deeper investigation.

Attack Chain

The attacker gains initial access to the Azure environment, possibly through compromised credentials or a misconfigured service principal.
The attacker authenticates to the Azure Resource Manager API.
The attacker uses the Azure CLI or PowerShell module to create a new Azure Automation account using the New-AzAutomationAccount command or equivalent API call.
The attacker configures the Automation Account with necessary permissions, possibly granting it access to other resources within the environment.
The attacker creates Runbooks within the Automation Account that contain malicious scripts designed to perform tasks such as data exfiltration, lateral movement, or privilege escalation.
The attacker schedules the Runbooks to execute automatically or triggers them manually as needed to maintain persistence.
The attacker uses the Automation Account to maintain a foothold in the environment, bypassing traditional security controls and remaining undetected for extended periods.
The attacker leverages the compromised Automation Account to achieve their final objective, such as data theft, system compromise, or disruption of services.

Impact

A successful attack can lead to long-term persistence within the Azure environment. This allows the attacker to maintain control even if other access methods are discovered and remediated. The attacker can use the Automation Account to execute malicious code, steal sensitive data, or disrupt critical services, leading to significant financial and reputational damage. This can affect organizations of any size that rely on Azure for their infrastructure and operations.

Recommendation

Deploy the Sigma rule "Azure Automation Account Created" to your SIEM and tune for your environment to detect account creations (rule.name).
Investigate the user or service principal responsible for creating new Automation Accounts (references).
Review the permissions granted to newly created Automation Accounts to identify any excessive privileges (references).
Monitor for suspicious activity originating from Automation Accounts, such as unauthorized access to resources or execution of unusual scripts (references).
Implement multi-factor authentication (MFA) for all Azure accounts, especially those with administrative privileges to prevent credential compromise (references).
Enforce the principle of least privilege to limit the impact of compromised accounts (references).

Azure Runbook Webhook Creation Detected

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This alert focuses on the creation of new Azure Automation Runbook Webhooks within an Azure tenant. Attackers can exploit these webhooks, which trigger Automation Runbooks through unauthenticated URLs, to execute malicious code, create unauthorized user accounts, or establish persistence within the Azure environment. This activity is detected using Azure Audit events, specifically monitoring for the "Microsoft.Automation/automationAccounts/webhooks/write" operation. This is especially critical as successful exploitation can lead to full control over the Azure resources. Defenders should prioritize monitoring for unexpected or unauthorized webhook creation activities. This detection originated from Splunk's ES-CU detections as of April 2026.

Attack Chain

The attacker gains initial access to an Azure account, possibly through compromised credentials or exploiting a vulnerability.
The attacker navigates to the Azure Automation service within the Azure portal.
The attacker attempts to create a new Automation Account if one doesn't exist, or uses an existing one.
The attacker creates a new Runbook designed to execute malicious tasks. This could include adding a new user account with elevated privileges.
The attacker creates a webhook associated with the malicious Runbook. This generates an unauthenticated URL.
The attacker configures the webhook to trigger the Runbook upon accessing the unauthenticated URL.
The attacker tests the webhook URL to ensure the Runbook executes as intended.
The attacker leverages the webhook URL to execute malicious actions within the Azure environment, such as creating new high privileged accounts or modifying existing infrastructure.

Impact

Successful exploitation allows attackers to gain unauthorized access and control over Azure resources. This can result in data breaches, service disruptions, and further compromise of the environment. If not detected promptly, this can lead to significant financial and reputational damage. This issue impacts any organization using Azure Automation and exposes all data and resources managed within the impacted Azure tenant.

Recommendation

Deploy the Sigma rule Azure Runbook Webhook Created to your SIEM and tune for your environment to detect the creation of malicious webhooks.
Investigate any detected instances of Azure Runbook Webhook creation, focusing on the user (user) and source IP (src_ip) involved.
Review Azure Activity logs for the "Microsoft.Automation/automationAccounts/webhooks/write" operation.
Monitor network traffic for suspicious connections to newly created webhook URLs (related to the created object).
Implement strict access control policies and multi-factor authentication for all Azure accounts to prevent initial compromise.

Azure Automation Runbook Creation for Persistence

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The creation of Azure Automation Runbooks can be a legitimate administrative task, but it also presents a significant security risk. Threat actors with sufficient privileges can create or modify runbooks to establish persistence, escalate privileges, or execute malicious code within the Azure environment. This activity, if malicious, can lead to significant damage, including the creation of rogue Global Administrators, unauthorized code execution on virtual machines, and ultimately, the compromise of the entire Azure infrastructure. This brief focuses on detecting the creation of these runbooks as a potential indicator of malicious activity and provides guidance on how to identify and respond to such events. The detection logic is based on Azure Audit events.

Attack Chain

An attacker gains initial access to an Azure tenant, possibly through compromised credentials or exploiting a vulnerability.
The attacker escalates their privileges to a level sufficient to create or modify Azure Automation Runbooks.
The attacker creates a new Azure Automation Account if one does not already exist, or uses an existing one.
The attacker crafts a malicious Runbook containing code designed to perform unauthorized actions. This could involve PowerShell scripts or other supported languages.
The attacker creates the malicious Azure Automation Runbook, triggering an Azure Audit event with operationName.value="Microsoft.Automation/automationAccounts/runbooks/write".
The attacker schedules or manually executes the Runbook.
The Runbook executes malicious code, potentially creating new user accounts with elevated privileges or deploying malware to virtual machines.
The attacker achieves persistence by maintaining the Runbook for future unauthorized access or control.

Impact

Successful exploitation via malicious Azure Automation Runbook creation can lead to a complete compromise of the Azure environment. Attackers can create new administrative accounts, giving them persistent and unrestricted access. They can execute arbitrary code on virtual machines, potentially leading to data theft, ransomware deployment, or other destructive activities. The impact can range from data breaches and service disruptions to significant financial losses and reputational damage.

Recommendation

Deploy the Sigma rule Azure Automation Runbook Created to your SIEM to detect suspicious runbook creation activity. Tune the rule based on your environment to minimize false positives.
Investigate any detected instances of Runbook creation, paying close attention to the user involved (user field) and the contents of the Runbook itself.
Monitor Azure Audit logs for unusual or unauthorized activity related to Automation Accounts and Runbooks.
Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate the risk of credential compromise.
Review and enforce the principle of least privilege, ensuring that users only have the necessary permissions to perform their tasks.

Azure Automation Account Creation

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This brief focuses on detecting the creation of new Azure Automation accounts, a technique used by attackers to establish persistence and execute malicious actions within Azure environments. Azure Automation allows users to automate tasks across Azure and on-premise systems via runbooks. An attacker creating a rogue Automation account with elevated privileges can maintain a foothold in the environment, execute malicious scripts, and potentially gain control over virtual machines and other resources. This detection leverages Azure Audit events (Azure Activity log) to identify such suspicious account creation activity. The risk is significant due to the potential for broad impact and the difficulty in tracing actions back to the attacker-controlled Automation account. The provided Splunk analytic was last updated in version 13 on April 15, 2026.

Attack Chain

The attacker gains initial access to the Azure environment, potentially through compromised credentials or a vulnerability in a web application.
The attacker attempts to create a new Azure Automation account using stolen credentials or through a compromised service principal.
An Azure Audit event is generated with operationName.value="Microsoft.Automation/automationAccounts/write" and status.value=Succeeded, indicating the successful creation of the account.
The attacker configures the Automation account, assigning it elevated privileges, such as Contributor or Owner roles.
The attacker creates or imports malicious runbooks into the Automation account. These runbooks can contain PowerShell or Python scripts designed to execute malicious tasks.
The attacker leverages the Hybrid Runbook Worker feature to execute runbooks on Azure VMs or on-premise servers, allowing them to move laterally within the environment.
The runbooks execute malicious code, potentially installing backdoors, stealing credentials, or exfiltrating sensitive data.
The attacker maintains persistence by scheduling runbooks to execute regularly, ensuring continued access to the environment.

Impact

Successful exploitation can lead to significant damage, including data breaches, system compromise, and financial loss. Attackers can leverage Automation accounts to maintain persistence even after initial compromises are remediated. The scope of impact depends on the privileges assigned to the Automation account, but could potentially affect the entire Azure subscription and connected on-premise resources. This could lead to ransomware deployment, sensitive data exfiltration, or long-term espionage.

Recommendation

Deploy the provided Sigma rule to your SIEM and tune for your environment to detect the creation of Azure Automation accounts.
Investigate any detected Automation account creation events, focusing on accounts created by unfamiliar users or service principals.
Monitor Azure Audit logs for suspicious activity associated with newly created Automation accounts, such as runbook creation and execution.
Implement multi-factor authentication (MFA) for all Azure users to reduce the risk of credential compromise.
Review and restrict the permissions assigned to Azure Automation accounts, following the principle of least privilege.
Use Azure Policy to enforce restrictions on Automation account creation and configuration.

Azure Automation Webhook Created for Persistence

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This alert identifies the creation of Azure Automation webhooks, which adversaries may abuse to establish persistence within cloud environments. Azure Automation allows users to define and execute runbooks, which are scripts that automate tasks. Webhooks provide a mechanism to trigger these runbooks via HTTP requests. An attacker can create a webhook associated with a malicious runbook, allowing them to execute arbitrary code within the Azure environment whenever the webhook URL is accessed. This poses a significant risk, as it allows attackers to maintain a persistent foothold and potentially escalate their privileges. The detection rule focuses on identifying specific operation names within Azure activity logs related to webhook creation.

Attack Chain

An attacker gains initial access to an Azure account, possibly through compromised credentials or exploiting a vulnerability.
The attacker navigates to the Azure Automation service within the compromised account.
The attacker creates a new runbook or modifies an existing one to include malicious code (e.g., PowerShell script to create a new user, exfiltrate data, or deploy malware).
The attacker creates a new webhook associated with the malicious runbook. The webhook is configured to be triggered by an HTTP request to a unique URL.
The attacker obtains the webhook URL.
The attacker triggers the webhook by sending an HTTP request to the URL, either manually or through an automated process.
The Azure Automation service executes the runbook associated with the webhook.
The malicious code within the runbook executes, achieving the attacker's objective (e.g., persistence, privilege escalation, data exfiltration).

Impact

Successful exploitation allows attackers to establish a persistent presence within the Azure environment. This can lead to unauthorized access to sensitive data, deployment of malware, or further compromise of other resources within the cloud infrastructure. While the risk score is low, the long-term impact of persistence can be severe, potentially affecting hundreds or thousands of resources depending on the scope of the compromised Azure account.

Recommendation

Deploy the Sigma rule "Azure Automation Webhook Created" to your SIEM and tune for your environment (rule below).
Review Azure activity logs for unusual webhook creation events, focusing on the azure.activitylogs.operation_name field as indicated in the rule (rule below).
Implement enhanced monitoring and alerting for webhook creation and execution activities to detect similar threats in the future as described in the Overview section.
Enforce multi-factor authentication (MFA) for all accounts with access to Azure Automation as mentioned in the Response and Remediation section.