On the penultimate project for fintech, we received read-only IAMkeys “for auditing”. After four hours - full access to theproduction-bouquet with personal data. Chain: iam
assRole on theforgotten ti-role, Lambda-function with execution role, readingSecrets Manager, from there credentials from RDS. Not a singleexploit, not a single CVE - only the regular API-calls of AWS.ScoutSuite did not show the chain privesc through PassRole. Prowler,especially. Found Pacu through iam__privesc_scan, confirmed with hishands. Here is the typical reality of the cloud pentest: the criticalpath does not pass through the open port, but through the IAMconfiguration, and automation sees only individual pieces of themosaic.
Why Cloud Pentest is a Separate Discipline
In on-premise, the usual logic is built around the network route:subnets, open ports, SMB, AD, lateral through WinRM or RDP. In thecloud, the network layer remains, but ceases to be the main source ofauthority. The EC2-tisansion is closed from the Internet - but itsinstance profile gives access to Secrets Manager. Lambda withoutpublic endpoint has a role with production-block rights.CI/CD-pipeline runs from internal GitLab, but its cloud role changesfeatures and policies.
The vector is shifted from network vulnerabilities toconfiguration and identification management vulnerabilities.According to the Wiz State of Cloud Security 2024, more than 80% ofreal incidents in the cloud are not related to softwarevulnerabilities, but with configuration errors: excessive IAM rights,publicly open storage, lack of encryption, unsecured API-endpoint.OWASP confirms the picture - Security Misconfiguration (A05:2021)both Broken Access Control (A01:2021) are stable in the top three,and in the cloud they are especially pronounced.
If you’re at MITRE ATT&CK, a typical cloud-based punchetcovers: Cloud Accounts (T1078.004, Initial Access / Persistence /Privilege Escalation), Cloud Discover Infrastructurey (T1580,Discovery), Cloud Instation Metadata API (T1552.005, CredentialAccess), Data from Cloud Storage (T1530, Collection), AdditionalCloud Credentials (T1098.001, Persistence), Disable or Modify CloudLogs (T1562.008, Defense Evasion). Every technique is not about“catching”, but about the abuse of legitimate APIs. No ID willwork on aws secretsmanager get-secret-value, if the challenge comesfrom the role with rights.
Shared Responsibility Model sets the test boundaries. The provideris responsible for the infrastructure of the cloud (iron,hypervisors), the client - for everything inside the account. Pentestis bounded by the client's area, and it is there that critical findslie. AWS allows testing without prior approval only for explicitlylisted services (EC2, RDS, Lambda, S3, CloudFront, Gateway API andseveral others according to AWS Customer Policy Policy forPenetration Testing); for the rest, you need a filing for SimulatedEvents form. Azure and GCP are similar, but DDoS tests, DNS attacksand flooding are prohibited in all three.
Cloud infrastructure pentest methodology: from reconnaissance topersistence
Cloud surface exploration and transfer of resources
Foreign intelligence in the cloud is not needed for the sake of asubdomain table. The task is to find cloud bindings, forgottenenvironments and resources that are then compared with the internalinventory. CNAME on the old load balancer, object storage endpoint inthe dev zone, staging agent certificate - all this is valuable whenit is clear which workload is behind them and what rights itreceives.
Adjustments to the environment:
• OS: Linux (Kali, Ubuntu 22.04+) or macOS
• AWS CLI v2, Azure CLI, gcloud SDK via a separate --profilefortest account
• Python 3.9+ for ScoutSuite (pip install scoutsuite) and Pacu(Cloning from GitHub)
• At least 4 GB RAM (ScoutSuite when auditing a large accounteats 2-3 GB)
• Isolated VM or Docker container - do not mix credentials of atest account with workers
• Stable Internet (all three tools run through cloud APIs, thereis no offline mode)
Minimum external passage: DNS-listing (subfinder -d target.com),Certificate Transparency, HTTP-fingerprinting (httpx with flags-title -tech-detect -status-code) To search for open S3-bouquets -cloud_enum by keyword or s3scanner. GrayHatWarfare covers publicvesti through the web interface. This is the Cloud Service Discovery(T1526, Discovery).
After receiving credentials, the first team - aws stsget-caller-identity. Without fixing the identity report is notreproducible: the same team for the auditor, workloading and thefederated user gives different results. Next - Cloud InfrastructureDiscovery (T1580): EC2 enumeration in all regions, weight balancers,Lambda-functions, S3-bouquets, ECS task definitions. What isimportant not just a list of resources, but a graph of connections:what role is tied to workload, who can do sts:AssumeRole, which trustpolicies are open to external accounts. Without a graph, you see thedot, but not the chain between them.
IAMI privilege escalation: chains instead of individual finds
IAM-escalation rarely looks like one AdministratorAccess on theuser. This happens in training labs, but not in the production. Moreoften the chain is assembled from formally resolved actions: the usercreates Lambda, Lambda gets a role through iamassRole, the rolereads the secret from Secrets Manager, the secret opens a pypaline, apaipine deloset in production. At each step, the API works normally,but the whole chain leads far beyond the original level of access.These are the methods of Other Cloud Credentials (T1098.001) andOther Cloud Roles (T1098.003) - persistence and escalation via IAM.
The test begins with current rights:
Cross-account access is built via trust policy inAssumeRolePolicyDocument. If Principal indicatesarn:aws:iam::111122223333:root without condition sts:ExternalId -Here is a potential element movement in another account. Thecontrolled option limits a specific role and requires an externalidentifier. Confirmation of the transition: aws sts assume-role--role-arn ... --role-session-name pentest-validation, then repeatedget-caller-identity to fix a new identity.
Separate pain - non-human identities: OAuth-applications, APIkeys, CI/CD tokens, Kubernetes ServiceAccounts. They live longer thanuser sessions, are worse inventory and almost always get the rightsmore broad than a real use case. On one project we found a CI/CDtoken two years ago with the right iam:* - it was created "forthe time of migration" and forgotten.
[Applicable to: grey box (issued read-only credentials) and whitebox. In black box - only if the key leaks are detected throughOSINT.]
SSRF and metadata endpoint: when AppSec-bug leads to a clouddisaster
SSRF (OWASP A10:2021) in a conventional application is restrictedby access to internal HTTP resources. In the cloud, the same bug canlead to workload credentials - and this is a completely differentscale. If the application runs on EC2 with a role, metadata endpointhttp://169.254.169.254 becomes a bridge from web vulnerability toCloud API - Cloud Instance Metadata API (T1552.005, CredentialAccess).
IMDSv1 does not require token: request curlhttp://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAMEreturns AccessKeyId, SecretAccessKey and Token. Just like that, noquestion. IMDSv2 requires a PUT query with a header for receiving asessional token - the standard SSRF via GET / redirect will not pass(you need to control the method and headers). IMDS status check onthe bustier: field MetadataOptions.HttpTokens in the conclusiondescribe-instances. Importance optional - IMDSv1 is active, the busis vulnerable. Importance required IMDSv2 only
In Azure metadata endpointhttp://169.254.169.254/metadata/instance Requires the title Metadata:true - partial protection against simple SSRF, but redirect-basedattacks bypass this limitation. The GCPhttp://metadata.google.internal with headline Metadata-Flavor:Google.
It would seem that IMDSv2 solves the problem. But in practice, weregularly see HttpTokens = "optional" atproduction-instances - especially those that were created before 2021and have not been touched since then.
[Applicable: an external pentest if SSRF is available in a webapplication; internal - when accessed to EC2/VM.]
ScoutSuite, Prowler and Pacu: audit of cloud infrastructure inpractice
Three tools solve three different tasks. Confusion between them isan error that costs the time and quality of the report.
ScoutSuite - the first configuration pass
ScoutSuite (NCC Group, Python, multi-cloud:AWS/Azure/GP/Alibaba/OCI; the latest release is actively supported,~5k stars on GitHub) connects to the cloud API, subtracts theconfiguration of services and generates an HTML report from findingsby criticality. Launch for AWS: scout aws --profile pentest-target--report-dir ./report. For Azure: az login, then scout azure --cli.For GCP: gcloud auth application-default login, then scout gcp--user-account.
What does well: the full configuration picture in 15-30 minutes.Open S3-bouquets, security groups with 0.0.0.0/0 on SSH/RDP,IAM-users without MFA, unencrypted EBS-tom, public RDS-instinuses.For the first pass on the account - the very thing.
What is the waiver: the privilege escalation chains (does notmodel the attack), the runtime configuration of Lambda (modeledenvironments, function code), detailed analysis of resource-basedpolicies (S3, SQS, SNS - partially). ScoutSuite will show that thesecurity group is open, but will not say whether it can be used inthe chain.
Place in kill running: Discovery / Recon. It is first to build anaccount card.
Prowler - compliance-noiss and real risks
Prowler (open source, actively developing, ~10k stars on GitHub;supports AWS/azure/GCP) was originally created as a compliance testtool CIS Benchmarks and AWS Well-Architected Framework. On theaverage AWS account, Prowler generates 200-400 genes. Critical ofthem - 3-5. The rest is a compliance noise: no tags included byAccess Analyzer, CloudTrail without CMK encryption. For a compliancereport, the customer is useful. For the attack chain - noise thatneeds to be filtered.
Start with filtration: prowler aws --severity critical high -M csvjson-ocsf. Prowler is stronger than ScoutSuite in granular-checks bycompliance-free flooring (PCI DSS, HIPAA), in the analysis ofCloudTrail configuration, in the detection of disconnected logging -and this is critical for detecting technology Disable or Modify CloudLogs (T1562.008).
Place in kill chain: Recon / Audit. In parallel with ScoutSuitefor cross-checking.
Pacu - patent framework for AWS
Pacu (Rhino Security Labs, Python, only AWS; ~4k stars on GitHub,is actively supported) is a fundamentally different tool class.ScoutSuite and Prowler are looking for myconfigurations. Pacuexploits them.
Module iam__privesc_scan checks specific combinations ofpermissions: iamassRole + lambda:CreateFunction,iam:CreatePolicyVersion, iam:AttachUserPolicy, sts:AssumeRole forroles with broad rights - and gives out ready-made ways ofescalation. This is something ScoutSuite and Prowler don’t do inprinciple.
For Azure, there is no analogue of this level - and this is aproblem. The nearest combination is ROADtools for Azure ADreconnaissance + manual operation via Azure CLI. For GCP - gcloud CLIwith custom scripts. PMapper (NCC Group) builds an IAM-privilegegraph, but does not operate a chain.
[Applicable to: grey box and white box, only AWS. Minimumread-only access to IAM API.]
Selection of tool for task
Optimal sequence on the project: ScoutSuite first (map), Prowlerparallel (compliance + logging), Pacu after the analysis of theprimary data (exploitation of target chains). Changing order is towaste time.
What CloudTrail and GuardDuty: OPSEC Sees Cloud Pentester
Cloud pentest without understanding the customer's detectabilityis half-lived work. IAM and STS APIs are recorded in CloudTrail. AWSbluntly specifies: CloudTrail captures IAM and STS API calls,including calls from the console and via SDK.
Critical events in CloudTrail: AssumeRole, CreateAccessKey,AttachRolePolicy, PutRolePolicy, CreatePolicyVersion,UpdateAssumeRolePolicy. If the SOC team monitors CloudTrail viaAthena, CloudWatch Logs or SIEM, these actions are visible. Thequestion is whether they are being monitored.
GuardDuty detective automatically. FindingUnauthorizedAccess:IAMUser/InstanceCredentialExfiltration It workswhen temporary credentials EC2 is used with IP outside of AWS.Recon:IAMUser/MaliciousIPCaller - API-calls from IP threatintelligence feeds. GuardDuty doesn’t need to be customized –it’s either on or not.
OPSEC-recommendations for the pentester:
• Do not use credentials EC2 rolls from external IP - GuardDutywill work instantly
• Work from the region of the customer's infrastructure -anomaly by geolocation is detected
• Fix all actions: time, caller identity, target ARN, result
If the action is played, but the SOC cannot find it in magazines -finding it is a separate one. The lack of observability on thecontrol plane in the cloud is as dangerous as the weak IAM-politics.The report records both types: successful chains of attacks, and gapsin monitoring. The second sometimes frightens the customer more thanthe first.
Often, the cloud penalty is reduced to the launch of ScoutSuite +Prowler, the generation of PDF findings with 300 and transfer to thecustomer. Formally, the pentest was held. In fact, no one checkedwhether it is possible to get to production data from read-onlyaccess in four hours. The problem is not in tools - Prowler andScoutSuite do exactly what they are created for. The problem is thatcompliance audit is sold as a cloud infrastructure pentest. Pentestis an attack modeling: chains, PassRole, cross-account lateralmovement, SSRF to metadata, persistence through “quiet” regions.If the report does not have a single operated chain, but only thecheck/fail list - the customer received an audit, not a pentest.
assRole on theforgotten ti-role, Lambda-function with execution role, readingSecrets Manager, from there credentials from RDS. Not a singleexploit, not a single CVE - only the regular API-calls of AWS.ScoutSuite did not show the chain privesc through PassRole. Prowler,especially. Found Pacu through iam__privesc_scan, confirmed with hishands. Here is the typical reality of the cloud pentest: the criticalpath does not pass through the open port, but through the IAMconfiguration, and automation sees only individual pieces of themosaic.Why Cloud Pentest is a Separate Discipline
In on-premise, the usual logic is built around the network route:subnets, open ports, SMB, AD, lateral through WinRM or RDP. In thecloud, the network layer remains, but ceases to be the main source ofauthority. The EC2-tisansion is closed from the Internet - but itsinstance profile gives access to Secrets Manager. Lambda withoutpublic endpoint has a role with production-block rights.CI/CD-pipeline runs from internal GitLab, but its cloud role changesfeatures and policies.
The vector is shifted from network vulnerabilities toconfiguration and identification management vulnerabilities.According to the Wiz State of Cloud Security 2024, more than 80% ofreal incidents in the cloud are not related to softwarevulnerabilities, but with configuration errors: excessive IAM rights,publicly open storage, lack of encryption, unsecured API-endpoint.OWASP confirms the picture - Security Misconfiguration (A05:2021)both Broken Access Control (A01:2021) are stable in the top three,and in the cloud they are especially pronounced.
If you’re at MITRE ATT&CK, a typical cloud-based punchetcovers: Cloud Accounts (T1078.004, Initial Access / Persistence /Privilege Escalation), Cloud Discover Infrastructurey (T1580,Discovery), Cloud Instation Metadata API (T1552.005, CredentialAccess), Data from Cloud Storage (T1530, Collection), AdditionalCloud Credentials (T1098.001, Persistence), Disable or Modify CloudLogs (T1562.008, Defense Evasion). Every technique is not about“catching”, but about the abuse of legitimate APIs. No ID willwork on aws secretsmanager get-secret-value, if the challenge comesfrom the role with rights.
Shared Responsibility Model sets the test boundaries. The provideris responsible for the infrastructure of the cloud (iron,hypervisors), the client - for everything inside the account. Pentestis bounded by the client's area, and it is there that critical findslie. AWS allows testing without prior approval only for explicitlylisted services (EC2, RDS, Lambda, S3, CloudFront, Gateway API andseveral others according to AWS Customer Policy Policy forPenetration Testing); for the rest, you need a filing for SimulatedEvents form. Azure and GCP are similar, but DDoS tests, DNS attacksand flooding are prohibited in all three.
Cloud infrastructure pentest methodology: from reconnaissance topersistence
Cloud surface exploration and transfer of resources
Foreign intelligence in the cloud is not needed for the sake of asubdomain table. The task is to find cloud bindings, forgottenenvironments and resources that are then compared with the internalinventory. CNAME on the old load balancer, object storage endpoint inthe dev zone, staging agent certificate - all this is valuable whenit is clear which workload is behind them and what rights itreceives.
Adjustments to the environment:
• OS: Linux (Kali, Ubuntu 22.04+) or macOS
• AWS CLI v2, Azure CLI, gcloud SDK via a separate --profilefortest account
• Python 3.9+ for ScoutSuite (pip install scoutsuite) and Pacu(Cloning from GitHub)
• At least 4 GB RAM (ScoutSuite when auditing a large accounteats 2-3 GB)
• Isolated VM or Docker container - do not mix credentials of atest account with workers
• Stable Internet (all three tools run through cloud APIs, thereis no offline mode)
Minimum external passage: DNS-listing (subfinder -d target.com),Certificate Transparency, HTTP-fingerprinting (httpx with flags-title -tech-detect -status-code) To search for open S3-bouquets -cloud_enum by keyword or s3scanner. GrayHatWarfare covers publicvesti through the web interface. This is the Cloud Service Discovery(T1526, Discovery).
After receiving credentials, the first team - aws stsget-caller-identity. Without fixing the identity report is notreproducible: the same team for the auditor, workloading and thefederated user gives different results. Next - Cloud InfrastructureDiscovery (T1580): EC2 enumeration in all regions, weight balancers,Lambda-functions, S3-bouquets, ECS task definitions. What isimportant not just a list of resources, but a graph of connections:what role is tied to workload, who can do sts:AssumeRole, which trustpolicies are open to external accounts. Without a graph, you see thedot, but not the chain between them.
IAMI privilege escalation: chains instead of individual finds
IAM-escalation rarely looks like one AdministratorAccess on theuser. This happens in training labs, but not in the production. Moreoften the chain is assembled from formally resolved actions: the usercreates Lambda, Lambda gets a role through iam
assRole, the rolereads the secret from Secrets Manager, the secret opens a pypaline, apaipine deloset in production. At each step, the API works normally,but the whole chain leads far beyond the original level of access.These are the methods of Other Cloud Credentials (T1098.001) andOther Cloud Roles (T1098.003) - persistence and escalation via IAM.The test begins with current rights:
Cross-account access is built via trust policy inAssumeRolePolicyDocument. If Principal indicatesarn:aws:iam::111122223333:root without condition sts:ExternalId -Here is a potential element movement in another account. Thecontrolled option limits a specific role and requires an externalidentifier. Confirmation of the transition: aws sts assume-role--role-arn ... --role-session-name pentest-validation, then repeatedget-caller-identity to fix a new identity.
Separate pain - non-human identities: OAuth-applications, APIkeys, CI/CD tokens, Kubernetes ServiceAccounts. They live longer thanuser sessions, are worse inventory and almost always get the rightsmore broad than a real use case. On one project we found a CI/CDtoken two years ago with the right iam:* - it was created "forthe time of migration" and forgotten.
[Applicable to: grey box (issued read-only credentials) and whitebox. In black box - only if the key leaks are detected throughOSINT.]
SSRF and metadata endpoint: when AppSec-bug leads to a clouddisaster
SSRF (OWASP A10:2021) in a conventional application is restrictedby access to internal HTTP resources. In the cloud, the same bug canlead to workload credentials - and this is a completely differentscale. If the application runs on EC2 with a role, metadata endpointhttp://169.254.169.254 becomes a bridge from web vulnerability toCloud API - Cloud Instance Metadata API (T1552.005, CredentialAccess).
IMDSv1 does not require token: request curlhttp://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAMEreturns AccessKeyId, SecretAccessKey and Token. Just like that, noquestion. IMDSv2 requires a PUT query with a header for receiving asessional token - the standard SSRF via GET / redirect will not pass(you need to control the method and headers). IMDS status check onthe bustier: field MetadataOptions.HttpTokens in the conclusiondescribe-instances. Importance optional - IMDSv1 is active, the busis vulnerable. Importance required IMDSv2 only
In Azure metadata endpointhttp://169.254.169.254/metadata/instance Requires the title Metadata:true - partial protection against simple SSRF, but redirect-basedattacks bypass this limitation. The GCPhttp://metadata.google.internal with headline Metadata-Flavor:Google.
It would seem that IMDSv2 solves the problem. But in practice, weregularly see HttpTokens = "optional" atproduction-instances - especially those that were created before 2021and have not been touched since then.
[Applicable: an external pentest if SSRF is available in a webapplication; internal - when accessed to EC2/VM.]
ScoutSuite, Prowler and Pacu: audit of cloud infrastructure inpractice
Three tools solve three different tasks. Confusion between them isan error that costs the time and quality of the report.
ScoutSuite - the first configuration pass
ScoutSuite (NCC Group, Python, multi-cloud:AWS/Azure/GP/Alibaba/OCI; the latest release is actively supported,~5k stars on GitHub) connects to the cloud API, subtracts theconfiguration of services and generates an HTML report from findingsby criticality. Launch for AWS: scout aws --profile pentest-target--report-dir ./report. For Azure: az login, then scout azure --cli.For GCP: gcloud auth application-default login, then scout gcp--user-account.
What does well: the full configuration picture in 15-30 minutes.Open S3-bouquets, security groups with 0.0.0.0/0 on SSH/RDP,IAM-users without MFA, unencrypted EBS-tom, public RDS-instinuses.For the first pass on the account - the very thing.
What is the waiver: the privilege escalation chains (does notmodel the attack), the runtime configuration of Lambda (modeledenvironments, function code), detailed analysis of resource-basedpolicies (S3, SQS, SNS - partially). ScoutSuite will show that thesecurity group is open, but will not say whether it can be used inthe chain.
Place in kill running: Discovery / Recon. It is first to build anaccount card.
Prowler - compliance-noiss and real risks
Prowler (open source, actively developing, ~10k stars on GitHub;supports AWS/azure/GCP) was originally created as a compliance testtool CIS Benchmarks and AWS Well-Architected Framework. On theaverage AWS account, Prowler generates 200-400 genes. Critical ofthem - 3-5. The rest is a compliance noise: no tags included byAccess Analyzer, CloudTrail without CMK encryption. For a compliancereport, the customer is useful. For the attack chain - noise thatneeds to be filtered.
Start with filtration: prowler aws --severity critical high -M csvjson-ocsf. Prowler is stronger than ScoutSuite in granular-checks bycompliance-free flooring (PCI DSS, HIPAA), in the analysis ofCloudTrail configuration, in the detection of disconnected logging -and this is critical for detecting technology Disable or Modify CloudLogs (T1562.008).
Place in kill chain: Recon / Audit. In parallel with ScoutSuitefor cross-checking.
Pacu - patent framework for AWS
Pacu (Rhino Security Labs, Python, only AWS; ~4k stars on GitHub,is actively supported) is a fundamentally different tool class.ScoutSuite and Prowler are looking for myconfigurations. Pacuexploits them.
Module iam__privesc_scan checks specific combinations ofpermissions: iam
assRole + lambda:CreateFunction,iam:CreatePolicyVersion, iam:AttachUserPolicy, sts:AssumeRole forroles with broad rights - and gives out ready-made ways ofescalation. This is something ScoutSuite and Prowler don’t do inprinciple.For Azure, there is no analogue of this level - and this is aproblem. The nearest combination is ROADtools for Azure ADreconnaissance + manual operation via Azure CLI. For GCP - gcloud CLIwith custom scripts. PMapper (NCC Group) builds an IAM-privilegegraph, but does not operate a chain.
[Applicable to: grey box and white box, only AWS. Minimumread-only access to IAM API.]
Selection of tool for task
Optimal sequence on the project: ScoutSuite first (map), Prowlerparallel (compliance + logging), Pacu after the analysis of theprimary data (exploitation of target chains). Changing order is towaste time.
What CloudTrail and GuardDuty: OPSEC Sees Cloud Pentester
Cloud pentest without understanding the customer's detectabilityis half-lived work. IAM and STS APIs are recorded in CloudTrail. AWSbluntly specifies: CloudTrail captures IAM and STS API calls,including calls from the console and via SDK.
Critical events in CloudTrail: AssumeRole, CreateAccessKey,AttachRolePolicy, PutRolePolicy, CreatePolicyVersion,UpdateAssumeRolePolicy. If the SOC team monitors CloudTrail viaAthena, CloudWatch Logs or SIEM, these actions are visible. Thequestion is whether they are being monitored.
GuardDuty detective automatically. FindingUnauthorizedAccess:IAMUser/InstanceCredentialExfiltration It workswhen temporary credentials EC2 is used with IP outside of AWS.Recon:IAMUser/MaliciousIPCaller - API-calls from IP threatintelligence feeds. GuardDuty doesn’t need to be customized –it’s either on or not.
OPSEC-recommendations for the pentester:
• Do not use credentials EC2 rolls from external IP - GuardDutywill work instantly
• Work from the region of the customer's infrastructure -anomaly by geolocation is detected
• Fix all actions: time, caller identity, target ARN, result
If the action is played, but the SOC cannot find it in magazines -finding it is a separate one. The lack of observability on thecontrol plane in the cloud is as dangerous as the weak IAM-politics.The report records both types: successful chains of attacks, and gapsin monitoring. The second sometimes frightens the customer more thanthe first.
Often, the cloud penalty is reduced to the launch of ScoutSuite +Prowler, the generation of PDF findings with 300 and transfer to thecustomer. Formally, the pentest was held. In fact, no one checkedwhether it is possible to get to production data from read-onlyaccess in four hours. The problem is not in tools - Prowler andScoutSuite do exactly what they are created for. The problem is thatcompliance audit is sold as a cloud infrastructure pentest. Pentestis an attack modeling: chains, PassRole, cross-account lateralmovement, SSRF to metadata, persistence through “quiet” regions.If the report does not have a single operated chain, but only thecheck/fail list - the customer received an audit, not a pentest.
