Cloud computing was supposed to make infrastructure easier to manage securely. The reality documented in external attack surface research is more complicated: cloud infrastructure is easier to provision, which means it is also easier to provision insecurely, and the default configurations of many cloud services are permissive rather than restrictive. The result is a generation of cloud-hosted infrastructure where misconfigurations that expose sensitive data or provide unauthorised access are common, frequently persistent for extended periods, and discovered by attackers using the same automated scanning tools that security teams use to audit their own environments.
The categories of cloud misconfiguration that consistently appear in external attack surface audits have been well-documented for years, yet they continue to appear in large numbers because the speed of cloud provisioning outpaces the security review processes that would catch them, because developers who need to test something quickly prioritise getting it working over getting it secure, and because the permissions model in cloud environments is complex enough that misconfiguration is easy even for engineers who understand security in principle. Understanding the specific misconfiguration categories, how they are found, and what can be done to detect and remediate them is directly relevant to any organisation with meaningful cloud infrastructure.
Amazon S3 buckets configured for public access are the most consistently documented cloud misconfiguration category. The history of publicly disclosed open S3 bucket incidents is long and includes breaches at major organisations across every sector. Despite years of attention to this issue and AWS's introduction of account-level block public access settings in 2018, open buckets continue to appear because each new account, subsidiary, or third-party integration may not have the block public access setting applied, and because the inherited permissions settings can be overridden at the individual bucket level by developers who need to test public access for a legitimate reason and forget to revert the change.
What makes open S3 buckets high impact is not just that attackers can read the data they contain, but that the data they contain is often disproportionately sensitive relative to how the bucket was treated. Backup archives that were created during a system migration and stored in S3 for temporary access contain database dumps. Log archives contain authentication records. Development environment configs contain database credentials and API keys. The casual data that ends up in an S3 bucket that "just needs to be temporarily accessible" is frequently the kind of data that should be in the most restricted storage environment available.
Automated scanning tools like TruffleHog, Grayhat Warfare, and S3Scanner index publicly accessible S3 buckets continuously, and their results are publicly searchable. Any open S3 bucket is discoverable through these services within hours of being made public. Organisations that want to know about their open buckets before attackers do need to scan their own AWS accounts proactively, which requires knowing which accounts contain S3 buckets, which may itself require maintaining an inventory of all cloud accounts.
Kubernetes has become the dominant container orchestration platform for enterprise cloud infrastructure, and its management interfaces present several categories of misconfiguration risk. The Kubernetes dashboard, when deployed and exposed without authentication or with weak authentication, provides an interface through which an attacker can view the entire cluster configuration, access secrets stored in Kubernetes secrets objects, and in many cases create new pods or modify existing deployments. A public Kubernetes dashboard is essentially an administrative console for the production infrastructure exposed to the internet.
Shodan and Censys index Kubernetes API servers and dashboards that are accessible from the public internet, and the resulting data is searchable. The Tesla cryptocurrency mining incident in 2018, in which an exposed Kubernetes dashboard was used to gain access to Tesla's AWS environment, remains one of the most documented examples, but the pattern continues to repeat because Kubernetes clusters are routinely spun up for development and testing with default configurations that include an accessible dashboard, and those clusters sometimes make their way into production or are forgotten rather than decommissioned.
OAuth 2.0 is the authentication delegation standard that underlies most cloud service integrations, and its complexity creates several categories of misconfiguration that appear consistently in external attack surface audits. Overly broad OAuth application permissions, where a third-party application has been granted access to read all email or all files in a cloud storage service rather than the minimum permissions it needs, represent a latent exposure: if the third-party application is compromised, the attacker inherits those permissions in the target organisation's environment.
OAuth Device Code Flow misuse, which requires no phishing page at all, has been documented in real attacks including the Helix group activity covered in earlier Defendis articles: an attacker initiates a Device Code Flow authentication request, sends the resulting code to the victim via email or Teams message, and the victim who enters the code grants the attacker an authenticated OAuth token without realising they have authenticated anything malicious. The attack exploits a legitimate OAuth flow designed for device authentication.
Continuous monitoring of OAuth application grants in cloud tenants, specifically flagging new applications with broad permissions and reviewing the access history of applications that have not been recently audited, is the internal control for OAuth misconfiguration. External attack surface monitoring that includes OAuth application discovery, looking for applications registered in your cloud tenant that are not in your approved application inventory, provides a complementary detection layer for shadow IT OAuth integrations that may have been provisioned without security review. External visibility into your cloud environment from an attacker's perspective is the most reliable way to identify what needs attention before attackers find it.
The cloud misconfiguration challenge is amplified in organisations that use multiple cloud providers simultaneously, which in 2026 is the majority of enterprises with significant cloud presence. Different cloud providers have different permission models, different default configurations, and different tooling for auditing and monitoring security posture. A security team that has built expertise in AWS security tooling may have significant blind spots in their organisation's Azure or GCP environments, where the security controls look different and the documentation is less familiar.
Multi-cloud environments also complicate the asset inventory problem. An organisation that tracks its AWS assets in one system, its Azure assets in another, and its GCP assets in a third does not have a single view of its complete cloud attack surface. Shadow IT in cloud environments is particularly difficult to track when developers in different teams use different cloud providers for their projects, each under different billing accounts that may not be centrally inventoried.
External attack surface monitoring that takes a provider-agnostic view of the organisation's internet-facing infrastructure, looking for exposed services, open storage, and management interfaces across all cloud providers, addresses the inventory gap that multi-cloud environments create. By scanning the organisation's IP ranges and domain space from the outside, regardless of which cloud provider hosts the infrastructure behind those addresses, external ASM tools can find exposed cloud resources that internal tools miss because they are in a cloud account or provider that is not connected to the internal monitoring infrastructure. The external attacker's perspective on your cloud infrastructure is the view that internal tools cannot fully replicate.
Understanding how quickly cloud misconfigurations are discovered by attackers is important context for the urgency of detection and remediation. Research into exposure windows for common cloud misconfigurations, primarily open S3 buckets and exposed management interfaces, consistently shows that newly created exposures are discovered by automated scanning infrastructure within hours to days, not weeks. Honeypot experiments that create intentionally misconfigured cloud resources and monitor when those resources receive unauthorised access attempts reliably show access within 24-48 hours, and in some experiments within minutes for particularly prominent exposure types.
This timeline means that a cloud misconfiguration is not a risk that sits dormant waiting for a human attacker to find it. It is discovered by automated scanning infrastructure that continuously indexes the internet's exposed services, and it becomes available to any subscriber to those scan results. The data from continuous internet scanning services is commercialised through multiple channels: directly as security research data, as inputs to attack surface management platforms, and on criminal markets where threat actors purchase access to scan results to identify targets.
The implication for cloud security teams is that the window between a misconfiguration being created and it being discovered and potentially exploited is shorter than the window between a misconfiguration being created and it being caught by a quarterly vulnerability scan or an annual penetration test. External attack surface monitoring that runs continuously and alerts on new exposures in near-real time is what closes this gap. A continuous scan that detects a newly created open S3 bucket within hours of its creation gives the security team a chance to remediate before the access window becomes an exploitation event. External visibility into your cloud footprint from the attacker's perspective is the monitoring paradigm that matches the timeline of actual risk.
Attackers use the same tools and data sources that security researchers use to find misconfigured cloud resources: internet-wide scan databases like Shodan and Censys that index exposed services, automated tools that scan for specific misconfiguration patterns like S3 bucket enumeration tools, and commercial intelligence feeds that aggregate scan data. Some attackers purchase access to detailed scan results from commercial sources. Cloud service providers' own security research teams and external bug bounty hunters also discover these misconfigurations, but so do attackers who are specifically looking for targets.
Exposed cloud storage buckets containing sensitive data are among the most commonly exploited misconfigurations documented in public incident disclosures. Exposed management interfaces like Kubernetes dashboards and Elasticsearch instances without authentication are also well-documented in incident reports. Overly permissive IAM policies, particularly those granting wildcard permissions or public access, are exploited in attacks that use legitimate-seeming API calls rather than traditional exploitation. Misconfigured serverless functions with insufficient input validation have also been documented in attack chains targeting cloud environments.
Attack surface management (ASM) and vulnerability management (VM) are complementary but distinct practices. Vulnerability management focuses on known vulnerabilities in software with CVE identifiers, tracking which systems need patches and prioritising remediation by severity. Attack surface management takes a broader view of what is exposed to the internet, including misconfigured services, shadow IT, and orphaned assets that may not appear in the internal asset inventory at all. An ASM scan may find an exposed service that has no known CVE but is misconfigured in a way that grants unauthorised access. VM scans that use an internal asset inventory will miss assets they do not know about, which is exactly where ASM provides complementary coverage.
Internal cloud security tooling, including cloud security posture management (CSPM) platforms, cloud infrastructure entitlement management (CIEM) tools, and cloud workload protection platforms (CWPPs), provides visibility into the configuration and behaviour of cloud resources within managed cloud accounts. These tools are valuable and provide coverage that no external tool can replicate for the internal details of a cloud environment. However, they share a structural limitation: they only cover what they can see, and they can only see what they are connected to.
The resources they miss are the ones most likely to be misconfigured. Shadow IT cloud accounts, provisioned by teams or individuals outside of the central IT procurement process, are by definition not connected to the central CSPM deployment. Old accounts provisioned for a project that has since concluded may have been disconnected from the billing consolidation structure without their resources being decommissioned. Accounts created by acquired entities before the acquisition completed the technical integration process may have security tooling from the acquired company rather than the acquirer's standard stack. In all of these scenarios, the internal security tooling does not have a view of the external exposure that those accounts create.
The attack surface management perspective resolves this blind spot by approaching the organisation's cloud footprint from the outside. An ASM scan does not know in advance which cloud accounts belong to the organisation; it discovers the organisation's internet presence by following domain and IP associations, certificate transparency records, and other external signals. This discovery process finds the forgotten EC2 instance in an old AWS account that is not in the central inventory, the developer sandbox that was spun up outside of the approved provisioning process, and the staging environment that was never decommissioned because everyone forgot it existed. These are precisely the environments that are most likely to have configuration issues, because they were never subjected to the security review processes that govern standard deployments.
Integrating ASM findings with internal CSPM coverage creates a unified picture that neither tool provides alone. The ASM findings surface the unknown assets; the CSPM tools provide detailed configuration analysis once those assets are brought into the managed inventory. Some organisations automate this integration: ASM findings trigger an automated workflow that connects new cloud accounts to the CSPM platform and runs an immediate configuration assessment. Continuous external monitoring that covers your cloud footprint with this discovery-first approach is the foundational layer for an ASM programme that closes the shadow IT visibility gap.
Cloud infrastructure misconfigurations are not only a risk that originates within an organisation's own provisioning decisions. Third-party software and services that organisations use to build and operate their cloud infrastructure may themselves contain misconfigurations or vulnerabilities that expose the customer's cloud environment. The software supply chain risk for cloud infrastructure spans multiple categories: configuration management tools that apply settings across cloud environments may have vulnerabilities that allow an attacker to modify configurations; infrastructure-as-code templates shared through public repositories may contain insecure defaults that are deployed without review; and third-party integrations that are granted cloud account access may themselves be compromised, allowing an attacker to access the cloud environment through the integration's permissions.
The Solarwinds incident in 2020 demonstrated the scale of supply chain risk for cloud-connected software, but the principle applies to a much broader category of cloud tooling than that single incident covered. Any software or service that has programmatic access to a cloud account, through API keys, service accounts, or OAuth tokens, represents a potential supply chain attack vector if that software or service is compromised. The access permissions granted to these integrations should be the minimum necessary for their function, regularly reviewed, and revoked when the integration is no longer in use.
Identity security for cloud accounts, specifically the management of service accounts, API keys, and OAuth grants that allow programmatic access to cloud resources, is a category of security management that complements the infrastructure misconfiguration focus of traditional attack surface management. Rotating API keys regularly, maintaining an inventory of active integrations and their permission levels, and monitoring for unusual API activity that might indicate a compromised integration are the controls that address supply chain risk for cloud infrastructure. External attack surface management that includes detection of unusual cloud API endpoints being exposed or of service account credentials appearing in public repositories provides the external visibility component for this risk category.
Cloud security is a practice of continuous improvement rather than a state that can be achieved and maintained indefinitely. The speed at which cloud infrastructure evolves, new services adopted, new developers onboarded, new integrations created, means that the attack surface is never static. A misconfiguration assessment that passes today may fail tomorrow because of a new resource provisioned with default settings. The only posture that matches this pace of change is continuous monitoring that detects new exposures as they appear, rather than periodic assessments that reveal the state at a single point in time.
The frequency of cloud misconfiguration incidents in publicly disclosed breaches reflects both the prevalence of the vulnerability category and the business impact that makes disclosure necessary. Cloud storage bucket exposures have been implicated in breaches affecting hundreds of millions of records across multiple major incidents, making them among the most impactful vulnerability categories in terms of data exposed per incident. The combination of high prevalence, easy exploitability through automated scanning, and high impact when sensitive data is present makes cloud misconfiguration a priority category for any organisation with significant cloud infrastructure, regardless of sector. The preventive and detective controls described in this article address the specific mechanisms through which cloud misconfigurations are discovered and exploited, providing a framework for risk reduction that is proportionate to this level of impact.
QR code phishing campaigns distribute lures through channels that internal email security cannot scan. Cloud misconfiguration exposures appear on attacker reconnaissance tools within hours of being created. Both categories of threat depend on external visibility: seeing what your organisation looks like from the outside, including the assets and attack paths that internal tools have no context for.
Defendis monitors your external attack surface continuously and correlates it with dark web threat intelligence, so that you know about exposed assets before attackers find them, and about phishing infrastructure targeting your users before the first credential is stolen.
Book a demo to see external attack surface and threat intelligence monitoring in action.
