South Africa sits at a painful inflection point. Between 40% and 50% of local organisations have moved to cloud-first infrastructure, yet incident response data consistently shows that roughly 60% of cloud breaches trace back to misconfigured permissions rather than sophisticated malware. Attackers are not cracking encryption or deploying zero-days to get into your AWS, Azure, or GCP environment. They are walking through doors your own Identity and Access Management configuration left open.
The ransomware bill that follows is substantial. Recovery costs routinely dwarf the initial ransom demand once you factor in forensic investigation, downtime, data reconstruction, regulatory notifications under POPIA, and reputational damage in a market where enterprise clients are increasingly scrutinising security posture before signing contracts. The root cause, in breach after breach, is cloud IAM misconfiguration that nobody tested.
Standard on-premises penetration testing disciplines do not catch these failures. On-prem testing assumes firewalls, network segments, and Active Directory as the primary attack surface. Cloud IAM lives in an entirely different control plane, one that on-prem methodology was not designed to probe. The six failures below are the ones your penetration testers must be explicitly scoping for in any cloud environment.
Cloud platforms grant permissions through roles, and roles inherit from one another. An IAM role assigned to a development function may have inherited administrative rights from a parent role configured during the initial cloud deployment, rights that were never intentionally granted to that function and were never revoked because nobody tracked the inheritance chain.
The attack path is direct. A threat actor compromises a developer credential through phishing or credential stuffing. That credential maps to a role with inherited write access to production storage, the ability to create new IAM users, or rights to modify Lambda functions and Azure Logic Apps. The attacker does not need to escalate privileges in the traditional sense; the inherited permissions already provide lateral movement paths into sensitive workloads. Ransomware payloads deployed via cloud function modifications can reach storage, databases, and backup volumes simultaneously.
Traditional on-premises penetration testing checks who has domain admin rights in Active Directory. It does not enumerate cloud IAM role inheritance graphs or simulate what a compromised low-privilege identity can reach through permission chaining. The specific cloud-native test here is IAM privilege escalation simulation: testers enumerate all roles assigned to an identity, map every inherited permission, and attempt to reach sensitive resources or create higher-privileged identities using only those inherited rights. This test regularly surfaces administrative access where none was intended.
Service accounts accumulate fast in cloud environments. Every application, pipeline, automated job, and integration creates one. Teams spin up service accounts to solve immediate problems and move on. Six months later, those accounts are still active, their keys have never rotated, and nobody is monitoring their activity. Some are attached to workloads that no longer exist. Others have permissions scoped far wider than the original task required.
Attackers prioritise service accounts precisely because they are unmonitored. A compromised service account key does not trigger the same detection logic as a compromised human credential because service accounts are expected to behave programmatically, often at unusual hours, accessing resources in automated patterns. Ransomware operators use service account access to move laterally across cloud projects and regions, exfiltrate data, and stage encryption payloads, all while generating activity that looks automated and therefore benign to an analyst without specific alerting in place.
"We find service account sprawl in nearly every cloud environment we test," said Kevin Wotshela, Managing Director, Magix. "The client is often surprised by how many accounts exist, and even more surprised when we show them what those accounts can access. A service account with six months of unused permissions and no rotation policy is one phishing email away from a significant breach."
Cloud-native vulnerability assessment and penetration testing for service accounts involves full inventory enumeration, access key age analysis, last-used activity review, and permission scope validation against the principle of least privilege. Testers should specifically attempt to use dormant service account credentials to traverse cloud project boundaries and access backup storage or management APIs.
API keys left in code repositories is a well-documented problem. Less discussed is the same problem manifesting in cloud storage: configuration files, deployment scripts, environment variable exports, and CI/CD pipeline artefacts sitting in S3 buckets or Azure Blob containers, containing API keys, database connection strings, and cloud platform credentials that were written there months or years ago.
The attack path requires no technical sophistication once the bucket is located. If the bucket allows public access, unauthenticated discovery is trivial. If access is restricted but the bucket's IAM permissions are misconfigured, an attacker with any valid cloud identity may be able to read it. Keys extracted from stored configuration files often grant access to services far beyond the original scope: payment processors, HR platforms, cloud management APIs, and backup systems. Ransomware operators who obtain cloud management API keys can disable backup policies and snapshot protections before triggering encryption, ensuring recovery is maximally difficult.
On-premises penetration testing does not scan cloud storage object contents for credential exposure. A cloud-specific assessment must include authenticated storage enumeration, object content analysis for secrets, cross-referencing discovered credentials against cloud IAM to confirm what access they grant, and validation that discovered keys are genuinely active and not yet rotated. Many organisations are surprised to find that keys extracted from storage artefacts still work because the rotation workflow was never completed after the original deployment. Vulnerability management programmes that do not extend into cloud storage contents miss this category entirely.
The shared responsibility model is one of the most consequential concepts in cloud security, and one of the most persistently misunderstood. AWS, Azure, and GCP secure the infrastructure: the physical data centres, the hypervisor layer, the networking fabric. They do not configure your IAM policies, your role assignments, your bucket permissions, or your conditional access rules. That responsibility sits entirely with the customer.
The gap this creates is dangerous. Organisations that have invested significantly in cloud migration often proceed with implicit confidence that the platform is handling security comprehensively. Security audits focus on traditional controls: firewalls, endpoint protection, patch management. Nobody asks who can access the cloud management console, what MFA enforcement looks like for privileged cloud identities, or whether conditional access policies actually restrict access to expected IP ranges and device states.
Attackers know this gap exists and target it deliberately. Phishing campaigns aimed at cloud console credentials succeed against organisations that treat MFA as optional for non-human-facing accounts. Compromised cloud console access can disable logging, alter IAM policies in real time, and stage ransomware deployment across all cloud-hosted workloads before any alert fires. A proper cloud penetration test must explicitly validate the IAM controls the customer is responsible for: MFA enforcement on all privileged identities, conditional access policy effectiveness, IAM policy boundary configuration, and control plane access logging coverage. The test should also verify that cloud-native security services like AWS GuardDuty or Microsoft Defender for Cloud are enabled and properly configured, not just provisioned.
Third-party vendors, managed service providers, and software integrations routinely receive access to cloud environments during onboarding. Rarely does that access get revisited. Vendors retain cloud roles assigned during initial implementation long after the project concludes. SaaS integrations retain OAuth permissions scoped to full read access when they required only a specific data type. MSPs hold administrative cloud access granted during a migration that completed two years ago.
Third-party risk management in on-premises environments typically involves reviewing contractual obligations and periodic questionnaires. That approach does not translate to cloud IAM. The actual permissions held by third-party identities in your cloud environment must be enumerated, validated against current business need, and tested for what they could enable in the hands of an attacker. Supply chain compromises frequently begin with a vendor whose credentials or OAuth tokens are stolen; the attacker inherits whatever cloud access that vendor legitimately held, which is often far broader than anyone remembers granting.
The cloud-native test for third-party access involves full enumeration of external identities and cross-account trust relationships, permission scope analysis for each, and simulation of what an attacker could achieve with those permissions. Particular attention should go to any third-party identity with the ability to modify IAM policies or access backup and snapshot resources, as these represent the highest-impact ransomware staging paths.
Your cloud audit logs are where forensic investigators go after a breach to establish what happened, when, and through which identity. Attackers know this. One of the first actions in a sophisticated cloud ransomware campaign is tampering with or disabling logging infrastructure before triggering the destructive payload. If your cloud logging configuration is itself an unmonitored resource, an attacker with sufficient permissions can quietly alter retention settings, disable log export, or delete log streams without triggering any alert.
The secondary problem is access sprawl within the logging layer itself. AWS CloudTrail, Azure Monitor, and GCP Cloud Audit Logs contain detailed records of every API call and management action. An attacker who can read your audit logs before launching an attack can identify the detection gaps in your monitoring, understand which accounts are watched and which are not, and time their actions to avoid scrutiny. Too many organisations grant read access to cloud audit logs without treating that access as sensitive or tracking who holds it.
Cloud penetration testing must explicitly validate whether an identity with standard cloud permissions can modify or disable logging configuration, whether log access is restricted and monitored, and whether alerts fire when audit log settings change. This is a test category that on-premises assessments have no equivalent for, and one that separates cloud-aware penetration testing services from traditional network assessments applied to cloud infrastructure.
Each of the six failures above has a pattern in common: standard on-premises testing methodology does not reach the cloud control plane. The tools differ, the attack paths differ, and the remediation differs. An assessor who is strong at Active Directory enumeration but unfamiliar with cloud IAM policy inheritance, cross-account trust relationships, and cloud-native logging configuration will produce a penetration test report that gives you false confidence in your cloud security posture.
What cloud-specific testing requires is testers who are certified and practiced in cloud-native attack techniques: AWS IAM privilege escalation, Azure AD lateral movement through service principal abuse, GCP project boundary crossing via misconfigured service accounts. The scope declaration for any cloud engagement must explicitly include the IAM control plane, storage object inspection, third-party identity enumeration, and logging infrastructure validation. Anything less than this is not a cloud penetration test; it is an on-premises test run adjacent to cloud infrastructure.
South African enterprises facing POPIA obligations around personal information security, and those operating in regulated sectors under PCI DSS or the FSCA Joint Standard, should note that cloud IAM misconfigurations create direct regulatory exposure. A breach attributable to permission drift that was identifiable through testing is a difficult conversation to have with the Information Regulator.
Permission drift does not announce itself. It accumulates steadily as cloud environments grow, teams change, and vendor relationships evolve. By the time an attacker exploits an overpermissive role or a stale service account key, the misconfiguration has often existed for months. The cost of validating these six failure categories through targeted cloud penetration testing is a fraction of the forensic, recovery, and regulatory cost that follows a successful ransomware deployment through a cloud IAM vector.
Magix runs cloud-native penetration testing engagements that specifically address IAM control plane risk, including all six failure categories covered here. If your last penetration test did not explicitly include IAM privilege escalation simulation, service account credential enumeration, and cloud logging access validation, your cloud attack surface has not been properly assessed. Contact the Magix team to scope a cloud IAM security assessment before the next incident scopes it for you.
