Cloud Security: attack surfaces & hardening

Cloud Security encompasses the techniques, controls, and threat models specific to cloud environments. Attack surfaces in cloud security differ fundamentally from on-premises infrastructure. Instead of network perimeters, the primary exposure points are identity and access management (IAM) policies, misconfigured storage buckets, overly permissive service accounts, and insecure API endpoints. Cloud providers such as AWS, Azure, and GCP operate under a shared responsibility model. The provider secures the underlying infrastructure. The customer is responsible for securing workloads, identities, and data. Misunderstanding this boundary is a leading cause of breaches. Key threat vectors include public S3 buckets, excessive IAM permissions granted to compute instances, exposed metadata endpoints (such as the EC2 Instance Metadata Service), and insecure serverless function configurations. Container orchestration platforms like Kubernetes introduce additional attack surface through misconfigured RBAC policies and exposed API servers. Cloud-native threats also include credential harvesting from environment variables, cross-tenant data leakage, and abuse of cloud-managed services. Understanding these mechanics is essential for both offensive and defensive practitioners operating in modern hybrid and multi-cloud architectures.

Detecting threats in cloud environments requires visibility across control plane logs, data plane activity, and identity events. On AWS, CloudTrail logs record all API calls. Analysts should alert on events such as CreateAccessKey, AttachUserPolicy, PutBucketPolicy with public ACLs, and GetCallerIdentity called from unusual IP ranges. AWS GuardDuty automates anomaly detection on CloudTrail and VPC Flow Logs. On Azure, Unified Audit Logs and Microsoft Defender for Cloud surface events like role assignment changes, guest user invitations, and suspicious sign-in patterns flagged by Azure AD Identity Protection. On GCP, Cloud Audit Logs track Admin Activity and Data Access separately. Key indicators of compromise include access key usage from Tor exit nodes, sudden spikes in data egress, enumeration of IAM permissions via iam:SimulateCustomPolicy, and disabling of logging services. CSPM tools like Wiz, Orca Security, or Prisma Cloud provide continuous posture assessment. They detect drift from baseline configurations, such as security groups open to 0.0.0.0/0 or unencrypted EBS snapshots shared publicly. Integrating cloud logs into a SIEM with correlation rules tuned to cloud-specific TTPs (mapped to MITRE ATT&CK for Cloud) significantly reduces mean time to detect.

Red Team operations in cloud environments focus on three primary objectives: initial access, privilege escalation, and data exfiltration. Initial access typically involves harvesting credentials from public code repositories, exploiting SSRF vulnerabilities to query instance metadata endpoints (IMDSv1 on AWS returns IAM role credentials without authentication), or phishing cloud console users. Tools like Pacu (AWS exploitation framework) and ROADtools (Azure AD enumeration) automate reconnaissance and privilege escalation paths. A common escalation chain on AWS involves a low-privilege IAM user with iam:PassRole and ec2:RunInstances permissions. This combination allows attaching a high-privilege role to a new instance and retrieving its credentials. On Azure, abusing Managed Identities or exploiting Contributor-level access to deploy a malicious runbook in Azure Automation achieves similar results. Hardening measures include enforcing IMDSv2 on all EC2 instances, applying least-privilege IAM policies with AWS IAM Access Analyzer, enabling MFA for all console and API access, and using SCPs (Service Control Policies) in AWS Organizations to restrict dangerous actions at the organizational level. Rotating credentials regularly, enabling CloudTrail log integrity validation, and running automated CSPM scans on every infrastructure-as-code change are baseline requirements for a mature cloud security posture.