By Alex Delamotte, with Ian Ahl (Permiso) and Daniel Bohannon (Permiso)

Executive Summary

• Throughout June 2023, an actor behind a cloud credentials stealing campaign has expanded their tooling to target Azure and Google Cloud Platform (GCP) services. Previously, this actor focused exclusively on Amazon Web Services (AWS) credentials.
• Cloud service credentials are increasingly targeted as actors find more ways to profit from compromising such services. This actor targeted exposed Docker instances to deploy a worm-like propagation module.
• These campaigns share similarity with tools attributed to the notorious TeamTNT cryptojacking crew. However, attribution remains challenging with script-based tools, as anyone can adapt the code for their own use.

Background

In December 2022, the threat research team at Permiso Security reported about a cloud credential stealer campaign that primarily targeted Amazon Web Services (AWS) credentials from public-facing Jupyter Notebooks services. The actors likely accessed these impacted services through unpatched web application vulnerabilities.

From June 14, 2023 through the end of the month, we worked with the Permiso team to track and analyze files related to a new incarnation of this campaign targeting exposed Docker services. The hallmark shell scripts remain the core of these campaigns, though we also identified an Executable and Linkable Format (ELF) binary written in Golang. The research team at Aqua also recently reported elements they observed from these actors’ abuse of Docker images.

SentinelLabs thanks the Permiso Security research team for their collaboration on the research in this report. The Permiso team released a blog about this campaign, which can be found here.

Tooling Updates

Since the December campaign, the actor has made several updates to how their tooling works.

Script Functionality

The December campaign targeted AWS credentials; the most recent campaigns added functions that target credentials from Azure and GCP. The actor actively modified these features as the campaigns evolved throughout June: Initially, a script aws.sh contained references to Azure credentials, but the relevant function was not called. A week later, samples emerged where the Azure credential functions were called.

The actor stored the generic credentials in an array labeled CRED_FILE_NAMES. The AWS-specific array from the original script ACF has been replaced with AWS_CREDS_FILES. We dive into this in more detail in the next section. There are also two new cloud service provider (CSP)-specific credentials variables: GCLOUD_CREDS_FILES and AZURE_CREDS_FILES.

The actor made the script more modular as it grew larger and more complex. The AWS functionality is now split into three smaller functions that are driven by the run_aws_grabber function only if the system is identified as AWS. This increases the efficiency of the script by running AWS commands only on AWS systems, which also enhances the script’s stealth.

Infrastructure

The actor no longer hosts files in an open directory, which complicates efforts to track and analyze these campaigns. Instead, C2 activity relies on a hardcoded username and password combination that are passed as arguments to the curl command.

The older campaign infrastructure was hosted on a Netherlands-based IP associated with Nice IT Services. The attacker has since moved infrastructure to AnonDns, a dynamic domain name service (DDNS) provider. The campaigns through June 2023 use one of several AnonDNS subdomains:

everlost.anondns.net
silentbob.anondns.net
ap-northeast-1.compute.internal.anondns.net

Credentials Collection

The newer versions target credentials in newly added arrays GCLOUD_CREDS_FILES and AZURE_CREDS_FILES. The versions emerging the week of 6/26/2023 added .env and docker-compose.yaml; the version from 6/15/2023 has env without the period, so the actor is apparently updating the tool to be more effective in the newest campaign. The newest campaign also has a new variable, MIXED_CREDFILES which contains only redis.conf.

The newer versions omitted the following credentials files that were present in the December campaign’s ACF:

cloud
.npmrc
credentials.gpg

The credentials collection logic in the new campaign’s samples targets the following services & technologies:

There is considerable overlap in the targeted files between these credential stealer campaigns and the TeamTNT Kubelet-targeting campaign reported by Sysdig in October 2022.

The script uses the cred_files function to search for credentials files on the system, write them to a temporary file $EDIS, copy the new file to a master credential-holding file $CSOF, then delete the temporary file. The $EDIS and $CSOF variable file names and paths are randomly generated via the special use Bash variable $RANDOM, meaning the value is an integer between 0 and 32767 that changes each time $RANDOM is accessed.

AWS

The new scripts show more attention to making the features modular, a natural evolution as a script becomes more complex. The AWS-specific functionality is driven by a function named run_aws_grabber. Most AWS-centric features from the December campaign have been rolled into one of four functions driven by run_aws_grabber:

• get_aws_infos: Queries the AWS instance metadata service (IMDS) for IAM configuration and sets the output to $AWS_INFO, as well as security credential configuration from EC2 and IAM resources, which are set to $AWS_1_EC2 and $AWS_1_IAM_NAME, respectively.
• get_aws_meta: Writes the values from each of the variables generated in get_aws_infos then parses the data for specific values via grep and extracts them using sed, writing the output to the $CSOF variable.
• get_aws_env: Checks for values in AWS credential related variables, writes them to $CSOF when present. When the $AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is found, the function calls curl against the URL, then modifies the response using sed to format specific values into an aws configure set command. For example, the string AccessKeyId in the response is transformed to aws configure set aws_access_key_id. The actor likely chose to format the values as a command so that the output feeds into additional automated actions.

• get_awscli_data: This function is only implemented in the two most recent versions: the function exists in the 6/15/2023 version of aws.sh, but it is not called. The function invokes aws sts get-caller-identity to collect the 12-digit AWS account identifier and writes the result to $CSOF.

Azure & GCP

A notable recent addition is logic specific to the Azure and Google Cloud platforms. The get_azure and get_google functions are implemented in the newest versions seen on 06/26/2023; the logic was present in the 6/15 campaign, but the functions were not called. These changes indicate that these features are being actively developed, so we expect more changes as the actors roll out and test these features.

System Profiling

The attackers now perform system profiling through the aws.sh scripts as well as other scripts delivered under certain conditions. Another new feature is the get_docker function, which checks if the environment is a Docker container. When it is, the function runs docker inspect against each running container and saves the result to $CSOF. The output will not necessarily have credentials and this likely serves as a mechanism for system profiling.

Additionally, the new version added the function get_prov_vars, which calls cat /proc/*/env* to collect environment variable details from each running process and writes the result to $CSOF. The actor likely does this to enumerate other valuable services running on the system for manual targeting.

We also observed profiling activity from Data.sh, a post-exploitation script that collects details from the system and sends it to the attacker’s server. The script uses Bash to craft a web request to download the curl binary from the attacker’s server through the bashload function. This is notable because attacks against minimal systems–such as containers–can be limited by the absence of ubiquitous binaries like curl.

The attacker sets variables for a lockfile and datafile in /var/tmp. The result of the following reconnaissance commands is written to the datafile:

The script then sends the results collected in the datafile to the C2 using curl with a provided username and password.

Credentials Exfiltration

After collecting and processing the credentials, the credentials stealing scripts use curl to exfiltrate the contents of the $CSOF file to an AnonDNS-hosted server. The script contains hardcoded credentials that are used to authenticate the request. The June 2023 campaigns use the following username, password, and server URL combinations:

Propagation

In addition to the usual shell scripts, we observed the actor delivering a UPX-packed, Golang-based ELF binary. The binary ultimately drops and executes another shell script that scans an actor-specified range and attempts to propagate to vulnerable targets. We believe the reason the actor used this binary to deliver yet another script is due to the relatively noisy nature of the scanning activity. The scanner is hidden as an embedded base64 object within the packed Golang binary, adding more stealth than a standalone shell script. Additionally, the binary drops Zgrab–a Golang network scanning tool–which depends on Golang environment variables that are set by running the parent Go binary.

The implemented code enables the binary to read a command from a string and execute it using os_exec.

The main_main function decodes an embedded base64 blob, resulting in a Bash script that is written and then executed by the main_runCommand function. In the embedded script, the setupsomething function downloads the following packages on systems using the Yum package manager:

• Compiler and code processing: gcc make git jq
• Network utilities: libpcap libpcap-devel curl

This function also downloads the following packages on systems that use the Apt package manager:

• Compiler and code processing: gcc make git jq
• Network utilities: libpcap0.8 libpcap0.8-dev masscan curl

Next, setupsomething checks if masscan, docker, and zgrab are installed. If not, the script downloads the dependencies from the attacker’s server, hosted at the URI: /bin/[bin_name].

The dAPIpwn function takes the following arguments:

• IP range: collected from the C2 server at /gr.php
• Ports: 2375, 2376 – respectively used for Docker unencrypted and encrypted communications
• Rate: 500,000 packets per second

The function passes these arguments to masscan, which scans the specified IP ranges then passes the results to zgrab, which looks for http responses from the remote endpoint /v1.16/version. The output is filtered using grep to search for lines containing the strings 'ApiVersion' or 'client version 1.16'. Aqua also detailed a step in the attack chain that looks for misconfigured Docker daemons running version 1.16. Interestingly, a Shodan search revealed only apparent honeypot systems responding with these strings on the specified ports.

When a system is deemed vulnerable, the script calls back to the C2 using curl with the vulnerable IP address and port added to the request URI.

Conclusion

This campaign demonstrates the evolution of a seasoned cloud actor with familiarity across many technologies. The meticulous attention to detail indicates the actor has clearly experienced plenty of trial and error, shown in choices like serving the curl binary to systems that do not already have it. The actor has also improved the tool’s data formatting to enable more autonomous activity, which demonstrates a certain level of maturity and skill.

While AWS has long been in the crosshairs of many cloud-focused actors, the expansion to Azure and GCP credentials indicates there are other major contenders holding valuable data.

We believe this actor is actively tuning and improving their tools. Based on the tweaks observed across the past several weeks, the actor is likely preparing for larger scale campaigns. The lack of threats explicitly targeting Azure and GCP credentials up to this point means there are likely many fresh targets. The current focus on Docker is ultimately arbitrary: this actor has previously targeted other technologies and there are many other oft-forgotten vulnerable applications.

Organizations can prepare against these attacks by ensuring that applications are configured properly and patched as security fixes become available. Docker access should be restricted to suit your organization’s needs while reducing exposure from outside connections.

Indicators of Compromise

Monero Wallet address, C3Pool XMR

43Lfq18TycJHVR3AMews5C9f6SEfenZoQMcrsEeFXZTWcFW9jW7VeCySDm1L9n4d2JEoHjcDpWZFq6QzqN4QGHYZVaALj3U 

Domains

ap-northeast-1.compute.internal.anondns[.]net
everlost.anondns[.]netsilentbob.anondns[.]net
everfound.anondns[.]net

IPv4s

207.154.218.221
45.9.148.108

URLs

http[:]//silentbob.anondns.net/bin/chattr 
http[:]//silentbob.anondns.net/bin/a 
http[:]//silentbob.anondns.net/cmd/grab.sh 
http[:]//silentbob.anondns.net/cmd/clean.sh 
http[:]//silentbob.anondns.net/cmd/aws.sh 
http[:]//silentbob.anondns.net/cmd/xc3.sh 
http[:]//silentbob.anondns.net/bin/sysfix/curl.full 
http[:]//silentbob.anondns.net/bin/chattr 
http[:]//silentbob.anondns.net/insert/gscat.php 
http[:]//silentbob.anondns.net/insert/tmate.php