A common problem: relaxing permissions during deployments
In many corporate environments, especially during development phases or urgent deployments, technical teams choose to simplify IAM policies using wildcards like "Action": "*" or "Resource": "*". The intent is usually to speed up temporary processes, but these overly broad permissions are almost never removed afterwards.
This creates a significant attack surface: any actor with access to that role or user can execute unexpected operations, including modifying policies, creating session tokens, or deleting critical resources.
At a financial sector client, we detected a legacy policy with "Effect": "Allow", "Action": "iam:*" and "Resource": "*" assigned to a production EC2 instance. This allowed an internal attacker to generate new access keys for other privileged users, escalating privileges without triggering immediate alerts.
Expanded and hard-to-audit attack surface
Wildcard permissions not only allow more than necessary, they also make effective auditing impossible. Misuse detection, least privilege analysis, or compliance validations become imprecise or ineffective.
Amazon CloudTrail records performed actions, but without prior knowledge of which actions were truly allowed, it’s nearly impossible to distinguish between legitimate use and abuse. This complicates incident response processes and increases mean time to containment.
- Perception errors: Many teams assume that
Action: *is acceptable if limited with aCondition, but this only works if the conditions are well designed, which rarely occurs outside a mature access control model. - Analysis tool limitations: AWS Access Analyzer detects wildcards, but doesn’t interpret context. Without manual review processes and purpose validation, many violations go unnoticed.
Typical abuse cases and viable attack scenarios
A pattern we’ve repeatedly seen is token rotation or role modification using wildcard permissions. Applications operating with such policies can be easily subverted by internal attackers or through exposed web app vulnerabilities.
In an audit at a digital retail company, a role granted to a lambda had wildcard access to kms:*. After compromising the execution of that lambda from a vulnerable endpoint, an attacker gained access to decrypt secrets of multiple production clients.
Allowing s3:* or ec2:* on all resources also enables scenarios like:
- Data exfiltration: copying entire buckets without leaving immediate traceability.
- Persistence: creating new EC2 instances with custom keys to maintain persistent access.
How to proceed in practice: review, detection, and hardening
Practical remediation involves three key steps: identifying policies with wildcards, analyzing effective use, and redefining based on necessary privileges.
To identify policies with wildcards:
aws iam list-policies --scope Local | \
jq '.Policies[] | select(.Arn) | .Arn' | \
xargs -n1 aws iam get-policy-version --policy-arn <arn> --version-id <version>
Search for "Action": "*" or "Resource": "*" patterns in the resulting JSONs. These should be manually audited. Amazon Identity Analyzer also allows reviewing who has actual access to certain resources, though its coverage is still incomplete.
When redefining policies, using conditions like "Condition": {"StringEquals": {"aws:RequestedRegion": "eu-west-1"}} should be accompanied by explicit usage audits. Permissions must be documented with the purpose of actual use, not just by service type.
The anti-pattern: policies generated by automated tools
A frequent source of issues are tools like AWS Console or IaC frameworks (CloudFormation, Terraform) that generate predefined or overly broad policies during quick resource creation. These policies are rarely corrected later and remain as insecure legacy.
In a CDK deployment, using iam.ManagedPolicy.fromAwsManagedPolicyName('AdministratorAccess') in non-production environments was manually “replicated” in production for symmetry. This granted full access to all services without restriction, with huge operational costs when it became evident during an external audit.
This kind of error results in environments where it’s no longer possible to determine what part of the system has critical permissions. The only solution in such cases is to rewrite policies from scratch, which may require weeks of work depending on the environment size.
Recommendations for corporate environments
Reducing or eliminating the use of wildcard permissions should be a priority in any hardening program. Each wildcard represents a gray area where an attacker can move freely.
Implementing least privilege models requires investment in observability and collaboration between security and platform teams. AWS native tools like IAM Access Analyzer and CloudTrail must be integrated with internal review and change control processes.
Proper design involves:
- Using custom managed policies with environment- and service-specific scopes.
- Automating wildcard detection as part of CI/CD pipelines or pre-deploy reviews.
- Training teams on securely writing IAM policies using concrete product-specific guides.
This kind of work can’t be delegated to the security team alone: it must be part of the development and operations lifecycle to have real and sustained effectiveness.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.