A full-spectrum AWS infrastructure security assessment of CloudReach SaaS — a B2B cloud-native platform running across a 5-account AWS organization. We found everything from public S3 buckets leaking customer data to a Terraform state file sitting in a public bucket. CIS AWS Foundations compliance: 8%. SOC2 coverage: 10%.
CloudReach SaaS operates a Terraform-managed, multi-account AWS organization serving 340 enterprise B2B customers. Their stack spans S3, RDS, Lambda, ECS, EKS, and VPCs across five AWS accounts. The engagement started with a read-only IAM role handoff — within 2 hours, we had identified customer data leaking from a publicly accessible S3 bucket with no bucket policy.
The most alarming discovery wasn't a single vulnerability — it was the complete absence of detection infrastructure. GuardDuty was not enabled in any AWS region. CloudTrail was missing from two of five accounts. There were no AWS Config rules, no budget alerts, and no VPC flow logs. CloudReach had been running $40,000/month in AWS spend with zero visibility into what was happening inside their own infrastructure.
Across three days of assessment, we mapped every misconfiguration, demonstrated active data exposure from the public S3 bucket, and documented the IAM privilege escalation path from a Lambda execution role to full administrative access via an overprivileged *:* policy. The Terraform state file stored in a public bucket alone would have given any attacker a complete map of the infrastructure.
Every major AWS service in the CloudReach stack had at least one misconfiguration. This is what the infrastructure looked like from an attacker's perspective.
7 Critical, 7 High, 11 Medium. Every finding maps to CIS AWS Foundations Benchmark controls, SOC2 trust criteria, and NIST 800-53 control families.
cloudreach-customer-exports bucket had no bucket policy and was set to public. Any unauthenticated HTTP request could LIST and GET every customer export file — contract PDFs, usage reports, and billing data for 340 enterprise accounts.Enable Block Public Access at the account level (aws s3api put-public-access-block). Add an explicit bucket policy denying s3:GetObject to *. Use S3 Access Points with IAM conditions for application access.
*:* Policy"Effect":"Allow","Action":"*","Resource":"*". Compromise of any of these services — via a dependency vulnerability, SSRF, or RCE — would give an attacker full administrative access to the entire AWS account.Apply least-privilege principles using IAM Access Analyzer to generate service-specific policies based on CloudTrail activity. Replace wildcard actions with exact service actions required. Enable IAM Access Analyzer organization-wide for continuous policy analysis.
all, making them publicly restorable by any AWS customer. The snapshots contained unencrypted production data including customer PII and API credentials.Delete public snapshots immediately. Enable encryption at rest using AWS KMS on all RDS instances (requires a snapshot → restore cycle for existing instances). Set snapshot visibility to private and restrict sharing to specific account IDs only.
0.0.0.0/0 on TCP port 22 (SSH) and 7 security groups allowed 0.0.0.0/0 on TCP port 3389 (RDP). These EC2 instances are exposed to global brute-force and credential-stuffing attacks 24/7.Remove all 0.0.0.0/0 rules on port 22/3389. Use AWS Systems Manager Session Manager for SSH-less EC2 access. If SSH is required, restrict to corporate NAT IP ranges and rotate key pairs quarterly.
Enable hardware MFA on root immediately. Create dedicated IAM admin users for all routine tasks. Set a CloudTrail-based alarm for any root account activity. Lock root credentials in a hardware security key stored in a physical safe.
terraform.tfstate) was stored in the same public S3 bucket as customer exports. Terraform state contains a complete map of all infrastructure: resource IDs, database connection strings, IAM role ARNs, KMS key IDs, and plaintext output values — a full blueprint for targeted attacks.Move Terraform state to a private, encrypted S3 bucket with versioning and DynamoDB state locking. Enable server-side encryption (SSE-KMS). Never store Terraform state in a public bucket. Consider Terraform Cloud or AWS CodePipeline for managed state.
publicly_accessible = true and were reachable from the internet on port 5432. While security groups restricted access, public accessibility combined with any security group misconfiguration creates direct database exposure. Production databases must never be internet-reachable.Set publicly_accessible = false on all RDS instances. Place databases in private subnets with no internet gateway route. Use RDS Proxy for Lambda connections and a bastion host or SSM for administrative access.
cloudreach-dev and cloudreach-staging accounts had no CloudTrail configured. Any API activity — including IAM changes, resource creation, or data access — in these accounts is completely unauditable. Attackers routinely use non-production accounts as lateral movement pivot points precisely because logging is often absent.cloudreach-cicd-role allowed any principal in the partner organization to assume it without an external ID condition. This is a textbook "confused deputy" vulnerability — any compromised account in the trusted organization can assume production deployment roles.lambda:GetFunctionConfiguration access, and are captured in exception reporting and CloudWatch Logs.http://169.254.169.254/latest/meta-data/iam/security-credentials/ and extract temporary IAM credentials — the same technique used in the Capital One breach.From address to verified domains. Any authenticated IAM user (or any compromised Lambda function with SES permissions) could send email appearing to originate from @cloudreach.io — enabling internal spear-phishing attacks against their own enterprise customers.String type parameters (plaintext) rather than SecureString or AWS Secrets Manager. Any IAM user or role with ssm:GetParameter access can read these in plaintext.Three frameworks govern AWS infrastructure security. CloudReach's pre-assessment scores reflect an organization that has never run a formal cloud security review.
A screen-share walkthrough of the CloudReach findings — service by service, finding by finding. Coming soon to the Sentinel Stacks video channel.
Each use case covers a different industry, stack, and threat profile. All findings are realistic and reference-able for sales conversations.
If your team uses S3, IAM, Lambda, RDS, or ECS — your environment may have findings like these. Run a free cloud audit or schedule a full AWS security assessment.