Welcome to the November 2022 SCYTHE #ThreatThursday! This month’s emulation takes a break from our traditional adversary emulation campaigns and instead features use of BishopFox’s cloud enumeration tool CloudFox. A common question we hear from SCYTHE customers is “how do we use SCYTHE to audit the security of our cloud resources?” Some clarification is needed since SCYTHE is an adversary emulation platform focusing on post-exploitation and this question implies a different use-case: a customer wanting to perform an audit. Diving deeper into the question and peeling back the layers reveals the idea that customers are looking for tooling to help ensure they have configured the appropriate settings in the public cloud environments.

This of course is understandable and totally relatable. Public cloud providers, such as AWS, GCP, or Azure, offer organizations unprecedented capabilities to rapidly scale their infrastructure up and down based on demand. This can represent significant cost savings for the organization, especially when they have workloads that are idle for large portions of the day. However, there’s no such thing as a free lunch and certainly that sentiment applies to the public cloud as well. Deploying to the public cloud extends your perimeter, and starting a deployment comes with all the security risks of adding another remote office where you have critical assets deployed. Assets in the public cloud are more easily exposed directly to the Internet, often accidentally, which significantly expands your organization's attack surface. Being able to quickly assess your current cloud security posture is a use case SCYTHE can assist with.

We have put together a plan that demonstrates use of CloudFox for basic reconnaissance and enumeration. CloudFox is a command line tool that contains a collection of enumeration commands that offensive security professionals can use to explore unfamiliar cloud environments and discover attack paths in AWS infrastructure. We won’t be providing ATT&CK tagging as this campaign is not indicative of real threat actor behavior, and as such detection engineering isn’t warranted. Before running this campaign, please ensure you are on a system with an AWS IAM role configured or under an account with AWS credentials configured or you will receive error messages/failed steps.

In our plan, CloudFox will be downloaded to the directory specified in ‘WORKING_DIR’. By default, CloudFox creates a profile directory (.cloudfox) in the home directory of the user who runs it which contains the logs. This is one of the many reasons we note that cloudfox is not a tool a typical threat actor would run.

The version of cloudfox used in this emulation has been modified to run more seamlessly for our customers (modified source available here). Our custom build of cloudfox is built from source tagged as 1.9.0, but predates an official 1.9.0 release. Unlike the typical cloudfox, it does not create a ~/.cloudfox directory for logs. Instead, we write a cloudfox-logs directory to the current working directory (in our emulation this will be the “WORKING_DIR” variable.

The other change to our version of cloudfox is that it does not output anything to the console. Outputting status messages to the console can make sense for interactive tool use, but for unattended tool use these messages provide no value. An added benefit of removing console output is that emojis and other unicode characters output to the console cannot interfere with any operation of the SCYTHE implant or the reporting UI. Note that no data is lost by removing these status messages. All data is still present in the cloudfox-output directory.

The specific enumeration command to run can be set by editing the ‘CloudFoxCommand’ variable. In our emulation, we use the default of “all-checks” which (as the name implies) runs all checks for AWS in this build of cloudfox. You might want to change it to one of the other checks to reduce noise in your CloudTrail logs. The full list of options for ‘CloudFoxCommand’ include:

access-keys: Enumerate active access keys for all users
all-checks: Run all of the other checks (excluding outbound-assumed-roles)
buckets: Enumerate all of the buckets. Get loot file with s3 commands to list/download bucket contents
cloudformation: Enumerate Cloudformation stacks. Get a loot file with stack details. Look for secrets.
ecr: Enumerate the most recently pushed image URI from all repositories. Get a loot file with commands to pull images
ecs-tasks: Enumerate all ECS tasks along with assigned IPs and profiles
elastic-network-interfaces: Enumerate all elastic network interfaces along with their private and public IPs and the VPC
endpoints: Enumerates endpoints from various services. Get a loot file with http endpoints to scan.
env-vars: Enumerate the environment variables from multiple services that have them
filesystems: Enumerate the EFS and FSx filesystems. Get a loot file with mount commands
iam-simulator: Wrapper around the AWS IAM Simulate Principal Policy command
instances: Enumerate all instances along with assigned IPs, profiles, and user-data
inventory: Gain a rough understanding of size of the account and preferred regions
lambda: Enumerate lambdas.
outbound-assumed-roles: Find the roles that have been assumed by principals in this account
permissions: Enumerate IAM permissions per principal
principals: Enumerate IAM users and Roles so you have the data at your fingertips
ram: Enumerate cross-account shared resources
role-trusts: Enumerate all role trusts
route53: Enumerate all records from all zones managed by route53. Get a loot file with A records you can scan
secrets: Enumerate secrets from secrets manager and SSM
tags: Enumerate resources with tags.

‍

We begin by creating our working directory. Then we download CloudFox to the working directory, unzip the file, and give ourselves read/write/execute permissions.

Next we execute CloudFox with the command we specified earlier. In our plan, the default command is ‘all-checks’.

Following completion of the all-checks command we zip the log files, upload/exfiltrate the data, and remove the artifact.

The next steps provided are used to display the data collected for better visualization in the SCYTHE campaign reporting.

‍

The loot directory contains commands you can use to further interrogate systems, such as listing contents of S3 buckets, as shown below. Note that you may not have any such output. Cloudfox can only enumerate resources that the corresponding IAM role or credentials can access.

‍

‍

The table directory contains output, such as the public IP addresses of running EC2 instances (as shown below). Note that you may not have any such output. Cloudfox can only enumerate resources that the corresponding IAM role or credentials can access.

‍

Operational Notes

Because SCYTHE is not a Cloud Security Posture Management (CSPM) tool, we make no attempt to interpret security implications of the data collected by Cloudfox. This emulation plan is one of many to come where SCYTHE focuses on collecting security artifacts useful to the security team. As with this CloudFox plan, these will often use tools that threat actors themselves are unlikely to employ due to OPSEC considerations.

‍

If you have CloudTrail logging enabled, running this emulation with the all-checks parameter (as is the default), will result in significant logging. Because most IAM roles and API keys should not have access to all resources, enumeration is likely to create alarms in security tools ingesting CloudTrail logs. Notify your cloud security teams before running this emulation plan.

‍

To learn more about cloudfox and its output, please refer to the BishopFox documentation linked in the Github repo. Stay tuned for more cloud-focused content to come!

‍

-SCYTHE AES Team

‍

This Threat Thursday post discusses data, tools, or active research by other cited third parties into an ongoing threat. This information is provided “as-is” without any warranty or condition of any kind, either express or implied.

‍

References: