99% of cloud security incidents are the fault of the client, not the provider. This is Gartner (Through 2025, original publication 2019), quoted by CybelAngel. Not zero-day and not APT-grouping: enough one forgotten tick in the access settings. Large businesses simultaneously hold thousands of mysified cloud resources, and the average configuration error detection time is months. During this time, automated scanners have time to index and unload data from the forgotten S3-bouquet. Cloud incursions rose 26% in 2024 (CrowdStrike Global Threat Report 2025) and by 37% in 2025 (CybelAngel), and attacks using valid credentials by 71% (IBM X-Force 2025). The misofening of the cloud is the cheapest for the attacking vector: no need for exploits, enough curl and understanding where to look.
Topic map: navigation on the cloud security cluster
Kill chain cloud attack: 6 stages from reconnaissance to exfiltration
The misification of the cloud is not an isolated error. This is the starting point of a full-fledged attack chain. On cloud pentests, I pass the same sequence that fits into specific MITRE ATT&CK tactics:
The chain is nonlinear - it branches depending on the finds. The open tank gives a straight path to the T1530 (Data from Cloud Storage). The leaked .env-aile with AWS keys in the same tank is already T1078.004 and then the neutral movement inside the cloud account. SSRF in the EC2 web application is a classic T1552.005 with the extraction of temporary credentials from metadata service.
OWASP attributes open cloud storages to the category A05:2021 - Security Misconfiguration: insecure default configurations, open cloud storage. Not a theoretical classification - an accurate description of what is found on every second cloud pentest.
And this is what distinguishes the cloud kill chain from on-premise: each stage is performed through the API, without having to break the network perimeter. No firewall between the attacker and your S3-backet – there is only an access configuration. Is she wrong? The attacker works directly with the provider’s cloud API from anywhere in the world.
Detailed methodology with a full set of tools and real chains - in a guide Cloud Infrastructure Pentest: Methodology, Tools and Real Efforts.
Open S3-bouquets, Azure Blob and GCP Storage: 3 clouds - one system error
Misconfigurations of cloud storage are responsible for 23% of all cloud security incidents in 2025 (CybelAngel). The scale of specific incidents is impressive: in August-September 2025, the Casmer Labs (Cloud Storage Security) team found a publicly available S3-babket with hundreds of thousands of bank transfer PDFs - customer names, account numbers, IFSC codes, debit authorization documents. The bucket was active: the new files continued to arrive in the analysis process. No hacking - enough public URL.
AWS S3: Global Namespace as a Gift to an Attacker
S3-bakeries live in a global namespace. If company-prod-backups exists, it belongs to someone - and the attacker checks the availability of one team:
Azure Blob Storage: A False Sense of Security
Containers inside storage accounts. Anonymous access is possible if storage account allows allowBlobPublicAccess and the container is configured as container (listening + reading) or blob (reading by direct link). Microsoft changed the default for the new storage in November 2023, disabling the anonymous access - but the existing accounts with the misof configuration of Azure Blob Storage did not affect this update. Verification: curl to endpoint https://<account>.blob.core.windows.net/<container>?restype=container&comp=list - XML-back with a list of blobs means open container. BlobHunter (Python, last update: 2022) lists storage accounts by subscription and checks public access.
GCP Cloud Storage: organizational policies as the last frontier
Team gsutil ls gs://bucket-name for anonymous verification. A typical GCP bucket misconfiguration is a non-activated uniform bucket-level access: each object can have its own ACL, and control turns into chaos. Organizational policy constraints/storage.publicAccessPrevention at the organization level and VPC Service Controls to prevent data exfiltration, the two main security boundaries recommended by Google.
The pattern is the same for all three providers: the repository is created “for time” for test wokflou, receives broad access rights, over time, it gets data – and access settings no one revises. According to the observations of Casmer Labs, this lifecycle is repeated in most incidents. On audits, I see the same picture: a kaneshove created six months ago “for integration with the contractor” is still sticking out with SQL dams inside.
Detailed analysis of reconnaissance and operation commands with full examples of ACL and bucket policy: Cloud imconfiguration as attack vector: S3-bouquets, Spines and storage AWS/Azure/GCP.
Public Suffoces and EBS-tom: data that everyone forgot about
EBS Snapshots (Amazon Elastic Block Store) - point-in-time copies of virtual machine drives - one of the most underrated sources of data leakage. Organizations rely on snapshots to quickly restore EC2-instalnes, but often leave them public - available to any AWS account.
In practice, the operation looks like this: the attacker through the AWS CLI lists public snapshots in the target region, mounts the snapshot found to its own EC2-instant and gets full access to the file system - configuration files, credentials, SSH keys, database dumps. The whole operation takes place in the account of the attacker, without any interaction with the victim's infrastructure. The victim will not even know - no alerates, no lanes in her CloudTrail.
According to Trend Micro, among the goals of cloud ransomware EBS-snapshots are in a priority position: without them, system recovery can take days. Attackers destroy snapshots after copying data to their account, blocking any recovery pathways. A similar problem exists for RDS-slips (PostgreSQL, MySQL, Aurora data) - client data, transactions and credentials are available when incorrect shared settings.
A separate threat is container registries. According to Trend Micro, Amazon Elastic Container Registry (ECR) contains images on which CI/CD-PIplays and production-decking. Compromising or removing images can paralyze all the deployment environments.
What to do right now: launch aws ec2 describe-snapshots --owner-ids <your-account-id> --query 'Snapshots[].SnapshotId' --output text | xargs -n1 -I{} aws ec2 describe-snapshot-attribute --snapshot-id {} --attribute createVolumePermission to detect public snapshots. Implement Service Control Policy (SCP) at the level of AWS Organization, which prohibits the creation of public snapshots. Check RDS Snippets: aws rds describe-db-snapshot-attributes --db-snapshot-identifier <id> on each of your snapshot - look for restore attribute with value all (Meaning of public access).
S3-ransomware: when the storage mix configuration is converted into an encryption
Ransomware groups have adapted tactics for cloud infrastructure. Researchers (Halcyon Research, Trend Micro) have described several variants of S3-ransomware that exploit the Native AWS encryption mechanisms instead of traditional ransomware binaries. Beautiful move - why drag your cipher, if AWS encrypts everything itself?
The key scenario described by Halcyon Research (Cadfinger, January 2025): the attacker uses SSE-C (Server-Side Encryption with Customer-Provided Keys) to rewrite objects in the S3-bag. The encryption key only knows the attacker - AWS stores only HMAC for verification. Original files are deleted, ransom note appears in their place. An alternative is the abuse of SSE-KMS with the rotation of the encryption key to the KMS-controlled key.
Before the attack, the attacker evaluates the backet according to three criteria:
1. Versioning is disconnected - you can not roll back the re-recorded files to the previous version
2. Object Lock is not configured - objects can be freely re-registered and deleted
3. MFA Delete turned off - deletion of versions without multifactor authentication
All three conditions are met - the tank becomes the perfect target. According to Trend Micro, ransomware groups are expanding their target list beyond S3: EBS-slipshots, RDS bases, ECR container images and backup (Glacier, AWS Backup). The logic of the attackers: destroy backups, block the recovery, maximize the pressure on the victim. In real cases, companies without protected backups resorted to the payment of ransoms as the only way to restore data.
What to do: enable versioning and Object Lock (compliance mode) on tanks with critical data. Configure MFA Delete. Use AWS Backup with vault lock - even the compromising IAM keys will not allow you to remove secure backups. Detailed analysis of operation and protection: Cloud imconfiguration as attack vector: S3-bouquets, Spines and storage AWS/Azure/GCP.
SSRF and cloud metadata endpoint: one vulnerability - full access to account
Server-Side Request Forgery (SSRF) in a web application on a cloud virtual machine is one of the most effective ways to capture a whole account. The mechanism is simple to indecency: the application on request of the attacker appeals to the metadata service (IP 169.254.169.254 in AWS and GCP, a special endpoint in Azure) and returns temporary IAM credentials, tied to the role of the country.
The technique is mapping on T1552.005 - Cloud Instante Metadata API MITRE AT&CK. The resulting credentials give the attacker the same rights as the role of the EC2-instantia - and in practice roles are often assigned with excessive privileges (access to S3, DynamoDB, SQS, Secrets Manager). Here’s the key point: one SSRF vulnerability is transformed into a full-fledged initial access to a cloud account through stolen temporary keys.
AWS introduced IMDSv2 (Instance Metadata Service v2) with a mandatory session-tone for queries to metadata, which greatly complicates operation through a simple SSRF. But IMDSv2 is not forcibly on all instances – the organizations must clearly migrate. They don't migrate. In Azure, IMDS plays a similar role with Managed Identity, in GCP - metadata server with a headline Metadata-Flavor: Google.
A separate threat is vulnerabilities at the application level that can bypass even IMDSv2. CVE-2026-40175 in the Axios library (CVSS 4.8, Medium) demonstrates a chain in which prototype pollution, in mind-due to inject unsanitized header values into outgoing HTTP requests (CWE-113 Improper Neutralization of CRF Sequences in HTTP Headers, CWE-444 HTTP Request Smuggling, CWE-918 SRF). This is not RCE - but header injection can theoretically be used as an SSRF vector to access the metadata endpoint when using IMDSv1; for IMDSv2, this CVE does not provide a bypass, since IMDSv2 requires a separate PUT query with session-token. Detailed analysis: CVE-2026-40175: Prototype Pollution in Axios - header injection and SSRF vector.
To countertact T1552.005 MITRE D3FEND, recommends: Configuration Inventory (D3-CI) to audit IMDSv2 settings of all instances, Credential Compromise Scope Anaz (D3-CCSA) to assess the scale of compromise when the metad metatadentials and Credential Revocation (D-3-CR) calculating the compromise scale.
What to do: forcibly enable IMDSv2 via --metadata-options HttpTokens=required every EC2-instanza. Keep secure review web applications for SSRF. In-depth analysis from IMDSv1 to post-explanation: SSRF attack on cloud credentials.
IAM-misconfigurations: from read-only to full account capture in 5 steps
IAM (Identity and Access Management) is the foundation of cloud security and at the same time the most frequent point of failure. Technique T1078.004 - Valid Accounts: Cloud Accounts It is included in four tactics of MITRE ATT&CK: initial access, persistence, privilege escalation and defense evasion.
According to the CrowdStrike Global Threat Report 2025, 75% of cloud incursions in 2024 involved valid accounting data - not exploits, not malware, but legitimate keys and tokens. IBM X-Force estimates the volume of fresh credentials appearing daily on the shadow platforms in more than 6000 records - cloud keys are included in this stream along with corporate passwords.
Typical IAM-misconfigurations that I find on audits:
• Wildcard Politicies ("Action": "", "Resource": "") - full access to all services of the account. It is more common than I would like
• Long-lived access keys without rotation - single key compromise means constant access
• Cross-account trust relationships with broad rights - lateral movement between accounts
• No Service Control Policies (SCP) - no restrictions even for administrators
• Preferred roles on EC2-instances performing one narrow task (classic: an instalment to send email has AdministratorAccess)
In GCP, a similar problem: the use of primitive roles (Owner/Editor/Viewer) instead of predefined roles and the leak of JSON-keys of service accounts. Google recommends the Workload Identity Federation instead of JSON keys and an organizational policy that prohibits the creation of service account keys.
About 41 detection rules for the tag T1078.004 are available in SigmaHQ to monitor IAM-anomaly (repository is regularly updated) - from aws_iam_s3browser_loginprofile_creation.yml (creating a login profile via S3 Browser as a potential persistence) azure_mfa_interrupted.yml and azure_mfa_denies.yml (Detection of brute force through MFA stops).
What to do: Conduct an audit of IAM using AWS IAM Access Analyzer and Prowler. Remove unused access keys older than 90 days. The principle of least privileges - each role is obtained only by the permissions of those which are needed for a specific task. Detailed escalation techniques: Increasing the privileges of AWS IAM: escalation techniques through roles, policies and misconfiguration.
Infrastructure as Code: Unsafe configuration is born before the deck
Terraform modules, CloudFormation templates and Kubernetes-manifes – code that determines your infrastructure. Error in IaC-config is a mys configuration that is reproduced at each deck and scaled on all environments automatically. Wrote once crooked - got ten equally leaky media.
Typical IaC-miconfigurations from real audits:
• acl = "public-read"in Terraform resource aws_s3_bucket- unprotected cloud storage is created public from the moment of birth
• Absence encryption_configuration- data is stored without encryption
• Security group c ingress 0.0.0.0/0:22- SSH is open to the Internet
• Kubernetes pod with securityContext.privileged: true- container with root rights on the host (check the compliance of DISA Kubernetes STIG)
IaC Static Analysis Tools detect these errors before the deck: Trivy (Aqua Security, actively supported, covers IaC + containers + CSPM), Checkov (Bridgecrew/Palo Alto), tfsec. Integration into CI/CD-pipeline allows you to block a deck with critical mys configurations - a shift-left approach that prevents the problem instead of responding.
A separate vector is supply chain attack through IaC dependencies. In early June 2026, Microsoft Security published a report on the large-scale campaign of Red Hat ndm Miasma: compromising more than 90 versions of packages @redhat-cloud-services with theft of credentials from CI/CD environments and cloud platforms. The malware code was distributed at each npm install, infecting the assembly environment.
What to do: introduce pre-commit hooks with Trivy or Checkov for all IaC repositories. Conduct an audit of dependencies - npm, pip, Go modules - for typosquatting. Full guide: Infrastructure as Code: From Misconfiguration in Terraform to SIEM detection rule.
Serverless and SaaS: Expanding Perimeter of Cloud Attacks
The misification of the cloud is not limited to storage and virtual machines. Serverless functions (AWS Lambda, Azure Functions, Google Cloud Functions) and SaaS-platform (Salesforce, Microsoft 365) form new attack surfaces that often fall out of the field of security commands. And in vain.
Serverless: Injection and Evening
The Lambda function that processes events from S3 or API Gateway inherits an IAM role with certain privileges. If the input data is not validated - the attacker conducts command injection through the event payload, receives the execution of the context function and uses its IAM role to access other account resources (DynamoDB, S3, Secrets Manager). This chain is a specific example of an lateral movement inside a cloud account without compromising traditional servers.
The specifics of serverless security: EDR on Lambda can not be put, the container lives for a minute (try time to react successfully), and CloudWatch Logs is often the only native source of telemetry. This creates blind zones that attackers are actively exploiting.
Detailed analysis of technicians: Attacks on serverless functions: injection, event poisoning and compulsory escalation.
SaaS platforms: Salesforce as an indicative example
Salesforce is one of the most common SaaS platforms in the enterprise-segment. Open API enportons, excess sharing rules, guest user access with broad rights lead to data leaks without any “hacking” in the classical sense. The problem is similar to the S3 imconfiguration - data becomes available on a direct URL because of an error in the access settings.
Turn-based audit Salesforce: Salesforce Mysconfigurations: We find and close to leaking.
What to do: Include serverless features and SaaS platform options in cloud audit. For Lambda - minimize the IAM role to the desired permissions, validate all entrance events. For Salesforce - audit of guest user access and sharing rules.
Attacks on cloud accounts: credential theft and account trust
Commutation of a cloud account is the final target of most attacks through myconfiguration. Stolen IAM keys intercepted via SSRF temporary credentials, passwords from open .env- files - all roads lead to account takeover.
The scale of the problem with the credentials: IBM X-Force Thrade Intelligence Index 2025 records an increase in attacks using valid accounting data by 71% year-on-year. CrowdStrike notes that the average time of the lateral movement after initial access was 62 minutes in 2024, with a record of 51 seconds. At such speeds, manual response does not have time. Just think about it: 51 seconds from initial access to the local movement.
Techniques of fixing in the cloud account after the initial access:
• Persistence through IAM - creating hidden IAM users, additional access keys, Automation Runbook in Azure (for verification: Atomic Red Team contains the Azure Persistence Automation Automation Runbook Created or Modified according to T1078.004)
• Credential stuffing - using dilapidated passwords to access cloud consoles
• Session hijacking - interception of tokens via XSS or leaked session cookies
• Abuse of trusted integrations - use of CI/CD-pipelines for lateral movement
MITRE D3FEND recommends to counteract T1078.004: Access Modeling (D3-AM) to identify abnormal account patterns, Account Locking (D3-AL) when anomalies and Agent Authentication (D3-AA) are detected to enhance authentication mechanisms.
What to do: MFA for all IAM users and root account. CloudTrail with alerting to create new IAM users and access keys. Full analysis with the details of the rules: Attacks on cloud accounts AWS and Azure: equipment, detection and real cases.
Cloud Storage Security Audit: CSPM, Tools and Detection Rules
Detection of myconfigurations - a task that can not be solved by manual checks. Cloud resources are constantly created, modified and removed. You need continuous automated monitoring - Cloud Security Posture Management (CSPM).
Detection rules and verification
41 detection rule for tag T1078.004 is available to monitor suspicious cloud activity in SigmaHQ. Examples for implementation in SIEM:
• aws_iam_s3browser_loginprofile_creation.yml- detection of the creation of login profile via S3 Browser (persistence)
• azure_tap_added.yml- adding Temporary Access Pass to Entra ID (legitimate function for onboarding; abnormal outside HR/onboarding workingflow - potential account takeover)
• azure_mfa_denies.yml- MFA multiple bounces (brute force / credential stuffing)
The Atomic Red Team provides reproducible tests to check your detection-capabilities:
• T1530 : AWS - Scan for Anonymous Access to S3 (iaas:aws); Azure - D Azumpure Storage Account Objects via CLI (iaas:azure). Tests T1530 in Atomic Red Team are available only for iaas:aws and iaas:azure platforms
• T1619 : AWS - Scan for Anonymous Access to S3 (iaas:aws); Azure - Scan for Anonymous Access to Azure Storage (iaas:azure)
• T1078.004 : Creating GCP Service Account and Key (iaas:gcp); Azure Persistence Automation Runbook (iaas:azure); GCP - Create Custom IAM Role (iaas:gcp)
Nacional Tools of Providers
AWS Config + Security Hub, Azure Defender for Storage + Microsoft Defender for Cloud, GCP Security Command Center - native CSPM solutions integrated with CloudTrail / Activity Log / Cloud Audit Logs. Minimum for each organization: setting up an alert for specific events - creating a public tank, disconnecting encryption, changing IAM policy, creating new access keys.
What to do: Deploy Prowler for initial audit (free of charge, cover CIS Benchmarks). Configure the Sigma rule in SIEM for continuous monitoring. Run the Atomic Red Team tests for the T1530 and T1619 for verification detection. Full methodology of cloud pentest: Cloud Infrastructure Pentest: Methodology, Tools and Real Efforts.
Checklist: 12 actions for immediate audit of cloud storage
This checklist is suitable for transmitting to a security engineer or included in the audit report. Each item is a specific action with a command or setup.
1. Block Public Access at account level - AWS: aws s3control put-public-access-block; Azure: allowBlobPublicAccess = falseon account storage; GCP: organization policy constraints/storage.publicAccessPrevention
2. Audit of existing public tanks - Prowler check s3_bucket_public_accessor manual checking through aws s3api get-bucket-aclfor each tank
3. Enable versioning on all channels with critical data - re-recording protection and S3-ransomware
4. Configure Object Lock (compliance mode) - the immutability of objects on the specified delayed period
5. Enable MFA Delete - prohibition to remove object versions without MFA-confirmation
6. Forced to include IMDSv2 on all EC2-instinsters - HttpTokens=required(Protection from SSRF to metadata)
7. Audit IAM-politic - Remove Wildcardcards ("Action": "*"), rotate access keys over 90 days, remove unused keys
8. Enable CloudTrail Data Events for S3 - GetObject/PutObject/DeleteObject for Foricsens and Futureing
9. Check public EBS and RDS-slip Slipshots - aws ec2 describe-snapshots --owner-ids <your-account-id> --query 'Snapshots[].SnapshotId' --output text | xargs -n1 -I{} aws ec2 describe-snapshot-attribute --snapshot-id {} --attribute createVolumePermission; aws rds describe-db-snapshots --snapshot-type public
10. Configure encryption at rest - SSE-KMS with customer-managed keys (AWS), Entra ID auth + customer-managed keys via Key Vault (Azure), CMEK (GCP)
11. Deploy CSPM - Prowler/Scout Suite for Contemporary or Native Security Hub / Defender for Cloud / Security Command Center
12. Integrate IaC scanning in CI/CD - Trivy/Checkov in pre-mager check Terraform/CloudFormation/Kubernetes-manifes
For Azure additionally: disable shared key access (use only Entra ID auth), user-delegation SAS instead of account SAS, Private Endpoints for storage.
For GCP additionally: Instult uniform bucket-level access, organizational policy of banning the creation of service accounts keys, VPC Service Controls to prevent data exfiltration.
Where Cloud Security Is Going: Prediction and Priorities
Cloud Security Alliance in a report for 2024 puts mys configurations and insufficient control of changes in first place among cloud threats - rising from the third position in just two years. Dynamics are unambiguous: the growth of cloud intravasions from 26% in 2024 to 37% in 2025 (Cybel Angel) is a steady curve, not a temporary surge.
Three shifts that will determine the next year.
Shift-left will be mandatory. Detection of mys configuration after the deck is a late reaction. CSPM + IaC scanning in CI/CD + Policy-as-Code is the minimum stack for an organization that does not want to get into the news. According to CloudAdvisor (referring to Gartner), by 2026, 60% of organizations will consider the prevention of myconfigration as a priority of cloud security. The source Gartner is not verified.
Ransomware in the cloud will cease to be exotic. The Codefinger campaign and Trend Micro studies have shown that S3-ransomware is technically ripe. The next step is mass automation, which operates typical mys configurations according to the template.
Credential theft will continue to accelerate. At 6000+ credentials leaks daily and a reduction in the time of the lateral movement to minutes and seconds - detection and response must work in real time.
Priority right now: go checklist from 12 points higher. This will close 80% of typical myconfigurations in one sprint.
Most of the teams I see on audits spend a budget on WAF, EDR and SIEM – and at the same time keep S3-bakeries with data in public-read mode. Not an exaggeration. Thousands of mys-configured resources per medium-sized enterprise – and months before detection.
The problem is not the tools. Prowler is free, AWS Config is worth a penny, Block Public Access is enabled by one team. The problem is in organizational blindness: the configuration of the cloud is not perceived as the surface of the attack. The Security Command monitors network traffic and endpoints, and the cloud control plane is the responsibility zone of “someone of DevOps”. This “someone” creates a tank for test pypline, makes it public for integration with the contractor, switches to the next task – and a week later in the tank there are SQL-dumbra with PII.
Shared responsibility model has been explaining for ten years that the configuration is the client’s zone. But on audits, I continue to find public tanks from companies with SOC, SIEM and six ISO certifications. The problem is deeper: cloud security is not an add-on on top of an existing life-sufficient program, but a separate discipline with its own tools, processes and a competency model. Who in a year will perceive CSPM as “another traction for a tick” rather than as a fundamental layer of monitoring on a par with SIEM – will learn about their misifications from the public reports of researchers. Or from the ransom requirement.
Topic map: navigation on the cloud security cluster
Kill chain cloud attack: 6 stages from reconnaissance to exfiltration
The misification of the cloud is not an isolated error. This is the starting point of a full-fledged attack chain. On cloud pentests, I pass the same sequence that fits into specific MITRE ATT&CK tactics:
The chain is nonlinear - it branches depending on the finds. The open tank gives a straight path to the T1530 (Data from Cloud Storage). The leaked .env-aile with AWS keys in the same tank is already T1078.004 and then the neutral movement inside the cloud account. SSRF in the EC2 web application is a classic T1552.005 with the extraction of temporary credentials from metadata service.
OWASP attributes open cloud storages to the category A05:2021 - Security Misconfiguration: insecure default configurations, open cloud storage. Not a theoretical classification - an accurate description of what is found on every second cloud pentest.
And this is what distinguishes the cloud kill chain from on-premise: each stage is performed through the API, without having to break the network perimeter. No firewall between the attacker and your S3-backet – there is only an access configuration. Is she wrong? The attacker works directly with the provider’s cloud API from anywhere in the world.
Detailed methodology with a full set of tools and real chains - in a guide Cloud Infrastructure Pentest: Methodology, Tools and Real Efforts.
Open S3-bouquets, Azure Blob and GCP Storage: 3 clouds - one system error
Misconfigurations of cloud storage are responsible for 23% of all cloud security incidents in 2025 (CybelAngel). The scale of specific incidents is impressive: in August-September 2025, the Casmer Labs (Cloud Storage Security) team found a publicly available S3-babket with hundreds of thousands of bank transfer PDFs - customer names, account numbers, IFSC codes, debit authorization documents. The bucket was active: the new files continued to arrive in the analysis process. No hacking - enough public URL.
AWS S3: Global Namespace as a Gift to an Attacker
S3-bakeries live in a global namespace. If company-prod-backups exists, it belongs to someone - and the attacker checks the availability of one team:
Successful response to --no-sign-request means public access without authentication. Intelligence includes passive methods: Google dorks site:s3.amazonaws.com "companyname", GrayhatWarfare to search by public buckets and files index, crt.sh to detect subdomains indicating S3-hosted resources. s3scanner (Last Release: 2023, Python) Automates Bench and ACL Check. To search for leaked keys - trufflehog v3 (>15k GitHub stars, actively supported), which scans the git history and pulls AWS keys, tokens, passwords.
Azure Blob Storage: A False Sense of Security
Containers inside storage accounts. Anonymous access is possible if storage account allows allowBlobPublicAccess and the container is configured as container (listening + reading) or blob (reading by direct link). Microsoft changed the default for the new storage in November 2023, disabling the anonymous access - but the existing accounts with the misof configuration of Azure Blob Storage did not affect this update. Verification: curl to endpoint https://<account>.blob.core.windows.net/<container>?restype=container&comp=list - XML-back with a list of blobs means open container. BlobHunter (Python, last update: 2022) lists storage accounts by subscription and checks public access.
GCP Cloud Storage: organizational policies as the last frontier
Team gsutil ls gs://bucket-name for anonymous verification. A typical GCP bucket misconfiguration is a non-activated uniform bucket-level access: each object can have its own ACL, and control turns into chaos. Organizational policy constraints/storage.publicAccessPrevention at the organization level and VPC Service Controls to prevent data exfiltration, the two main security boundaries recommended by Google.
The pattern is the same for all three providers: the repository is created “for time” for test wokflou, receives broad access rights, over time, it gets data – and access settings no one revises. According to the observations of Casmer Labs, this lifecycle is repeated in most incidents. On audits, I see the same picture: a kaneshove created six months ago “for integration with the contractor” is still sticking out with SQL dams inside.
Detailed analysis of reconnaissance and operation commands with full examples of ACL and bucket policy: Cloud imconfiguration as attack vector: S3-bouquets, Spines and storage AWS/Azure/GCP.
Public Suffoces and EBS-tom: data that everyone forgot about
EBS Snapshots (Amazon Elastic Block Store) - point-in-time copies of virtual machine drives - one of the most underrated sources of data leakage. Organizations rely on snapshots to quickly restore EC2-instalnes, but often leave them public - available to any AWS account.
In practice, the operation looks like this: the attacker through the AWS CLI lists public snapshots in the target region, mounts the snapshot found to its own EC2-instant and gets full access to the file system - configuration files, credentials, SSH keys, database dumps. The whole operation takes place in the account of the attacker, without any interaction with the victim's infrastructure. The victim will not even know - no alerates, no lanes in her CloudTrail.
According to Trend Micro, among the goals of cloud ransomware EBS-snapshots are in a priority position: without them, system recovery can take days. Attackers destroy snapshots after copying data to their account, blocking any recovery pathways. A similar problem exists for RDS-slips (PostgreSQL, MySQL, Aurora data) - client data, transactions and credentials are available when incorrect shared settings.
A separate threat is container registries. According to Trend Micro, Amazon Elastic Container Registry (ECR) contains images on which CI/CD-PIplays and production-decking. Compromising or removing images can paralyze all the deployment environments.
What to do right now: launch aws ec2 describe-snapshots --owner-ids <your-account-id> --query 'Snapshots[].SnapshotId' --output text | xargs -n1 -I{} aws ec2 describe-snapshot-attribute --snapshot-id {} --attribute createVolumePermission to detect public snapshots. Implement Service Control Policy (SCP) at the level of AWS Organization, which prohibits the creation of public snapshots. Check RDS Snippets: aws rds describe-db-snapshot-attributes --db-snapshot-identifier <id> on each of your snapshot - look for restore attribute with value all (Meaning of public access).
S3-ransomware: when the storage mix configuration is converted into an encryption
Ransomware groups have adapted tactics for cloud infrastructure. Researchers (Halcyon Research, Trend Micro) have described several variants of S3-ransomware that exploit the Native AWS encryption mechanisms instead of traditional ransomware binaries. Beautiful move - why drag your cipher, if AWS encrypts everything itself?
The key scenario described by Halcyon Research (Cadfinger, January 2025): the attacker uses SSE-C (Server-Side Encryption with Customer-Provided Keys) to rewrite objects in the S3-bag. The encryption key only knows the attacker - AWS stores only HMAC for verification. Original files are deleted, ransom note appears in their place. An alternative is the abuse of SSE-KMS with the rotation of the encryption key to the KMS-controlled key.
Before the attack, the attacker evaluates the backet according to three criteria:
1. Versioning is disconnected - you can not roll back the re-recorded files to the previous version
2. Object Lock is not configured - objects can be freely re-registered and deleted
3. MFA Delete turned off - deletion of versions without multifactor authentication
All three conditions are met - the tank becomes the perfect target. According to Trend Micro, ransomware groups are expanding their target list beyond S3: EBS-slipshots, RDS bases, ECR container images and backup (Glacier, AWS Backup). The logic of the attackers: destroy backups, block the recovery, maximize the pressure on the victim. In real cases, companies without protected backups resorted to the payment of ransoms as the only way to restore data.
What to do: enable versioning and Object Lock (compliance mode) on tanks with critical data. Configure MFA Delete. Use AWS Backup with vault lock - even the compromising IAM keys will not allow you to remove secure backups. Detailed analysis of operation and protection: Cloud imconfiguration as attack vector: S3-bouquets, Spines and storage AWS/Azure/GCP.
SSRF and cloud metadata endpoint: one vulnerability - full access to account
Server-Side Request Forgery (SSRF) in a web application on a cloud virtual machine is one of the most effective ways to capture a whole account. The mechanism is simple to indecency: the application on request of the attacker appeals to the metadata service (IP 169.254.169.254 in AWS and GCP, a special endpoint in Azure) and returns temporary IAM credentials, tied to the role of the country.
The technique is mapping on T1552.005 - Cloud Instante Metadata API MITRE AT&CK. The resulting credentials give the attacker the same rights as the role of the EC2-instantia - and in practice roles are often assigned with excessive privileges (access to S3, DynamoDB, SQS, Secrets Manager). Here’s the key point: one SSRF vulnerability is transformed into a full-fledged initial access to a cloud account through stolen temporary keys.
AWS introduced IMDSv2 (Instance Metadata Service v2) with a mandatory session-tone for queries to metadata, which greatly complicates operation through a simple SSRF. But IMDSv2 is not forcibly on all instances – the organizations must clearly migrate. They don't migrate. In Azure, IMDS plays a similar role with Managed Identity, in GCP - metadata server with a headline Metadata-Flavor: Google.
A separate threat is vulnerabilities at the application level that can bypass even IMDSv2. CVE-2026-40175 in the Axios library (CVSS 4.8, Medium) demonstrates a chain in which prototype pollution, in mind-due to inject unsanitized header values into outgoing HTTP requests (CWE-113 Improper Neutralization of CRF Sequences in HTTP Headers, CWE-444 HTTP Request Smuggling, CWE-918 SRF). This is not RCE - but header injection can theoretically be used as an SSRF vector to access the metadata endpoint when using IMDSv1; for IMDSv2, this CVE does not provide a bypass, since IMDSv2 requires a separate PUT query with session-token. Detailed analysis: CVE-2026-40175: Prototype Pollution in Axios - header injection and SSRF vector.
To countertact T1552.005 MITRE D3FEND, recommends: Configuration Inventory (D3-CI) to audit IMDSv2 settings of all instances, Credential Compromise Scope Anaz (D3-CCSA) to assess the scale of compromise when the metad metatadentials and Credential Revocation (D-3-CR) calculating the compromise scale.
What to do: forcibly enable IMDSv2 via --metadata-options HttpTokens=required every EC2-instanza. Keep secure review web applications for SSRF. In-depth analysis from IMDSv1 to post-explanation: SSRF attack on cloud credentials.
IAM-misconfigurations: from read-only to full account capture in 5 steps
IAM (Identity and Access Management) is the foundation of cloud security and at the same time the most frequent point of failure. Technique T1078.004 - Valid Accounts: Cloud Accounts It is included in four tactics of MITRE ATT&CK: initial access, persistence, privilege escalation and defense evasion.
According to the CrowdStrike Global Threat Report 2025, 75% of cloud incursions in 2024 involved valid accounting data - not exploits, not malware, but legitimate keys and tokens. IBM X-Force estimates the volume of fresh credentials appearing daily on the shadow platforms in more than 6000 records - cloud keys are included in this stream along with corporate passwords.
Typical IAM-misconfigurations that I find on audits:
• Wildcard Politicies ("Action": "", "Resource": "") - full access to all services of the account. It is more common than I would like
• Long-lived access keys without rotation - single key compromise means constant access
• Cross-account trust relationships with broad rights - lateral movement between accounts
• No Service Control Policies (SCP) - no restrictions even for administrators
• Preferred roles on EC2-instances performing one narrow task (classic: an instalment to send email has AdministratorAccess)
In GCP, a similar problem: the use of primitive roles (Owner/Editor/Viewer) instead of predefined roles and the leak of JSON-keys of service accounts. Google recommends the Workload Identity Federation instead of JSON keys and an organizational policy that prohibits the creation of service account keys.
About 41 detection rules for the tag T1078.004 are available in SigmaHQ to monitor IAM-anomaly (repository is regularly updated) - from aws_iam_s3browser_loginprofile_creation.yml (creating a login profile via S3 Browser as a potential persistence) azure_mfa_interrupted.yml and azure_mfa_denies.yml (Detection of brute force through MFA stops).
What to do: Conduct an audit of IAM using AWS IAM Access Analyzer and Prowler. Remove unused access keys older than 90 days. The principle of least privileges - each role is obtained only by the permissions of those which are needed for a specific task. Detailed escalation techniques: Increasing the privileges of AWS IAM: escalation techniques through roles, policies and misconfiguration.
Infrastructure as Code: Unsafe configuration is born before the deck
Terraform modules, CloudFormation templates and Kubernetes-manifes – code that determines your infrastructure. Error in IaC-config is a mys configuration that is reproduced at each deck and scaled on all environments automatically. Wrote once crooked - got ten equally leaky media.
Typical IaC-miconfigurations from real audits:
• acl = "public-read"in Terraform resource aws_s3_bucket- unprotected cloud storage is created public from the moment of birth
• Absence encryption_configuration- data is stored without encryption
• Security group c ingress 0.0.0.0/0:22- SSH is open to the Internet
• Kubernetes pod with securityContext.privileged: true- container with root rights on the host (check the compliance of DISA Kubernetes STIG)
IaC Static Analysis Tools detect these errors before the deck: Trivy (Aqua Security, actively supported, covers IaC + containers + CSPM), Checkov (Bridgecrew/Palo Alto), tfsec. Integration into CI/CD-pipeline allows you to block a deck with critical mys configurations - a shift-left approach that prevents the problem instead of responding.
A separate vector is supply chain attack through IaC dependencies. In early June 2026, Microsoft Security published a report on the large-scale campaign of Red Hat ndm Miasma: compromising more than 90 versions of packages @redhat-cloud-services with theft of credentials from CI/CD environments and cloud platforms. The malware code was distributed at each npm install, infecting the assembly environment.
What to do: introduce pre-commit hooks with Trivy or Checkov for all IaC repositories. Conduct an audit of dependencies - npm, pip, Go modules - for typosquatting. Full guide: Infrastructure as Code: From Misconfiguration in Terraform to SIEM detection rule.
Serverless and SaaS: Expanding Perimeter of Cloud Attacks
The misification of the cloud is not limited to storage and virtual machines. Serverless functions (AWS Lambda, Azure Functions, Google Cloud Functions) and SaaS-platform (Salesforce, Microsoft 365) form new attack surfaces that often fall out of the field of security commands. And in vain.
Serverless: Injection and Evening
The Lambda function that processes events from S3 or API Gateway inherits an IAM role with certain privileges. If the input data is not validated - the attacker conducts command injection through the event payload, receives the execution of the context function and uses its IAM role to access other account resources (DynamoDB, S3, Secrets Manager). This chain is a specific example of an lateral movement inside a cloud account without compromising traditional servers.
The specifics of serverless security: EDR on Lambda can not be put, the container lives for a minute (try time to react successfully), and CloudWatch Logs is often the only native source of telemetry. This creates blind zones that attackers are actively exploiting.
Detailed analysis of technicians: Attacks on serverless functions: injection, event poisoning and compulsory escalation.
SaaS platforms: Salesforce as an indicative example
Salesforce is one of the most common SaaS platforms in the enterprise-segment. Open API enportons, excess sharing rules, guest user access with broad rights lead to data leaks without any “hacking” in the classical sense. The problem is similar to the S3 imconfiguration - data becomes available on a direct URL because of an error in the access settings.
Turn-based audit Salesforce: Salesforce Mysconfigurations: We find and close to leaking.
What to do: Include serverless features and SaaS platform options in cloud audit. For Lambda - minimize the IAM role to the desired permissions, validate all entrance events. For Salesforce - audit of guest user access and sharing rules.
Attacks on cloud accounts: credential theft and account trust
Commutation of a cloud account is the final target of most attacks through myconfiguration. Stolen IAM keys intercepted via SSRF temporary credentials, passwords from open .env- files - all roads lead to account takeover.
The scale of the problem with the credentials: IBM X-Force Thrade Intelligence Index 2025 records an increase in attacks using valid accounting data by 71% year-on-year. CrowdStrike notes that the average time of the lateral movement after initial access was 62 minutes in 2024, with a record of 51 seconds. At such speeds, manual response does not have time. Just think about it: 51 seconds from initial access to the local movement.
Techniques of fixing in the cloud account after the initial access:
• Persistence through IAM - creating hidden IAM users, additional access keys, Automation Runbook in Azure (for verification: Atomic Red Team contains the Azure Persistence Automation Automation Runbook Created or Modified according to T1078.004)
• Credential stuffing - using dilapidated passwords to access cloud consoles
• Session hijacking - interception of tokens via XSS or leaked session cookies
• Abuse of trusted integrations - use of CI/CD-pipelines for lateral movement
MITRE D3FEND recommends to counteract T1078.004: Access Modeling (D3-AM) to identify abnormal account patterns, Account Locking (D3-AL) when anomalies and Agent Authentication (D3-AA) are detected to enhance authentication mechanisms.
What to do: MFA for all IAM users and root account. CloudTrail with alerting to create new IAM users and access keys. Full analysis with the details of the rules: Attacks on cloud accounts AWS and Azure: equipment, detection and real cases.
Cloud Storage Security Audit: CSPM, Tools and Detection Rules
Detection of myconfigurations - a task that can not be solved by manual checks. Cloud resources are constantly created, modified and removed. You need continuous automated monitoring - Cloud Security Posture Management (CSPM).
Detection rules and verification
41 detection rule for tag T1078.004 is available to monitor suspicious cloud activity in SigmaHQ. Examples for implementation in SIEM:
• aws_iam_s3browser_loginprofile_creation.yml- detection of the creation of login profile via S3 Browser (persistence)
• azure_tap_added.yml- adding Temporary Access Pass to Entra ID (legitimate function for onboarding; abnormal outside HR/onboarding workingflow - potential account takeover)
• azure_mfa_denies.yml- MFA multiple bounces (brute force / credential stuffing)
The Atomic Red Team provides reproducible tests to check your detection-capabilities:
• T1530 : AWS - Scan for Anonymous Access to S3 (iaas:aws); Azure - D Azumpure Storage Account Objects via CLI (iaas:azure). Tests T1530 in Atomic Red Team are available only for iaas:aws and iaas:azure platforms
• T1619 : AWS - Scan for Anonymous Access to S3 (iaas:aws); Azure - Scan for Anonymous Access to Azure Storage (iaas:azure)
• T1078.004 : Creating GCP Service Account and Key (iaas:gcp); Azure Persistence Automation Runbook (iaas:azure); GCP - Create Custom IAM Role (iaas:gcp)
Nacional Tools of Providers
AWS Config + Security Hub, Azure Defender for Storage + Microsoft Defender for Cloud, GCP Security Command Center - native CSPM solutions integrated with CloudTrail / Activity Log / Cloud Audit Logs. Minimum for each organization: setting up an alert for specific events - creating a public tank, disconnecting encryption, changing IAM policy, creating new access keys.
What to do: Deploy Prowler for initial audit (free of charge, cover CIS Benchmarks). Configure the Sigma rule in SIEM for continuous monitoring. Run the Atomic Red Team tests for the T1530 and T1619 for verification detection. Full methodology of cloud pentest: Cloud Infrastructure Pentest: Methodology, Tools and Real Efforts.
Checklist: 12 actions for immediate audit of cloud storage
This checklist is suitable for transmitting to a security engineer or included in the audit report. Each item is a specific action with a command or setup.
1. Block Public Access at account level - AWS: aws s3control put-public-access-block; Azure: allowBlobPublicAccess = falseon account storage; GCP: organization policy constraints/storage.publicAccessPrevention
2. Audit of existing public tanks - Prowler check s3_bucket_public_accessor manual checking through aws s3api get-bucket-aclfor each tank
3. Enable versioning on all channels with critical data - re-recording protection and S3-ransomware
4. Configure Object Lock (compliance mode) - the immutability of objects on the specified delayed period
5. Enable MFA Delete - prohibition to remove object versions without MFA-confirmation
6. Forced to include IMDSv2 on all EC2-instinsters - HttpTokens=required(Protection from SSRF to metadata)
7. Audit IAM-politic - Remove Wildcardcards ("Action": "*"), rotate access keys over 90 days, remove unused keys
8. Enable CloudTrail Data Events for S3 - GetObject/PutObject/DeleteObject for Foricsens and Futureing
9. Check public EBS and RDS-slip Slipshots - aws ec2 describe-snapshots --owner-ids <your-account-id> --query 'Snapshots[].SnapshotId' --output text | xargs -n1 -I{} aws ec2 describe-snapshot-attribute --snapshot-id {} --attribute createVolumePermission; aws rds describe-db-snapshots --snapshot-type public
10. Configure encryption at rest - SSE-KMS with customer-managed keys (AWS), Entra ID auth + customer-managed keys via Key Vault (Azure), CMEK (GCP)
11. Deploy CSPM - Prowler/Scout Suite for Contemporary or Native Security Hub / Defender for Cloud / Security Command Center
12. Integrate IaC scanning in CI/CD - Trivy/Checkov in pre-mager check Terraform/CloudFormation/Kubernetes-manifes
For Azure additionally: disable shared key access (use only Entra ID auth), user-delegation SAS instead of account SAS, Private Endpoints for storage.
For GCP additionally: Instult uniform bucket-level access, organizational policy of banning the creation of service accounts keys, VPC Service Controls to prevent data exfiltration.
Where Cloud Security Is Going: Prediction and Priorities
Cloud Security Alliance in a report for 2024 puts mys configurations and insufficient control of changes in first place among cloud threats - rising from the third position in just two years. Dynamics are unambiguous: the growth of cloud intravasions from 26% in 2024 to 37% in 2025 (Cybel Angel) is a steady curve, not a temporary surge.
Three shifts that will determine the next year.
Shift-left will be mandatory. Detection of mys configuration after the deck is a late reaction. CSPM + IaC scanning in CI/CD + Policy-as-Code is the minimum stack for an organization that does not want to get into the news. According to CloudAdvisor (referring to Gartner), by 2026, 60% of organizations will consider the prevention of myconfigration as a priority of cloud security. The source Gartner is not verified.
Ransomware in the cloud will cease to be exotic. The Codefinger campaign and Trend Micro studies have shown that S3-ransomware is technically ripe. The next step is mass automation, which operates typical mys configurations according to the template.
Credential theft will continue to accelerate. At 6000+ credentials leaks daily and a reduction in the time of the lateral movement to minutes and seconds - detection and response must work in real time.
Priority right now: go checklist from 12 points higher. This will close 80% of typical myconfigurations in one sprint.
Most of the teams I see on audits spend a budget on WAF, EDR and SIEM – and at the same time keep S3-bakeries with data in public-read mode. Not an exaggeration. Thousands of mys-configured resources per medium-sized enterprise – and months before detection.
The problem is not the tools. Prowler is free, AWS Config is worth a penny, Block Public Access is enabled by one team. The problem is in organizational blindness: the configuration of the cloud is not perceived as the surface of the attack. The Security Command monitors network traffic and endpoints, and the cloud control plane is the responsibility zone of “someone of DevOps”. This “someone” creates a tank for test pypline, makes it public for integration with the contractor, switches to the next task – and a week later in the tank there are SQL-dumbra with PII.
Shared responsibility model has been explaining for ten years that the configuration is the client’s zone. But on audits, I continue to find public tanks from companies with SOC, SIEM and six ISO certifications. The problem is deeper: cloud security is not an add-on on top of an existing life-sufficient program, but a separate discipline with its own tools, processes and a competency model. Who in a year will perceive CSPM as “another traction for a tick” rather than as a fundamental layer of monitoring on a par with SIEM – will learn about their misifications from the public reports of researchers. Or from the ransom requirement.
