Cloud Penetration Testing in Singapore: What Gets Missed and Why It Matters

Singapore organisations moved to the cloud fast. The pandemic compressed years of cloud migration into months, and security reviews often got skipped or rushed. Now the bills are coming due. Misconfigured IAM policies, exposed storage, overly permissive network rules — these are the findings that show up in almost every cloud engagement we run in Singapore, regardless of organisation size or industry.

The uncomfortable truth is that most "cloud security assessments" in Singapore are configuration reviews dressed up as something more serious. Someone runs a tool against your AWS account, flags what doesn't match a CIS benchmark, and delivers a spreadsheet. Useful? Sure, up to a point. But it won't tell you whether an attacker can chain three low-severity misconfigurations into full production database access. That's what penetration testing is for, and cloud environments need it just as much as on-premise infrastructure ever did.

Why cloud environments need different testing

On-premise penetration testing is relatively straightforward. There's a network perimeter, defined IP ranges, and a clear inside-outside boundary. Cloud doesn't work like that. Your infrastructure is API-driven, globally distributed, and managed through control planes that most security tools weren't designed to assess.

In AWS, the control plane is the attack surface. An attacker doesn't need to exploit a buffer overflow or find an open port if they can assume an IAM role with excessive permissions. In Azure, managed identities and service principals create trust relationships that are invisible to traditional network scanners. GCP's service account key management introduces risks that have no on-premise equivalent.

Cloud penetration testing requires understanding these platform-specific attack surfaces. The methodology, tools, and mindset are different from traditional network testing. A consultant who's excellent at Active Directory exploitation might miss critical cloud findings because they're looking for the wrong things in the wrong places.

What actually gets found

After running cloud penetration tests across Singapore organisations in finance, healthcare, and technology, certain patterns repeat. Here's what we see most often, broken down by platform.

AWS

S3 buckets still get exposed. It's been years since public S3 buckets made headlines, and Singapore organisations still have them. Sometimes it's a legacy bucket that predates the current team. Sometimes someone toggled public access for "just a minute" and forgot. The finding hasn't gone away.

IAM policy misconfigurations are more common and more dangerous. Wildcard actions on production resources, roles that can be assumed by any authenticated AWS user in the same account, inline policies that grant administrator access because someone was in a hurry. We regularly find IAM setups where compromising a single low-privilege Lambda function gives an attacker the ability to create new users, modify security groups, or disable CloudTrail logging.

Security groups with 0.0.0.0/0 ingress rules on management ports. RDP, SSH, database ports open to the internet. Sometimes these are intentional because someone needed remote access and couldn't figure out VPN configuration. Sometimes they're vestigial from a development environment that got promoted to production without cleanup.

Azure

Overly permissive app registrations and enterprise applications are the most common high-severity finding in Azure environments in Singapore. Service principals with directory-level write permissions, app registrations that can modify other applications' credentials, managed identities with contributor access across resource groups they shouldn't touch.

Azure AD (now Entra ID) conditional access policies are often incomplete. MFA required for some users but not others. Legacy authentication protocols enabled because some old application needs them. Guest accounts with more access than permanent employees.

Network Security Groups with allow-all rules buried in the priority list. Someone adds a specific deny rule at priority 200, but there's an allow-all at priority 4096 that was there first and takes precedence for traffic the deny rule doesn't explicitly match.

GCP

Service account key management is the consistent finding. Keys created, downloaded, and never rotated. Keys stored in source code repositories. Service accounts with owner-level permissions because assigning least-privilege roles takes longer and the project deadline was yesterday.

GCP's resource hierarchy (organisation, folder, project) means IAM misconfigurations at higher levels cascade down. An organisation-level policy granting broad access to one team affects every project beneath it. We've found production data accessible through inherited permissions that the project owner didn't even know existed.

Config review vs cloud penetration testing

These are not the same thing, and the distinction matters in Singapore's regulatory environment.

A cloud security assessment or configuration review checks your infrastructure against known benchmarks. CIS, AWS Well-Architected, Azure Security Benchmark. It identifies misconfigurations, flags deviations from best practice, and gives you a prioritised list of things to fix. Tools like ScoutSuite, Prowler, and cloud-native services like AWS Security Hub handle most of this automatically.

Cloud penetration testing goes further. A pentester takes those misconfigurations and tries to exploit them. Can that over-permissive IAM role be used to access production data? Can the exposed metadata endpoint be used to assume a more privileged role? Can the security group rule be chained with an application vulnerability to reach an internal database?

The difference shows up in the results. A config review might flag 200 findings, most of them low or informational. A penetration test might find five things, but three of them demonstrate paths to sensitive data that would cause a reportable incident. One of those paths is usually something no automated tool would have found because it requires chaining cloud misconfigurations with application-level weaknesses.

Both have value. But if you're choosing one, the penetration test gives you a clearer picture of actual risk. The config review tells you what's non-compliant. The pentest tells you what's actually dangerous.

What Singapore regulators expect

MAS TRM and cloud security

The Monetary Authority of Singapore updated its Technology Risk Management guidelines to address cloud computing directly. Financial institutions in Singapore are expected to apply the same security standards to cloud environments as they do to on-premise infrastructure. From our experience running cloud security assessments in Singapore, we regularly find misconfigurations that wouldn't exist if the same controls had been applied during migration. That includes penetration testing. We regularly find that organisations assume their cloud provider handles security testing — they don't, at least not for your configurations.

MAS TRM Section 6 covers cloud computing specifically. The guidelines require financial institutions to conduct risk assessments of cloud deployments, including security testing appropriate to the risk level of the data and systems involved. For critical systems hosted in cloud environments, this means penetration testing, not just configuration reviews.

During MAS examinations, examiners ask about cloud security testing methodology, scope, and findings. They want to see that the institution understands the cloud-specific risks and has tested for them. A generic network penetration test that happens to include some cloud IP addresses won't satisfy this expectation. The testing needs to address cloud-specific attack surfaces.

Using CREST-certified providers for cloud penetration testing is considered best practice in Singapore's financial sector. CREST certification demonstrates that the testing methodology and consultant expertise have been independently validated. When MAS examiners review your penetration testing evidence, CREST certification provides a clear signal of quality.

CSA and broader expectations

The Cyber Security Agency of Singapore's Cyber Essentials and Cyber Trust marks both address cloud security. Organisations pursuing these certifications need to demonstrate that their cloud environments are being assessed for security risks. Penetration testing provides stronger evidence than configuration scanning alone.

PDPA implications

Under Singapore's Personal Data Protection Act, organisations must protect personal data with reasonable security arrangements. When that data lives in cloud environments, the PDPC's expectation is that cloud-specific security risks are being assessed. The PDPC has taken enforcement action against organisations that failed to secure cloud storage, which suggests they view cloud misconfigurations as a failure to meet the "reasonable security" standard.

How to prepare for a cloud penetration test

Preparation determines how much value you get from the engagement. Here's what to do before the testing starts.

First, inventory everything. Every AWS account, Azure subscription, and GCP project. Most Singapore organisations we work with discover cloud resources they forgot existed. Shadow IT is a real problem when departments can spin up infrastructure with a credit card. You can't test what you don't know about.

Second, document your architecture. VPC layouts, subnet purposes, IAM structures, data flows between services. The testing team needs this context to design realistic attack scenarios. A pentester who understands your architecture will find more meaningful issues than one who has to reverse-engineer it during the engagement.

Third, set up a dedicated testing IAM role. Give the consultants read-only access at a minimum. For a full penetration test, you'll want to provide a role that allows common enumeration actions without granting destructive capabilities. Work with the testing provider to define the exact permissions needed.

Fourth, notify your cloud provider. AWS, Azure, and GCP all have policies around penetration testing. AWS and GCP don't require prior notification for most tests against your own infrastructure. Azure historically required notification for certain types of testing. Check the current policy before the engagement starts to avoid having your testing traffic flagged or blocked.

Fifth, make sure logging is enabled and configured. CloudTrail in AWS, Activity Log in Azure, Audit Logs in GCP. These logs serve two purposes: they let your team practice detecting the testing activity (which is valuable incident response training), and they help the testing team prove their findings with evidence. If logging isn't enabled, you're losing value from the engagement.

What the testing process looks like

A proper cloud penetration test has distinct phases that differ from traditional network testing.

Scoping starts with understanding the cloud architecture. Which provider or providers, how many accounts and subscriptions, what data sensitivity levels are involved. The provider should ask about your regulatory requirements, whether that's MAS TRM, PDPA, or industry-specific standards. This conversation shapes the testing methodology and what gets prioritised.

Reconnaissance in cloud is different from on-premise. Instead of port scanning, the tester enumerates IAM policies, resource relationships, and trust configurations. They map out the cloud control plane and identify potential attack paths before attempting exploitation. This phase alone can take several days in a complex multi-account environment.

Exploitation tries to validate the attack paths identified during reconnaissance. Assuming IAM roles, accessing restricted storage, pivoting between accounts, escalating privileges. The goal is demonstrating impact, not just identifying misconfigurations. Every finding should answer the question: what could an attacker actually do with this?

Reporting delivers findings with cloud-specific remediation guidance. Not "fix your IAM policies" but "restrict this specific action on this specific resource to these specific principals." CREST-certified providers include proof-of-concept steps and evidence for each finding, which is what regulators expect to see.

Common questions about cloud penetration testing in Singapore

Do we need separate testing for each cloud provider?

Not necessarily, but the tester needs platform-specific expertise for each provider you use. AWS IAM and Azure AD are fundamentally different. A tester who knows AWS inside out might miss critical Azure AD misconfigurations. If you run multi-cloud, make sure the provider has demonstrated experience across all your platforms. Ask for specific case studies or references, not just "we do cloud."

How often should cloud environments be tested?

The same cadence as traditional penetration testing in Singapore: at least annually for critical environments, and after significant infrastructure changes. Cloud environments change faster than on-premise ones. Infrastructure as code means new resources get created constantly. Consider continuous configuration monitoring supplemented by annual manual penetration testing to catch the things automated tools miss.

Can we test production cloud environments safely?

Yes, with proper rules of engagement. Cloud penetration testing doesn't involve destructive actions. The tester enumerates configurations, attempts privilege escalation, and tries to access restricted resources without modifying or deleting production data. Rules of engagement define what's off-limits, and the testing team should have protocols for immediate communication if they encounter unexpected risk.

What to do next

Cloud security in Singapore isn't getting simpler. More services, more configurations, more attack surface. The organisations that handle this well test their cloud environments the same way they'd test anything else hosting critical data: with actual penetration testing by people who understand the platform.

If your last "cloud security assessment" was a configuration scan, you have gaps you don't know about. Not because the scan was bad, but because config reviews and penetration tests find different things. You need both, or at minimum, you need the one that shows you what an attacker could actually accomplish.

We run cloud penetration tests across AWS, Azure, and GCP for Singapore organisations, from startups through MAS-regulated financial institutions. If you want a straight conversation about what your cloud environment actually needs, we're here for that.