Kishin's Blog
← Back to all posts
10 min readKishin

Cloud Security Misconfigurations: The #1 Threat to Your AWS/Azure Environment

SecurityCloud Security

The cloud security landscape has a clear villain: misconfiguration. According to Gartner, through 2025, 99% of cloud security failures will be the customer's fault, and the majority of those failures will stem from misconfigured resources. The problem is not a lack of security features from cloud providers: AWS, Azure, and GCP offer comprehensive security controls. The problem is that organizations fail to use them correctly.

This article catalogs the most common and dangerous cloud misconfigurations, explains how attackers exploit them, and provides a practical roadmap for detection and remediation.

Publicly Exposed Storage

Exposed cloud storage is the single most common cause of data breaches involving cloud infrastructure. S3 buckets and Azure Blob containers have been at the center of some of the largest data exposures in history, affecting billions of records.

S3 Buckets

AWS S3 buckets are private by default, but misconfigurations quickly change that. Common causes include:

  • ACL grants to "Everyone": Access Control Lists that grant read or write access to "Authenticated Users" or "All Users." Note that "Authenticated Users" means any authenticated AWS account, not just yours.
  • Bucket policies with wildcard principals: Policies that specify "Principal": "*" effectively make the bucket publicly accessible.
  • Block Public Access disabled: AWS introduced the S3 Block Public Access feature specifically to prevent accidental exposure, but organizations disable it for legitimate use cases and forget to re-enable it.
  • Public access via access points: S3 access points can inherit or override the bucket's public access settings, creating exposure through a less obvious vector.

Remediation: Enable S3 Block Public Access at the account level. Use SCPs (Service Control Policies) in AWS Organizations to prevent any account from disabling Block Public Access. Audit bucket policies and ACLs regularly. Use AWS Config rules to detect and alert on public buckets.

Azure Blob Storage

Azure Blob storage containers can be configured with anonymous read access at the container or blob level. Common misconfigurations include:

  • Setting the container access level to "Blob" or "Container" during testing and never reverting to "Private."
  • Shared access signatures (SAS) tokens with overly broad permissions and long expiration dates that are accidentally published in code repositories.
  • Storage account firewall rules that allow access from all networks instead of restricting to specific VNets or IP ranges.

Overly Permissive IAM Policies and Roles

Identity and Access Management (IAM) is the foundation of cloud security, and it is where the most critical misconfigurations occur. The principle of least privilege is well understood in theory but rarely enforced in practice.

  • Wildcard permissions: Policies that grant "Action": "*" or "Resource": "*" give users or roles unrestricted access to every service and resource in the account. This violates the principle of least privilege in the most fundamental way.
  • Admin roles for routine tasks: Assigning AdministratorAccess to developers, CI/CD pipelines, or service accounts because it is "easier" than creating scoped policies. Every overly privileged identity is a high-value target for attackers.
  • Cross-account role assumptions: Roles that can be assumed by external accounts without proper trust policies enable lateral movement across organizational boundaries.
  • Stale credentials: Unused access keys, forgotten service accounts, and orphaned roles persist indefinitely if not actively managed. These dormant identities are frequently exploited in breaches.
  • IAM user long-term credentials: Using IAM users with static access keys instead of IAM roles with temporary credentials increases the risk of credential leakage.

Remediation: Implement IAM Access Analyzer to identify policies that grant external access. Use permission boundaries to cap the maximum permissions any role can have. Enforce temporary credentials through IAM roles and SSO. Rotate and remove unused credentials on a regular schedule. Use policy conditions to restrict access by IP range, time of day, or MFA status.

Unrestricted Security Groups

Security groups act as virtual firewalls for EC2 instances and other cloud resources. The most dangerous misconfiguration is allowing inbound traffic from 0.0.0.0/0 (the entire internet) on sensitive ports.

  • SSH (port 22) open to the world: Exposes servers to brute-force attacks. If the SSH key is compromised or a vulnerability is discovered in the SSH daemon, the instance is immediately accessible to any attacker on the internet.
  • RDP (port 3389) open to the world: The equivalent risk for Windows instances. RDP is one of the most targeted services for initial access by ransomware operators.
  • Database ports (3306, 5432, 1433, 27017) open: Exposing database ports to the internet allows attackers to attempt authentication directly against the database, bypassing application-layer controls.
  • All ports open: Some security groups allow all TCP and UDP traffic from any source, providing no network-level protection at all.

Remediation: Restrict security group rules to specific source IP ranges or other security groups. Use bastion hosts or VPN for SSH/RDP access. Deploy databases in private subnets with no internet gateway route. Use VPC flow logs to detect unauthorized access attempts. Implement automated compliance checks that flag security groups with 0.0.0.0/0 on sensitive ports.

Disabled Logging

Logging is not just a compliance requirement: it is the foundation of security visibility. Cloud environments with disabled logging are blind to attacks.

  • CloudTrail disabled: AWS CloudTrail records all API calls in your account. Without it, you have no audit trail of who did what, when, and from where. Many organizations enable CloudTrail but fail to enable it in all regions or fail to enable multi-region trails.
  • VPC Flow Logs disabled: Without flow logs, you cannot detect unusual network traffic patterns, port scanning, or data exfiltration attempts.
  • S3 access logging disabled: Without server access logs, you cannot determine who accessed objects in your S3 buckets.
  • Azure Monitor / Activity Logs disabled: Azure Activity Logs provide the equivalent of CloudTrail for Azure. Organizations that fail to configure diagnostic settings lose visibility into control plane operations.
  • No log integrity protection: CloudTrail logs should be stored in a dedicated S3 bucket with Object Lock enabled to prevent tampering. Without integrity protection, an attacker who compromises the account can delete their tracks.

Remediation: Enable CloudTrail in all regions with log file validation. Ship logs to a centralized, hardened logging account with cross-account access restrictions. Enable VPC Flow Logs for all VPCs. Configure Azure Monitor diagnostic settings for all subscriptions. Use log aggregation tools (Splunk, Datadog, ELK) for centralized analysis and alerting.

Unencrypted Data at Rest and in Transit

Cloud providers offer encryption capabilities that are often free and straightforward to enable, yet many organizations fail to use them.

  • S3 default encryption not enabled: While AWS now enables S3 default encryption for new buckets, existing buckets created before this change may lack encryption. Server-side encryption with SSE-S3 or SSE-KMS should be enforced on every bucket.
  • EBS volumes unencrypted: Elastic Block Store volumes attached to EC2 instances may contain sensitive data. Enable EBS encryption by default at the account level.
  • RDS instances unencrypted: RDS database instances must be encrypted at creation: encryption cannot be added to an existing unencrypted instance without migration. Always create RDS instances with encryption enabled.
  • TLS not enforced: Load balancers, API endpoints, and internal services should enforce TLS 1.2 or higher. Use ACM (AWS Certificate Manager) or Azure Key Vault for certificate management. Reject connections that attempt to downgrade to plaintext HTTP.

Default Credentials on Cloud Databases

Cloud-managed databases (RDS, Azure SQL, Cloud SQL) are often deployed with default master passwords, weak passwords, or passwords that were set during initial provisioning and never changed. If the database is exposed to the network (which happens more often than it should) these credentials provide immediate access.

Remediation: Use IAM database authentication where supported. Rotate database credentials regularly using AWS Secrets Manager or Azure Key Vault. Enforce strong password policies through automation. Never hardcode database credentials in application code or infrastructure templates.

Publicly Accessible Management Consoles

Cloud management consoles and administrative interfaces should never be exposed to the public internet without additional protections.

  • Azure Portal without conditional access: Without conditional access policies, any user with valid credentials can access the Azure Portal from any location. Restrict access to trusted locations and require MFA.
  • AWS Console without MFA: Root and IAM user accounts without MFA enabled are vulnerable to credential stuffing attacks. Enforce MFA on all console access.
  • Kubernetes dashboards exposed: The Kubernetes dashboard, when deployed with default settings, often allows unauthenticated access. Restrict dashboard access to the internal network or use OIDC-based authentication.

Missing MFA on Root and Admin Accounts

The root account in AWS and the Global Administrator role in Azure are the most powerful identities in your cloud environment. Compromising one of these accounts gives an attacker complete control over every resource.

Yet many organizations fail to enable MFA on root accounts, or they enable MFA but use SMS-based MFA, which is vulnerable to SIM swapping. Some organizations share root account credentials among team members, making it impossible to attribute actions to individuals.

Remediation: Enable hardware MFA (FIDO2) on all root and admin accounts. Store root account credentials in a physical safe with access logging. Use break-glass procedures for root access and log every use. Implement AWS Organizations with SCPs that restrict what root accounts can do. Use Azure Privileged Identity Management (PIM) for just-in-time admin access.

Cross-Account Access Misconfigurations

In multi-account architectures, cross-account role assumptions are common for legitimate purposes: centralized logging, CI/CD deployments, shared services. However, misconfigured trust policies can allow unauthorized accounts to assume roles.

  • External ID not enforced: Cross-account role trust policies should require an External ID to prevent the "confused deputy" attack, where an attacker tricks a service into assuming a role on your behalf.
  • Trust policies accepting any account: Trust policies that allow any AWS account to assume a role effectively make that role accessible to every AWS user on the planet.
  • Overly broad Azure service principals: Azure service principals (app registrations) with excessive API permissions can be exploited if the application's credentials are compromised.

Detection Tools

Several tools can help identify cloud misconfigurations before attackers do:

  • AWS Config: Continuously evaluates resource configurations against compliance rules. Provides managed rules for common misconfigurations and supports custom rules.
  • Azure Policy: Enforces organizational standards and assesses compliance at scale across Azure subscriptions and management groups.
  • ScoutSuite: An open-source multi-cloud security auditing tool that provides a comprehensive security posture assessment across AWS, Azure, and GCP.
  • Prowler: An AWS security assessment tool that checks against CIS Benchmarks and provides hundreds of additional security checks.
  • CloudSploit / Aqua Security: Cloud security posture management (CSPM) tools that provide continuous monitoring and alerting.
  • AWS Security Hub: Aggregates findings from multiple AWS security services and third-party tools into a single dashboard.

Hardening Frameworks

The CIS (Center for Internet Security) Benchmarks provide detailed, consensus-based configuration guidelines for AWS, Azure, and GCP. Implementing the CIS Benchmark controls gives your organization a strong security baseline.

Key CIS controls for cloud environments include:

  • Ensuring CloudTrail is enabled in all regions.
  • Ensuring S3 buckets are not publicly accessible.
  • Ensuring IAM policies are attached to groups or roles, not individual users.
  • Ensuring no security groups allow ingress from 0.0.0.0/0 to sensitive ports.
  • Ensuring MFA is enabled for all IAM users with console access.
  • Ensuring rotation is enabled for customer-managed KMS keys.

Continuous Compliance Monitoring

Cloud environments change constantly. A configuration that is secure today may be misconfigured tomorrow when a developer creates a new resource or modifies a policy. Continuous compliance monitoring is essential.

  • Integrate cloud security posture management (CSPM) tools into your CI/CD pipeline to detect misconfigurations before deployment.
  • Use infrastructure-as-code scanning tools (Checkov, tfsec, cfn-nag) to validate Terraform, CloudFormation, and ARM templates before provisioning.
  • Implement automated remediation for common misconfigurations: for example, automatically blocking public access on newly created S3 buckets.
  • Conduct regular cloud security assessments that go beyond automated scanning to evaluate architectural decisions, trust relationships, and business logic.
  • Establish a cloud security center of excellence that defines standards, reviews architectures, and provides guidance to development teams.

Automated scanning is a fine starting point for a cloud security review, but it's still a starting point. The misconfigurations that actually get exploited are usually the ones that required understanding how three separate services interacted, not just checking a single resource against a rule.