How CrowdStrike Detects Cloud Storage Misconfigurations to Protect Valuable Data

Cloud storage misconfigurations continue to become more prevalent and problematic for organizations as they expand their cloud infrastructure, driving the importance of technologies such as cloud security posture management (CSPM) as crucial tools for protectors everywhere.

Consider the recently reported public exposure of data associated with some Microsoft customers and prospects. The data leak was publicly reported Oct. 19 by Microsoft and SOCRadar, whose security researchers discovered the leak and reported it to Microsoft on Sept. 24. Microsoft reconfigured the storage bucket, identified as Azure Blob Storage, “within several hours” of being notified, making it “no longer publicly accessible,” SOCRadar reported.

According to Microsoft, “The issue was caused by an unintentional misconfiguration on an endpoint that is not in use across the Microsoft ecosystem and was not the result of a security vulnerability” and there was “no indication customer accounts or systems were compromised.”

As organizations continue to adopt such cloud data storage services and expand their cloud infrastructure, the risk of misconfigurations is poised to grow — potentially leaving valuable resources exposed to threat actors. Here, we dive into this issue and discuss how CSPM can help.

Cloud Storage Misconfigurations and the Growing Need for CSPM

Cloud-based data storage is a favorite target of threat actors who seek organizations’ valuable data to achieve their goals, whether they include espionage — an attempt to gather data about the target for use in future attacks — or monetary gain. While cloud service providers (CSPs) offer services to enable scalable data storage solutions and integrations with other services, the risk of exposing data to unauthorized parties through misconfiguration remains high.

Azure Blob Storage is one example of such storage services which can, if desired, integrate with SQLServer by acting as a backup destination for databases. The service provides a number of configuration settings to increase the security posture of storage Blobs. As the recent report by SOCRadar suggests, organizations using these services would do well to ensure these configurations are consistently monitored and enforced in their environments. This can be difficult to achieve, however, particularly as environments scale and you begin adding complexity through integrations such as SQLServer backup, as in this reported instance.

Here is where CrowdStrike can help. Read on to learn best practices as well as how CrowdStrike’s CSPM solution, Falcon Cloud Security, enables CrowdStrike customers to monitor their storage configurations, quickly identify misconfigurations that can potentially be exploited, and prioritize remediation steps to keep data safe.

First, we’ll overview the risk that misconfiguration poses to organizations.

How a Threat Actor Could Exploit Misconfigurations

Here, we describe a potential attack scenario involving the following components, all of which were factors in the recent scenario SOCRadar reported:

1. Misconfigured, publicly accessible Azure bucket
2. SQL servers backed up in said Azure bucket which contain unencrypted data at rest
3. Additional Azure buckets accessed with information retrieved from SQL server backups

The following steps outline how a threat actor might exploit such a situation for malicious gain. It’s important to note this is a generalized and hypothetical scenario.

1. Recon: The first step in an attack exploiting these weaknesses is understanding the different levels of public accessibility. In the case of Azure Storage Blobs, anonymous public accessibility permissions can be granted at the container or the blob access level.

The container access level allows an anonymous client to make requests to containers enumerating the blobs they contain as well as to individual blobs, accessing their content or metadata. A threat actor only needs to know a storage account name and a container name to enumerate content within these blob storages.

In contrast, the blob access level only allows requests to individual blobs for their content meaning a threat actor also needs to know the name of individual blobs ahead of time to access them.

At this point a threat actor would likely perform some general reconnaissance on the target with the goal of defining wordlists containing likely names of storage accounts, containers and blobs. To discover targets of opportunity, threat actors might scan public DNS records to find active storage accounts, based on common naming conventions used for domains, such as <storage_account_name>.blob.core.windows.net.

2. Enumeration: The second step is enumeration. Though this can be achieved by simply visiting the blob URLs directly in the Azure portal, we will walk through a programmatic method as enumeration is often scripted.

In a case where the access level is set to container, a threat actor can iterate through a wordlist of storage account names and container names making GET requests to the list blobs API that Microsoft provides for Azure.

curl “https://{storage_account_name}.blob.core.windows.net/{container_name}?restype=container&comp=list”

This request with the comp=list query parameter returns XML data that can be parsed to retrieve a list of Blobs within the container.

<?xml version="1.0" encoding="utf-8"?>
<EnumerationResults ContainerName="https://{storage_account_name}.blob.core.windows.net/{container_name}">
	<Blobs>
		<Blob>
			<Name>backup1.bak</Name>
			<Url>https://{storage_account_name}.blob.core.windows.net/{container_name}/backup1.bak</Url>
			<Properties>
				<Last-Modified>Mon, 31 Oct 2022 20:17:14 GMT</Last-Modified>
				<Etag>0x8DABB7CE67F8660</Etag>
				<Content-Length>15</Content-Length>
				<Content-Type>text/plain</Content-Type>
				<Content-Encoding />
				<Content-Language />
				<Content-MD5>4ZwSg8klsyBmhf9SKs/j5g==</Content-MD5>
				<Cache-Control />
				<BlobType>BlockBlob</BlobType>
				<LeaseStatus>unlocked</LeaseStatus>
			</Properties>
		</Blob>
		<Blob>
			<Name>backup2.bak</Name>
			<Url>https://{storage_account_name}.blob.core.windows.net/{container_name}/backup2.bak</Url>
			<Properties>
				<Last-Modified>Wed, 02 Nov 2022 17:21:08 GMT</Last-Modified>
				<Etag>0x8DABCF6A1682309</Etag>
				<Content-Length>0</Content-Length>
				<Content-Type>text/plain</Content-Type>
				<Content-Encoding />
				<Content-Language />
				<Content-MD5>1B2M2Y8AsgTpgAmY7PhCfg==</Content-MD5>
				<Cache-Control />
				<BlobType>BlockBlob</BlobType>
				<LeaseStatus>unlocked</LeaseStatus>
			</Properties>
		</Blob>
	</Blobs>
	<NextMarker />
</EnumerationResults>

On the other hand, if the access level is blob, a threat actor would need a third wordlist containing possible blob names. They could then iterate through all three wordlists making HEAD requests to the get blob properties API.

curl -I “https://{storage_account_name}.blob.core.windows.net/{container_name}/{blob_name}”

If the blob exists, this endpoint returns a status code of 200 and some HTTP headers containing blob metadata.

HTTP/1.1 200 OK Content-Length: 0 Content-Type: text/plain Content-MD5: 1B2M2Y8AsgTpgAmY7PhCfg== Last-Modified: Wed, 02 Nov 2022 14:14:03 GMT ETag: 0x8DABCDC7EC99D24 Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0 x-ms-request-id: 22ce96f8-901e-0029-50c8-eede8a000000 x-ms-version: 2009-09-19 x-ms-lease-status: unlocked x-ms-blob-type: BlockBlob Date: Wed, 02 Nov 2022 14:35:38 GMT

If the blob doesn’t exist a status code of 404 is returned with the message “The specified blob does not exist.”

HTTP/1.1 404 The specified blob does not exist. Transfer-Encoding: chunked Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0 x-ms-request-id: eb2b2339-801e-00a3-6ac8-ee853b000000 x-ms-version: 2009-09-19 Date: Wed, 02 Nov 2022 14:35:43 GMT

While more cumbersome, a threat actor could enumerate existing blobs by making these requests and recording those that return status codes of 200.

3. Data Exfiltration: Once the publicly accessible blobs are discovered and enumerated, they can be downloaded and their contents inspected via get blob requests.

curl “https://{storage_account_name}.blob.core.windows.net/{container_name}/{blob_name}”

The response body of this request will contain the contents of the blob.

4. Further Enumeration and Exfiltration: In this reported case the downloaded blobs contained unencrypted SQL Server backups. Database backups often contain sensitive information; if they are unencrypted, all it would take for the threat actor to access their data is the use of SQL statements to read and retrieve the stored information just as an authorized administrator or data owner would. Upon inspection of the backups, fields are discovered referencing further publicly accessible Azure Blob Storages that were unknown to the threat actor. At this point, the threat actor can repeat the enumeration and exfiltration of these newly discovered Azure Blobs which might contain further sensitive information.

CrowdStrike Best Practices for Configuring Azure Blob Storage

As a baseline for protection, CrowdStrike recommends implementing the following essential controls when using Azure Blob Storage services:

• Apply access control lists (ACLs) to restrict access to files or directories in storage to certain security principals (users, groups or application service principals)
• Apply storage networking firewalls to restrict access to only authorized IP spaces or virtual networks (never allow access from the entire public Internet unless that fits your intended use)
• Apply authorization methods to restrict access to only authorized users or services, and refrain from enabling anonymous access unless that fits your intended use
  • Shared access signatures can often fill the need for temporary anonymous access in a more secure way
• Leverage encryption at rest and in transit to secure the data from unauthorized view

Note: Because threat actors who gain access to user accounts that can manage these settings may modify them to create exposures they can leverage externally, CrowdStrike also recommends you:

• Leverage Azure storage role-based access control (RBAC) to restrict unauthorized users from changing configurations
• Continuously monitor the configuration state of these protections to ensure they remain intact

In its investigation, SOCRadar discovered additional publicly accessible Azure Blobs by analyzing some unencrypted SQLServer backups found in the initial blob. To prevent this from happening, CrowdStrike recommends not only ensuring your Azure Blob Storage configuration is secure but also securing the configuration of any services that interact with Azure Blob. As unencrypted SQLServer backups were relevant in this case CrowdStrike recommends the following:

• Apply transparent data encryption for SQL databases to encrypt data at rest within SQL databases, transaction log files, and associated SQL database backups

Falcon Cloud Security Policies to Support Best Practice Configuration

Falcon Cloud Security can detect misconfigurations in storage accounts as well as Azure SQL services that would help protect customers from an attack like the one outlined above. Namely, Falcon Cloud Security can:

• Alert on storage accounts that are set as publicly accessible
  • Allowing users to prevent public data exposure in storage blobs
• Alert on storage accounts that are not encrypting data at rest via file service or blob service encryption
  • Allowing customers to ensure they are encrypting data at rest in storage
• Alert on azure SQL databases that are not encrypting data via transparent data encryption
  • Allowing customers to ensure they are encrypting data within the database as well as within backups of the database. This way again, even if the backups are publicly accessible, threat actors would likely not be able to read them. It should be noted that whilst Azure SQL databases don’t back up to Azure Storage Blobs, SQL Servers running on-premises or in Azure VMs can and often do

The following table contains a current list of Falcon Cloud Security detection policies. These enable discovery of Azure Blob Storage configuration issues at scale that may allow remote threat actors to exploit related weaknesses. They are listed under two headings as Falcon Cloud Security has two types of detection policies: indicators of attack (IOAs), which are behavior-based detections (e.g., actions taken by a user), and indicators of misconfiguration (IOMs), which are misconfiguration based detections (e.g., static configuration settings of a service).

Conclusion

Threat actors have proven to show a continued interest in gaining access to the information stored by cloud services. By leveraging security standards and monitoring solutions like those described above, protectors of this data can work to ensure it remains secure, to stop the breach from happening.

Additional Resources

• Request a CrowdStrike cloud security demo: Falcon Cloud Security: CSPM | Falcon Cloud Security: CWP | Falcon Cloud Security: Container Security.
• Learn more about CrowdStrike’s recognition as a security leader by industry analysts, independent testing organizations, security professionals and customers by visiting our Industry Recognition and Technology Validation webpage.
• Learn more about how CrowdStrike solutions protect your business from crippling data leaks and ransoms and proactively defend against ransomware threats.
• See for yourself how the industry-leading CrowdStrike Falcon platform protects against modern threats like ransomware. Start a 15-day free trial today.