Case Study Technology ·Australia · June 20, 2025

AWS Security Assessment: Uncovering Critical Misconfigurations in a Sydney IT Firm

A Sydney-based managed IT services provider commissioned an AWS security assessment ahead of their ISO 27001 certification audit. CyberneticsPlus discovered 31 findings including a publicly readable S3 bucket containing client backup data.

31

Vulnerabilities Found

3

Critical Findings

ISO 27001

Certification Achieved

Cloud Security AssessmentAWS SecurityCompliance Support

Background

A Sydney-based managed IT services provider (MSP) serving 80+ SME clients across New South Wales engaged CyberneticsPlus for an AWS security assessment. The driver was their ISO 27001 certification project — their certifying body had recommended a cloud security assessment as part of the Annex A.8 technical controls evidence.

The MSP managed client data in AWS across 3 AWS accounts:

  • Production: hosting client backups, monitoring data, and managed service tooling
  • Staging: replica of production for testing
  • Shared services: central logging, billing, and identity management

All three accounts were in scope for the assessment.

Assessment Scope and Approach

Assessment type: White-box (full access to IAM credentials with read permissions across all accounts)

Coverage:

  • IAM configuration (users, roles, policies, trust relationships)
  • S3 buckets (all 34 buckets across 3 accounts)
  • EC2 instances and security groups
  • RDS databases
  • VPC networking (subnets, NACLs, security groups)
  • CloudTrail and logging configuration
  • GuardDuty and Security Hub status

Tools used: Prowler, ScoutSuite, custom IAM analysis scripts, manual review

Critical Findings

Critical 1: Public S3 Bucket with Client Backup Data

Finding: The S3 bucket mspcorp-client-backups-prod was publicly readable. The bucket contained encrypted VM backups for 14 client organisations, including backup metadata files that revealed client company names, server names, IP addresses, and backup schedules — in plaintext.

The bucket had been created 18 months earlier with a public ACL set for a brief period (the administrator believed they had removed it). While the ACL was removed, a bucket policy added by a third-party backup tool had granted s3:GetObject to "Principal": "*".

Data exposed:

  • 847 GB of encrypted backup files
  • 14 unencrypted metadata files containing client infrastructure details
  • Directory listings revealing client organisation names and server counts

Risk: The encrypted backup files required client-specific decryption keys (not exposed). However, the metadata files containing client names and infrastructure details represented a significant confidentiality breach — this information could be used for targeted attacks against the MSP’s clients.

Immediate action: Bucket policy updated within 4 hours of finding notification. Block public access enabled at account level. Metadata files reviewed — no decryption keys or credentials present.

Notification: MSP’s legal team assessed the need for client notification under Australian Privacy Act (APPs). Determined that encrypted backup files with no exposed credentials did not meet the threshold for mandatory notification. Metadata exposure documented and incident report filed.

Critical 2: IAM User with AdministratorAccess and Exposed Access Keys

Finding: An IAM user terraform-deploy had AdministratorAccess managed policy attached. The access keys for this user were active and had last been used 6 months earlier. Investigation showed the keys had been committed to a private GitHub repository (now rotated after our notification, but git history retained them).

Risk: The keys, if discovered by a threat actor via repository scanning (a common automated attack), would provide full administrative access to all three AWS accounts — including access to client backup data.

Remediation:

  • Access keys immediately deactivated
  • IAM role with scoped permissions created for Terraform (using OIDC federation with GitHub Actions)
  • AdministratorAccess removed from all non-human IAM users
  • GitHub repository history scrubbed using git-filter-repo

Critical 3: GuardDuty Disabled in 2 of 3 Accounts

Finding: GuardDuty was enabled only in the production account. The staging and shared-services accounts had GuardDuty disabled. The shared-services account contained the central IAM and billing infrastructure — its compromise would affect all accounts.

Risk: No threat detection capability in two of three accounts. The shared-services account, which held the most sensitive access (cross-account roles, billing), was completely unmonitored.

Remediation: GuardDuty enabled in all three accounts. AWS Organizations-based delegated administrator configured so findings aggregated to a central security account.

High Findings (12 Identified)

  • CloudTrail not enabled in 4 regions across the staging and shared-services accounts
  • 6 security groups with port 22 open to 0.0.0.0/0
  • 3 RDS instances not encrypted at rest
  • IMDSv2 not enforced on EC2 instances (IMDSv1 allowed)
  • No MFA enforcement on IAM users (8 IAM users without MFA)
  • Access keys older than 180 days not rotated (12 keys identified)
  • VPC Flow Logs not enabled on any VPC in staging or shared-services accounts

Medium Findings (16 Identified)

  • Missing resource tags (cost allocation and ownership)
  • S3 versioning not enabled on backup buckets (prevents ransomware deletion)
  • CloudWatch alarms not configured for security-relevant events
  • Unused IAM roles (14 roles with no activity in 90+ days)
  • No SCP (Service Control Policy) preventing security service deletion
  • IAM password policy not meeting minimum requirements (no complexity, no rotation)

Remediation and Certification Outcome

CyberneticsPlus worked alongside the client’s DevOps team over 6 weeks to remediate findings:

Week 1–2: Critical findings resolved Week 3–4: High findings resolved Week 5–6: Medium findings resolved, security controls documentation prepared for ISO 27001 audit

ISO 27001 audit outcome: The certification audit (conducted by a BSI-accredited body) covered the cloud security controls in Annex A.8. The auditors reviewed:

  • CyberneticsPlus penetration test report
  • Remediation evidence (screenshots, configuration exports)
  • Updated cloud security policies and procedures

Result: ISO 27001:2022 certification granted — the cloud security work was cited as evidence of effective technical control implementation.

The MSP has since established quarterly cloud security reviews as part of their ISMS (Information Security Management System) surveillance process, with CyberneticsPlus conducting annual assessments.

A

Anonymous

Technology · Australia

Want similar results for your business?

Book a free consultation and we'll assess your current security posture.

Book a Free Consultation