Quick Answer

Cloud security audit and penetration testing identify misconfigurations, overly broad IAM permissions and open storage buckets across AWS, Azure and Microsoft 365 environments, within authorized scope. Unlike traditional pentesting, it focuses on identities and the control plane rather than network ports. Continuous auditing with CSPM and CIS Benchmarks is strongly recommended.

Why Cloud Security Differs From Traditional Security

As organizations move workloads into AWS, Microsoft Azure and Microsoft 365, the attack surface has changed fundamentally. In a classic data center, the security team controlled physical servers, network switches and firewalls. In the cloud, everything became abstract resources managed through an API call, defined as code, and created or destroyed within minutes.

This transformation introduced a new reality: in the cloud, the most critical attack surface is no longer network ports but identities. For an attacker, an overly privileged IAM role, a leaked access key or a misconfigured OAuth application is as valuable as an open 3389 port. For this reason, cloud security audit and cloud penetration testing have become a discipline entirely distinct from traditional network pentesting.

At DSET, we have carried our forensic and offensive security experience, accumulated since 2003, into the unique dynamics of cloud environments. In this article, we explore the core concepts of cloud security auditing, provider rules, the most common misconfigurations and modern testing tools in depth.

The Shared Responsibility Model: Who Protects What?

At the heart of cloud security lies the shared responsibility model. Any audit performed without understanding this model remains incomplete.

In short, the provider (AWS, Microsoft) is responsible for the security of the cloud itself: data centers, physical hardware, the hypervisor layer and core network infrastructure. The customer is responsible for the security of what is in the cloud: data, identity and access management, network configuration, operating system patches and application security.

The distribution of responsibility varies by service model:

  • IaaS (Infrastructure as a Service, e.g. EC2 / Azure VM): The customer is responsible for the operating system, network and application layers. This model has the widest attack surface.
  • PaaS (Platform as a Service, e.g. App Service, RDS): OS management shifts to the provider; the customer is responsible for application and data configuration.
  • SaaS (Software as a Service, e.g. Microsoft 365): The provider manages the application; the customer is responsible for user identities, access policies and data sharing settings.

In SaaS environments such as Microsoft 365, many organizations fall into the trap of believing "the provider already protects everything." Yet conditional access policies, OAuth application permissions and sharing settings are entirely the customer's responsibility, and they are among the most frequently breached areas.

Differences Between Cloud Pentest and Traditional Pentest

A traditional penetration test typically follows steps such as port scanning, service discovery and vulnerability exploitation against an IP range or web application. Cloud penetration testing requires an architecturally different approach.

Dimension Traditional Pentest Cloud Pentest
Primary target Network ports, services Identities, IAM roles, APIs
Reconnaissance Nmap, port scanning Configuration audit, permission mapping
Privilege escalation Local exploit, kernel IAM policy chains, role assumption
Authorization source Customer Customer + provider rules
Control plane None Control plane exploitation critical
Data exfiltration Over the network S3/Blob, snapshot, API

In cloud testing, the assumption that "the attacker has already compromised an identity inside" is very common. The real question is: if an attacker starts with a low-privileged identity, how far can they go through the control plane? For this reason, cloud pentesting focuses on mapping identity-based attack paths.

Control Plane vs Data Plane

This distinction is one of the most critical concepts in cloud security.

  • Control plane: The API layer that creates, configures and manages resources. For example, changing the access policy of an S3 bucket, creating a new IAM user or taking a disk snapshot of a VM are control plane operations.
  • Data plane: The layer where the actual data is accessed. Reading files in an S3 bucket or querying a database are data plane operations.

The critical point is this: even if an attacker cannot directly access the data plane, with permissions on the control plane they can copy a database snapshot to their own account or loosen a bucket policy to expose the data. In DSET audits, we always address control plane attack paths as a separate topic.

Provider Rules and Permissions: Testing Within Scope

One of the most important differences between cloud penetration testing and traditional testing is that the provider is also a stakeholder. Unauthorized testing on shared infrastructure creates both a contract violation and a legal problem.

AWS Penetration Testing Policy

AWS allows customers to perform penetration testing against certain services in their own accounts without prior approval. Services such as EC2, RDS, CloudFront, API Gateway and Lambda are on the permitted list. However, tests such as DNS poisoning, DoS/DDoS simulation and port flooding require separate approval or are prohibited. Tests must only be performed against resources you own.

Azure and Microsoft 365 Testing Rules

Microsoft similarly publishes a set of penetration testing rules. You may test resources in your own subscription, but tests that affect Microsoft's shared infrastructure or other customers are prohibited. In Microsoft 365 environments, phishing simulations and account takeover tests require an especially careful scope definition.

At DSET, for every cloud audit, we clarify the scope, target subscriptions and compliance with provider rules in writing before testing begins. All our testing tools, including KAOS, operate only within authorized scope and in compliance with provider rules. You can find details on how the process works in our article on the pentest process and pricing.

IAM and Privilege Escalation: The Heart of the Cloud

Identity and Access Management (IAM) is the most critical and most frequently misconfigured area of cloud security. For an attacker, the ideal target is an identity with broad permissions but weak protection.

AWS IAM Privilege Escalation Scenarios

In AWS IAM, privilege escalation usually occurs through the exploitation of policy chains. Common scenarios:

  • iam:PassRole + service abuse: If a low-privileged user is granted iam:PassRole and, for example, lambda:CreateFunction, they can pass a high-privileged role to a Lambda function and reach admin privileges.
  • iam:CreatePolicyVersion: A user with permission to add a new version to an existing policy can silently expand their own privileges.
  • iam:AttachUserPolicy: The user can attach the AdministratorAccess policy directly to themselves.
  • sts:AssumeRole chains: Privilege escalation through transitioning from one role to another (role chaining).

The combination of seemingly harmless permissions often opens a path to admin privileges. This is exactly why cloud pentesting analyzes the permission graph rather than individual permissions.

Azure RBAC and Managed Identities

On the Azure side, privilege escalation usually happens through RBAC role assignments and managed identities. For example, the User Access Administrator role granted by mistake instead of Owner allows a user to assign other roles to themselves. An overly privileged managed identity attached to a VM also becomes a privilege escalation tool for the attacker.

Open Storage: S3 Buckets and Azure Blob

The most well-known cause of data breaches is still misconfigured storage. An S3 bucket or Azure Blob container left publicly accessible on the internet can expose an organization's most sensitive data within seconds.

Common misconfigurations:

  • Public read/write access: An S3 bucket with Block Public Access disabled and a bucket policy containing Principal: *.
  • Listable Blob containers: In Azure, setting a container's access level to Blob or Container opens the door to anonymous access.
  • Unencrypted data: Server-side encryption (SSE) not being enabled.
  • Unlogged access: When S3 access logs or Azure Storage Analytics are disabled, a breach can go unnoticed.
  • Long-lived presigned URLs: A leaked URL remaining valid for days.

In DSET audits, we do not merely detect open storage findings; with our verified vulnerability, false-positive-free testing approach, we confirm them with proof (PoC). This way we present the customer not with a "maybe open" finding but with the clarity of "this file is currently readable from outside."

Azure Entra ID Identity Attacks (Summary)

Azure Entra ID (formerly Azure AD) is the identity backbone of hybrid cloud environments and is therefore a primary target for attackers. Techniques such as token theft, OAuth consent phishing, Golden SAML and abuse of federation trust allow an attacker to take over cloud identities and establish persistence.

Since this article focuses on cloud auditing and pentesting, we do not repeat Entra ID attack techniques here. For an in-depth analysis of token-based attacks, Golden SAML and hybrid cloud persistence techniques, we recommend our article on Azure Entra ID attack techniques and Golden SAML. From an audit perspective, the key point is this: Entra ID configuration (conditional access, MFA coverage, legacy authentication protocols) is an integral part of every cloud audit.

Microsoft 365 Security Audit

Because Microsoft 365 hosts organizations' email, file sharing and collaboration infrastructure, its attack surface is extremely broad. The main areas we focus on in M365 audits:

Email and Exchange Online

  • Correct configuration of SPF, DKIM and DMARC records (to prevent email spoofing).
  • Auditing of auto-forwarding rules, because attackers create hidden forwarding rules to exfiltrate data from compromised mailboxes.
  • Disabling legacy authentication protocols (POP3, IMAP, SMTP AUTH).

OAuth Application Permissions

The most insidious attack surface of Microsoft 365 is the permissions granted to third-party OAuth applications. Once a user approves the "read my emails" permission for a malicious application, the attacker gains persistent access without knowing the password and without bypassing MFA. This "illicit consent grant" attack is an area that must be scanned in audits.

Conditional Access Policies

Conditional Access is the policy set that determines who can access from where and with which device. Common weaknesses: MFA exceptions, legacy protocols falling outside conditional access, and overly broad configuration of "break-glass" accounts.

Continuous Auditing With CIS Benchmark and CSPM

A one-time pentest offers a snapshot in time. But cloud environments change constantly; new resources are created and policies loosen. For this reason, modern cloud security requires continuous auditing.

CIS Benchmark

CIS (Center for Internet Security) Benchmarks are industry-standard secure configuration guides for AWS, Azure and Microsoft 365. They contain hundreds of control items such as "MFA must be enabled for the root account" or "storage encryption must be enforced." Audits are scored against these benchmarks.

CSPM (Cloud Security Posture Management)

CSPM tools continuously scan the cloud environment to automatically detect misconfigurations. They report CIS Benchmark non-compliance, open storage and overly privileged identities in real time. DSET's AI-powered offensive security agent, the KAOS AI security engine, combines this continuous scanning approach with an offensive perspective: it does not merely list a misconfiguration but verifies, within authorized scope, whether it forms an attack path.

Cloud Penetration Testing Tools

The open-source tools used in cloud pentesting form the foundation of an audit. Main tools and their use cases:

Tool Provider Use Case
ScoutSuite AWS, Azure, GCP Multi-cloud configuration audit
Prowler AWS, Azure CIS Benchmark compliance scanning
Pacu AWS Offensive AWS exploitation framework
ROADtools Azure / Entra ID Entra ID reconnaissance and data collection
AzureHound Azure / Entra ID Attack path graph (BloodHound)

Roles of the Tools

  • ScoutSuite: A multi-cloud audit tool that quickly reports an environment's security posture. Ideal for the reconnaissance phase.
  • Prowler: Automatically runs hundreds of CIS controls and produces a compliance report. Frequently used for continuous auditing.
  • Pacu: An AWS-specific offensive framework that can be considered the cloud equivalent of Metasploit. Includes IAM privilege escalation modules.
  • ROADtools: Collects user, group, application and permission data from the Entra ID environment, laying the groundwork for attack surface analysis.
  • AzureHound: Maps relationships in Azure and Entra ID into a graph, visualizing the path through which an attacker could escalate privileges.

At DSET, we combine these tools with KAOS. KAOS takes the reconnaissance output, automatically detects misconfigurations, verifies vulnerabilities with proof, and produces reports at separate levels for management and the technical team. This entire process runs within authorized scope and in compliance with provider rules.

DSET Cloud Audit Methodology

We carry out a cloud security audit in the following stages:

  1. Scope and authorization: Target subscriptions, services and compliance with provider rules are clarified in writing.
  2. Reconnaissance and inventory: All resources, identities and configurations are mapped.
  3. Configuration audit: Non-compliance is detected with CIS Benchmark and CSPM.
  4. Attack path analysis: Privilege escalation paths are derived through IAM/RBAC permission graphs.
  5. Vulnerability verification: Findings are confirmed with proof (PoC) within authorized scope.
  6. Reporting and remediation: An executive summary, technical detail and prioritized remediation steps are presented.

Frequently Asked Questions

Do I need permission from the provider before performing a cloud penetration test?

AWS and Microsoft publish testing policies that do not require prior approval for most services in your own account. However, DoS, port flooding and tests affecting the provider's shared infrastructure require separate approval or are prohibited. DSET clarifies provider rules and scope before every test.

Are cloud pentest and traditional pentest the same thing?

No. Traditional pentest focuses on network ports and services; cloud pentest focuses on identities, IAM/RBAC permissions and the control plane. The attack paths and tools are entirely different.

Isn't Microsoft 365 already protected by Microsoft?

Under the shared responsibility model, Microsoft protects the application infrastructure, but user identities, OAuth application permissions, conditional access and data sharing settings are the customer's responsibility. These are the most frequently exploited areas.

Does CSPM replace a penetration test?

No. CSPM provides continuous configuration auditing and detects misconfigurations, but it does not verify whether these turn into a real attack path. The two are complementary: CSPM offers continuous visibility, while pentest offers in-depth verification.

How dangerous is an open S3 bucket?

A publicly accessible S3 bucket or Azure Blob container can anonymously expose an organization's most sensitive data. Many major data breaches stem from this misconfiguration. DSET verifies these findings with proof and provides prioritized remediation steps.

What exactly does KAOS do in a cloud test?

KAOS is DSET's AI-powered offensive security agent. In authorized tests, it performs reconnaissance, IAM misconfiguration detection, open storage analysis and identity attack path mapping; it verifies vulnerabilities with proof (PoC) and reports them. All tests are within authorized scope and in compliance with provider rules.

Sources

DSET Information and Cybersecurity (established 2003). For corporate cloud security audits and continuous scanning with KAOS: +90 536 662 38 09.