Cloud Pentest Malaysia — AWS, Azure & GCP Security Testing

The shared-responsibility model — what is in scope

The cloud shared-responsibility model is the starting point for every cloud-pentest scoping conversation. The provider (AWS, Microsoft, Google) is responsible for security of the cloud — the underlying physical infrastructure, the hypervisor, the global network. The customer is responsible for security in the cloud — IAM configuration, network architecture, application code, OS hardening, data classification and encryption. A cloud pentest tests customer responsibilities, not provider responsibilities.

This matters for two reasons. First, scoping discipline: the engagement scope must enumerate which accounts, subscriptions or projects are in scope, which IAM principals can be tested, which production data may be enumerated, and the exact boundaries beyond which we do not cross. Second, vendor terms of service: AWS, Azure and GCP each publish acceptable-use policies for security testing — most testing types no longer require pre-approval, but several still do (heavy stress testing, anything resembling DDoS). We work to the published policies and document compliance in the engagement letter.

AWS-specific attack patterns

The AWS attack surface in 2026 still revolves around the same handful of misconfiguration classes that dominated the 2018-2024 caseload, evolved with newer services:

• S3 misconfigurations: Public-read or public-write buckets, public-list ACLs, bucket policies with overly broad principals, missing block-public-access at account level. Despite years of vendor messaging and S3 Block Public Access defaults, we still find sensitive S3 buckets exposed in nearly every Malaysian engagement that scopes S3 broadly.
• IAM privilege escalation: The Rhino Security Labs catalogue of IAM privilege-escalation paths remains the canonical reference — iam:CreateAccessKey on a higher-privilege user, iam:PassRole combined with service-creating permissions, lambda:UpdateFunctionCode on a high-privilege Lambda. Pacu automates the enumeration; manual chaining is faster on focused engagements.
• Lambda environment-variable leaks: Lambda function environment variables routinely contain database credentials, API keys and signing secrets. A read-only IAM principal with lambda:GetFunctionConfiguration walks the lot.
• EC2 IMDSv1 risks: Instances still running IMDSv1 are vulnerable to SSRF-to-instance-credentials attacks. Enforcing IMDSv2 cluster-wide is the fix; we still find IMDSv1 enabled on a meaningful share of production EC2 fleets.
• VPC misconfiguration: Overly permissive security groups, public RDS instances, missing VPC endpoints causing internal traffic to traverse the public internet.
• CloudTrail tampering: The forensic-evidence concern — attacker disables CloudTrail, modifies the S3 destination, or moves to a region where CloudTrail is not enabled. Multi-region trail with log-file validation is the baseline.

Azure-specific attack patterns

Azure's attack surface differs materially because so much of Azure is fronted by Entra ID (formerly Azure AD), which sits at the boundary between cloud and on-premises identity:

• Storage Account public access: The Azure equivalent of S3 misconfiguration — public-blob containers, anonymous-access enabled at the account, SAS tokens leaked into source repos with overly broad permissions and long expiry.
• Managed Identity overscope: User-assigned and system-assigned managed identities granted broader Azure RBAC roles than the workload requires. Combined with SSRF or container-escape, the managed identity walks the subscription.
• AAD Conditional Access bypass: Conditional Access policies have a long history of bypass techniques — legacy authentication protocols (POP, IMAP, SMTP-AUTH) that ignore Conditional Access, device-compliance rules that can be spoofed, named-location bypasses through trusted IP ranges that turn out to include attacker-accessible space.
• Service Principal abuse: Application service principals with high-privilege Microsoft Graph permissions (Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All) are persistent backdoors if compromised. Periodic review of service-principal permissions is essential.
• Azure DevOps and pipeline attacks: Build pipelines with broad service-connection scopes can be hijacked via pull-request workflows or branch-protection bypasses to mint cloud credentials.
• Hybrid identity: The on-premises AD Connect / sync account is one of the most sensitive principals in any hybrid environment. Compromise collapses the on-prem and cloud identity boundary.

GCP-specific attack patterns

GCP is the smallest of the three in Malaysian enterprise deployment but the share is growing. The attack patterns:

• IAM role attacks: GCP IAM is project-, folder- and organisation-scoped. Misallocated roles at folder level cascade across all child projects. iam.serviceAccounts.actAs is the equivalent of AWS iam:PassRole — combined with service-creating permissions, it grants the holder execution-as-any-service-account.
• GCS bucket exposure: The GCP equivalent of S3 misconfiguration; allUsers and allAuthenticatedUsers IAM bindings on buckets are the public-access pattern.
• Cloud Function injection: Cloud Functions and Cloud Run deployments with weak input validation, often executing with broad service-account permissions.
• Workload Identity Federation gaps: WIF removes long-lived service-account keys but introduces its own misconfiguration class — overly permissive identity-pool bindings, audience claims that allow cross-tenant token reuse.
• Compute Metadata abuse: Equivalent to AWS IMDS — SSRF against the GCP metadata server (metadata.google.com or 169.254.169.254) returns service-account tokens. Defending requires the equivalent of IMDSv2 — metadata-flavor header enforcement.

Tooling — ScoutSuite, Prowler, Pacu, ROADtools

The cloud-pentest toolchain is open-source-led; we layer commercial tooling for specific needs:

• ScoutSuite (NCC Group) — multi-cloud configuration auditor (AWS, Azure, GCP, Alibaba, Oracle). Read-only enumeration, HTML report. The first tool we run on any cloud pentest to establish baseline posture.
• Prowler — AWS-focused security assessment, also covers Azure and GCP. Maps findings to CIS Benchmarks, NIST and ISO 27001. Excellent for evidence-gathering against compliance frameworks.
• Pacu (Rhino Security Labs) — AWS exploitation framework. Modular attack chains across enumeration, privilege escalation, persistence and exfiltration. Read-only enumeration is the safe default; exploitation modules require explicit operator action.
• ROADtools — Microsoft Entra ID enumeration and analysis, the cloud-identity equivalent of BloodHound. AzureHound and BloodHound v6 also cover Entra ID attack-path graphing.
• Stratus Red Team (DataDog) — adversary emulation for cloud, MITRE ATT&CK Cloud Matrix-aligned. Useful for purple-team validation that detection actually fires.
• CloudFox — situational-awareness tool for AWS and Azure, designed for offensive engagements. Quickly enumerates ‘what can I do with these credentials’.

BNM RMiT cloud guidance

BNM's position on cloud has evolved materially. The Risk Management in Technology Policy Document and accompanying papers set explicit expectations for licensed financial institutions adopting cloud — material outsourcing controls, data-localisation considerations, exit-strategy requirements, and continuous control validation. Cloud pentesting is now a mainstream line-item in the annual pentest scope for any FI with material cloud workloads. Examiners will look for evidence of:

• Documented shared-responsibility split per cloud provider in use
• Periodic configuration assessment (typically continuous via CSPM tooling, validated by annual pentest)
• IAM privilege-escalation testing
• Data-classification and encryption controls validated under test
• Exit-strategy testing — can workloads be repatriated within the documented timeframe

The pentest scope must explicitly enumerate cloud accounts/subscriptions/projects in scope and the IAM principals authorised for testing. Generic ‘cloud pentest’ scoping language fails examiner scrutiny. See our cloud penetration testing service and our Active Directory security assessment for the on-premises identity foundation that most cloud environments still anchor to.

Engagement structure for a Malaysian enterprise

A typical Malaysian enterprise cloud pentest is a 3-4 week engagement structured in three blocks: read-only configuration assessment via ScoutSuite/Prowler (week 1), authenticated assessment from a representative IAM principal with privilege-escalation enumeration via Pacu/ROADtools (week 2-3), targeted exploitation against the highest-impact paths with customer SOC observation for purple-team validation (week 3-4). Deliverable maps to RMiT clauses, ISO 27001 Annex A controls, and CIS Cloud benchmarks.

For execution: see our cloud penetration testing service, Active Directory security assessment, and our RMiT compliance practice.