Topic starter
24/06/2026 11:30 pm
TL;DR: Independent testing against 16 known AWS attack paths found that unrestricted environments remained exploitable while Cloud Permissions Firewall controls blocked all 16 scenarios, including privilege escalation, persistence, and lateral movement paths, according to Sonrai Security. The result reinforces that cloud least privilege must be enforced at execution time, not only described in policy.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “Independent Testing Confirms Sonrai’s Cloud Permissions Firewall Blocks Real AWS Attack Paths”.
Key questions
Q: What breaks when AWS access is still based on standing privileges?
A: Standing privileges create a governance gap because access can outlive the task, the approval, and sometimes the operator.
Q: Why do over-provisioned cloud permissions increase the risk of escalation?
A: Over-provisioned permissions increase risk because privileged APIs can become attacker tools when an identity can attach policies, create keys, change roles, or start sessions without additional approval.
Q: How do you know if cloud least privilege is actually working?
A: You know it is working when every high-sensitivity datastore has a short, explainable list of identities with clearly bounded access and documented business need.
Practitioner guidance
- Map high-risk AWS actions to approval-gated permissions Treat actions such as policy attachment, access-key creation, role policy updates, and session starts as privileged events that require explicit approval before execution.
- Reduce standing privilege in cloud roles Replace always-on access with just-in-time permission grants for the specific service and task so high-risk rights do not persist between operations.
- Block unused services and regions at the organisation boundary Use cloud-native guardrails to disable services and regions that should not be available in the account structure, shrinking the number of usable attack paths.
Bottom line: AWS attack paths remain exploitable when high-risk permissions are left standing, even if policy language says least privilege is in place.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 8:26 am
Execution-time least privilege is the real cloud control boundary: AWS privilege escalation is no longer just a policy design problem. When permissions remain available during runtime, legitimate API actions become an attack chain rather than a governed task sequence. The practitioner conclusion is that cloud identity controls have to be evaluated where action occurs, not where policy is documented.
A few things that frame the scale:
- 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.
A question worth separating out:
Q: Should organisations use service control policies or role reviews to control cloud privilege?
A: Both matter, but they solve different problems. Role reviews show who appears over-privileged, while service control policies can stop risky actions from being used at all. For cloud escalation paths, the stronger control is the one that constrains execution, because that is where legitimate permissions become abuse.
👉 Read our full editorial: AWS attack paths expose the cloud privilege escalation problem