# Leveraging AI Planning For Detecting Cloud Security Vulnerabilities

Mikhail Kazdagli,1,2 Mohit Tiwari, 1,2 Akshat Kumar 1,3

###### Abstract

Cloud computing services provide scalable and cost-effective solutions for
data storage, processing, and collaboration. Alongside their growing
popularity, concerns related to their security vulnerabilities leading to data
breaches and sophisticated attacks such as ransomware are growing. To address
these, first, we propose a generic framework to express relations between
different cloud objects such as users, datastores, security roles, to model
access control policies in cloud systems. Access control misconfigurations are
often the primary driver for cloud attacks. Second, we develop a PDDL model
for detecting security vulnerabilities which can for example lead to
widespread attacks such as ransomware, sensitive data exfiltration among
others. A planner can then generate attacks to identify such vulenrabilities
in the cloud. Finally, we test our approach on 14 real Amazon AWS cloud
configurations of different commercial organizations. Our system can identify
a broad range of security vulnerabilities, which state-of-the-art industry
tools cannot detect.

##  1 Introduction

Cloud computing services play a pivotal role in modernizing and optimizing
businesses by providing scalable, cost-effective, and accessible solutions for
data storage, processing, and collaboration. However, alongside their growing
popularity, security threats in public clouds are also ever increasing (Unit42
2022; Pernet 2021). Access control in common commercial clouds is governed by
the Identity and Access Management (IAM) component, which intuitively means
deciding and authorizing which users should have access to what cloud
resources such as datastores, is challenging even for small and medium
enterprises (Kuenzli 2020). Amazon AWS adopts the shared responsibility model
(AWS 2023), wherein the task of configuring IAM security policies is entrusted
to the AWS customer. Thus, IAM policies of an organization are configured by
their IT experts who often do not have support of automated tools to analyze
the full impact of their decisions on the security of the cloud configuration.
As a result, several data breaches and security attacks continue to happen
regularly (One 2022; Scroxton 2020; Holmes 2021; Marks 2021).

#### Related work

There are several types of known attacks that exploit the misconfiguration of
clouds such as privilege escalation attacks (a non-admin entity getting admin
permissions), impact attacks (deleting data buckets), ransomware attacks
(encrypting sensitive data), data exfiltration (stealing private sensitive
data) among others (CSA 2023). There has been some analysis of what kind of
common IAM misconfigurations can cause such attacks (Gietzen 2021). There are
few open source tools that analyze a cloud configuration to detect
vulnerabilities such as PMapper (NCC Group 2023). However, such tools use the
notion of graph reachability analysis to detect whether a cloud has security
vulnerabilities, without performing a systematic search to detect complex
vulnerabilities. Tools such as Policy Sentry (Salesforce 2023) are
preventative tools that help ease the complexity of writing secure IAM
Policies. The problem of optimizing IAM policies using constraint programming
has been addressed in (Kazdagli, Tiwari, and Kumar 2022). However, their
method computes a new IAM policy rather than analyzes an existing one, and
their attack criteria are not as diverse as addressed in our work.

Formal methods have been used to analyze the security aspect of cloud
offerings by cloud providers such as Amazon. The Amazon offering Zelkova
(Backes et al. 2018), an IAM policy analysis tool, can reason whether a data
bucket has public access using SMT solver. Microsoft uses theorem provers to
validate global properties of their data centers (Jayaraman et al. 2019). A
key limitation of these tools is that they analyze the current state of the
organization. In contrast, the tool we develop can reason about multi-step
attacks that involve an attacker performing a sequence of operations to
compromise the system. Another model checking method is presented in (Hu et
al. 2023). However, this tool is specifically focused on privilege escalation
(PE) attacks and can only provide a binary answer whether the current IAM
configuration allows PE attacks or not.

In the AI planning literature, simulated penetration testing (pentesting), for
example of networked systems, is closely related (Boddy et al. 2005; Obes,
Sarraute, and Richarte 2010; Sarraute, Buffet, and Hoffmann 2012; Hoffmann
2015). In such a setting, a model of the underlying system is constructed and
using model-based planning (e.g., using PDDL solvers), attacks are generated
(Hoffmann 2015). Attack graphs have also been used to describe such pentesting
(Lippmann and Ingols 2005). Such attacks are then used to inform IT admins of
system vulnerabilities. We also take a similar approach. However, a key
difference lies in the modeling of the cloud system, which is significantly
different than the models used for network system security (Obes, Sarraute,
and Richarte 2010). A significant contribution of our work is to provide a
simple and generic representation of the IAM model of a cloud which is easily
extendable by IT admins to model future functionalities and different cloud
operations based on action schemas.

#### Contributions

Our key contributions are:

  * •

We define a relation tuple-based formulation of a cloud system, which has been
shown to be highly efficient and scalable for authorization control in large-
scale clouds (Pang et al. 2019). Intuitively, a tuple describes which identity
(e.g., a cloud user) can access which resource in the cloud (e.g., datastore)
with what permission (e.g., read-only). Key benefits of this formulation
include (a) It is easily extendable to allow future cloud configuration
changes; (b) it is explainable as IT admins can directly change the text file
storing such tuples; (c) it is general enough to represent multiple cloud
platforms such as Amazon AWS, Google GCP, Microsoft Azure among others.

  * •

We show how the problem of generating attacks (such as sensitive data
exfiltration, ransomware etc) can be translated into a PDDL formulation with
appropriate actions. Our approach is able to detect multi-step attacks. Our
formulation uses appropriate modeling choices to make the planning problem
easier for solvers such as Fast Downward (Helmert 2006).

  * •

Finally, we test on 14 real-world cloud instances and show that our approach
can detect a range of attacks. In contrast, industry tools such as PMapper are
unable to generate such a diverse range of attacks (NCC Group 2023).

##  2 Cloud Identity Access Management (IAM)

For ease of exposition, we focus on Amazon AWS, and briefly describe relevant
concepts; more details can be found here (Amazon AWS 2023). An IAM policy is a
set of permissions, attached to a cloud identity, that define what actions a
user is allowed to execute on what AWS resources. A resource is a cloud object
with a unique identifier, such as an S3 bucket (a directory in a distributed
file storage system). Each policy consists of one or more statements and each
statement describes a specific set of permissions.

A statement in an IAM policy includes the following key elements:

  * •

Effect: It can be either “Allow” or “Deny.” The “Allow” effect grants the
specified permissions, while the “Deny” effect explicitly denies the specified
permissions.

  * •

Action: The specific AWS service or resource actions that the policy allows or
denies. Actions can range from simple tasks like read (e.g., s3:GetObject) to
more complex operations involving multiple resources. These actions are also
called permissions, which give the privilege of performing the associated
operation. These actions are related to, but different from PDDL actions that
we will define later.

  * •

Resource: The AWS resources to which the actions apply. This can include
specific ARNs (Amazon Resource Names).

The statement in Listing 1 allows the “s3:GetObject” action (which is the read
permission) on the object with Amazon Resource Name (ARN)
“arn:aws:s3:dummyBucket” (which is a datastore). Every item of an IAM policy
is allowed to be specified in the form of a regular expression that makes the
policy able to grant multiple permissions to multiple cloud objects in a
concise manner but also introduces security vulnerabilities because of making
the policy over-permissive (Kazdagli, Tiwari, and Kumar 2022).

Furthermore, each IAM policy may include an optional condition element which
acts as an additional filter, serving to further restrict the policy’s scope.

⬇

{

Effect: Allow,

Action: s3:GetObject,

Resource: arn:aws:s3:dummyBucket

}

Listing 1: IAM Policy Statement Example

An AWS policy is composed of one or more statements as shown in listing 1.
Policies are associated with IAM identities, such as users, _groups_ , or
_roles_ , and they determine what actions those identities are allowed or
denied to perform on AWS resources. An AWS “identity” refers to a
representation of a computing entity that can either make requests to cloud
services or control access to such services. The key identities we address
are:

  * •

Users: These are entities that represent individual people, applications, or
services within an AWS account. Users have unique credentials (username,
password) and can be assigned specific permissions using policies.

  * •

Groups: IAM groups are collections of IAM users, roles, and other groups. By
organizing identities into groups, we can manage their permissions
collectively. Policies can be attached to IAM groups to grant a set of
permissions to all identities within the group.

  * •

Roles: Unlike users or groups, roles are not associated with a specific end-
user or an application. Policies can be attached to roles to give them
specific set of permissions. Roles can be assumed by AWS services and users,
allowing them to temporarily take on the permissions assigned to the role.

In AWS, “resources” refer to computing components such as storage resources
(Amazon S3), database and networking resources (Amazon AWS 2023).

The IAM provides a centralized way to control access to different AWS
resources allowing IT admins to define policies for users and other AWS
identities. However, given the complexity of IAM, often misconfigurations can
result which can lead to unintended side effects that result in cloud attacks.
In the next section, we show one such scenario.

###  2.1 Attack Example

Consider an example where a compromised user can execute a ransomware attack
(Labs 2019) in just a few steps. Typically, a ransomware attack involves two
key actions: encrypting data and deleting the original, unencrypted data. In
AWS cloud, attackers benefit from the availability of server-side encryption,
which is performed within AWS, circumventing the need for conspicuous data
transfers between the attacker’s machine and cloud storage. To leverage
server-side encryption, an attacker requires access to the AWS Key Management
Service (KMS) for encryption keys and write permissions to a relevant S3
bucket. For the sake of simplicity, this discussion assumes that the Effect
field of corresponding IAM policies is set to Allow.

⬇

{ Action: s3:*Object,

Resource: s3:sensitiveDataBucket }

{ Action: sts:AssumeRole,

Resource: iam:keyManagementRole }

Listing 2: Ransomeware attack: policy attached to a compromised user

⬇

{ Action: kms:*Key*,

Resource: * }

Listing 3: Ransomeware attack: policy attached to the role
iam:keyManagementRole

The policy in Listing 2 grants a compromised user the ability to perform
object-level operations (e.g. read and write) on the s3:sensitiveDataBucket
that contains sensitive data. However, write permission alone isn’t sufficient
for an attacker to launch a ransomware attack. The attacker also needs to
assume the iam:keyManagement role. As permitted by the policy in Listing 2
(bottom statement), this role grants extensive access to the KMS service
(Listing 3). It provides the critical permission kms:CreateKey, allowing the
attacker to create a private encryption key attacker-kms-key-id. This key,
which is used for encryption but not decryption, enables the attacker to
encrypt data in place using a single AWS command (Listing 4).

⬇

{ aws s3 cp s3://sensitiveData

s3://sensitiveData \--sse aws:kms

\--sse-kms-key-id attacker-kms-key-id }

Listing 4: Ransomware: in-place server-side data encryption with an attacker-
controlled key attacker-kms-key-id

##  3 PDDL Modeling of IAM

In our PDDL modeling of the IAM, given a compromised IAM user, the goal is for
the planner to generate a sequence of cloud actions (to be defined later) such
that some attack predicate becomes true. Given these simulated attacks, IT
admins can harden the IAM configuration to fix such vulnerabilities. Such a
planning framework provides a systematic way to search for vulnerabilities.

We incorporate a list of known attacks denoted in Table 1; however, our
planning framework is generic and can be extended to future attack types as we
model actions that allow flow of permissions among entities, which is a key
source of multi-step complex attacks.

Table 1 describes well-known attacks we model; _bucket_ refers to an object
storage container (e.g., like a directory).

Attack type |  Interpretation
---|---
Sensitive data exfiltration |  Move sensitive data to a public bucket
Impact |  Delete bucket, user, role, group, or policy
Persistence |  Create a new IAM user
Lateral movement |  Set or change password/access key for a user
Privilege escalation |  Get elevated privileges for a user
Ransomware |  Encrypt sensitive data and delete the original data
Table 1: Attack Types

We also make certain assumptions while planning for attacks. First, the IAM
model is known without any uncertainty. For our experiments, we mine a
company’s cloud configuration to extract their IAM model. Second, similar to
the concept of monotonic actions (Hoffmann 2015), as an attacker compromises
different IAM identities, the permissions the attacker gains accumulate and do
not expire during the attack. Realistically, some of these permissions may
have an expiration date, but we assume the attack is over by that time. Third,
given an opportunity to attack, the attacker chooses the most permissive
attack (e.g. if an attacker can assume any role in the system, then they will
choose to assume the admin role, which has the highest privilege).

###  3.1 Relational modeling of IAM

We consider users, roles, and groups as IAM identities. For simplicity, we
consider datastores as IAM resources (it is possible to consider additional
resources such as compute, and network among others). At any point in time,
the state of the IAM system is represented using the following 3- and
4-tuples:

  * •

$\langle\text{{{$\mathrm{id}$}{1}, $\mathrm{perm}$,
{$\mathrm{id}$}{2}}}\rangle$: This tuple implies that identity $\mathrm{id}$1
has permission $\mathrm{perm}$ over $\mathrm{id}$2\. E.g., this permission can
be assumeRole, which implies $\mathrm{id}$1 can assume the role $\mathrm{id}$2
and gain all associated permissions of $\mathrm{id}$2\. The $\mathrm{id}$2 can
be another identity (user, role, or group).

  * •

$\langle\text{{$\mathrm{id}$}, $\mathrm{perm}$, $\mathrm{ds}$}\rangle$: This
tuple implies that identity $\mathrm{id}$ has permission $\mathrm{perm}$ over
datastore $\mathrm{ds}$. Permissions can be full_control, read, write, delete,
etc.

  * •

$\langle\text{{$\mathrm{id}$}, {$\mathrm{id}$}{1}, $\mathrm{perm}$,
{$\mathrm{id}$}{2}}\rangle$: In IAM, there are special types of permissions
that allow an identity $\mathrm{id}$ to add a 3-tuple
$\tau=\langle\text{{$\mathrm{id}$}{1}, $\mathrm{perm}$,
{$\mathrm{id}$}{2}}\rangle$ to the IAM state. Under certain conditions, a PDDL
action can be taken (e.g., when $\mathrm{id}$ is a compromised user) to add
$\tau$ to the system state.

  * •

$\langle\text{{$\mathrm{id}$}, {$\mathrm{id}$}{1}, $\mathrm{perm}$,
$\mathrm{ds}$}\rangle$: Same interpretation as above; except that
$\mathrm{ds}$ is a datastore.

Such a simple tuple-based formulation is enough to model the majority of cloud
operations in AWS, GCP (Pang et al. 2019) to analyze its security
vulnerabilities. When we say an $\mathrm{id}$ has permission $\mathrm{perm}$,
it would refer to the tuple $\langle\text{{$\mathrm{id}$}, $\mathrm{perm}$,
{$\mathrm{id}$}1}\rangle$ or $\langle\text{{$\mathrm{id}$}, $\mathrm{perm}$,
$\mathrm{ds}$}\rangle$ ($\mathrm{id}$1 and $\mathrm{ds}$ would be clear from
the context).

For a concrete example of a 4-tuple, consider the permission
$\mathrm{iam\\!:\\!AttachGroupPolicy}$111https://docs.aws.amazon.com/IAM/latest/APIReference/API˙AttachGroupPolicy.html
in Listing 5. Assume identity $\mathrm{id}$ has this permission. This
permission allows $\mathrm{id}$ to attach a policy with ARN (Amazon resource
name) $\mathrm{PID}$ to the group with ARN $\mathrm{GID}$. We represent this
as tuple $\mathrm{\langle\text{{$\mathrm{id}$}},GID,hasPolicy,PID\rangle}$.

⬇

{

Effect: Allow,

Action: iam:AttachGroupPolicy,

Resource: <GID>,

Condition: {

StringEquals: {

aws:RequestTag/policy-id: <PID>

}}}

Listing 5: Json for $\mathrm{iam\\!:\\!AttachGroupPolicy}$

###  3.2 Permission Flow for Multi-step Attacks

We first parse an organization’s cloud setup to construct the relational model
as in Section 3.1. We next show how the planner (or the attacker) uses such
relations starting from a compromised user to make progress towards
accomplishing an attack (as noted in Table 1). The key to gain permissions to
enable an attack is via permission flow between identities as described next.

Assume we have three identities in the cloud—user $\mathrm{u}$1, group
$\mathrm{g}$1 and role $\mathrm{r}$1; and one datastore $\mathrm{ds}$. Assume
the tuples that describe the current state are:

$\displaystyle\langle\text{$\mathrm{u}${1}},\textrm{belongsTo},\text{$\mathrm{g}${1}}\rangle$
$\displaystyle\langle\text{$\mathrm{g}${1}},\textrm{any\\_user},\textrm{assumeRole},\text{$\mathrm{r}${1}}\rangle$
$\displaystyle\langle\textrm{$\mathrm{r}${1}},\textrm{deleteBucket},\text{$\mathrm{ds}${1}}\rangle$

For the impact attack to succeed, $\mathrm{u}$1 needs to delete $\mathrm{ds}$.
However, in the current state, $\mathrm{u}$1 does not have the target
permission $\langle\textrm{$\mathrm{u}$1, deleteBucket,
$\mathrm{ds}$1}\rangle$. The following sequence of operations takes place to
enable this attack:

  * •

Since, $\mathrm{u}$1 belongs to group $\mathrm{g}$1, it assumes all the
permissions of $\mathrm{g}$1\. After this permission flow, the tuple
$\langle\textrm{$\mathrm{u}${1}, any\\_user, assumeRole,
$\mathrm{r}${1}}\rangle$ is activated.

  * •

We use the keyword “any_user” to denote that any user in the system can
replace it. Therefore, $\mathrm{u}$1 replaces any_user with itself and
activates the tuple $\langle\textrm{$\mathrm{u}$1, assumeRole,
$\mathrm{r}${1}}\rangle$.

  * •

Tuple $\langle\textrm{$\mathrm{u}$1, assumeRole, $\mathrm{r}${1}}\rangle$
allows $\mathrm{u}$1 to assume the role $\mathrm{r}$1 and thus gain all the
permissions role $\mathrm{r}$1 has. In this way, $\mathrm{u}$1 gains target
permission $\langle\textrm{$\mathrm{u}$1, deleteBucket,
$\mathrm{ds}$1}\rangle$.

From this example, one can see how even for a system with a small number of
tuples, permission flow can quickly become challenging. Therefore, we need an
automated planning method to systematically search through all permission flow
paths and check if an attack is possible. This is achieved by the PDDL
modeling of the problem. We categorize actions into four classes as defined
next.

#### Permission flow actions

We first focus on PDDL actions that enable different kinds of permission flow.
In what follows, we shall introduce relevant predicates alongside the actions
that require them. The predicates below indicate the corresponding relation
tuples introduced in section 3.1.

  * •

$\operatorname{id\\_tpl}(\text{?{$\mathrm{id}$}1, ?$\mathrm{perm}$,
?{$\mathrm{id}$}2})$

  * •

$\operatorname{ds\\_tpl}(\text{?{$\mathrm{id}$}1, ?$\mathrm{perm}$,
?$\mathrm{ds}$})$

  * •

$\operatorname{id\\_4tpl}(\text{?{$\mathrm{id}$}, ?{$\mathrm{id}$}1,
?$\mathrm{perm}$, ?{$\mathrm{id}$}2})$

  * •

$\operatorname{ds\\_4tpl}(\text{?{$\mathrm{id}$}, ?{$\mathrm{id}$}1,
?$\mathrm{perm}$, ?$\mathrm{ds}$})$

⬇

(:action permissionFlow_id_3tpl

:parameters (?id2 ?perm ?id ?id1)

:precondition

(

isFlowActive(?id2, ?id1)&

id_tpl(?id2, ?perm, ?id)&

not id_tpl(?id1, ?perm, ?id)

)

:effect id_tpl(?id1, ?perm, ?id)

)

Listing 6: Permission flow of 3-tuple relations from $\mathrm{id}$2 to
$\mathrm{id}$1

⬇

(:action permissionFlow_id_4tpl

:parameters (?id1 ?id2 ?id3 ?perm ?id4)

:precondition

(

id_4tpl(?id2 ?id3 ?perm ?id4) &

isFlowActive(?id2 ?id1)&

not id_4tpl(?id1 ?id3 ?perm ?id4)

)

:effect id_4tpl(?id1 ?id3 ?perm ?id4)

)

Listing 7: Permission flow of 4-tuple relations from $\mathrm{id}$2 to
$\mathrm{id}$1

For exposition ease, we introduce the following logical condition that checks
whether permissions can flow from $\mathrm{id}$2 to $\mathrm{id}$1:

$\displaystyle\mathrm{isFlowActive}\text{(?{$\mathrm{id}$}2,
?{$\mathrm{id}$}1)}:=$
$\displaystyle\operatorname{id\\_tpl}\text{(?{$\mathrm{id}$}1,
$\mathrm{assumeRole}$, ?{$\mathrm{id}$}2)}\;$ $\displaystyle\vee$
$\displaystyle\operatorname{id\\_tpl}\text{(?{$\mathrm{id}$}1,
$\mathrm{belongsTo}$, ?{$\mathrm{id}$}2)}\;$ $\displaystyle\vee$
$\displaystyle\operatorname{id\\_tpl}\text{(?{$\mathrm{id}$}1,
$\mathrm{hasPolicy}$, ?{$\mathrm{id}$}2 )}$ (1)

This logical condition ensures if $\mathrm{id}$1 can either assume the role
$\mathrm{id}$2 (if $\mathrm{id}$2 is a role), or $\mathrm{id}$1 is part of
$\mathrm{id}$2 (if $\mathrm{id}$2 is a group), or in case $\mathrm{id}$2 is a
policy (a policy in AWS can also be represented as an identity type), then
$\mathrm{id}$1 has the policy $\mathrm{id}$2.

The interpretation of the action permissionFlow_id_3tpl in Listing 6 (using
$\mathrm{isFlowActive}$) is:

  * •

Assume that $\mathrm{id}$2 has permission
$\operatorname{id\\_tpl}\text{({$\mathrm{id}$}2, $\mathrm{perm}$,
{$\mathrm{id}$})}$.

  * •

Assume $\mathrm{isFlowActive}$ ($\mathrm{id}$2, $\mathrm{id}$1) holds.

  * •

In such a case, the permission that $\mathrm{id}$2 has
($\operatorname{id\\_tpl}\text{({$\mathrm{id}$}2, $\mathrm{perm}$,
{$\mathrm{id}$})}$) can flow to $\mathrm{id}$1\. This implies the tuple
$\operatorname{id\\_tpl}\text{({$\mathrm{id}$}1, $\mathrm{perm}$,
{$\mathrm{id}$})}$ will become activated as an effect of this action.

We can define an analogous action permissionFlow_ds_3tpl for permissions over
datastores (or resources); shown in the supplement (pddl model file). It is
possible to have a permission flow action that flows all the permissions
$\mathrm{id}$2 has to $\mathrm{id}$1 at once. In our testing, while simpler,
this action used forall effects, which was challenging for the planning
solver. Therefore, we use the current design of permission flow actions.

Listing 7 shows how permissions flow for 4-tuple relations. The interpretation
is analogous to action permissionFlow_id_3tpl. If
$\mathrm{isFlowActive(\text{{$\mathrm{id}$}2, {$\mathrm{id}$}1})}$ holds, and
$\mathrm{id}$2 has tuple $\mathrm{id\\_4tpl(\text{{$\mathrm{id}$}2,
{$\mathrm{id}$}3, $\mathrm{perm}$, {$\mathrm{id}$}4})}$, then
$\mathrm{id\\_4tpl(\text{{$\mathrm{id}$}1, {$\mathrm{id}$}3, $\mathrm{perm}$,
{$\mathrm{id}$}4})}$ holds. Action $\mathrm{permissionFlow\\_ds\\_4tpl}$ is
defined analogously for datastores.

⬇

(:action activate_id_3tpl

:parameters (?id1 ?perm ?id2)

:precondition

(

not id_tpl(?id1 ?perm ?id2) &

(

id_tpl(?id1 full_control ?id2)|

id_tpl(?id1 full_control any_user)|

id_tpl(?id1 ?perm any_user)

)

)

:effect id_tpl(?id1 ?perm ?id2)

)

Listing 8: Addressing regular expression $\star$ for “full_control” and
“any_user”

#### Actions for handling regular expressions

For succinct and efficient representation in PDDL (w.r.t. the number of
tuples), we use the keyword “full_control” to match to any permission in the
system, and “any_user” to match to any user (or analogously any role/group) in
the cloud environment. Such permissions are useful for defining admin users or
admin policy, or succinctly defining a set of permissions an identity can
have. This representation also helps the planner as the planner only needs to
instantiate the required tuple for an attack to match these keywords (and not
explicitly create all the tuples).

⬇

(:action add_id_3tpl

:parameters (?id1 ?id2 ?perm ?id3 )

:precondition (

not id_tpl(?id2 ?perm ?id3) &

compromised(?id1) &

id_4tpl(?id1 ?id2 ?perm ?id3 )

)

:effect id_tpl(?id2 ?perm ?id3)

)

Listing 9: Action for adding a 3-tuple to the cloud environment

⬇

(:action moveObject

:parameters (?id ?ds1 ?ds2 )

:precondition (compromised_id ?id) &

has_sensitive_data(?ds1) &

(not is_dummy_datastore(?ds1)) &

(not is_dummy_datastore(?ds2)) &

ds_tpl(?id s3_GetObject ?ds1) &

ds_tpl(?id s3_DeleteObject ?ds1)&

ds_tpl(?id s3_PutObject ?ds_2)

:effect has_sensitive_data(?ds2) &

(not has_sensitive_data(?ds1)) &

(when (is_public_datastore ?ds_2)

(sensitive_data_exfiltration)

)

)

Listing 10: Sensitive data attack action

Action in Listing 8 enables such a regular expression matching. The action
checks if predicate $\mathrm{id\\_tpl}\text{({$\mathrm{id}$}1,
$\mathrm{perm}$, {$\mathrm{id}$}2)}$ can be set to true. This is only possible
if full_control keyword is present to match to $\mathrm{perm}$, and any_user
matches to $\mathrm{id}$2, among other preconditions set in this action.
Analogously, we can define such an action for datastores as
$\mathrm{activate\\_ds\\_3tpl}$ where we can use keyword “any_datastore”
instead of any_user.

#### Actions for adding additional tuples

An attacker in a cloud setting can also add additional relations to the
environment to help itself achieve target attacks. This can be done by using
4-tuple relations as described in Section 3.1. Action in Listing 9 checks if
$\mathrm{id}$1 trying to add a tuple is a compromised id, has the required
permission $(\text{{$\mathrm{id}$}1, {$\mathrm{id}$}2, $\mathrm{perm}$,
{$\mathrm{id}$}3})$, and tuple to be added is not already present, then the
effect makes the predicate
$\mathrm{id\\_tpl}(\text{{$\mathrm{id}$}2,$\mathrm{perm}$, {$\mathrm{id}$}3})$
true. That is, now $\mathrm{id}$2 has permission $\mathrm{perm}$ on
$\mathrm{id}$3, which was not present earlier in the system. Analogously, we
can define an action add_ds_3tpl to add additional permissions over
datastores.

#### Actions to enable attacks

Previous class of actions described how permissions flow among different
identities, how to expand regular expressions and add additional relations to
the cloud environment. Actions in the current class check the set of
permissions the attacker has to enable any of the attacks noted in Table 1.
Listing 10 shows moveObject action for the sensitive data flow attack. This
action moves data from datastore $\mathrm{ds}$1 to $\mathrm{ds}$2 by copying
data from $\mathrm{ds}$1, moving it to $\mathrm{ds}$2, and then deleting data
from $\mathrm{ds}$1\. We also check if $\mathrm{ds}$1 has sensitive data as
only this enables sensitive data exfiltration attack. In the action effect, if
$\mathrm{ds}$2 is a public datastore, then it makes the attack predicate true.

There are several other actions that make different attack predicates true,
they are in the supplementary material (pddl model file).

#### Initial state

The initial state in the PDDL formulation consists of all the 3- and 4-tuple
relations mined from an organization’s AWS IAM. It also contains information
about which datastores are public and/or have sensitive data. We also have
predicates for currently non-existent datastores, which can be created by the
attacker for a data exfiltration attack; same holds for non-existing user
identities for the persistence attack. There are also predicates denoting
which identities are users, roles, groups, datastores, or policies.

We also need to define which user is compromised. There can be multiple ways
to do this. We can run the planner by setting each user as compromised one by
one. Another method, which is faster, when we are looking to generate any
attack plan for a particular type of attack is to let the planner choose which
user to make compromised. This action is selectCompromisedUser shown in
Listing 11. Typically, we compromise user identities (not group or role-type
identities). We also have additional predicates to make sure that the action
selectCompromisedUser is the first action to be executed (and only once) in
the plan (details omitted). It is also possible to compromise multiple users
in case required by the end use case.

#### Goal state

The goal state contains which attack type we would like to generate an attack
for (that is, a predicate for each entry in Table 1).

⬇

(:action selectCompromisedUser

:parameters ?id

:precondition user_pred(?id)

:effect compromised_id(?id)

)

Listing 11: Action to select a compromised user

##  4 Results

Our evaluation methodology is twofold, addressing both the verification of
modeling accuracy and the identification of actual attacks. For verification,
we employ the IAM Vulnerable benchmark (Fox 2021) developed by Bishop Fox (Fox
2023), a penetration testing firm. This benchmark comprises 31 attack
scenarios associated with various AWS cloud services, particularly those
vulnerable to misconfigurations potentially leading to privilege escalation
attacks. The accuracy of the model is demonstrated through the application of
CloudExploit across 14 distinct cloud configurations belonging to various
commercial organizations. Details about the experimental setup are in
supplementary. Anonymized datasets used in our evaluation together with
CloudExploit’s implementation will be publicly released.

Data set |  Users |  Groups |  Roles |  Data stores |  Permissions
---|---|---|---|---|---
1 |  1,648 |  38 |  1,093 |  230 |  18,537
2 |  180 |  30 |  673 |  167 |  7,003
3 |  107 |  38 |  580 |  147 |  4,540
4 |  189 |  20 |  1,117 |  452 |  16,894
5 |  103 |  22 |  525 |  166 |  14,624
6 |  1,587 |  51 |  794 |  257 |  30,930
7 |  29 |  21 |  283 |  182 |  38,592
8 |  670 |  23 |  131 |  115 |  210,645
9 |  388 |  100 |  2,146 |  406 |  762,461
10 |  832 |  102 |  4,902 |  1,644 |  245,860
11 |  129 |  10 |  112 |  94 |  11,639
12 |  674 |  17 |  1,676 |  1,654 |  1,086,714
13 |  582 |  110 |  64,880 |  2,857 |  12,150,172
14 |  1,113 |  132 |  15,520 |  3,477 |  1,277,689
Table 2: Properties of real-world data sets Figure 1: Real-world datasets: The
number of unique compromised users (after exclusion of admin users).

###  4.1 IAM Vulnerable Benchmark

We conducted a thorough evaluation of our model’s accuracy against IAM
Vulnerable benchmark (Fox 2021), specifically focusing on the attack scenarios
relevant to our modeling efforts. Remarkably, CloudExploit successfully
detected all 19 attacks (out of 31) that are within the scope of PDDL
modeling.

In terms of IAM policy modeling, CloudExploit demonstrates comprehensive
support for the most frequently used services, such as IAM, EC2, S3, Lambda,
STS, and SSM. However, we deliberately chose to exclude less common services
like SageMaker, CloudFormation, CodeBuild, and DataPipeline from our modeling
process to keep PDDL problem files compact for solver scalability. This
exclusion accounts for the 12 undetected test cases in the benchmark. In
summary, our evaluation highlights CloudExploit’s effectiveness in modeling
and detecting vulnerabilities within the scope of widely used AWS services.

###  4.2 Real-world Datasets

CloudExploit is employed to analyze 14 commercial cloud configurations,
detailed in Table 2. The data includes hundreds to thousands of identities and
datastores. To our knowledge, this dataset is one of the most extensive in
cybersecurity for modeling cloud permission vulnerabilities.

To enable Fast Downward solver to process such large datasets, we partition
them based on AWS accounts that serve as effective boundaries for both
administration and billing. In some cases account partitioning is not
sufficient because the solver still runs out of memory. To handle those
situations we partition an account into non-overlapping groups of users and
include other types of identities and datastores that are reachable from the
source users via permission edges using breadth-first search. We intentionally
exclude admin users from our analysis, as compromising such users is likely to
have a widespread impact on the entire system, attributable to their extensive
array of potentially high-risk permissions.

Figure 2: Distribution of attack path lengths measured in terms of the number
of actions

#### Attack path diversity

Our evaluation methodology is designed to estimate the diversity of attack
paths generated by CloudExploit. It’s important to note that a mere syntactic
analysis of these paths is insufficient, as their diversity could be
artificially increased by the inclusion of irrelevant actions that do not
alter their semantic meaning. For instance, a path that incorporates a role
assumption action that is irrelevant to the attack may appear different from
one without such a redundant element, yet both paths are semantically
identical. Our approach to measuring attack diversity draws on principles from
the cybersecurity domain. We specifically gauge the number of compromised
users for each attack-data set combination. While there may exist other
diverse paths, the critical factor for our analysis is the extent to which
users are vulnerable to attacks.

Figure 1 presents the number of compromised users for each attack, data set
combination. The y-axis indicates the count of compromised users, while the
data sets are arrayed along the x-axis. CloudExploit identified 425 non-admin
users across the datasets who could potentially be exploited by attackers to
initiate one or more attacks if compromised.

A noticeable trend is the vulnerability of almost all real data sets to
ransomware and impact attacks, such as encrypting and deleting sensitive data
or removing critical cloud resources: identities, access keys essential for
programmatic access to cloud resources, and IAM policies. The latter action
usually leads to the removal of access-control constraints, potentially
resulting in privilege escalation.

At least one user in nearly every environment can execute a ransomware attack.
This vulnerability stems from flaws in the IAM model. To conduct a ransomware
attack, as detailed in Section 2.1, a user requires just two permissions:
s3:PutObject and kms:CreateKey. The former is a common ’write’ permission,
while the latter is often inadvertently assigned through blanket KMS access,
neglecting the exclusion of hazardous permissions. Additionally, CloudExploit
evaluates two critical S3 bucket configuration parameters: versioning and
multi-factor authentication (MFA). The activation of bucket versioning enables
the restoration of any version of objects stored in an S3 bucket. Meanwhile,
MFA protection mandates extra authentication for object deletion in an S3
bucket, enhancing security against unauthorized actions. In our experiments,
we found that both of those configuration settings are disabled sometimes,
which is a prerequisite for a successful ransomware attack.

Contrary to our initial expectations, our analysis identified that three
organizations are prone to privilege escalation attacks, which are among the
most severe security vulnerabilities. Surprisingly, in the data set #5,
numerous users have the capability to carry out data exfiltration attacks. A
deeper investigation disclosed that the organization possesses an S3 datastore
filled with synthetic sensitive data accessible to almost all users for
software development purposes.

#### Distribution of attack path lengths

In our analysis, we focus on the lengths of the generated attack paths, as
illustrated in Figure 2. Predominantly, these paths are short, with lengths of
2 or 3 actions, indicating that compromised users often have immediate access
to the necessary permissions for launching attacks. Conversely, paths
extending to 4 or more steps represent a distinct pattern, typically involving
the propagation of permissions via PDDL permission flow actions (Section 3.2).
From a security perspective, this indicates a requirement for attackers to
augment their permissions, either through assuming roles or by leveraging
inherited permissions from their security group memberships.

Figure 3: Execution time of the translation and search phases of the Fast
Downward planner (log scale)

#### Execution time

We mentioned earlier the Fast Downward solver’s scalability issues with real-
world datasets. Our analysis, detailed in Figure 3, examines the execution
times of the translation and search phases separately, with results plotted on
a logarithmic scale on the vertical axis. Significantly, the translation phase
dominates in execution time and is more prone to memory exhaustion compared to
the search phase. Improving scalability would result in even more attack
exploit being found.

#### Real-world Attack Examples

As previously mentioned, we conducted a manual analysis of generated attack
paths to ensure they were free of modeling errors. In this section, we present
a selection of these attack paths for illustration. For clarity, we focus on
the shorter paths. We exclude the discussion of ransomware attacks, as their
details have been covered in Section 2.1. The supplement shows a more complex,
longer plan.

#### Impact attack

Listing 12 demonstrates a three-step impact attack. The attack initiates by
designating user_181 as a compromised entity. It then enables the deleteBucket
permission. This permission is available to user_181 due to their
comprehensive (full_control) access rights, thus authorizing them to employ
the deleteBucket action on data_store_71. This particular S3 bucket,
identified as containing sensitive data through a prior data scan, becomes the
target. The attack reaches its conclusion when user_181 executes the
deleteBucket action, effectively compromising the data.

⬇

(:action selectCompromisedUser

:parameters (user_181))

(:action activate_ds_3tpl

:parameters (user_181

deleteBucket data_store_71))

(:action deleteBucket

:parameters (user_181 data_store_71))

Listing 12: Impact attack

#### Sensitive data exfiltration

We discovered that in one of the commercial environments (referred to as
dataset #5), there exists an IAM configuration that permits user_0 access to
data_store_0, a repository of sensitive data, as well as to a public
data_store_138 (Listing 13). At first glance, this might appear as a minor
issue in IAM design. However, this configuration could potentially lead to a
significant data breach. The absence of protections against legitimate data
transfers between S3 buckets means attackers could transfer large volumes of
sensitive data to data_store_138 rapidly. AWS S3, known for its high data
throughput capabilities, could facilitate the swift transfer of gigabytes of
sensitive information out of public data_store_138.

⬇

(:action selectCompromisedUser

:parameters (user_0))

(:action copyobject

:parameters (user_0 data_store_0

data_store_138))

Listing 13: Sensitive data exfiltration attack

###  4.3 Comparison against PMapper

We compare PMapper, the only publicly available tool tackling a similar
problem as CloudExploit, albeit with a narrower focus. PMapper is limited to
identifying privilege escalation attack paths, whereas CloudExploit has a much
broader scope - it detects 6 different attack types. Unlike CloudExploit’s
formal methodology for modeling IAM permissions, PMapper relies on scanning
IAM policies and identifying dangerous permissions via ad-hoc definitions,
making it incapable of detecting attacks involving sensitive data, such as
ransomware or data exfiltration, due to its lack of datastore visibility.
Moreover, PMapper’s limitation in not providing a comprehensive attack plan
makes the manual validation of reported attacks difficult, necessitating
extensive knowledge of PMapper’s internal mechanisms.

CloudExploit and PMapper differ in their categorization of attacks.
CloudExploit aligns with standard MITRE (ATT&CK 2021) categories, while
PMapper primarily labels attacks as privilege escalation, which may not always
be accurate. In our analysis, PMapper flagged 19 users for potential privilege
escalation, with 9 of these also recognized by CloudExploit. The discrepancy
in results – specifically, the 10 additional users identified by PMapper – can
be attributed to its inadequate modeling of the AWS IAM permission model and
less rigorous attack patterns compared to CloudExploit. This can lead to
ambiguous conclusions about exploitability, as successful exploitation often
depends on system configurations not covered in their modeling. In addition to
the 9 users identified by both CloudExploit and PMapper, CloudExploit
pinpoints 416 additional users vulnerable to at least one attack type. This
broader detection range is due to CloudExploit’s capability to model six
attack types, in contrast to PMapper’s focus on just one.

##  5 Conclusion

Our research not only identifies key vulnerabilities in contemporary cloud
infrastructures but also offers a viable and efficient solution for mitigating
these risks, thus significantly improving the security and dependability of
cloud computing services. CloudExploit, grounded in a robust formal framework,
addresses existing deficiencies in cloud security. Its proficiency in
detecting sophisticated cloud attacks has been thoroughly validated across
multiple commercial cloud configurations.

## References

  * Amazon AWS (2023) Amazon AWS. 2023.  AWS Documentation.  https://docs.aws.amazon.com/.
  * ATT&CK (2021) ATT&CK, M. 2021.  ATT&CK Matrix for Enterprise.  https://attack.mitre.org.  Accessed: 2022-05-29.
  * AWS (2023) AWS. 2023.  Shared Responsibility Model.  https://aws.amazon.com/compliance/shared-responsibility-model/.
  * Backes et al. (2018) Backes, J.; Bolignano, P.; Cook, B.; Dodge, C.; Gacek, A.; Luckow, K.; Rungta, N.; Tkachuk, O.; and Varming, C. 2018.  Semantic-based Automated Reasoning for AWS Access Policies using SMT.  In _Formal Methods in Computer Aided Design (FMCAD)_ , 1–9.
  * Boddy et al. (2005) Boddy, M.; Gohde, J.; Haigh, T.; and Harp, S. 2005.  Course of Action Generation for Cyber Security Using Classical Planning.  In _International Conference on International Conference on Automated Planning and Scheduling_ , 12–21.
  * CSA (2023) CSA. 2023.  Top Threats to Cloud Computing: Pandemic 11 Deep Dive.  https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-pandemic-eleven-deep-dive/.
  * Fox (2021) Fox, B. 2021.  IAM Vulnerable.  https://github.com/BishopFox/iam-vulnerable.  Accessed: 2023-12-01.
  * Fox (2023) Fox, B. 2023.  Bishop Fox.  https://bishopfox.com.  Accessed: 2023-12-01.
  * Gietzen (2021) Gietzen, S. 2021.  AWS IAM Privilege Escalation – Methods and Mitigation.  https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/.
  * Helmert (2006) Helmert, M. 2006.  The Fast Downward Planning System.  _Journal of Artificial Intelligence Research_ , 26(1): 191–246.
  * Hoffmann (2015) Hoffmann, J. 2015.  Simulated Penetration Testing: From “Dijkstra” to “Turing Test++”.  In _ICAPS_ , 364–372.
  * Holmes (2021) Holmes, A. 2021.  533 million Facebook users’ phone numbers and personal data have been leaked online.  https://www.businessinsider.com/stolen-data-of-533-million-facebook-users-leaked-online-2021-4.  Accessed: 2022-05-29.
  * Hu et al. (2023) Hu, Y.; Wang, W.; Khurshid, S.; McMillan, K. L.; and Tiwari, M. 2023.  Fixing Privilege Escalations in Cloud Access Control with MaxSAT and Graph Neural Networks.  In _IEEE/ACM International Conference on Automated Software Engineering (ASE 2023)_. IEEE.
  * Jayaraman et al. (2019) Jayaraman, K.; Bjørner, N.; Padhye, J.; Agrawal, A.; Bhargava, A.; Bissonnette, P.-A. C.; Foster, S.; Helwer, A.; Kasten, M.; Lee, I.; Namdhari, A.; Niaz, H.; Parkhi, A.; Pinnamraju, H.; Power, A.; Raje, N. M.; and Sharma, P. 2019.  Validating Datacenters at Scale.  In _Proceedings of the ACM Special Interest Group on Data Communication_ , 200–213.
  * Kazdagli, Tiwari, and Kumar (2022) Kazdagli, M.; Tiwari, M.; and Kumar, A. 2022.  Using Constraint Programming and Graph Representation Learning for Generating Interpretable Cloud Security Policies.  In _International Joint Conference on Artificial Intelligence,_ , 1850–1858.
  * Kuenzli (2020) Kuenzli, S. 2020.  Why are good AWS security policies so difficult?  https://www.k9security.io/posts/2020/06/why-are-good-aws-security-policies-so-difficult.  Accessed: 2023-12-01.
  * Labs (2019) Labs, R. S. 2019.  S3 Ransomware Part 1: Attack Vector.  https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/#:~:text=Attacker%20creates%20a%20KMS%20key,not%20decrypt%20objects%20in%20S3. Accessed: 2023-12-01.
  * Lippmann and Ingols (2005) Lippmann, R.; and Ingols, K. 2005.  An Annotated Review of Past Papers on Attack Graphs.
  * Marks (2021) Marks, G. 2021.  A LinkedIn ‘Breach’ Exposes 92% Of Users.  https://www.forbes.com/sites/quickerbettertech/2021/07/05/a-linkedin-breach-exposes-92-of-usersand-other-small-business-tech-news.  Accessed: 2022-05-29.
  * NCC Group (2023) NCC Group. 2023.  Principal Mapper.  https://github.com/nccgroup/PMapper.
  * Obes, Sarraute, and Richarte (2010) Obes, J. L.; Sarraute, C.; and Richarte, G. 2010.  Attack Planning in the Real World.  In _SecArt’10_.
  * One (2022) One, C. 2022.  Information on the Capital One Cyber Incident.  https://www.capitalone.com/digital/facts2019/.
  * Pang et al. (2019) Pang, R.; Caceres, R.; Burrows, M.; Chen, Z.; Dave, P.; Germer, N.; Golynski, A.; Graney, K.; Kang, N.; Kissner, L.; Korn, J.; Parmar, A.; Richards, C.; and Wang, M. 2019.  Zanzibar: Google’s Consistent, Global Authorization System.  In _USENIX Annual Technical Conference (USENIX ATC)_.
  * Pernet (2021) Pernet, C. 2021.  Research reveals that IAM is too often permissive and misconfigured.  https://www.techrepublic.com/article/research-iam-permissive-misconfigured/.
  * Salesforce (2023) Salesforce. 2023.  Policy Sentry: IAM Least Privilege Policy Generator.  https://policy-sentry.readthedocs.io/en/latest/.
  * Sarraute, Buffet, and Hoffmann (2012) Sarraute, C.; Buffet, O.; and Hoffmann, J. 2012.  POMDPs Make Better Hackers: Accounting for Uncertainty in Penetration Testing.  In _AAAI_.
  * Scroxton (2020) Scroxton, A. 2020.  Leaky AWS S3 bucket once again at centre of data breach.  https://www.computerweekly.com/news/252491842/Leaky-AWS-S3-bucket-once-again-at-centre-of-data-breach.  Accessed: 2022-05-29.
  * Unit42 (2022) Unit42. 2022.  IAM Your Defense Against Cloud Threats: The Latest Unit 42 Cloud Threat Research.  https://unit42.paloaltonetworks.com/iam-cloud-threat-research/.  Accessed: April 12, 2022.