# Bypass Cloudtrail Detection using AWS Appstream ### Introduction *** In this blog, we're going to talk about how one can bypass cloudtrail detection with AWS AppStream. While AWS AppStream has been a game-changer in managing applications, it seems there might be a loophole that could possibly be exploited for evading CloudTrail detection. We'll delve into the nitty-gritty of this issue, exploring the roles and permissions that could potentially be manipulated to bypass detection. ### What is Appstream 2.0 ? *** [AWS AppStream](https://docs.aws.amazon.com/appstream2/) is a fully managed application streaming service from Amazon, allowing users to access and use desktop applications from any device, anywhere, through a web browser. While deep diving into AWS AppStream, it's essential to understand the different roles that come into play when launching AppStream instances in resource accounts. These roles, managed by AppStream, are pivotal in facilitating backend service communication. The roles are as follows: * **PhotonInstance Role**: Identified in the "aws sts get-caller-identity" output, this role is crucial during the launch of AppStream instances in resource accounts. * **Machine Role ( appstream\_machine\_role )**: Created by the customer within their AWS account, it is vital to assign the correct permissions to this role and attach it to the AppStream fleet. This role is referred to as “test-appstream” in the blog. * **AppStream Service Role ( AmazonAppStreamServiceAccess )**: This role describes the native AWS resources in a customer's account and is used by the backend for instance provisioning, making it a requisite when utilizing the AppStream service. **It is noteworthy that AppStream does not document any CloudTrail data from end-users who are utilizing the instance.** * The IAM roles in question are configured by the customer, and all role permissions are defined by the customer. * As AppStream processes the request from its end user to launch an EC2 instance for a corresponding user, the CloudTrail logs document AppStream by name. * As an attacker, you would need access to AWS Appstream instances **NOTE: AWS will soon update its documentation for enhanced clarity.** ### **Understanding How Appstream Works?** *** * When an end user logs into a Linux fleet, they are assigned a user named `as2-streaming-user` * This user has access to all applications that are installed on the fleet's image by the admins. Thus, using an image created from the image builder for the AppStream fleet grants default access to all its installed applications. It is important to note this that Access to files/folders and applications on an image is controlled by admins. While creating image, admin can choose to configure ACLs to prevent users from accessing such resources. `as2-streaming-user` is a **non-privileged user**. * By default, **awscli** is pre-installed. * Running the command `aws sts get-caller-identity | jq .` reveals that the AWS accountID is not the customer's account but rather AWS managed account.

* Reviewing the role linked with the fleet, it's evident that only `appstream.amazonaws.com` can assume this role.

* After checking the IAM Role(**test-appstream),** the trusted entity of the role was allowing only **appstream.amazonaws.com** to assume this role. As you can see currently we are running this fleet on an EC2 instance, and yet **ec2.amazonaws.com** is not mentioned under the trusted entity.

* If IMDS was present(which actually is) and the IAM Role was directly attached to the instance profile corresponding to the EC2 instance, then ideally **ec2.amazonaws.com** should have been under the **Trusted Entity** * This means, this instance is running under the fleet of **Appstream AWS Accounts** whose source is **appstream.amazonaws.com** * This instance operates under the fleet of AppStream AWS accounts, sourced from appstream.amazonaws.com. However, it cannot assume the role directly; only the AppStream service can assume this role, subsequently making temporary credentials available within the context of the instance, i.e `arn:aws:iam::761675973624:role/test-appstream`. * But there is another way of assuming the role and fetching these credentials, essentially impersonating **Appstream Service.** ### Understanding \~/.aws/config for appstream instances *** * Upon checking `~/.aws/config` It reveals two unique profiles: `appstream_machine_role` and `appstream_home_folder_role` * If you look closely, there is an executable **AppStreamRoleCredentialProvider** which helps this instance to essentially assume a role(generate credentials) in the customer's AWS Account and perform necessary tasks. ```json [profile appstream_machine_role] credential_process = /usr/local/appstream/credentials-provider/AppStreamRoleCredentialProvider --role=Machine [profile appstream_home_folder_role] credential_process = /usr/local/appstream/credentials-provider/AppStreamRoleCredentialProvider --role=S3HomeFolder ``` ### Bypassing Cloudtrail *** * With the command `aws sts get-caller-identity --profile appstream_machine_role | jq .`, access to the role `arn:aws:iam::761675973624:role/test-appstream` is established, which is typically only accessible through **appstream.amazonaws.com**. ```json { "Account": "761675973624", "UserId": "AROA3CV3NAP4BCIV7TASY:PhotonSession", "Arn": "arn:aws:sts::761675973624:assumed-role/test-appstream/PhotonSession" } ``` * By exploring further and executing `aws sts get-caller-identity --profile appstream_home_folder_role`, we see both roles have been assumed.

* The Role Session Name always remains the same for all users who access appstream service **PhotonSession -> appstream\_machine\_role** and **Appstream2.0 -> appstream\_home\_folder\_role** * Checking Cloudtrail we can also see some trails regarding this username as **AppStream2.0** & **PhotonSession**. Notably, AWS services integrated with CloudTrail emit events when they are accessed using AWS credentials. In this case, as shown in the CloudTrail events, AppStream is accessing S3 and EC2 on behalf of customers using `AmazonAppStreamServiceAccess` service role or the fleet machine role. Even though machine role is used by customer applications (or users), since it is assumed by AppStream to make temporary credentials available on the instance, CloudTrail events are shown under AppStream.

Cloudtrail logging user activity as Appstream2.0

Cloudtrail logging userIP as appstream.amazonaws.com

* CloudTrail logs **sourceIP** as **appstream.amazonaws.com**. Our objective is to bypass CloudTrail detection and utilize the keys generated by `/usr/local/appstream/credentials-provider/AppStreamRoleCredentialProvider --role=Machine` or by simply using the `--profile appstream_machine_role` with AWS CLI commands. **NOTE: The `machine_role` is provisioned to facilitate customer applications or users connecting to the fleet to access AWS resources seamlessly. It is important to note that the policies governing this role are managed by the customers, allowing for a tailored approach to accessing AWS resources.** * Generating a [FederateLink](https://github.com/groovyBugify/aws-federated-login) for console sign-in is equally straightforward: ```bash /usr/local/appstream/credentials-provider/AppStreamRoleCredentialProvider --role=Machine -> {machine_role_credentials} python3 federation.py ``` * This produces a federated link to access AWS Management Console, enabling access AWS Management console, enabling low privileges user to utilise IAM Role attached to the fleet.

Generating Federeated Link for Console Access

* Accessing the AWS management console through the federated link is seamless.

Console access via "appstream-machine-role"

* CloudTrail subsequently recorded the entries.

### Testing out same hypothesis on AWS Lambda with service-roles *** * Let's create a simple python function on AWS Lambda with the following contents ```python import os def lambda_handler(event, context): os.system("printenv") ``` * We can extract the STS Credentials for the service role that is attached to the Lambda function via the env variables.

exporting AWS Lambda's credentials to local

* Upon configuring the Credentials on my local system, you can check the subsequent Cloudtrail API calls of these credentials which is clearly logging my source IP address for the API call "**GetCallerIdentity**".

cloudtrail logging my IP address after running "GetCallerIdentity"

### Signoff notes According to the mentioned method one can simply generate credentials using the internal executables built by AWS team and bypass **sourceIP and userName** detection on Cloudtrail. Few things to keep in mind * Customers are responsible for the Images that they wish to attach to the fleet. * "appstream\_machine\_role" is configurable by customers essentially meaning granting access to AWS Resources and Services is upto the customer. * Any usage of the credentials generated by "appstream\_machine\_role" or "AmazonAppstreamServiceAccess" either from your local machine or from the running fleet will be logged as **appstream.amazonaws.com** under **sourceIP** and **PhotoSession/Appstream2.0** under **userName** **Thank You!** **Saransh Rana** **Infrastructure Security @ CRED**