What if a ‘low severity’ bug could lead to full cloud takeover?

Low-severity vulnerabilities are commonly and easily identified by various tools and scanners, including Burp Suite, Nessus, and Netsparker. These tools often flag minor issues such as missing security headers, hardcoded API keys, directory listings, and the most common low finding: outdated JavaScript components. Most of the time, these low-risk issues are ignored or treated as accepted risks simply because they don’t appear to pose an immediate threat.

But that is a dangerous illusion. These low-risk issues can be far more critical than you might imagine, potentially compromising your entire cloud account.

The Problem

As pentesters, our role is to deliver maximum value by identifying not only high and critical issues but also low and informational findings. The challenge arises because many organizations, when reviewing reports detailing numerous medium, high, and critical issues, tend to overlook low-risk findings. This is often due to the perception that low-risk issues lack immediate impact, leading security teams to prioritize critical issues that have a clear, demonstrable business impact.

While automated scanners can detect these low-severity issues, they lack the capability to "connect the dots," chain vulnerabilities, or perform self-escalation. This is precisely where human-led pentesting proves its value. We advocate for the continuous use of scanners, but relying solely on automated scanning is a dangerous practice for any organization.

The Reality

Web applications are no longer isolated on a single server as they were in the past, when all components typically resided within a single virtual machine (VM). In the age of cloud applications, numerous distributed components share keys and connection strings with a common backend. These interconnected elements form a complex chain where a single point of failure can compromise the entire sequence.

For example:

• Web app → APIs
• APIs → Storage
• Storage → Logs/telemetry
• Logs → DevOps / pipelines
• Pipelines → Identity/permissions

Cloud services have a trust relationship with each other by their design where:

• App Services trust storage accounts
• Pipelines trust variable groups
• Managed identities trust Azure resources

Due to the inherent design of cloud services, compromising one component often allows an attacker to inherit trust and gain access to other interconnected resources. This is precisely how overlooked low-severity issues can be exploited. For instance, obtaining an API key might grant access to a function app, which could then reveal logs containing tokens. Based on the token's permissions, this chain can escalate, ultimately leading to the complete takeover of the entire cloud account.

Mini Case Study

So let’s take a quick look at the case study of how a single API key actually allowed a Global admin user to compromise the whole Account. In one our Offensive Engagement where at first glance what seemed to be simple Low finding issues actually came out to be the real nightmare.

A Key that was supposed to be just send/create logs for the application meant to be safe at first place, but after an OSINT it revealed that the same key was being used somewhere in the Git Repo in its python file. This file also contained another key that belonged to that same logging server but had permission for reading as well and this is where our actual hunt begins.

These Logs revealed the SAS URL of a storage account function app which leads us to access of a storage account as it had that trust relationship where this storage account later revealed a Personal Access Token of Azure Devops in its Queues.

Now when we have access to the Devops, and it allows us to access not just Repoistores but also the Pipelines which later by abusing the pipeline we were able to exfiltrate Secure Variable value from it which belongs to an App registration. These Apps had permission to access App service where by abusing it somehow we were able to get an RCE on that App Service whose managed identity had access to a key vault.

Inside the Key Vault, we found credentials for a user account that had never been used. This allowed us to configure MFA ourselves and log in. Even more concerning, the account had Privileged Identity Management (PIM) enabled for the Global Administrator role which we could activate.

What made this possible wasn’t a single critical vulnerability, but a chain of small, overlooked issues combined with excessive permissions and weak access controls.

The complete attack path, including every step of the escalation, is detailed in our whitepaper.

Reference: https://resource.cobalt.io/chaining-vulnerabilities-for-a-cloud-compromise

Why Human Pentesting Matters

Based on what we have just seen is exactly where human-led pentesting proves its value.

Currently, no automated scanner can conceptualize the entire attack path, connect these various findings, or execute this level of vulnerability chaining. This process requires the context, creativity, and persistence that only a human tester can provide.

For example, while a tool can identify findings like a directory listing, only a human can initiate enumeration within it, retrieve sensitive downloadable files, and consider the possible escalation from that information, including lateral movement, post-exploitation, and establishing deep persistence within the victim's infrastructure.

Automated tools remain important and necessary for any engagement, but they must be complemented by manual efforts. The organization, not just the tester, must address all low and informational findings. While these issues might lack immediate impact, they could lead to serious damage in the future as applications and their components expand.

Business Impact

The potential business impact spans from severe data theft to irreparable damage to reputation. Data breaches are a common consequence, especially since many organizations utilize services like AWS S3 Buckets and Azure Storage Accounts to house critical data, logs, and code, often accumulating terabytes of information. A single key leak is often enough for an attacker to download the entirety of a storage container.

Even major entities like Microsoft are not immune; a case study demonstrated that a single misconfiguration exposed 38TB of their data, including secrets, code, and AI training material.

What is most concerning about these incidents is not merely the scale of data exposure, but the ease with which they occur. A single misconfigured storage container, an overly permissive access token, or an overlooked key can quietly enable massive data exposure, often without immediate detection. In real-world scenarios, attackers rarely rely on complex exploits; they frequently leverage already exposed keys, tokens, or misconfigured services to move laterally across the environment.

The impact extends far beyond data loss, encompassing:

• Regulatory and compliance violations

• Financial losses from incident response and legal actions

• Loss of customer trust and brand reputation

• Operational disruption across critical systems

Crucially, these incidents are often preventable. This reinforces the core premise of this discussion: It’s not always the critical vulnerabilities that cause the biggest damage, but the small, overlooked ones that get chained together.