An Offensive Security Perspective on Hacking the Cloud: Five AWS and Azure Cloud Security Threats to Focus On

According to Gartner, the global market for cloud infrastructure services increased by 30% in 2022, exceeding $100 billion for the first time. AWS and Azure account for almost two-thirds of this figure. While many organizations benefit from these platforms, the popularity of the cloud can also present significant security challenges. The ethical hacking of Azure and AWS by expert practitioners provides key insights into potential vulnerabilities and the ways in which threat actors are able to exploit them. In this article, we outline the most common types of cloud security threats on AWS and Azure and some defenses against them, from the perspective of an experienced offensive security specialist.

Cloud Security Threats on AWS and Azure

Cloud Storage Attacks

Cloud storage attacks are a significant challenge for organizations because they target data and other important business assets. An important first step for pen testers in identifying these types of cloud security threats is to check enumerated buckets for unauthenticated user access. Enumeration can lead to discovery of Azure Shared Access Signature (SAS) links. For these links, pen testers will start with a similar Azure URL structure which will also contain “ss”, “srt”, “sp”, “se” and “sig” parameters and will then load it via the Azure Storage Explorer.

An example of an Azure SAS link is:

https://<accountname>.<service>.core.windows.net/?ss=bfqt&srt=sco&sp=rwdlacup&se=2023-09-15T13:00:00Z&sip=88.208.222.83&sig=ACNA15d%2B%2BZSzPtPO71fMS34k%2FhLf2W13hjnamoGffIm%3D 

A key defense against cloud storage attacks is to check your organization’s containers to ensure that appropriate permissions are set up. Confirm that any open buckets are meant to be open. If utilizing SAS, it is also important to establish that permissions aren’t too broad-ranging.

Password Spraying Against Azure/O365 Accounts

If in-scope, penetration testers may be able to use password spraying, which targets commonly used passwords, such as those including the season and year, for example, "Summer2023."  Pen testers will choose the type of password that an end user would use, such as Fall2023!, Autumn2023! and September2023! This is then sprayed to valid accounts using a tool such as MSOLSpray or CredMaster.

A useful layer of defense against these types of cloud security threats on AWS and Azure environments is to implement and maintain a strong password policy, supported by multi-factor authentication (MFA). Keep in mind that attackers can spray passwords slowly, even using different IP addresses for each request. Implement detection mechanisms suitable for your organization, based on whether attacks are likely to be on a large number of failed logins from a single IP or on successful login from cloud service provider IPs.

Social Engineering

Attackers often attempt to phish, vish or smish user credentials to cloud services to gain credentials and also permissions. An example of this is an illicit consent grant attack in Azure. In this type of attack, the threat actor registers a multitenant application in their own tenant. The app is usually configured for user.read and user.readbasic.all permissions. If consent is granted, the attacker can obtain user access tokens.

Regular training and awareness sessions for all employees are a critical aspect of defending against phishing. Ensure detection with URL rewriting via email protection. Apply user behavior analytics, message trace logs and audit trace logs, etc.

Implement phishing-resistant authentication methods, such as devices enrolled in Fast Identity Online (FIDO), especially for privileged users. Alongside this, review and update IT helpdesk policies and exception-handling procedures to address social engineering attacks aimed at enrolling or disabling multifactor authentication (MFA) and unauthorized devices.

Use creative Conditional Access control (CAC) policies to reduce your attack surface, for example:

• If your corporate device policy only includes Windows for desktop and iOS mobile devices, block Android and MacBooks from authenticating.
• Disable or limit the scope of allowed MFA methods, such as SMS and voice approval, or unused MFA application types.
• Consider blocking or flagging authentication attempts and enrollment from geographies outside the scope of your organization’s footprint.
• Limit the number of allowed MFA devices per user and require extra authentication factors when authorizing MFA devices.
• Review and reduce session token lifetimes and implement continuous access evaluation features (CAE), where available

To defend effectively against illicit consent grant, ensure that your organization’s app consent policies are being effectively managed. Limit the apps that users can consent to or disable them altogether. Any previously consented application will still have consent after making changes.

Ensure effective detection of social engineering attacks in the cloud by:

• Using Microsoft 365 Defender portal (if licensed)
• Removing all Oauth consent grants
• Utilizing AzureADPSPermissions.ps1

Web App Attacks

More traditional types of attacks are still possible even in cloud environments. Examples include:

• Insecure File Upload
• Server-Side Template Injection (SSTI)
• Remote Code Execution (RCE)
• Path Traversal
• Server-Side Request Forgery (SSRF) 

To identify SSRF attacks in AWS, pen testers look for a feature that makes calls to another server or local resource. In a case recently observed by Kroll, the threat actors were seen attempting to access Metadata API via the following URL, which provided AccessKeyId and SecretAccessKey to the underlying account that the web app utilized. In this instance, an attacker would simply need to utilize the URL in the vulnerable input to obtain this information.

http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLENAME>

Metadata APIs

Instance metadata APIs are another vector for threat actors. Metadata APIs allow applications to access information about the running instance. Generally accessible over APIPA (169.254.169.254), their features vary based on the specific provider. They respond to HTTP requests, with the structure of HTTP requests again varying on the basis of the provider.

AWS Metadata API has two versions: IMDSv1 and IMDSv2o, with the latter being more security-focused and session-based instead of role-based. Initial requests should be changed to PUT and additional headers are required. However, it can still be obtained if command execution is possible. The base URL is:  

http://169.254.169.254/latest/meta-data

Organizations should disable IMDS v1 in favor of only using IMDSv2. While IMDSv2 isn't fool-proof, it offers more security features and makes exploitation more difficult.

In AWS, the base URL is: http://169.254.169.254/latest/meta-data/. The following table shows a sample of accessible metadata endpoints in AWS.

In Azure, the API requires a mandatory header for all requests, which is Metadata: True. It must not contain an X-Forward-For header in requests. The base URL is:

http://169.254.169.254/metadata/<ENDPOINT>?api-version=2017-08-01.

The following table shows a sample of accessible metadata endpoints in Azure.

In both AWS and Azure environments, it is important to only use secure code for applications and infrastructure. This is because, if an attacker is able to exploit remote code through vulnerable code, they can potentially utilize the IMDS services of both providers to gain further access into the cloud environment.

Maximizing the Security of Your AWS and Azure Platforms in the Face of Cloud Security Threats

While the flexibility of the cloud is hugely beneficial to businesses, it is also a key factor in associated web cloud security threats. The complexity of AWS and Azure environments means that organizations must avoid becoming complacent about their approach to security. The gap between organizations’ perceptions of their cyber maturity status and their actual cybersecurity practices has been revealed as a key security risk in recent Kroll research. Because you can’t protect what you don’t know you have, effective asset discovery is critical. This is why a key first step to enhancing your defensive posture, particularly for organizations with a less mature security strategy, is to fully understand what your cloud architecture encompasses.

Alongside this, regular red teaming, purple teaming and pen testing delivered by a field-proven security partner play an important role in ensuring that businesses are better prepared to defend against cloud security vulnerabilities. Kroll provides end-to-end security services proven to enhance the security of cloud environments and mitigate the risk of cloud security threats. Our team of certified cloud pen testers uncover vulnerabilities in your cloud environment and apps before they can be compromised by threat actors. Our cloud security team has industry-leading experience and conducts thousands of hours of assessments across AWS, Microsoft Azure and Google Cloud Platform every year. One of our key strengths is our dedication to understanding your unique environment and cloud maturity level to tailor our approach to support your overall cloud strategy.

Connect with our team via our 24x7 security hotlines or contact page.