Outplay Your Adversary: Red Teaming Tactics for AWS, Azure, and GCP

Introduction

The rapid shift to cloud services like AWS, Azure, and GCP has transformed the way organizations operate, offering unparalleled scalability, flexibility, and cost-effectiveness. However, these benefits come with significant security challenges. Traditional security models, which rely heavily on perimeter defenses, are inadequate in the dynamic and distributed nature of cloud environments.

To effectively counter these evolving threats, organizations must adopt an adversarial mindset. Red teaming — emulating the tactics, techniques, and procedures (TTPs) of sophisticated attackers — provides a critical approach for identifying and mitigating vulnerabilities within cloud environments before they can be exploited.

This blog will explore advanced red teaming tactics tailored specifically for AWS, Azure, and GCP. By adopting an attacker’s perspective, we will examine how to systematically breach, exploit, and maintain persistence in these cloud environments, outplaying your adversaries.

Understanding the Cloud Attack Surface

The Complexity of Cloud Environments

Cloud environments are inherently complex, consisting of numerous interconnected services, resources, and configurations that vary across platforms like AWS, Azure, and GCP. Understanding the attack surface in these environments is crucial for identifying potential vulnerabilities and crafting effective attack strategies.

Key Attack Vectors in Cloud Environments

• Identity and Access Management (IAM): IAM controls who can access what within a cloud environment. Misconfigured IAM roles, policies, or overly permissive permissions can lead to unauthorized access and privilege escalation.
• Network Security: Cloud environments use virtual networks to segment resources. Misconfigured network security groups, firewall rules, or open ports can expose critical resources to attackers.
• Data Storage: Services like S3 buckets (AWS), Azure Blob storage, and GCP Cloud Storage are often targeted due to misconfigurations that make them publicly accessible.
• API Endpoints: Cloud environments rely heavily on APIs for communication between services. Exposed or unsecured API endpoints can be exploited to interact with backend systems or extract sensitive data.
• Identity Management Services: AWS Cognito, Azure AD B2C, and Google Identity Platform are commonly used for authentication and user management. Misconfigurations in these services can lead to unauthorized access or privilege escalation.
• Compute Resources: Virtual machines, containers, and serverless functions are core components of cloud infrastructure. Vulnerabilities in these compute resources can provide attackers with a foothold within the environment.

Understanding these key attack vectors allows red teamers to identify where they are most likely to find weaknesses that can be exploited to gain initial access or move laterally within the cloud environment.

Step 1: Initial Access — Penetrating the Cloud Perimeter

Exploiting Publicly Accessible Resources

Gaining initial access is the first step to outplaying your adversary. One effective method is to exploit publicly accessible resources that have been mistakenly left exposed.

• S3 Buckets (AWS): If public S3 buckets are identified, use the aws s3 cp command to list and download objects. If the bucket has write permissions, upload a payload or a backdoor script to establish a foothold.
• Azure Storage Blobs: Use the Azure CLI or tools like MicroBurst to enumerate and interact with publicly accessible Blob storage. Upload a malicious file if write permissions are available.
• GCP Storage Buckets: In GCP, use the gsutil ls command to list the contents of publicly accessible storage buckets. If you have write access, upload a malicious object or leverage the bucket for data exfiltration.

Exploiting Identity Management Service Misconfigurations

Cloud-based identity management services like AWS Cognito, Azure AD B2C, and Google Identity Platform are used for authentication, authorization, and user management. Misconfigurations in these services can lead to unauthorized access or privilege escalation.

AWS Cognito

• Misconfigured Identity Pools: Identity Pools in Cognito provide temporary AWS credentials to users. If an identity pool is misconfigured to allow unauthenticated access, attackers can obtain AWS credentials and interact with other AWS services.
• Excessive Permissions: Analyze the roles associated with Cognito Identity Pools. If they are overly permissive, attackers can escalate privileges by performing actions beyond the intended scope, such as accessing or modifying sensitive data in other AWS services.
• Improper User Pool Settings: Check for weak settings in Cognito User Pools, such as allowing sign-ups without email verification or weak password policies. These settings can be exploited to create malicious accounts or take over existing accounts.

Azure AD B2C

Azure AD B2C is a cloud identity management service that allows for customer-facing applications to authenticate users.

• Insecure User Flow Configurations: Misconfigured user flows can allow unauthorized access or the ability to bypass multi-factor authentication (MFA). Attackers can manipulate these flows to gain access to sensitive applications or data.
• Weak Identity Providers: Azure AD B2C allows integration with various identity providers. If these providers are not properly secured, they can be exploited to authenticate malicious users. For example, using social logins with weak verification can lead to account takeovers.
• Excessive Claims and Permissions: Analyze the claims issued during the authentication process. If excessive claims are issued, they may grant attackers more access than intended, allowing them to interact with resources beyond their authorization level.

Google Identity Platform

Google Identity Platform provides authentication and user management services for GCP applications.

• Improper OAuth Scopes: Misconfigured OAuth scopes can allow excessive access to user data or GCP resources. Attackers can exploit these scopes to gain unauthorized access to sensitive information.
• Weak Identity Provider Configurations: Similar to Azure AD B2C, Google Identity Platform can integrate with external identity providers. If these providers are not properly secured, attackers can use them to authenticate without proper verification.
• Insecure User Account Settings: Weak password policies or lack of account verification can be exploited to create fraudulent accounts or hijack existing accounts within the Google Identity Platform.

Exploiting Exposed APIs

APIs are integral to cloud environments but can be a significant security risk if not properly secured:

• AWS API Gateway: Test exposed AWS API Gateway endpoints for authentication weaknesses. If an API is unprotected or uses weak authentication, leverage it to interact with backend services.
• Azure API Management: Use tools like Postman or Burp Suite to test Azure APIs for misconfigurations. Look for endpoints that may expose sensitive data or allow unauthorized access.
• GCP Endpoints: Enumerate and test GCP API endpoints for flaws. Focus on APIs that control critical resources, such as Cloud Functions or App Engine services, and attempt to manipulate them for unauthorized actions.

Exploiting Weak IAM Credentials

Weak or default IAM credentials can serve as a direct entry point into the environment:

• Password Spraying: Perform password spraying against IAM accounts across AWS, Azure, and GCP. Target accounts with common or weak passwords, focusing on services like AWS IAM, Azure AD, and GCP IAM.
• Compromised API Keys: Search code repositories, public files, or exposed metadata services for API keys and secrets. Use these keys to authenticate against cloud services and gain access to critical resources.

Phishing and Social Engineering

Phishing remains one of the most effective methods to gain initial access, particularly in environments with well-secured perimeters:

• Crafting Phishing Emails: Use reconnaissance information to craft convincing phishing emails targeting cloud administrators or developers. A successful phishing attack can provide credentials or tokens that allow direct access to cloud resources.
• Leveraging OAuth Tokens: If OAuth tokens are used within the environment, target them through phishing campaigns. Compromised OAuth tokens can be used to impersonate users and access cloud services.

Step 2: Lateral Movement — Expanding Control Across the Cloud

Exploiting Interconnected Services

Once inside the environment, the focus shifts to lateral movement — expanding control by exploiting the interconnections between cloud services.

• Cross-Service Pivoting (AWS): In AWS, use the compromised IAM role or API keys to access other services like S3, RDS, or DynamoDB. For example, after compromising an EC2 instance, use its attached IAM role to query S3 buckets or interact with Lambda functions.
• Azure Service Dependencies: In Azure, pivot through services by exploiting managed identities. If you compromise a VM, use its managed identity to access Key Vault secrets, which could provide credentials for other services.
• GCP Service Accounts: In GCP, leverage compromised service accounts to access additional resources like Cloud Storage, BigQuery, or Cloud SQL. Use the gcloud CLI to impersonate the service account and move laterally within the environment.

Privilege Escalation

Privilege escalation is critical for gaining full control over the cloud environment:

• IAM Role Escalation (AWS): Identify and exploit overly permissive IAM roles that allow privilege escalation. For example, if an IAM role can create or attach policies, use it to grant yourself administrative privileges.
• Azure RBAC Misconfigurations: In Azure, look for misconfigured RBAC roles that allow role assignments or access to sensitive resources. Escalate privileges by assigning yourself to higher-privileged roles.
• GCP IAM Privileges: Exploit GCP IAM policies that allow privilege escalation. If a service account has roles like Owner or Editor, it can be used to modify IAM policies or access sensitive resources.

Data Exfiltration

As you move laterally, begin exfiltrating valuable data to demonstrate the impact of the breach:

• S3 to EC2 Data Transfer (AWS): Transfer sensitive data from S3 buckets to a compromised EC2 instance, then exfiltrate it via a stealthy outbound connection.
• Azure Storage Exfiltration: In Azure, use compromised VMs to copy data from storage accounts or databases, then exfiltrate it through less monitored regions or endpoints.
• GCP Data Access: Leverage compromised GCP services to access and exfiltrate data from Cloud Storage, BigQuery, or Cloud Spanner. Use encrypted channels to avoid detection.

Step 3: Persistence — Securing Long-Term Access

Creating Stealthy Backdoors

Persistence is essential for maintaining long-term access to the environment without detection:

• Deploying IAM Backdoors: Create new IAM users or roles with minimal privileges that can be escalated later. For example, in AWS, create a low-privilege IAM role in an unused region, while in Azure, create a hidden service principal.
• Modifying Cloud Functions: In AWS, modify Lambda functions to include your payloads, or create new ones that periodically check in with your command and control server. In Azure, modify Logic Apps or Functions, while in GCP, tamper with Cloud Functions.
• Evading Detection: To avoid detection, manipulate logging services like CloudTrail (AWS), Azure Monitor, or Stackdriver (GCP). Disable or modify logs in regions that are less monitored, and carefully clean up traces of your activities.

Maintaining Stealth

To ensure your presence remains undetected, it’s crucial to cover your tracks:

• Log Manipulation: Modify or delete logs that could reveal your activities. In AWS, tamper with CloudTrail logs, while in Azure, modify diagnostic logs, and in GCP, adjust Stackdriver logs. Focus on high-risk activities that might draw attention.
• Stealth Communication: Establish encrypted communication channels that blend in with normal traffic patterns. Avoid using large data transfers or sudden spikes in activity, as these are likely to trigger security alerts.
• Anomaly Avoidance: Mimic legitimate traffic patterns and behaviors to avoid raising suspicions. For instance, schedule your activities during normal business hours and spread out your actions to avoid generating large amounts of unusual activity.

Cross-Cloud Attack Strategies

The Challenge of Multi-Cloud Environments

Many organizations today use a combination of AWS, Azure, and GCP in a multi-cloud strategy. While this approach offers flexibility and redundancy, it also presents unique challenges from a security perspective. Attackers must be adept at navigating and exploiting different cloud environments, often pivoting between them to achieve their objectives.

Cross-Cloud Reconnaissance and Initial Access

• Multi-Cloud Enumeration: Begin by identifying assets across all cloud environments. Use the AWS CLI, Azure CLI, and GCP’s gcloud to enumerate resources. Automate this process using scripts that can aggregate data across platforms to provide a unified view.
• API Key Discovery: Search for API keys, tokens, or credentials that may be valid across multiple cloud environments. For instance, a compromised AWS API key might be reused in GCP or Azure if the organization follows similar practices across clouds.
• Cross-Cloud Phishing: Craft phishing campaigns that target users with access to multiple cloud environments. Compromised credentials can then be used to breach multiple platforms simultaneously.

Pivoting Between Clouds

• Exploiting Cloud Interconnectivity: Many organizations set up direct connections between their cloud environments, such as AWS Direct Connect, Azure ExpressRoute, or GCP’s Interconnect. Exploit these connections to move laterally between clouds. For example, compromise a resource in AWS and use it as a springboard to access connected resources in Azure or GCP.
• Leveraging Multi-Cloud Services: Some services, like identity providers or CI/CD pipelines, are used across multiple clouds. Compromising these services can give you access to all associated cloud environments. For instance, compromising an Azure Active Directory (AAD) account that is used to manage resources in both Azure and AWS can give you access to both environments.

Multi-Cloud Persistence

• Distributed Backdoors: Create backdoors across multiple cloud environments to ensure persistence. For example, set up IAM roles in AWS, service principals in Azure, and service accounts in GCP. These backdoors should be low-privilege and located in less-monitored areas to avoid detection.
• Cross-Cloud Data Exfiltration: Exfiltrate data from one cloud environment to another to evade detection. For instance, exfiltrate data from an Azure storage account to a GCP storage bucket before moving it offsite. This cross-cloud data movement can make it harder for defenders to track and stop the exfiltration.

Thanks, everyone for reading

If you found this informative, do not forget to clap👏 and do let me know if you have any doubts

Support me if you like my work! Buy me a coffee

Follow me on Twitter, LinkedIn, GitHub